qubes-issues
qubes-issues copied to clipboard
QubesOS
Redesign Qube Manager
Problem
Qube Manager has multiple usability issues.
Solution
What user needs are and how this tool can better suit them—or, a different tool altogether—needs to be explored in user research. Then, a solution needs to be designed, iterated upon, tested with users, iterated upon further, and finally implemented. Implementation funding exists, but does not yet exist for the UX design and research work necessary to craft the best possible solution.
TL;DR, get this funded and happening. This issue will be used to track progress on the design and user research, once funding comes through (and to whatever extent possible, sketches that may be done by the community or before funding is approved) :)
Related Issues
#5678, #1870 and related project
Question for @marmarek: What exactly are you envisioning for a Template Manager? How could it provide value for users that today's Qube Manager does not? (asking because I don't know and want to learn, not because I question the flagging of it as a need)
Main (missing) function is easily discover and install new templates. Then, managing which VMs use what template - but this function we already have in the current "template manager".
In addition to general template discovery and install, one common use case I see for it, is to easily update to a new template version. Say, you have fedora-30 and fedora-31 came out - the tool should allow you to easily install fedora-31 (missing step) and then switch your VMs to that template (implemented).
Main (missing) function is easily discover and install new templates. Then, managing which VMs use what template - but this function we already have in the current "template manager".
In addition to general template discovery and install, one common use case I see for it, is to easily update to a new template version. Say, you have fedora-30 and fedora-31 came out - the tool should allow you to easily install fedora-31 (missing step) and then switch your VMs to that template (implemented).
Including custom packages that were installed by the user (or specified at the time you do this)? Or do most users not do this?
I try to keep my Fedora templates up to date. I always upgrade my existing template VMs (not create new ones from scratch). Since I've started useing QubesOS I had gone through 3 OS version updates on all of my templates (each with a diffrent set of packages) and had no issues so far (except once, with qubes-pulse-audio, but that got quickly resolved).
I'd love (as a user) an automated tool to perform the upgrades. It's the same set of commands to run both in dom0 and target VM and if you follow the best practices you have a seperate template for each domain/security concern, which means to upgrade you need to repeat this process for several template VMs (in my case, 8).
@ioleo Thank you for sharing the insight! Would you be open to doing a proper user interview to inform future design work, sometime?
@0spinboson We "know" nothing, but I'd love to schedule an interview you to hear how you use Qubes and what your needs might be!
Clarification: All knowledge to date about how folks use Qubes, is anecdotal. That's not a dismissive against what Marek and team know of their users—they're deeply, deeply engaged in user communities, which is awesome and wonderful.
The human brain can only retain so much knowledge, however... and when the collection of knowledge can be structured, qualitative data can be much more accurately measured—and quantitative measures to clearly discern value between all the variables, is possible. Conversely, when it's all "Marek remembers these things from 5 years of community discussion" only the vocal minority stand-out in his head... and, some things can be naturally forgotten or overlooked, because—well, the brain is fun like that.
I'm hoping to get some proper user research funded this year, which will pay for "proper" collection of user insights and data. "Proper," meaning it'll be objective and reach deeper into the community of users, than simply who is comfortable piping-up in a bbs, vs who isn't.
Honestly I'm happy with Qubes Manager; usually my legs shake when some UI acolyte pops up talking about "usability issues", because that means the current UI made by a developer proceeeding from tech needs/limits to use cases, could be soon reworked by a WebMaster going from eyecandy to use cases while being totally unaware of the inner workings of the underlying tech. Ending up with a shiny, polished, bloated and slow interface unable to accomplish the simplest tasks and control the small details... Gnome&Ubuntu docet (and both left behind bad casualties, like WMMaker and Compiz).
That said, the only thing I feel the lack of ... is to be able to hide/show some of the VMs (ex: hide/show templates, hide/show red VMs, etc). As the list-view can become pretty long and messy, and browsing it multiple times pretty time consuming, without a tree-view or hide/show features.
Side note. The same applies to the system menu: I don't need the templates listed in the menu as templates apps are not meant to be run from the menu (and I usually just "run command in qube" from Qubes Manager, most of the times the only thing needed to run in a template is xterm, gnome-terminal or xfce4-terminal). Moving the files out of usr local share applications (and the same user home directory) is an option but takes long time to identify the correct .desktop file for EACH app of EACH VM.
@mfp20 Don't worry, I'm not a webmaster and while visual design is a competency area of mine, my own bias is towards functional usability and empowering users. Qubes users trend towards highly technical security folks, and I enjoy the challenge of making something intuitive enough for my parents but that also delights CLI users.
Anything that could slow the system to support visual whiz-bang would also be a bad thing, as that kills the user's experience. You can have aesthetic polish w/o GPU or CPU strain, overuse of glowy-effects, etc. Order, not chaos, is the goal. Lightening the cognitive load, etc.
Thank you for the rad feedback, it's all inline with where my own priorities are, and with where the Qubes team's (Marek and Marta and Andrew, etc) interests are. :)
@ninavizz eheh, I didn't call your name, I didn't know your competency area. I'm more worried now than before :)
(just kidding, not worried at all, I just dropped my two cents; I'm actually happy someone is reworking the UI: after the functional parts are working, there's always the need to polish the resulting UI, and I had myself some thoughts about this on qubes in the past weeks)
About an intuitive/CLI compromise, i3 is already there with minimal (good) integration scripts. A bit more love for i3+dmenu+systray integration scripts and the right compromise could be here without too much effort to be spent. I've been experimenting a bit and doesn't seems too far away, as most of Qubes Manager functions can be triggered from console and the syntax is pretty coherent across all the qubes tools. I'm new to qubes and pretty far from owning it; having a pretty good default UI, moves the i3 wish down my TODO list. I hope I'll be able to contribute back something ASAP...
Having some i3+dmenu VM management scripts makes Qubes Manager less important. And i3 is way lighter in RAM than XFCE. From my perspective, this makes i3 an obvious choice for a RAM-huge system like Qubes OS tend to be.
@ioleo ...a friend just shared this, and I thought of your comment. Not sure if you're in the US or not—if you are, and ever on social media, then hopefully you'll get the humor.
About an intuitive/CLI compromise, i3 is already there with minimal (good) integration scripts. A bit more love for i3+dmenu+systray integration scripts and the right compromise could be here without too much effort to be spent. I've been experimenting a bit and doesn't seems too far away, as most of Qubes Manager functions can be triggered from console and the syntax is pretty coherent across all the qubes tools. I'm new to qubes and pretty far from owning it; having a pretty good default UI, moves the i3 wish down my TODO list. I hope I'll be able to contribute back something ASAP...
Having some i3+dmenu VM management scripts makes Qubes Manager less important. And i3 is way lighter in RAM than XFCE. From my perspective, this makes i3 an obvious choice for a RAM-huge system like Qubes OS tend to be.
@mfp20 Sounds like you are looking for something like qmenu.
So far, I think that the propositions made by ninavizz are really great and, in my opinion, there is a lot that can be improved regarding Qube Manager and application menu UX. I would argue that the murophobic crowd can not be satisfied by Qube Manager without the risk of it becoming a design mess, trying to cater to every user while users like me are annoyed because something takes a ms too long. I hope that in the future, qmenu-vm can become a satisfying alternative for these users while Qube Manager can be steadily improved to fulfill its purpose. (Eye candy would still be a terrible sin of course.)
About an intuitive/CLI compromise, i3 is already there with minimal (good) integration scripts. A bit more love for i3+dmenu+systray integration
@mfp20 Sounds like you are looking for something like qmenu.
Yep, that's the love I was looking for! Thank you dude!
So far, I think that the propositions made by ninavizz are really great and, in my opinion, there is a lot that can be improved regarding Qube Manager and application menu UX. I would argue that the murophobic crowd can not be satisfied by Qube Manager without the risk of it becoming a design mess, trying to cater to every user while users like me are annoyed because something takes a ms too long. I hope that in the future,
qmenu-vmcan become a satisfying alternative for these users while Qube Manager can be steadily improved to fulfill its purpose. (Eye candy would still be a terrible sin of course.)
Agreed. I disagree about the "eyecandy sin": I'd like to see Compiz's cube back, Qubes Manager permanently glued on the start face of the cube, and qmenu on the shortcut when that face is in light. The other faces customizable like workspaces. I tried to resurrect compiz a few months ago and kind-of worked but ... it was like soldering a floppy disk cable to an Arduino in order to have an USB 3.5 floppy disk drive.
P.s.: I love my mice. But I prefer to pet my mice in games only :)
The main thing that bugs me with the current manager is that I keep on resizing the columns so they fit my names.., I prefix them so I can order them by group.., or by used network.
And a very minor nuisance, is that visually I don't enjoy the 'state' icon being left-aligned instead of centered.
Just posting here something @bnvk did a good while ago @ninavizz. I'm not sure I dig the design, but since another designer did something around it, it might be worth mentioning. Took it from here. The repo also includes other ideas for the qube manager.
Thank you @deeplow! Kinda going to start from scratch by learning more about user needs and problems, before digging in too much.
Hi, (Not sure if discuss here or start another issue)
I would like to add more functionally to Qube Manager directly handled from the main window, I will put some ideas here like a brain storm before doing anything:
- [ ] Change VM names with double click on 'Name' cell (it will show a confirmation dialog for avoid errors)
- [ ] Change NetVM/Templates/Default DispVM for use directly a ComboBox when click on the cell
- [ ] Include in backup should use a Checkbox instead Yes/'' and using this checkbox you can directly add or remove VM's from default backup
- [ ] As said: https://github.com/QubesOS/qubes-issues/issues/6169#issuecomment-722306918 Directly backup single or multiple VM's using context menu
- [ ] Add options for change some settings (especially Template) in the context menu. This will be useful for editing many VM's at once using multiple selection
- [ ] If previous works fine, totally remove current Template Manager
On the other hand it will nice to add some kind of 'Tree View' which will group the the VM's in Templates, Network, System, AppVM's...
Maybe would be nice to define the labels in some levels of trusting instead simple color names. (E.G. black -> Vault, green -> Trusted , red -> Untrusted...) and you could just change it drag&dropping some VM from one group to other.
Those are great suggestions @donob4n TY for sharing here! Will totes keep in mind. Yeah, "Template Manager" as a different thing from "Qube Manager" makes little sense to me. If it's a template, it should have the options for managing templates; if it's an app qube, it should have options for an app qube.
Well I see it as a workaround for changing multiple templates at once when there was no easy alternative.
I will start working on it.
Change VM names with double click on 'Name' cell (it will show a confirmation dialog for avoid errors)
I would rather avoid it. Changing a VM name is a heavy operation with many side effects (changes to menu, VM disks, references in other VMs), some things may even be lost on rename (for example currently qrexec policy - https://github.com/QubesOS/qubes-issues/issues/5147). There are also non-trival rules when VM can be renamed - for example it cannot be running, but also for TemplateVM, none of VMs based on it can be running. So, I'd rather discourage from renaming, than making it simpler.
As said: #6169 (comment) Directly backup single or multiple VM's using context menu
There is one important details about the current backup format: regardless of what VM you choose to include, the backup archive always contains metadata of all the VMs. Having a "backup this single VM" option may suggest otherwise and lead to unwanted information leak - as it may suggest it is the right way to share a VM with another person. It is not. Details: https://github.com/QubesOS/qubes-issues/issues/1747#issuecomment-226048972
If previous works fine, totally remove current Template Manager
In the current form of "Template Manager" - yes, I agree, it very much makes sense to integrate this functionality into Qubes Manager.
There is also upcoming "Template Manager" that does more like its name suggests: manage (install, remove, update etc) templates. It's here: https://github.com/QubesOS/qubes-manager/pull/258
Otherwise, those are great ideas, and I'm really grateful about your contributions to the Qubes Manager!
Change VM names with double click on 'Name' cell (it will show a confirmation dialog for avoid errors)
I would rather avoid it. Changing a VM name is a heavy operation with many side effects (changes to menu, VM disks, references in other VMs), some things may even be lost on rename (for example currently qrexec policy - #5147). There are also non-trival rules when VM can be renamed - for example it cannot be running, but also for TemplateVM, none of VMs based on it can be running. So, I'd rather discourage from renaming, than making it simpler.
I agree that double-clicking on a qube's name should not prompt to rename. It would be more intuitive if double-clicking on a qube's name started that qube or brought up the Qube Settings window for that qube. (It currently does nothing.)
However, I'm not sure I agree about discouraging renaming. There are many situations where I find that I must rename a qube, and there is no other good option. For example, If I need to re-recreate a qube and keep the same name, I have to rename either the old qube or the new one. However, in such situations, the fact that RPC policies and launcher shortcuts don't change when I don't touch them is actually a feature for me. It's more convenient, because it allows me to re-create a qube, reuse the name, and not have to mess with the RPC policies or launchers.
If previous works fine, totally remove current Template Manager
In the current form of "Template Manager" - yes, I agree, it very much makes sense to integrate this functionality into Qubes Manager.
Agreed!
Yes, there are cases when rename is useful, sure. I'm not proposing removing this feature. I'm proposing keeping it where it is (VM settings), and not adding it to the main window.
Change VM names with double click on 'Name' cell (it will show a confirmation dialog for avoid errors) I would rather avoid it. Changing a VM name is a heavy operation with many side effects (changes to menu, VM disks, >
Ok. @andrewdavidwong idea seems better, start or open settings dialog.
As said: #6169 (comment) Directly backup single or multiple VM's using context menu There is one important details about the current backup format: regardless of what VM you choose to include, the backup archive always contains metadata of all the VMs. Having a "backup this single VM" option may suggest otherwise and lead to unwanted information leak - as it may suggest it is the right way to share a VM with another person. It is not. Details: #1747 (comment)
Well, this could happen with standard way too (I had no idea about it). Maybe we should warn in some backup dialog.
Otherwise, those are great ideas, and I'm really grateful about your contributions to the Qubes Manager!
Thanks, I'm glad to help.
Well, this could happen with standard way too (I had no idea about it). Maybe we should warn in some backup dialog.
I wouldn't want to end up a hundred obscure warnings all over Qubes that only a fraction of users will understand. Perhaps just a general warning to keep your backup passphrase secret (which precludes using backups to share qubes, along with a bunch of other things).
Uff do you think it would suppose some important advantages? Ask @WillyPillow , he started the new 'Template Manager' with gtk and rewrote to qt :crying_cat_face: .
Uff do you think it would suppose some important advantages? Ask @WillyPillow , he started the new 'Template Manager' with gtk and rewrote to qt :crying_cat_face: .
Well..less Qt because Qt!? Ok this is not an argument just less libraries just for Qt stuff for Manager :)
I'd LOVE to see QubesManager redesigned, but it's also important to do design iterations via wireframes, critique iterations, do user testing, and to consider ways to make things intuitive w/ best practices abreast factoring-in necessary impact checks (such as how to archive or rename a qube).
I also feel that what is currently done in "QubesManager" should be part of a broader settings/management experience/framework that would include a policies GUI, a way to make mass template updates, etc.
Changing libraries/codebases entirely at this point, doesn't feel prudent—unless a design direction merited it. I'm not a huge fan of GTK, but if its library could meet the needs of what's considered a solid design direction for Qubes Manager, than awesome!
I'm currently working on an AppMenu redesign, and somehow unifying more of the Qubes OS unique UI elements also seems like it'd be a good idea. The Devices and Whonix widgets (the latter, I realize was done by a Whonix contributor and is technically their code not Qubes') as well as the Updater widget, seem like the other primary Qubes UI touchpoints. Am I missing anything?
Mebbe instead of beginning this with code, post/share wireframes and mockups of what such an experience could resemble, and also to expose interactions that need a lot of love? Maybe schedule calls to do critiques, too?