Consider changing "AppVM" to "qube" for better UX

[bnvk]

I'm not sure if this is the right place to file what I consider UX bugs / improvements- if it's not, please tell me where else to do so :-)

I propose changing the root VM currently called dom0 to be called qubes as I wager it would be considerably more user friendly in testing. My reasoning is:

• It is less technical and jargony
• Does not introduce a new term a user must understand / remember
• Makes more logical sense "I installed Qubes OS on my computer, thus qubes is the main domain"

[marmarek]

I don't think this is good idea to name it qubes, because it can be
ambiguous. It will be even worse when we implement GUI VM (current
dom0 will be unaccessible to the user directly then). But we are
slowly moving to name AdminVM (currently you can see it as a type for
dom0).

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[andrewdavidwong]

I think Brennan's heart is the right place, but I have to agree with Marek. To elaborate:

1. a. "Qubes OS" refers to the entire OS, which includes Xen, dom0, and multiple domUs. If we start also referring to dom0 as "Qubes," then the term "Qubes" will be ambiguous between the whole OS and a single VM inside that OS.

   b. Joanna makes a distinction between "Qubes OS" and "Qubes." As I understand this distinction, "Qubes OS" refers to the whole OS which we currently have, while "Qubes" simpliciter refers to the Hypervisor Abstraction Layer (HAL), which is not by itself a complete OS.

2. Once dom0 is bifurcated into the GUIVM and the AdminVM, there will not be a compelling reason to refer to only one of these VMs as "Qubes" instead of the other, and it would be strange to refer to both of them as "Qubes," since then someone could say, "I'm having a problem in Qubes," and there will be three(!) different things they could be referring to.

[mfc]

sounds like we have agreement that it should be admin?

the thrust of this ticket is to change from dom0 which has no meaning to users and is a confusing term. There have been more recent in-person discussions about this with brennan, joanna and I think we all agree qubes is not the right term since that will be the future name for AppVMs most likely.

[bnvk]

I definitely think admin is an improvement over dom0 and per our in person chats... I think @mfc is referring to what we discussed at the usability work session at the OTF Summit, which was calling VMs in general a qube and in this specific case it would be the admin qube which seems pretty logical and decently intuitive!

[marmarek]

I don't think calling 'VM' a 'qube' is a good idea - this would make
virtually any non-Qubes documentation useless on Qubes...

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[adrelanos]

Marek Marczykowski-Górecki:

I don't think calling 'VM' a 'qube' is a good idea - this would make
virtually any non-Qubes documentation useless on Qubes...

I agree. I don't think this kind of complexity (term: VM) can be hidden.
We'd still explain somewhere, that a qube is a VM. So we wouldn't reduce
complexity, but add another term on top, qube. And thereby increasing
complexity.

[bnvk]

The concept of "qube" instead of "VM" was workshopped between
@mfc @rootkovska myself, and the SimplySecure team in DC. There
seemed a pretty unanimous agreement that it had the potential for
far more user friendly outcomes and that we could get much
mileage with icons, interface elements, and user friendly
storytelling.

Joanna, back this up here please, otherwise I'll drop the concept
(and stop working it into my website designs) and you all can
skip the rest of this and go on with your day :-)

this would make virtually any non-Qubes documentation useless on Qubes...

If you mean documentation on other projects, websites, etc. which
explain how VMs work- not necessarily. As long as we have short
sentences (throughout our docs) explaining "a qube is just a user
friendly term to represent a VM" I'd wager technical users who
like understanding what a VM actually is can handle one simple
metaphor.

I agree. I don't think this kind of complexity (term: VM) can be hidden... So we wouldn't reduce complexity, but add another term on top, qube. And thereby increasing complexity.

I think that's a fundamentally wrong assumption from a highly
technical user's POV. It can totally be hidden from
non-technical users. A VM does not need to be explained in the UI
via button names, terms, etc. Normal users will never need to
read / nor try to understand that a "qube" actually is a "VM"

