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

[ninavizz]

QuteQubes.zip

Includes: red, orange, yellow, green, blue, tor-purple, disp, template, services, domain menu

@marmarta Above is a ZIP file with what should be all the SVGs you'll need. Wd love to see a screenshot of what they look like in the app menu, qube manager, and either the devices or open domains tray menus, whenever you this is gotten to. The matching colored Qube Settings icons, are in #5447

When this issue is merged into a proper build, a "heavy" bit of work will be re-capturing and posting new screenshots for documentation and the website—as this is a very significant GUI change (and many of the screenies are out of date, anyway). FYI, that should be considered when evaluating when this shd be pushed.

[hexagonrecursion]

Note: it is currently possible for the user to create new labels with arbitrary RGB colors by either:

1. Writing a script to call qdmin.label.Create method of the Qubes Admin API with the appropriate arguments
2. Editing /var/lib/qubes/qubes.xml

<qubes>
  <labels>
    <label color="0xcc0000" id="label-1">red</label>
    <label color="0xf57900" id="label-2">orange</label>
    <label color="0xedd400" id="label-3">yellow</label>
    <label color="0x73d216" id="label-4">green</label>
    <label color="0x555753" id="label-5">gray</label>
    <label color="0x3465a4" id="label-6">blue</label>
    <label color="0x75507b" id="label-7">purple</label>
    <label color="0x000000" id="label-8">black</label>
  </labels>

Therefore I'm fairly certain that there is currently only one padlock icon and the color is applied programmatically.

I find it notable that this ability is not exposed even in the python api or the command line api let alone the GUI.

[ninavizz]

Ayy... well, crap, that stinks. Applying color programmatically is not ideal, since across the spectrum different hues need different degrees of contrast from darker color regions in an object, for it to render with equal perceptive clarity. TL;DR, math doesn't solve for everything.

It'd be my preference for each color option to get their own bit of cube artwork. If that's not possible @marmarta pls let me know (once this gets on your docket to work on).

[marmarta]

That would require a pretty big change in how we approach the label colors - I'm tempted to agree and say yes, we can have only a set amount of colors and use fixed icons. The way the padlock icons are drawn currently borders on horrifying and it would be much nicer to have them as actual icons. But there definitely will be some people very displeased with losing their custom colors...
Maybe we could have X amount of colors predefined and a legacy mechanism for handling any custom colors someone made for themselves. @marmarek, would you be fine with such a change? (+disabling the mechanism for adding custom colors, if it can be called a mechanism at all - I mean people will still be able to edit source files if they want, it's not that different from editing raw qubes.xml)

[mfp20]

Sorry to waste your time with this comment but ... PLEASE DO SOMETHING. I tried myself to have better icons and got a mess... I'm a poor graphicapped techy: can't draw anything, even avoiding all the pencils/pens/gimps at once and using a coding approach brings me nowhere when it comes to graphics. I need it, I can't give it to me.

A motivational comment. More like a desperate yell for help.

[marmarek]

Maybe we could have X amount of colors predefined and a legacy mechanism for handling any custom colors someone made for themselves. @marmarek, would you be fine with such a change?

Yes. I think it's fine to treat custom colors as second-class citizens here. It should be possible to also add custom icons for those custom colors, but fallback to less-nice icons by default should be ok. I'd not remove the feature completely, as it was requested multiple times over the years.
In the future, if/when we add the ability to define custom colors in GUI, we can also add an option to set specific icon associated with it.

There is one (two or even three) more issue related to icon colors: application icons. Currently we take original icon and color it in a VM's color. We do that in three places, which are mostly independent:

1. The menu - here the input icon is static, a file installed together with an application.
2. The application window (visible in application switcher under alt-tab, and depending on settings, on the title bar) - here application provide the icon at runtime and in theory can change it dynamically (although applications rarely do that) - in practice this icon is the same as the one in the menu, but in theory it doesn't need to be
3. The notification area/tray (network manager etc) - some applications place an icon there, in many cases this icon is very much dynamic, carrying some information (network connection status, new messages in case of IM clients etc). Currently we also take the original icon and apply color to it (using more or less the same algorithm), but we have also implemented other options like adding a colorful frame

The last one is especially tricky, as it is the only hint about the icon origin - contrary to normal application windows, there is no visible VM name next to it.

This may be getting offtopic, some of those three points may be discussed in other issues already.

[marmarta]

I think I would propose starting with 1: replacing the padlocks (what is returned by vm.icon). Using the ones delivered by @ninavizz for existing pre-defined colors and making a fallback that colorizes a generic icon if someone has a custom color. It's actually not related directly to 2 and 3, and we can discuss and/or change those separately, I think.

[h01ger]

those cute cube icons look very cute indeed, thank you!

[ninavizz]

@marmarta Sounds good to me! Should the "generic icon" to be colorized be white or black?

[marmarta]

I've finally got to implementing this in a non-ugly way (and there is a way), and I have two requests: could I get the template/dispvm/servicevm icons in all colours? while defaults are black/red/red, you can set those to any colour you want :) Another is: could I also get a grey icon? Grey label exists, at least for backwards compatibility we need to have it. Af for the default icon, it doesn't matter, and I can just use grey icons for that, too. Sorry for the delay!

[brendanhoar]

Paging @ninavizz (see @marmarta request above). :)

[ninavizz]

TY @brendanhoar for the ping, and no apologies @marmarta... super siked to see these going in!

Your request is my command, esp after all the work figuring-out how to get 'em swapped-out. Will getcha updated arts, sometime mid-week. FPF peeps gonna be siiiiked to see this go in, especially given the chorus of facepalms at new users wondering "why is everything locked?" :D

Yay, go team! :)

[ninavizz]

^ @marmarta Could I possibly see a screenshot of what the icons I'd previously delivered, look like in your dev build? I just want to make sure all is good in how I'd sized and formatted them, for delivering more (yes, sometimes SVGs re-size awkwardly). :)

[marmarta]

@ninavizz those are icons in the menu: ignore that not all show the correct icon type, I've only replaced a bunch on my current system to see if it works at all :) Oh, and the green Service VM icon is a bit wrong because I copied and pasted the star manually, just to get something to see if it works. So it's my fault, not your icons' :)

I'm resizing them with Inkscape, because it's the only tool that actually produces non-terrible icons without a lot of fuzzy back-of-the-napkin math.

[ninavizz]

Aah, cool! So, most are cutting-off an edge shadow on the right side. Are you using these as PNGs?

LOL, nothing is "my" or your faults; often stuff like this needs to get iterated on for the correct formats/sizes to get just-right, for how a system wishes to render things. Because in the end, humans only wish we could control everything. ;)

If you tell me the size and format all these things need to be, that could help me get u better ones.

[marmarta]

Yeah, I'm using them as pngs of various sizes. Well, potentially all kinds of sizes in different places: I generate icons from the smallest 16x16 to biggest 512x512, although in practice 16x16, 24x24, 48x48 get the most use, unless user changes the settings themselves.

I can send you a zip of the packaged pngs I get, if its helpful?

[ninavizz]

Yes! Always helpful to see actual art files being used in code... much appreciated! Yeah, following the multiples/divisors-of-8 rule, I take it?

[marmarta]

Alright, those are all the icons we generate (by default most of the sizes are unused - but if someone has an unusual high DPI etc. config, they can use them, and also providing all the sizes makes it easier for future development just to use "give me this icon and make it the size we want")
generated_icons.zip

[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.