QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
541 stars 48 forks source link

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

Open bnvk opened 9 years ago

bnvk commented 9 years ago

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:

andrewdavidwong commented 4 years ago

I feel like there are bigger fish to fry for the time being. There also needs to be a friendly introduction to QubesOS, separate from the docs, that explains how the ecosystem works to newbies. Something Marta and I have discussed a bit. Docs imho need to be more for nitty-gritty details stuff, and outlining best practices; less for "here is generally how this thing works."

Out of curiosity, what medium do you have in mind? (In other words, if not a doc, would it be a video? An infographic? An interactive software tutorial?)

deeplow commented 4 years ago

An interactive software tutorial?

Just my 2 cents on this. I'd be inclined to this approach (being discussed here: https://github.com/QubesOS/qubes-issues/issues/1395) complemented with some video tutorials (updated for r4.1). I've have some thoughts on this that I'd like to share at some point.

andrewdavidwong commented 3 years ago

@ninavizz https://github.com/QubesOS/qubes-issues/issues/4723#issuecomment-840154620:

Yes, in user-facing stuff, Marta and I are both also trying to get qube standardized around. Totally going to be a lost cause I think, getting contributors to stop using VM in threaded contributor conversations like this, tho... until we're all used to seeing it in our UIs, I suspect. :smile_cat:

The use of "VM" in technical contexts, such as this technical software issue tracker, is not only entirely appropriate, but necessary. There is no way that technical people in any field would be able to get things done if they were restricted to user-facing language and unable to use their own technical terminology. We should not be trying to get contributors to stop using terms like "VM" in technical discussions.

ninavizz commented 3 years ago

@andrewdavidwong I'm not at all suggesting that technical discussions should abide by user-facing language. However there is a "gray zone" where UX work needs to map to how functionality is exposed to a user. If even developers cannot get those user-facing conventions correct, that to me is indicative of a problem with the mental model those names inform. Mental models help people intuitively piece-together how a complex system works, without memorizing 1:1 names to functional ideas. To shape a system to be as intuitive and usable as possible, they are important.

That comment you quote, above, was mostly me trying to be lighthearted with Sven, on an aside. This discussion has gotten a bit tense, and I am not at all seeking to create tension. Only to help make Qubes more intuitive, to newer and non-Linux native users, while also not alienating existing and highly technical users. That is not an easy task. User "experience" as a practice separate from designing "user interfaces," does need to look at everything from documentation, to naming, to performance, to accessibility, and to the visual interface itself. I am truly not seeking to undermine or overlook a lot of community effort already involved.

DemiMarie commented 3 years ago

One problem with using “qube” is that (per internal discussion) it leads to confusion with “Qubes” (the complete system). In some languages (such as French), trailing “s”s are often silent, which makes the matter worse.

andrewdavidwong commented 3 years ago

@andrewdavidwong I'm not at all suggesting that technical discussions should abide by user-facing language. However there is a "gray zone" where UX work needs to map to how functionality is exposed to a user. If even developers cannot get those user-facing conventions correct, that to me is indicative of a problem with the mental model those names inform.

I just want to point out that it might be intentional rather than a mistake. I choose very carefully when I use "qube" and when I use "VM," depending on the context of the utterance.

That comment you quote, above, was mostly me trying to be lighthearted with Sven, on an aside. This discussion has gotten a bit tense, and I am not at all seeking to create tension. Only to help make Qubes more intuitive, to newer and non-Linux native users, while also not alienating existing and highly technical users. That is not an easy task. User "experience" as a practice separate from designing "user interfaces," does need to look at everything from documentation, to naming, to performance, to accessibility, and to the visual interface itself. I am truly not seeking to undermine or overlook a lot of community effort already involved.

Sorry if I was too harsh. Seeing all of us go in circles over this renaming stuff (as in, literally repeating conversations from years ago that are still on the very same pages, just closer to the top) has been frustrating for me as a lover of efficiency and a hater of repeating myself. 😆

unman commented 3 years ago

On Thu, May 13, 2021 at 01:43:14PM -0700, Demi Marie Obenour wrote:

One problem with using ???qube??? is that (per internal discussion) it leads to confusion with ???Qubes??? (the complete system). In some languages (such as French), trailing ???s???s are often silent, which makes the matter worse.

I dont know who the internal discussion was between, but in my experience with new users, this doesn't give rise to any confusion. In fact, as was said years ago, it's a natural usage for most people.

But I think it's beens said - we dont want to spend time on this unless there is good reason (and evidence) to do so.

andrewdavidwong commented 2 years ago

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

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

mfc commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago
Screen Shot 2021-11-22 at 2 45 53 PM

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago
adrelanos commented 2 years ago

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 commented 2 years ago

"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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago
  • "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.