Normal users never need to learn when they "connect to the
internet" or "go on the web" they are actually "making a TCP/IP
connection using the HTTP protocol to interact with to a
webserver". Or when they "access a website securely" they are
actually "doing public / private key cryptography using SSL /
TLS certificates." Yes, this admittedly dumbs things down, which
is entirely the point- it is essential for achieving a simple
"out of the box" UX for non-technical users. As long as honest
documentation & easy access to that technical information exists
for the curious / more technical, I don't see a problem here.

We have to think in terms of initial first impression of a user
when thinking of usability. Given the majority of users are
non-technical, is the term & concept of a "VM" helpful to anyone
if they don't already understand what a VM is? Would a user who's
never heard the term VM understand what a VM is? Furthermore,
would it make sense in the Qubes context after reading one to two
sentences? Almost certainly not. Therefore, eliminate jargon &
complexity and go for simple metaphors and try.

[mfc]

this would make virtually any non-Qubes documentation useless on Qubes...

I don't think non-technical users use non-Qubes documentation for Qubes, and there shouldn't be an expectation that they do so. Qubes documentation should be comprehensive for non-technical users.

We'd still explain somewhere, that a qube is a VM.

As long as we have short sentences (throughout our docs) explaining "a qube is just a user friendly term to represent a VM"

yep agreed. it would drastically increase the usefulness of the Qubes name & brand in explaining how Qubes works to non-technical users.

[woju]

On Tue, Nov 10, 2015 at 10:35:30AM -0800, Michael Carbone wrote:

As long as we have short sentences (throughout our docs) explaining
"a qube is just a user friendly term to represent a VM"

Maybe we could settle on the term „domain” which is both more
user-friendly than „VM” and already established in literature, most
importantly (and prominently) in libvirt, which we use.

[bnvk]

Maybe we could settle on the term „domain” which is both more

I think that word is already a bit understood by the general
public to represent websites- e.g. "domain names" and even then,
is bit ephemeral / abstract.

...and already established in literature, most importantly (and prominently) in libvirt

If we try to make our UI naming conventions match things in the
literature, we are bound to end up with things that make sense to
technical users who've read "the literature" probably at the
expense of those who have not :-)

[andrewdavidwong]

When I first encountered Qubes and saw the Qubes logo (a stack of three cubes, at the time), it was fairly obvious that "Qubes" was a unique spelling of "cubes," and that the "cubes" represented VMs. For this reason, I found it strange that nothing in Qubes was ever referred to as a "qube."

However, if the primary reason to start referring to VMs as "qubes" now is that the OS is already named "Qubes OS" and has had that name for many years, then this strikes me as a rather weak reason. There should be some compelling, independent reason to introduce a new term which abstracts away from VMs.

Here's one potential reason: In Qubes, there are important distinctions between different types of VMs. For example, TemplateVMs are typically more trusted than most of their child TemplateBasedVMs, and the compromise of a TemplateVM is generally (but not always) a worse outcome. We also have StandaloneVMs and HVMs, the latter of which can themselves be either TemplateVMs or StandaloneVMs. There are also ProxyVMs and NetVMs, which are typically less trusted than other types of VMs (but not always, e.g., TorVMs). Finally, we use the term "AppVM" to refer primarily to TemplateBasedVMs, but sometimes also to other types (rather ambiguously, unfortunately).

Given this complex situation, the term "qube" might be most helpful if it were used to refer only to a proper subset of these different types of VMs, namely the ones with which less technical users would primarily interact. For example, we might say:

A qube is where you do your work and store your files.
Qubes OS lets you compartmentalize your digital life into securely isolated qubes.

So, a "qube" would refer to most AppVMs, StandaloneVMs, (non-template) HVMs, TemplateBasedVMs, etc. Meanwhile, things like TemplateVMs, ProxyVMs, NetVMs, and dom0 would not be referred to as "qubes." Instead, these would be made less visible to less technical users in order to protect them from making common but fundamental mistakes (like trying to do work in a TemplateVM or in dom0).

(Note that this is just a provisional idea, not a finalized recommendation. My aim is to point out that there are more useful ways to leverage a term of abstraction like "qube" rather than as a 1:1 replacement for "VM.")

[mfc]

