Cute cube icons to replace padlocks, on VMs

[ninavizz]

Problem

The lock semiotic in the context of a UI typically means that an item is restricted from being modified. In Qubes, it is extremely confusing seeing it used to denote containers, and containers of different security, permanence, and derivation properties. The ecosystem of VMs within Qubes should have their own family of icons, within which Template, Service, Disposable, and App qubes are more clearly distinguished. Also, everyone liked the cute-cube, so—here we are!

Solution

Implement cute-cube icons across GUI components that currently show VMs with a colored padlock. Note, that dom0 is shown w/ an icon in the below schema—it's just always shown at 60% alpha. The below also shows a magenta icon, which I'm not including in the deliverables as that does not yet exist as an optional qube color.

Comments for iteration between delivered art, and screenshots of what they look like in various components w/in a build. My guess is that some iteration will be needed... :D

[marmarta]

Hi hi! Just saw the updated screnshots for 4.1 and... whee! So excited to see the qute qubes in there!!! :)

A few questions:

1. I did not see the disp-vm icons in place for VMs that were listed as disposable. Was there an interest in abandoning them, or was that just an oversight?

That I think is my oversight in implementing this . Will make a ticket for myself to fix that :)

2. For `dom0` there was an exclamation point atop its VM, and I wanted to make sure that is because there is some error state with the particular device the screenshot used, and not that the exclamation point is desired as an ongoing `dom0` designation. If there is an interest in creating a unique icon for `dom0` I'm happy to whip something up; but feel the exclamation-point will be confusing and alarming in its semiotics.

That's on me - I think it was my idea to put the exclamation mark there. @marmarek , are you for or against an AdminVM icon?

3. The domains menu icon in the tray is still getting cutoff around the edges. Absolute delight, seeing none of the app menu VM icons cut off, as I'm aware that was a problem for a while. <3

Working on the tray icon and I think I have a solution, will push it once I dig myself from a work-shaped hole :)

[andrewdavidwong]

Would definitely be handy to have icons for AdminVM and GUIVM, IMHO.

[ninavizz]

So: there's only so much meaning that can be stuffed into a 16x16 graphic. Especially when a group of graphics that size, need to clearly stand together as a family of like items. Likewise, there's only so much abstract meaning users can remember in a fashion that can be intuitively recalled, on different shapes/takes on a little cube. Marry both challenges, and I feel we've already gotten the most we can get from a family of 16x16 icons, without beginning to create confusion.

