Qubes Manager Decomposition for Qubes 4.0 #2132
For Qubes 4.x we would like to radically simplify the UX of Qubes OS, by hiding as much Qubes internal infrastructure (e.g. net/usb/firewall VMs) as possible, and by making the UX more coherent, and less confusing. One of the culprits of the current UX model is our infamous Qubes Manager. We would like to decompose and simplify it for Qubes 4.0. This ticket describes how I see this being done.
First we should observe that currently Qubes Manager is (confusingly) used for two different types of interactions/tasks: 1) those that involve creating or modifying the persistent configuration of the system (e.g. creation or removal of new AppVMs, setting their properties), and 2) those that involve observing or modifying the ephemeral state of the system (e.g. checking which VMs are running, stopping them, attaching devices to them). This confusing mix of duties is made worse by the fact that the user is expected to launch applications via the "Start Menu", which is not part of the Manager. I saw many users who looked into the Start Menu in order to create a new VM, as well as into the Qubes Manager in order to start an application...
So, we would like the next-gen manager for Qubes 4.0 (which we need to rewrite anyway because of the changes in the core-ng) to be essentially a widget for ephemeral system state observation and management (e.g. stop/restart/kill AppVMs). In other words the Qubes Manager should provide an answer to "What is currently happening with my Qubes system". And also allow some ways to fix/change this current state (e.g. stop VMs, start updates).
Practically-wise I imagine this to be a simple widget for the Xfce4 panel, just like e.g. audio mixer, or clock, and located in the top main taskbar somewhere to the far right, next to all the other icons/widgets for ephemeral state monitoring (network, clock, audio mixer, tray icons, etc). Here's an example screenshot to help your imagination.
This means that when the user clicks on the Q icon for this widget, a drop-down list of the running VMs will appear, potentially also showing other info, such as CPU/MEM resources, and also presenting buttons to shut down each of the VM.
This list should primarily show user AppVMs and optionally (if enabled in config, and in different color, e.g. grayed out, or after a separator - TBD) the system VMs (net/usb, firewall, tor, perhaps templates).
All persistent actions related to VM configuration, such as changing their template, netvm, etc, should be accessible through the appmenu via the Start Menu. In fact we're already exposing this way of modifying VM settings, via the "Add more shortcuts" appmenu for each of the AppVMs. This appmenu should now be called "Settings..." and should open the same window as today, only focused on the Basic Tab, instead of on the Applications tab. Additionally we should add "Delete this AppVM" button to the Setting dialog box.
We need a few more appmenus, for actions which operate on the global system configuration. These are:
Creation of all the above appmenus is trivial and requires essentially creation of a .desktop file which calls the already-implemented dialog boxe from the current manager (which we might later rewrite or not), and updating the Xfce4 main menu.
The QM widget should also handle device attachments to running VMs. I think the best way to implement this would be by having an additional (additional to the 'Q' icon which pops up the list of running VMs) tray icon appearing whenever there is at least one device to connect (this might be either a block device, or USB device). In that case a dropdown list with available devices and their assignment (similar to a combined output of
Two UI-related rules we would like to stick to:
Compact list of things to do:
The text was updated successfully, but these errors were encountered:
Additionally should display status/messages from the Health Monitoring Deamon (#2134). E.g. updates available (and offer a button to click), or "unrecoverable program with one of your system VMs, please restart the system".
Additionally the actual icon in the panel (the 'Q') might double as global security status indicator: green - all good, yellow - something's not ok (e.g. proprietary BIOS used), red - insecure configuration (e.g. VT-d not present or enabled, USB controllers or Network devices assigned to Dom0, etc). This is essentially implementing (the UI frontend part of) #6.
I have been forming some ideas in this general direction. Perhaps a column of start/stop buttons next to the vm names in QM? Or 'update available' icons that become buttons when appropriate to launch updates.
Also, since vm / application often become synonymous in the Qubes workflow (e.g. "I need this app, so appvm X starts to run the app, but quitting the app does not provide an opportunity to quit the vm") then maybe more can be done to make this convenient. Although monitoring of app processes from dom0 doesn't seem likely, some alternative to the regular 'close' widget may be both easy to learn and implement. My first thought is to use a modifier key along with the close widget to mean "stop the vm along with the app".
What complicates this is that Linux is bad at handling app run cycles to begin with. Although services get red-carpet treatment, user-facing applications are routinely obliterated on system shutdown, for instance. Apps that do a bit of routine maintenance on shutdown may close their windows some time before exiting. So there is a question of how to synchronize behaviors between apps and vm management functions to improve UX.
On Mon, Jul 04, 2016 at 02:57:24PM -0700, ttasket wrote:
This is already discussed here:
Generally the idea is to detect if the VM is "inactive" from inside of
After reading @rootkovska post. I did some thinking about the UI & workflows a user has and how to lower the barrier for usage of QubesOS. This is what I come up with, sorry that it's so lengthy, please bear with me.
First let me define some vocabulary: Allow me for just this post to introduce the word Space. The words Domain and AppVm/TemplateVM are loaded with too much of technical meaning, which is not interesting to the basic user™.
Space is a bundle of Apps you use (Firefox,OpenOffice,Xterm) to do some Activity (work, banking, image editing, anti NK propaganda), the Data you need for that and the Network Access. There are other Spaces, were you do other Activities, connected to other networks, but Qubes uses all technical abilities to keep them separate. I hope this vocabulary will us help concentrate on what we really want to show to the basic user.
Not basic users:
Any one who says: “…but Fedora-23 sucks because $REASON…”. If you think you are capable to judge a GNU/Linux Distribution, then congratulations you are not a basic user any more. The needs of this users should be taken care off, but we can assume that this users are capable reading the manuals, documentation or in app help. Of course All the options known from R2 & R3 should be there for the power user, but hidden for the basic user.
1. A Preferences App
I actually have no opinion on that, because I don't know how much do we think that the basic user understands the concept of NetVm, ClockVm, TorVm, RAM and so on… May be we can keep it complex, because we assume the basic user will never need to fiddle with it? Can we make sure that the basic user never needs to change the settings?
2 Add Space App
This is as simple dialog screen for creation and customization of the users space. The user has to enter the following values:
I would even go as far and propose that once a Space has a Network Connection assigned, it SHOULD NOT be possible for the user to easily change the Network Connection, because this can leak information in form of i.e. Firefox Cookies.
In a tab, or hidden to be shown on request we complement all the other settings provided by the current qvm-create dialog and may be some more options like storage. Here you could manually set the preferred NetVM, even if basic usage doesn't allow it.
2.1 Add Apps to Space
A dialog screen for adding and removing Apps to a space. Just Left Colum ←→ Right Column.
This should be called directly after new Space creation, but can called from the Q-Menu → SpaceName → “Add Apps to Space".
Future Advanced Options
Add package names which will be installed by package Manager. Under the hood a new TemplateVM based on the default fedora-23 is created and the App is installed, and the new TempateVM is assigned as template to the AppVM of the current Space. We can do this because volume snapshots are cheap in R4.
3. A Backup App
For a Backup App the following bits are important for the basic user:
Spaces to backup
A list of Spaces by default all are selected, to back up.
Backups is about saving your work, which is in Spaces. The backup system should be smart enough to figure out when to backup which TemplateVMs and which templates could be easily recreated from other TemplateVMs (see above) and only backup the bare minimum.
User has to choose How often to back up & How long to keep old backups.
The user SHOULD be able to trust the scheduling. We could try to do live backups of running VMs, assuming that we use LVM Thin by default, this should workout fine at least from qubes storage perspective. If we can't do backups of running machines, we should check if i.e.: xscreensaver is running, if so just suspend all the running machines, force them write to disk, backup-up and resume the machines.
User chooses Backup location & Folder. Available Backup locations:
This part needs to have a good API so we can plug different Backup Implementations. Behind the scene the backup mechanism creates an AppVM appropriate for the chosen backup method, which mounts the Network or Device and awaits data.
Restore specific Spaces
Chose Space → choose date → Go!
Chose date, Check the check box Restore System Configuration → Go
I count as System Configuration the following:
4. App Store
The user chooses an App and installs it. After Installation he can choose to which Spaces he adds the App.
The current QubesOS Storage system allows the creation of a very specific kind of volume. A volume can be snapshot at start of a vm from a source (Think AppVM root snapshots). A volume can also saved when the vm stops (i.e.: a private image of an AppVM or the root of the TemplateVM). An interesting side effect is that you can define a volumeB with a source volumeA, which on start makes a snapshot of the source A, but on the shutdown it saves the changes to disk as volumeB.
So imagine you have
dnf groupinstall “Development Tools” -y if [ -d /home/user/qubes-builder ]; then git clone $URL /home/user/qubes-builder && chown -R user:user /home/user/qubes-builder fi
If the user adds “Qubes Development Tools” in the “Add App to Space”-App to a Space behind the scene the following is happening:
Of course it's not a set in stone solution, just my mentioning of what can be achieved with the tech which is already available.
5 Other Important bits
5.1. Storage Management App
5.2 Space Manager
The basic user sees here by default all active spaces in a table (grid). Active means they waste resources in some way. He can “close them”. He also can view here all his other (inactive) Spaces.
(Reasoning: Tables are good, people understand Tables. See abuse of Excel)
This is the place to observe the ephemeral state of the system. This is the counterpart of
This should be the replacement for the body part of the current
Both grids (Space and VM) should be reusable. Use the Space Grid allowing the user to choose the Space in basic mode, show the VM Grid when in Advanced views.
5.3 Audio/Video Managment
Tasks to be accomplished by the user: assign microphone, Webcam and mute a Space While this should be available from the Space Manager, for day-to-day usage the user should use a small widget integrated in the xfce-panel.
I hope I have not forgotten anything. This is what i come up with, thinking about this thread and reading the source code of
I also don't insist on using the word Space, it's probably patented by some cloud company anyway
If we the list of Apps makes sense, we should create dedicated issues and discuss the different Apps there.
Most of the irritation in using Qubes comes from having to interact with task manager and window manager and launcher and VM manager separately. In particular, closing an app often entails the extra step of going to QM to issue a shutdown command. Breaking up QM functions can serve to alleviate this... but we might have to go as far as offering task management functions as well. It might even be less work and more user-accessible to instead extend existing task manager a bit to handle Qubes use cases. We can't keep task and window and vm management separate and expect praise for UX.
Also, keeping in mind that windows are the fulcrum of the Qubes UI--providing security context seamlessly with window management--we may want to add a vm-management function or two to the titlebars. The vm name/identity is right there, so why not? How else do users normally do task management? A: Via the window gadgets. This could be key.
FWIW, I don't think the term 'vm' is much of a problem apart from the far-off day we may see a non-hypervisor implementation of Qubes. Picking an often-used DE term like "space" with no isolation connotations as a replacement could increase confusion. The main problem is that adjectives denoting the vm types are incomplete (and a little misleading). "Netvm" is a misnomer when its used to denote the setting for an upstream interface. Meanwhile "standalone" and "HVM" overlap with most other descriptive lables and we use them imprecisely. There is a certain amount of irreducible complexity here, unfortunately. It could be the subject of a style guide and also forum etiquette.
FOSS distros almost always make their problems worse when they assume interfaces must be either "for grandma" or "leet h4x0rs"; the results are there for all to see. A balance must be struck in the easiest interface modes, lest a project descend to the sort of idiotic experiments circa 2005 where even browsers tried to banish location bars (the term "domain name" is not for innocent eyes). The sad thing is this spilled over into production software and we see it still; For example, browsers removed important visual context in the form of the status bar so that hovering over links now displays the target URL on the page canvas. These aberrations planted seeds of diminished security.
We certainly do need to assume the user can read manuals and howtos... and in the process learn terms and concepts that are meaningful. They need to learn some of the language that describes context, in addition to the usual PC and internet stuff. Good PC interfaces have always been about moderate learning curves and UIs that make features discoverable. That discover-ability causes people to ask questions which can seem inconvenient to us; some projects actively discourage this quality so they are not bothered. Something to keep in mind while going forward...
While we're talking about "burying QM" its worth noting that the ultimate direction things could go might just as well elevate QM to an all-encompassing status, in a ubiquitous mode such as a panel. This seems especially true given QM already has a certain degree of app management built into it. Adding launcher functions would be no stretch at all.
Combined with window widget/hotkey access to shutdown/pause/prefs functions, that leaves two focal points for managing windows, apps and vms together. The only things that wouldn't be integral are functions like backup/restore. I can easily imagine this as a winning combination.
Or perhaps a glossary? :)
While we appreciate that everybody has an opinion on how a UI/UX should looks like, we also recognize that almost everyone see this differently. I'd thus like to ask anybody commenting in this ticket to provide direct response to the original message I posted. Rather than writing essays on how they would like to do that. Or we would not get anywhere.
Also, I'd like to ask everybody that we save our grandmas, mothers, wives, sisters, and daughters (as well as all other members of our families, or other groups of people) the doubtfully prestigious roles of models for "non-technical" and/or "absent-minded" users.
Even if one considers their mother or sister to be indeed such a damn good example of a less advanced person in the art of Linux KungFu than themselves, please, please, use the correct term, such as... "non-technical user", or "absent-minded user" instead.
I'm sure every Linux wizard will be given dozens of other opportunities to prove their supremacy on the Command Line over the mere mortals like their mothers or sisters, outside our ticketing system, mailing lists, or Website documentation, or other resources.
I agree. Thank you for the reminder. I try to live up the CCC Hackerethik, which states: “You should only judge humans but what they do and not their looks, age, gender, species…”, but I'm sorry if I offended you(?) . I will replace mother & Jeff with genderless Alex & Sam, if you are okay with this.
The objective of the narrative was to make the more technical minded people understand, that there are humans who just want to get their stuff done and who are not interested in understanding all the VM magic behind the scene. IMHO good examples of average people to which you can relate can open eyes to the some other minded people. Which IMHO is important when talking about human interfaces, on an openly accessible ML/Ticketsystem where every one can respond and has an opinion.
I like this idea for advanced users:
it would be nice to have something like:
I think it is important to have a powerful solution for advanced users. I know it seams a little bit off topic, but issue is also about UI/UX simplification. I think all users are important and should have a tool to get their work done.
Everything that should work works. Further improvements that would be nice: - replace untidy multitude of QtGui Items with one generic type - restore Qubes Network functionality - add Boot From Device action (and easy way to install windows tool from there) fixes QubesOS/qubes-issues#2966 QubesOS/qubes-issues#2132
I guess this has been in the pipeline for a while, but t's hard to convey how big of a disappointment this news has been to so many of us enthusiastic Qubes users (and evangelists.) Not just of the loss of the Qubes Manager (yes, I know it's been brought back in a more limited form "by popular demand"), but the news that this is apparently the long term UX goal that will be aimed for.
Right now, the underserved segment of tech users are the power users. These are the people who understand what VMs do and roughly how they work, but do not know enough of the details, or have enough proficiency on the command line, to quickly see everything that needs seeing and do everything that needs doing.
It is possible to cater to these users--who are a massive part of the Qubes fanbase and are getting the word out there (for whatever that's worth)--without "confusing" people. To a power user, it is not at all confusing to have a list of all VMs with their configuration, their current state, and ways to alter or connect them easily at their fingertips. What is confusing is being told that we have to go hunt down a different part of the UI to do what needs doing. Why? If we know that a VM exists, we want to be able to look at a list of VMs, find it, click on it and do that thing, somehow. We're not fussy on how it gets done. Left click instead of right click, sure. And perhaps in the name of UNIX-y modularity, another GUI program could be launched as a result. But a requirement that I be aware of, track down and use a totally separate GUI to interact with the VM I'm staring a...?
Do you know what the UX feature that power users have appreciated the most in the past 10 years, the thing that gets the most mileage? It's that little box in the start menu (or equivalent) that searches for and suggests the program you're going to launch or the setting you want to alter. And that's because it does EVERYTHING. "I know exactly what I want to do... just tell me where I can relay that command to the OS!"
I've a tremendous amount of respect for the philosophies and the finished products that have come out of Rutkowska and the rest of the Qubes team (years before hearing about Qubes, I'd actually hacked together something superficially very similar using Virtualbox's "transparent desktop" feature, with different colored windows in each VM) but I believe that information hiding can be done without alienating the power users. It would be more work, probably. Every new demographic you cater too is more work. That is an inescapable fact of life, and obviously your time and money is limited. So if it is a tradeoff, I can only say, maybe just ask yourself... how important is the NON-power user demographic to you right now?
I've been pushing Qubes as the greatest thing since sliced bread over on Slashdot. Emphasizing how easy and intuitive it is; how it occupies that magical middle power-usery ground where you don't need to be so concerned with the specifics of how things are done, just knowing the 50,000 foot view is enough to get a lot out of it. They don't make distros like Qubes any more. I don't just mean there aren't other secure hypervisors out there; they don't offer UXes that occupy that wondrous middle around that so many of us part-time geeks are trapped in. Instead, everywhere we look the UXes have become extremely polarized: everything is either dumbed down into oblivion or requiring a CLI pipe proficiency that I never had the time to develop.
Do you understand how frustrating it is to be informed enough to know EXACTLY what you want to see or so but not be able to easily configure it? To not have enough hours in the day to become the highly proficient masters we'd all prefer to be?
I understand and even agree with many of the specific issues with the Qubes Manager, but the big picture verdict and philosophy sounds very disheartening. It is not "confusing" to us to have a centralized way of viewing and interacting with all of the VMs any more than the little search box in the start menu was confusing.
You guys do what you have to do, and I really can't applaud you enough for everything you've already done... but on behalf of all power users everywhere, I just felt like I need to make that detail perfectly clear.
@RefinedSoftwareLLC 1th better to archive with simple command line script at dom0.
2th Such a command is present (salt, the same command executed on setup). But unfortunately I don't remember it. @andrewdavidwong please, place it to update docs.
But I agree with all speakers: MS Windows 7 support and Visual Qubes Manager is critical to regular user. My Qubes Manager daily use: find vm -> Run command -> "gnome terminal" (QM must support run terminal by default). Second, I use it to change settings, stop/run.
I'm not aware of such a command, but I'd be happy to add it to the documentation if someone who knows it can provide it.
See readme here for the list of states. You can apply a single state with
@andrewdavidwong Can you include @marmarek 's how to use explanation along with the list of states. With the addition of running from dom0 and using sudo. "From dom0, you can apply a single state with