When I first encountered Qubes and saw the Qubes logo (a stack of three cubes, at the time), it was fairly obvious that "Qubes" was a unique spelling of "cubes," and that the "cubes" represented VMs. For this reason, I found it strange that nothing in Qubes was ever referred to as a "qube."

yep same here.

So, a "qube" would refer to most AppVMs, StandaloneVMs, (non-template) HVMs, TemplateBasedVMs, etc. Meanwhile, things like TemplateVMs, ProxyVMs, NetVMs, and dom0 would not be referred to as "qubes." Instead, these would be made less visible to less technical users in order to protect them from making common but fundamental mistakes (like trying to do work in a TemplateVM or in dom0).

yes exactly, agreed.

this is what brennan, joanna, and myself had discussed in DC - at the most basic level, that AppVMs are qubes, while everything else ("service VMs" = proxyvm, netvm, dom0) is not.

I don't think non-technical users will be using StandaloneVMs, HVMs, etc.

[rootkovska]

So, I think I still like the "VM" most, b/c it's shortest and also (for the slightly more technical crowd) immediately explains how the isolation is being done.

As for dom0 renaming -- we definately need to do that: not only is "Dom0" meaningless to most people, but also given Qubes HAL architecture it's too Xen-specific. I suggest to replace it with AdminVM, or just Admin (or 'admin' depending what looks nicer). In the future (Qubes 4) we will also have GUI domain, which should also be listed in the manager.

[adrelanos]

Michael Carbone:

I don't think non-technical users will be using StandaloneVMs, HVMs, TemplateBasedVMs, etc.

I think this was a mistake or a confusion about terms.

AppVMs can be one type of TemplateBasedVMs.

https://www.qubes-os.org/doc/glossary/

"Template-BasedVM Opposite of a Standalone(VM). A VM, that depends on
another TemplateVM for its root filesystem."

TemplateBasedVMs can be AppVMs, ProxyVMs, NetVMs, HVMs.

[mfc]

I think this was a mistake or a confusion about terms.

corrected in comment, thanks #1015 (comment)

[bnvk]

AppVMs, ProxyVMs, NetVMs, etc... are great if the goal is make sense to technical people familiar with virtualization. It's taken me, a mid level web engineer (who's used normal VMs), months to understand / how to use them correctly in Qubes. I still don't understand what an HVM is.

VM... it's shortest and also (for the slightly more technical crowd) immediately explains how the isolation is being done.

At the expense of being meaningless to the non-technical crowd. VM is accurate, it's less likely to explain the underlying concepts via UI elements to those learning a new system (unless one first learns what a VM is), and has the side effect of increasing cognitive load for all new users. The general practice in design is to reduce cognitive load by going with simple and identifiable metaphors.

A cube is a visual symbol lots of people around the world learn at a young age- thus, "qube" and "Qubes" for the name of the OS was a stroke of brilliance, I think. I also found it odd to never see a mention of a "cube" while using Qubes.

All of these are reasons I say- start with a fresh user friendly metaphor that's simple to visualize, easy to remember, and matches our name. Here is some of the ideas I was thinking to help explain Qubes and what a VM / qube is:

Here is something that explains our upcoming concept of "recipes" or pre-configurations that plays onto that "qube" metaphor:

The above concepts that could be on the website, in a slideshow, or within a GUI setup guide in the OS.

there are more useful ways to leverage a term of abstraction like "qube" rather than as a 1:1 replacement for "VM.")

More on this in another issue at a later date :)

[andrewdavidwong]

@bnvk:

there are more useful ways to leverage a term of abstraction like "qube" rather than as a 1:1 replacement for "VM.")

More on this in another issue at a later date :)

I think you've misunderstood. This isn't "another issue." It has to do with the very definition of the term "qube" and the fundamental way that term is used. In fact, your post seems to presuppose the very point I was making.

@rootkovska:

So, I think I still like the "VM" most, b/c it's shortest and also (for the slightly more technical crowd) immediately explains how the isolation is being done.