Why would the GUI VM ever be shown in the app menu? It makes sense to me in the Domains menu; and likewise, considering all the complexities herein it makes more sense to me now, that the Domains Menu and the App Menu find themselves merged... as it's between rare and never that a user would go to dom0 or the GUI VM to "open" anything other than the terminal or the VM's settings pane (as I'm aware).

I'd like to caution against making a common mistake I've observed in early GUI development, which is just too many darn icons for too many things; so much so that their meaning becomes obfuscated, and they then all just become too much to look at. Part of what imho makes the Qute-Qube family pleasing right now, is that it's clear what each one is. The more we add, the more that becomes muddled.

[andrewdavidwong]

Why would the GUI VM ever be shown in the app menu? It makes sense to me in the Domains menu; and likewise, considering all the complexities herein it makes more sense to me now, that the Domains Menu and the App Menu find themselves merged... as it's between rare and never that a user would go to dom0 or the GUI VM to "open" anything other than the terminal or the VM's settings pane (as I'm aware).

Well, my thinking is that, from a security perspective, it's very important that users know what the AdminVM and GUIVM are and what they are not. For example, if part of the idea behind isolating the GUI part of dom0 in the GUIVM is to allow users to be more liberal with customizing their desktop environments, then it's very important for security that such customizations (which might including installing less trusted stuff) be done in the correct place, namely the GUIVM. Now, maybe Qubes might take care of this in other ways, but this is just an example. And, if it's important that users be able to identify what is and is not part of the GUIVM (the way we can identify what is and is not part of dom0 right now), then having visual identifiers like a special icon seems like it could be useful. The icon could also be used in the documentation that explains the GUIVM, for example.

However, to say that something would be handy or useful is not to say that it's necessary. These security goals could certainly be achieved in other ways. We don't really have a special icon for dom0 right now, yet we're still able to distinguish it. So, if you think, given the other considerations you mentioned, that icons for these are not merited, I have no objection.

[ninavizz]

Thx for the explainer @andrewdavidwong that is most definitely helpful to hear!

There are other ways to signify "families" of like items, than just icons or color. Grouping and naming are important, too. To me it feels urgent to learn more about Qubes conceptually, with stuff like what you just explained above. Through that, I can better understand what the mental model needs are, and other methods for visual separation/distinction in the UI can be potentially considered.

"Utility VMs" feels like a possible parent category of qubes, that Template and Service VMs might fall into, and dom0 and GUI VMs wd also fall into. It's easier for users to work with the simplest possible mental models; and "These are the VMs I do stuff in everyday" vs "These are the VMs that shape my environment and grant access among containers" feels like a safe mental model. "Utility VMs" being like the government of my computer, and "App VMs" being like the citizens of my computer. Not to invoke politics, lol, just spitballing.

Always keeping things simple, is important. Simple, not dumb. Simple is really hard, dumb is easy.

[ninavizz]

I think this issue has mostly been completed @marmarta what do you think?

[ninavizz]

Oh @marmarta pls don't hate me, but @svensemmler nudged me and I'm deeply bored on this airplane right now... though quite like these sushi-ish "Service VM" icons. The 'lil crown is not quite as cute as the taller crown, but is much more compact.

Thoughts on these updated jabs at dom0 and service qubes?

[ninavizz]

Only downside I can see with the qute-sushi-qubes, is that they'll be difficult to extend to pastel colored qubes, should we go forward with #2523

[marmarek]

The sushi kind is IMO hard to distinguish from normal app qube, especially when small. It isn't very important (as there will be other hints it is a service qube - like separate section in the menu, sys- prefix etc), but if doing separate icon for this role, let it be seen as a different one. Also, it isn't obvious for me why qube with a hole (did I got it correctly?) means service. Maybe for sys-firewall, or sys-vpn, which are a pipe for network traffic yes, but IMO doesn't really fit for sys-usb for example. I've tried "system service icon" image search, but most results are based on either a wrench or a gear icon, which IMO better fit for a "settings" icon.

[ninavizz]

@marmarek All great feedback, TY!

So—as with much of Qubes, there is no common mental-model for "a virtual machine that does things for other virtual machines!" Mental models and associated semiotics, are what make things like a gear or wrench icon for a Settings panel, seem intuitive. Qubes speaking to few existing mental models, is why I enjoy all this (gestures arms in wild big circles) as a fun challenge. But, a challenge it is!

Because no mental models exist, I wanted to get as un-technically-specific/generally-conceptual as possible.

"Service" qubes bring things "from outside," to app qubes in the same way an electrical outlet brings electricity from a primary electrical source, to a room in your house, through the plug in the wall. That plug is an "inlet port," serving the same purpose as the literally-named "inlet port" on an internal combustion engine that brings fuel into the firing chamber.

I put a the cord for a fan into the electrical outlet in my bedroom's wall, and it brings electricity to the fan inside my bedroom. I inject fuel into an enclosed space through an inlet-port, so that compression (or a spark) can produce an explosion to push the rod on the crankshaft down. I may wish to bring a USB device into a specific app qube, the same way I wish to bring electricity into my bedroom to power a fan. I may also wish to bring internet into that same app qube, through the same delivery mechanism. Thinking-through delivery mechanisms, the "inlet port" metaphor felt like a solid concept to communicate the purpose of a Service Qube to folks learning Qubes OS, and to folks actively using it day to day. To me, the sushi qube looks like a go-between plug sort of a qube, that an app qube could theoretically "plug into" to get stuff like electricity or internet. Just like the Template icon shows a thing being created from another thing, and the disposable icon shows a thing disappearing.

It's "type" is an app qube—so it's a full-sized qube. But, it's role is as an "inlet port" or as a "bringer" of a service.

Conceptually, this makes a lot more sense to me than the star. I really love that the star is so clear in a 16x16 icon, but now with the crown implying royalty for dom0 the semiotic of a sheriff or police-type of official for a Service qube feels off. The most primary use-case of qubes that Qubes OS was specifically architected for (I think?), is the triad of "an App qube, built from a Template and connected to external devices and the internet through respective Service qubes." When seeing that triad of an App qube, its Template and Service qubes, in an ideal world the Template and Service qubes might be visually identifiable in quick recognition apart from the App qubes.

Does all of that make sense? IF so, yes, totally happy to fuss some more with improving the rendering.

All of the above is also quite rambly. Cannabis sleep-aid gummies are really lovely. I maybe just shouldn't do GitHub comments after taking one (or a few).

[andrewdavidwong]

It might be helpful to have a different icon for disposables and disposable templates, given how important it is not to mix them up. One idea is to use the other diagonal. In other words, all the double-cube icons currently use the diagonal between the top left and bottom right, but nothing yet use the diagonal between the top right and bottom left.

[andrewdavidwong]

Just like the Template icon shows a thing being created from another thing, and the disposable icon shows a thing disappearing.

This seems to be based partially on the assumption that the user "reads" the icon from left to right, which may not hold for right-to-left language users. On the other hand, the top-to-bottom direction may be intuitive to all users. Since it's diagonal, maybe that's enough.

[marmarek]

To me, the sushi qube looks like a go-between plug sort of a qube, that an app qube could theoretically "plug into" to get stuff like electricity or internet.

Ah, now I understand. But it wasn't clear for me the icon is "a qube with a socket". Is there a way to make it more visible in such a small icon? Or maybe use a plug not a socket - that IMO should be easier to see.

[ninavizz]

@andrewdavidwong My brain wants to explode, just thinking about that one. Disposable templates are App Qubes by type, and then Disposable Templates by role. I really love your idea, as it will be visually arresting—which would be the point. I question though, if it would create more confusion for users—and if the visual separation by alphabetization in Templates for 4.1 (discussed in another issue for 4.1's menu and Qube Manager to display) and then by menu tab and separate groups in Qubes Manager for 4.2?

All of this, I want to clearly document in our docs, in time for a 4.1rc—with much larger (96x96, probably) icons used in demonstrative illustrations throughout text.

From a puritanical design perspective, the backwards diagonal for a disposable template makes no conceptual sense. That is the only objection I can cite towards the specific idea. And yet, given how complicated—both infuriatingly and wonderfully—our system is, I don't know how much that really matters.

Question: So, I understand (and love) the rationale for an app qube being a disposable template, much as I also want regular templates to be able to be disposable templates, too. If I check the box for my Personal qube to open docs in a disposable, then my presumption is that Personal will also replicate as a disposable template. Or, would it exist by itself in the app menu as a disposable template?

[ninavizz]

Ah, now I understand. But it wasn't clear for me the icon is "a qube with a socket". Is there a way to make it more visible in such a small icon? Or maybe use a plug not a socket - that IMO should be easier to see.

Conceptually, though, the Service qube is the "socket" in that plug/socket relationship, tho. Regardless: will work on rendering! Agreed, it could use some improvement. :)

[ninavizz]

This seems to be based partially on the assumption that the user "reads" the icon from left to right, which may not hold for right-to-left language users. On the other hand, the top-to-bottom direction may be intuitive to all users. Since it's diagonal, maybe that's enough.

Honestly, I only made it diagonal to fit the two Qubes in a small/square footprint, and to have some overlap between them. It's more the goal for the both of them, that they demonstrate "transformation" of the object; for a Template, that its role is for other Qubes to be created from its form. For the disposable, that its role is to disappear.

The LTR/RTL thing is a real "problem" of sorts. With usability, we always need to keep the 80/20 rule in mind: Optimize for 80% of your users, preferably without disenfranchising the 20% minority. When you try to optimise for both, most of the time you'll just end up with solutions that don't work wonderfully for either—and that is something I believe should be avoided.

All app menus in OS GUS are the best example of this I can think of, off the top of my head. The icons are to the left of the titles, for LTR readers. When I go to London, I'm also expected to drive a car on what to me is the "wrong" side of the road. When users are in a minority, most adapt to things just not being optimized for them. Because we have no other choice. For that reason, I'd personally never want to rent a car in the UK, because I'm afraid of my own inability to remember such a radical shift—and failing to remember, could cause me to kill other people or to be killed, myself.

[marmarek]

Should this be closed now (#6745 is tracked separately), or is anything more in this issue left to do?

[ninavizz]

CLOSED!! With a hat-tip to @marmarta for a most excellent job implementing.