This sounds like a response to the proposal of performing a 1:1 replacement of "VM" with "qube," but that was not the only proposal made. I pointed out that there are more useful ways to leverage a term of abstraction like "qube," e.g., by using it to refer only to a proper subset of the VMs in Qubes OS, such as the ones in which users are supposed to run programs and storing data.

[unman]

It strikes me that there is a major disconnect here because it is not clear what the target audience is for Qubes, and therefore what terms are appropriate to adopt. (Perhaps I should say "not clear to me.")

I have no idea what the profile of current Qubes users is. If postings to qubes-users are any guide, they are pretty enthusiastic and cover all bases between complete novice with no prior linux experience and Dan Bernstein. Most of them are, I would say, "fiddlers", and don't read documentation or search for solutions.

AppVMs, ProxyVMs, NetVMs, etc... are great if the goal is make sense to technical people familiar with virtualization. It's taken me, a mid level web engineer (who's used normal VMs), months to understand / how to use them correctly in Qubes. I still don't understand what an HVM is.

I think this goes to the heart of the problem, although I'm quite surprised you found it so difficult. (HVM is pretty standard.) I would have thought that the solution was to improve documentation so that these terms are not so hard to understand. (Although this wont help people who wont read.)

But this is to make (technical) sense to (relatively) technical people, and you are trying to make a contribution at a technical level. You shouldn't need any of this to improve your security using Qubes.

Why is Bromium so neat? Because it's fast and there is no learning curve. A Windows user can just use it straight off.
I agree with @bnvk that detail can totally be hidden from non-technical users. But I don't think that the answer is to come up with new terms. It's to drastically simplify the offering (Is this what's implied in "recipes"?). Completely hide the implementation for those users.

I've been experimenting with a Torified Debian Qubes , with set VMs , and a single "standard" menu. No reference to VMs, no "domains" in the menu, no manager. Restricted applications running in the "email" and bank domain - all files are passed off to DispVMs for opening. Banking browser restricted to bank domains - this is the only thing that isn't easy to automate.
I don't have a mother to try it on, but I have given it to assorted folk, most completely non technical. The only complaints have been about browsing speed - that's Tor for you. Oh, and boot time. And that funny copy/paste thing. And slow boot times for VMs - not, of course, put in those terms. ( I mitigate that by prestarting standard VMs on login. ) And maybe some other minor stuff.
The point is that no explanation is required as long as it just works. And these are people who wouldn't find talk about VMs, recipes, qube(singular or plural) helpful. But they do want to be a little safer online.

Maybe that isn't the target?

The thing is that security is really difficult. You can improve security by educating people or by giving them tools to use, minimise the chances of misuse by enforcing use and taking away user choice. Once you let folk loose on the detail of the implementation then you had better hope they understand what they are doing and what the risks are: they wont unless they have some grasp of the technical background.
It's a moot point whether a terminology change will improve matters. I think not.

[mfc]

from Brennan's beautiful mock-ups and axon's points, it sounds like concept of a qube could be extended from just a replacement for the term AppVM to also incorporate some understanding of its netVM (ie how it connects to the internet, if it does).

So to tweak the mock-up I would say that a qube does not connect to a "Networking Qube", but rather one of the aspects of the qube itself is whether and how it networks.

That could be one of the "sides" of the qube (maybe the top?). Black if it is non-networked, purple if it is Torified, some-color for VPN, orange/yellow/red for regular clearnet.

@unman Your experiment sounds similar to discussions we have had about a "Beginner mode" for Qubes where there is not any domain management, just one AppVM and using the DispVM functionality for opening files/attachments. It would still be a step-up in security from plain Linux (or Windows...). Then there'd be "install some recipes" (Normal mode) and "I'll do it all myself" (Advanced mode).

I don't think this discussion is coming out of disagreement of target audience, just of what we think would be most helpful for new users. We all want non-technical, non-Linux users to be able to understand what Qubes does and integrate it into their existing workflows with minimum confusion. And terminology can help with that process.

[rootkovska]

1. I really like the Brennan's mock-ups (except, I think we should avoid Americanisms, such as "super simple" and keep it more emotionally neutral, say just "simple").
2. I feel persuaded we should replace the term "VM" with a more catchy term, and I like the reasoning for using the term "qubes" for that.
3. I think we should use this "qubes" term for all the VMs, including the service VMs, not just AppVMs. This is to minimize the amount of different classes of abstract terms we're introducing. Also because the services VMs can also be interacted with the same way the user interacts with his or her AppVMs (e.g. I can start Terminal in my TorVM).
4. I do not like the idea of squashing of the inter-VM (sorry, inter-qubes) connectivity picture on the properties of a single, 3D-visualized, qube. Not only might that be technically difficult (hard to show 3D pictures on 2D screen or paper, also mind the color-blind users if we wanted to use colors), it really is not correct (how would you represent a situation when 2 or more VMs use the same networking VM?) and also misses one of the important points of Qubes OS -- being able to separate networking, Tor, USB, etc (so everything we represent by a "qube") from the user AppVMs (so from the user "qubes").
5. So, I think we should perhaps advertise the term "qubes" as a container for running "things" -- be that user apps, be that (admittedly abstract to many users) networking.
6. Also thanks @unman for the detailed write-up, I agree with most of what you wrote there. As Michael mentioned, we definitely want to use the "recipe" infrastructure to implement "super easy", out of the box configurations.

[andrewdavidwong]

Minor issue: "Qube" is a geometric/structural metaphor, while "recipe" is a cooking metaphor. We should avoid mixing metaphors. A "recipe" is a way to "cook up" a qube. But that's weird, because qubes aren't really "consumed". It's also the opposite of what you're going for with pre-configured qubes. A recipe is a set of instructions you follow when you cook something yourself. Pre-configured qubes are the opposite of that, because they're already configured ("cooked") for you.

[andrewdavidwong]

@rootkovska

3 I think we should use this "qubes" term for all the VMs, including the service VMs, not just AppVMs. This is to minimize the amount of different classes of abstract terms we're introducing. Also because the services VMs can also be interacted with the same way the user interacts with his or her AppVMs (e.g. I can start Terminal in my TorVM).
[...]
5 So, I think we should perhaps advertise the term "qubes" as a container for running "things" -- be that user apps, be that (admittedly abstract to many users) networking.

Again, what about TemplateVMs?

In 3, you say you want to call all VMs "qubes," so TemplateVMs would be called qubes. Then in 5, you say that qubes should be advertised as containers for running "things." But users are not supposed to be running "things" in TemplateVMs (except, of course, to install and update software)!

[rootkovska]

On Tue, Nov 17, 2015 at 09:56:10PM -0800, Axon wrote:

In 3, you say you want to call all VMs "qubes," so TemplateVMs would be
called qubes. Then in 5, you say that qubes should be advertised as
containers for running "things." But users are not supposed to be running
"things" in TemplateVMs (except, of course, to install and update software)!

That one would be the "Template for qube(s)", right? :)

[andrewdavidwong]

That one would be the "Template for qube(s)", right? :)

So, a TemplateVM is a "Template for qube(s)"? Is it itself also a qube? If so, then since a qube should be advertised as a container for running "things" (by 5), it follows that a Template qube should also be advertised as a container for running "things" (false). If not, then since "qube" refers to all VMs (by 3), it follows that a TemplateVM is not a VM (false).

[andrewdavidwong]

Example of "qube" causing some user confusion in this thread:

https://twitter.com/Piniora/status/1462043541237022722

[mfc]

I read that feedback highlighting inconsistency in usage, and confusion with using "Qubes" to refer to "Qubes OS".

we probably want all references to "Qubes" (meaning "Qubes OS") to be "Qubes OS". so "Qubes OS Global Settings", etc

[unman]

On Mon, Nov 22, 2021 at 06:51:45AM -0800, Michael Carbone wrote: I read that feedback highlighting inconsistency in usage, and confusion with using "Qubes" to refer to "Qubes OS". we probably want all references to "Qubes" (meaning "Qubes OS") to be "Qubes OS". so "Qubes OS Global Settings", etc

Well, OK - but is this a genuine confusion, or manufactured?

[mfc]

well more consistency/clarity is always helpful.

but maybe also in some of these cases it is simplest & clearest to be removing words. like maybe "Qubes Global Settings" should just be "Global Settings", etc

[ninavizz]

The above are all perfect to resolve in a styleguide for naming. Took a screencap here.

A comments thread on an issue could go on forever. Perhaps we begin style-guiding terms use in a wiki? Working in Figma mockups has helped me identify many of the above problems by contextualizing them in the UI itself. I highly recommend those sorts of studies to help with an exercise like a style-guide.

[ninavizz]

Qubes OS System Settings, I think, is what I've named that functionality in my 4.2 Settings issue.

Backups things should all be managed from that, or a "Q Manager," eventually. Consolidating all of the system-level settings/management stuff to one or two primary GUIs, has been a desirable goal to work towards for a while, in my own noggin.

In the AppMenu, it'd be nice if all XFCE, KDE, Gnome, i3, or whatever DE the user chooses, has its UI tooling contained to a bucket in the Settings pane of the AppMenu. @marmarta Totally off-topic and not for this issue, but semi-relevant so cc'ing you for visibility.

Having a zillion applets to manage one's system with, is quite confusing—as it's very different from how single-environment systems function at the GUI level. Yes, CLI users are able to comprehend all settings functionality to be applets; but it's a radically different mental model, for non-CLI-regular folks.

well more consistency/clarity is always helpful.

but maybe also in some of these cases it is simplest & clearest to be removing words. like maybe "Qubes Global Settings" should just be "Global Settings", etc

[ninavizz]

Also—per the title of this issue, I just wanted to offer a correction—the current discussed idea, is retiring VM and instead using "qube" to meet both the needs of "domain" so it's not specific to VMs.

Instead of App VM, it would be App Qube. Likewise, Service Qube and Template Qube, even tho "Templates" and "Standalones" are acknowledged colloquial nomenclature.

[andrewdavidwong]

• "Create Qubes VM" -> "Create qube"
• "Qubes Global Settings" -> "Global settings"
• "Qubes Update" -> "System update"
• "Qubes Template Manager" -> "Template manager"
• "Backup/Restore Qubes" -> "Backup and restore"

[adrelanos]

Andrew David Wong:

- "Create Qubes VM" -> "Create qube"

"Create Qube" Nitpick perhaps but at the chance of lowercase which could introduce confusion. Anything can.

[mfc]

"Qubes Global Settings" -> "Global settings"

"System settings"

i like Nina's suggestion of "System settings", it also parallels "System update" better. also is more clear, as it is referring to the system rather than referring to a metaphor of a globe/earth to mean the computer.

otherwise they look good and seem more clear!

[unman]

On Tue, Nov 23, 2021 at 02:43:11AM -0800, Michael Carbone wrote: > "Qubes Global Settings" -> "Global settings" "System settings" i like Nina's suggestion of "System settings", it also parallels "System update" better. also is more clear, as it is referring to the system rather than referring to a metaphor of a globe/earth to mean the computer. otherwise they look good and seem more clear!

They are Global, in that they apply to everything. People who are confused by "Qube Manager" wont understand why "System Settings" doesnt encompass networking, USB support and so on.

[ninavizz]

@unman In 4.2, it should. See #6898 😄

Additionally in 4.2, it's hoped that the first generation of a Policies GUI will also be incorporated into the above Settings framework. Totally with you, and agreed that it all needs to be centralized. Networking things, too—with a lead-in to further reading on how to use Qubes OS as it's intended to be used (eg: net qube things).

I air-dried my hair this AM and it's now curly, so I'm feeling Marek-y. He's the ultimate source of truth on release inclusions. The above is just what's been discussed.

[andrewdavidwong]

• "Create Qubes VM" -> "Create qube"

"Create Qube" Nitpick perhaps but at the chance of lowercase which could introduce confusion. Anything can.

In this case, lowercasing "qube" should reduce confusion, as "Qubes" (the name of the operating system) is a proper noun, while "qube" (the term for an individual VM in Qubes OS) is a common noun.

"Qubes Global Settings" -> "Global settings"

"System settings"

No strong opinion on "global" vs. "system." I'd be fine with either one.