EPIC Improve small iconography w/ Intuitive & Size-Appropriate Icons

[ninavizz]

Problem

Many of the smaller icons across the OS either have confusing semotics, are illegible, or too busy. Many are from the Gnome project, and I suspect were likely designed to be shown much larger. An icon that's great at 48x48 cannot usually work at 16x16.

I'm a full time designer and do not code a lick, so had at it. Most of the icons I created are slight variants of icons from FontAwesome (optimized for the very small space), are from TheNounProject, or were created from scratch.

UX Solution

Below are the 2 areas I've drafted improved icons for. I have not attached production artwork to this Issue, as that's a lot of work (that I'm happy to do!), and unless it's elected to get built that feels silly for me to do.

• Tray
  • Spacing. There needs to be much more spacing, between icons. Currently they're too squished together; the white container holding together the icons to the right, also adds too much visual busyness that out-does the value I'm guessing was intended with it.
  • Many colors in each icon is TMI in the small space allowed for in a tray. No Linux or Windows system does tray icons well, imho. Below is an image of my mac tray, as an example of a tray that I feel is done well.
    
  • Gradients pack too much information into a space as small as 15x15, which imposes a cognitive burden with parsing semiotics from a blob of colors.
  • Icons just shouldn't be up in the Tray, if they don't need to be regularly used; the disk space widget, meets that criteria.
  • Left vs Right Items...
    • The "Devices" widget and the App menu, both need to spawn-out sub-panes that for usability, really need to open from left-to-right. As such, I feel both would be better served to live in the upper-left. This will also de-clutter the items in the upper-right, which are also items folks need to visually look-up at to check on status-y things, often (volume, connection, battery, time). The Qube Manager icon I'm opting to keep in the right, simply because users are most accustomed to tray icons all stuffed over to the right... and there is a compelling reason to put the App and Devices icons on the left, but there is not, with the Qube Manager one.
  • Updater: The explodey-thingy is unclear as an "Updates" icon. The traffic cone feels like a clearer semiotic (but maybe only to me, because I'm American and the traffic cone is a common object, here?). Using white and orange to punch this icon out, also feels appropriate.
  • Battery currently has 3 discernable states: dying, not charging, and charging. A landscape-orientation battery would provide more width to display legibly clear battery-life increments. Because my Qubes machine is a bit older, and Qubes is a battery/CPU hog... this feels really important. In my 2 weeks with my Qubes machine, I've had to do emergency OMGWTF panics to find my cord, a few too many times, because I didn't realize I was down to such low battery power... because today's icon does not clearly nor legibly display that the battery is at 75%, 50%, 25%, or in "Warning, plug-in" mode. A charging icon would simply be a lightning-bolt sitting atop a battery, as Macs have.
  • Wifi Again, it should just be simpler and cleaner—ditch the gradients, to just tell me if I have a connection, what the strength of that connection is (number of bars), and possibly other information via the solid coloring of the vertical bars—but no gradients or outlines on the bars. TMI.
  • Existing clipboard icon is unclear; the battery is a 2 rectangles, and should be the only artifact composed of 2 rectangles, imho, in the tray.
    • The "clip" signifying a clipboard may need some more work, or something different—like, scissors could work better—but for now, that's what the thingy in the below mockup is.
  • Whonix icon appears 2x, and is unclear. The rounded padlock in a bright purple w/o a gradient is a clear semiotic, and stands-out nicely.
  • Qube Manager
    • The Qubes logo is already used in the top bar, for the app menu—and those padlocks gotta go. I'm proposing this for a "Qube" icon, to span system-wide as a replacement for the padlock. This iteration of it should be solely to open the Qube Manager.
  • Devices Widget
    • The cleanest icon and the clearest semiotic, is simply the USB icon. A device can be a drive, a printer, a keyboard... a fan, anything. Keep it simple.
• App Menu
  • This is the one place it feels appropriate to use the Qubes logo, at the top—but it deserves to be cleaner than how it is currently executed. The gradient should span the full width and height of the button, it creates too much "busyness" when it's its own contained block.
  • New Qube icon redone with clearer semiotic but consistent use of the hexagon as an outline of an isometric cube.
  • Red should be reserved as a Qube color for Service and Disp qubes, only—as black is reserved for dom0. I've added a nice pink to replace red as a user-selectable color, and will note that in a separate issue.
  • The padlocks are a confusing semiotic, because typically those denote some unique security property. Here, they do not. I'm proposing a clean but un-branded "cube" instead.
  • Templates and Disposable VMs should have uniquely styled icons, to more clearly separate them from Domains.
  • Apps that don't have a unique icon, should get a simple/generic diamond. Nothing that calls attention to itself.
  • The Qube Settings icon for each Qube should match the color of that Qube.
  • The Logout and Settings icons, I just made slightly nicer versions of.
  • Many other tweaks were made to the App menu itself (namely groupings and not colorizing app icons), that I will open a separate issue for.

Of Note

None of this is related to the SecureDrop Workstation project. FPF got me a Qubes laptop, and I love Qubes so figured I'd offer this up on my own. :)

Mockups

[ninavizz]

Per @marmarta's comment on #2523, I'll post the Qube icons as usable PNGs, later this week. :)

[ninavizz]

P.S.: @marmarta You said in another issue that a Python script generates these icons. Would it be better to send you SVGs? Wd love to see any docs on this process to learn more about how I can get you the best possible artwork to render legibly by the OS.

It would help me with the PNG files if I could know what all of the sizes are of the PNG padlocks used in Qubes, today.

With icons smaller than ~24x24, they almost always need some visual tuning done at their end size, to improve visual recognition and clarity when rendered in code. Icons that are simply re-sized down, often lose important details and look "fuzzy" if this step is not done.

[marmarta]

Padlocks are different sizes depending on where they are used, but the most common ones are:

• 16x16 in the domains and devices widgets (I tried 24x24 and they were also fine, but currently it's 16x16)
• 24x24 in Qube Manager

[marmarta]

Overall impression: yes!
Details:

  * Spacing. There needs to be much more spacing, between icons. Currently they're too squished together; the white container holding together the icons to the right, also adds too much visual busyness that out-does the value I'm guessing was intended with it.

This is one of the "using existing solutions without much thinking" thing - the built-in XFCE tray behaves like that so we just used it. A small change that is easily doable (I think) is modifying padding around icons, bigger changes in the layout (like getting rid of the white rectangle) are probably unfortunately something to be put into the "far in the future" category.

  * Many colors in each icon is TMI in the small space allowed for in a tray. No Linux or Windows system does tray icons well, imho. Below is an image of my mac tray, as an example of a tray that I feel is done well.

  * Gradients pack too much information into a space as small as 15x15, which imposes a cognitive burden with parsing semiotics from a blob of colors.

100% agree.

  * Icons just shouldn't be up in the Tray, if they don't need to be regularly used; the disk space widget, meets that criteria.

There is no other way of getting that information through the GUI at the moment, though - I think it may be moved to Qube Manager or perhaps merged with some other widgets?

    * The "Devices" widget and the App menu, both need to spawn-out sub-panes that for usability, really need to open from left-to-right. As such, I feel both would be better served to live in the upper-left. This will also de-clutter the items in the upper-right, which are also items folks need to visually look-up at to check on status-y things, often (volume, connection, battery, time). The Qube Manager icon I'm opting to keep in the right, simply because users are most accustomed to tray icons all stuffed over to the right... and there is a compelling reason to put the App and Devices icons on the left, but there is not, with the Qube Manager one.

It's a very good point about the submenus needing more space , I have to think about how this could be implemented.

  * **Updater:** The explodey-thingy is unclear as an "Updates" icon. The traffic cone feels like a clearer semiotic (but maybe only to me, because I'm American and the traffic cone is a common object, here?). Using white and orange to punch this icon out, also feels appropriate.

This one is definitely my fault - it was supposed to be a placeholder (uses the GNOME generic 'software-update-available' icon), but, well. Placeholder solutions stick around sometimes..
My own automatic associations with updating are more things like arrows in a circle or an arrow suggesting 'downloading' things - traffic cone is used by VLC media player.

  * **Battery** currently has 3 discernable states: dying, not charging, and charging. A landscape-orientation battery would provide more width to display legibly clear battery-life increments. Because my Qubes machine is a bit older, and Qubes is a battery/CPU hog... this feels really important. In my 2 weeks with my Qubes machine, I've had to do emergency OMGWTF panics to find my cord, a few too many times, because I didn't realize I was down to such low battery power... because today's icon does not clearly nor legibly display that the battery is at 75%, 50%, 25%, or in "Warning, plug-in" mode. A charging icon would simply be a lightning-bolt sitting atop a battery, as Macs have.

I've had the same problem not that long ago - that would require us to change the default battery app, but this has to be doable without too much pain. @marmarek, will you be very unhappy about such a change?

  * **Wifi** Again, it should just be simpler and cleaner—ditch the gradients, to just tell me if I have a connection, what the strength of that connection is (number of bars), and possibly other information via the solid coloring of the vertical bars—but no gradients or outlines on the bars. TMI.

This is another of "existing solution" problem - I will think about alternatives. This is also an icon that does need a color - it's the color of the NetVM handling the connection.

  * Existing **clipboard** icon is unclear; the battery is a 2 rectangles, and should be the only artifact composed of 2 rectangles, imho, in the tray.

    * The "clip" signifying a clipboard may need some more work, or something different—like, scissors could work better—but for now, that's what the thingy in the below mockup is.

Yes, definitely. I like the clip, scissors would probably also be pretty easy to understand :)

  * **Whonix** icon appears 2x, and is unclear. The rounded padlock in a bright purple w/o a gradient is a clear semiotic, and stands-out nicely.

@marmarek , is this possible to implement?

  * **Qube Manager**
    
    * The Qubes logo is already used in the top bar, for the app menu—and those padlocks gotta go. I'm proposing this for a "Qube" icon, to span system-wide as a replacement for the padlock. This iteration of it should be solely to open the Qube Manager.

Yes!

  * **Devices Widget**
    
    * The cleanest icon and the clearest semiotic, is simply the USB icon. A device can be a drive, a printer, a keyboard... a fan, anything. Keep it simple.

Devices need not be USB, though - block devices and microphones are a common use case that has nothing to do with USB.

* **App Menu**
  
  * This is the one place it feels appropriate to use the Qubes logo, at the top—but it deserves to be cleaner than how it is currently executed. The gradient should span the full width and height of the button, it creates too much "busyness" when it's its own contained block.

Agreed.

  * Red should be reserved as a Qube color for `Service` and `Disp` qubes, only—as black is reserved for `dom0`. I've added a nice pink to replace red as a user-selectable color, and will note that in a separate issue.

I don't think this is a good idea - users can and will make their own 'service' type VMs, red should be manually selectable. Especially in case of various VPN-related or Firewall-related VMs, it's pretty natural for people to set them up manually.

  * The padlocks are a confusing semiotic, because typically those denote some unique security property. Here, they do not. I'm proposing a clean but un-branded "cube" instead.

1000% yes. I love the cube icon :)

  * `Templates` and `Disposable VMs` should have uniquely styled icons, to more clearly separate them from `Domains`.

Agree.

  * Apps that don't have a unique icon, should get a simple/generic diamond. Nothing that calls attention to itself.

That's another potential patch to xfce menu itself - but it seems pretty straightforward to do, and I love the idea.

  * The `Qube Settings` icon for each Qube should match the color of that Qube.

I love this idea!

  * The Logout and Settings icons, I just made slightly nicer versions of.

Logout: Another thing that would require some overwriting of XFCE defaults, but definitely doable.
Settings: it's beautiful, I love it!

  * Many other tweaks were made to the App menu itself (namely groupings and not colorizing app icons), that I will open a separate issue for.

Groupings I love, but not coloring app icons, while good for UI, seems to me a bad idea from security standpoint, that is, it makes it easier to confuse apps from different VMs (the same reason that we repeat VM name so many times in the menu: to avoid situations in which you want to run 'VeryImportantTopSecret' browser but instead click on 'RandomKittenBrowsing' one :) )

Of Note

None of this is related to the SecureDrop Workstation project. FPF got me a Qubes laptop, and I love Qubes so figured I'd offer this up on my own. :)

Thank you very much :)

[marmarta]

In brief, icons/visual upgrades that are (easily) implementable and can be introduced soon:

• cube icons for domains, their variants for templates/service vms
• icons for domains widget, cliboard widget, updates widget, devices widget, settings, menu (basically anything Qubes-specific)
  Things that are not easy to implement:
• better icons for wifi, battery

[marmarta]

Some ideas about coloring icons were mentioned here: #2523 (comment) , perhaps it is a better idea to overlay a square (or a cube?) with a color on the program icon instead of coloring it?

[ninavizz]

I question the value of visually signifying information in the app-icon, which at that point in the UI (the App menu), is redundant information to a user—unless there are other areas in Qubes where such information would appear? The user has already taken the action to look at what is available within a Qube, so even if nothing is colored in the flyout menu—they still know they're looking at options specific to that Qube, already.

In both the App menu and in the "Spaces" boxes, adding more information to the app icons distracts from recognizing them in any fashion. The only thing I can think of, would be to add a stroke/outline of 1px that would match the VM color. For the AppMenu, I don't feel that would add value—because ultimately I feel the Qube's flyout should carry that styling, not the individual app icons themselves. Again: Only so much information can be legibly recognized and put to use, from a 15x15 (or so) icon. We need to be judicious in determining which information needs to be prioritized, and how other information may be already getting communicated to users through behavioral choices.

I am also very curious to learn how the "Spaces" functionality is valued by users. I've only heard anecdotally from SD peeps, that they don't use it—so I'm curious how widely across the Qubes user community it is valued, before optimising things to do well in that specific part of the UI.

WRT the Wifi and Battery icons: aww, man! shrugs replacing the others will go a long way, at least. Is it within Qubes' control to at least give more spacing around the battery and wifi icons—or, more globally, to all tray icons?

[marmarta]

The application icons are also used on the panel itself (when they are running), in the Alt+Tab menu, and probably in some other places I forgot - while we could change what is shown in the menu without changing what's in Alt+Tab and for a running app, I'm not certain if it's good to have it different from what's in the menu? Although I may overestimate the need for consistency here. I think it's very important to have

I'm not sure what you mean by "Spaces" boxes (which may very well be because English is not my first language so sometimes things are not obvious) :)

About spacing about icons: I just discovered I can remove the frame manually (not sure how to make the setting be applied by Qubes installer, but it must be doable! (also: I've been using XFCE for years and never noticed the option :D). I'll look into providing more spacing for everything, because apparently the notification area has hidden depths I knew nothing about.

[ninavizz]

@marmarta See blab on "Spaces," above. I am probably the one using the wrong language, with it, here... as I'm sure you guys speak to it in the docs, that I just haven't found, yet. :)

WRT the app icons being colorized... that sounds like a great topic to discuss in a forthcoming UX meeting. Clearly I have a lot to learn on the topic, as I'm such a new Qubes user.

[ninavizz]

Also...

My own automatic associations with updating are more things like arrows in a circle or an arrow suggesting 'downloading' things - traffic cone is used by VLC media player.

Oops! Can you tell I don't use many FOSS products? Good call, confusion with that would definitely be bad. I'll mull on this and on the clipboard icon, some more.

There is no other way of getting that information through the GUI at the moment, though - I think it may be moved to Qube Manager or perhaps merged with some other widgets?

Yes(ish)! My Qubes laptop had been taken away for a week so FPF guys could do my Buster & relevant Template updates, but I just got it back, yesterday. After poking around a bunch, I feel like there's a LOT of consolidation that could happen between the disk drive icon, the "Q" menu in the right (that shows open qubes), and the App menu.

Also, it was never clear to me that the wifi was colored to correspond with one of my many red VMs. I'm not exactly sure why a VM with network access, would not be red. Likewise—the two-computers icon then turning into a wifi icon, feels very weird to me.

Bigger picture, it feels like a lot of these things could use some proper exploration, discussion, research, etc. I so appreciate your detailed responses to my points, above—really, really helpful insight and learning, for me! :)

Some good/clear immediately actionable things seem opportune, like replacing most of the padlocks with the cute new cube icon, grouping domains and templates and services in the app menu... give more spacing to icons in the tray, killing the white container-ish blobby thing in the tray, the show/hide on decrypt and login, etc.

Colors as a VM signifier across the OS (not just for applications), the devices widget, and how to perhaps consolidate functionality for a cleaner qube/app navigation experience, all feel like things that could benefit from richer discussion and more proper exploration. All, of course, that should correspond with funder expectations and dev prioritization against other needs.

I'll get ya stuff for the more easily actionable items, later this week or early next week. Looking forward to chatting through other stuff, as we all are able to find the time in the weeks ahead! :)

[marmarek]

Regarding tray icons, here you can find discussion leading to the current version: #2042
Keep in mind the solution should provide information which qube the icon belongs to - otherwise some malicious qube could pretend to be another. The current one doesn't fully do that, but at least you have qube color.

[andrewdavidwong]

See blab on "Spaces," above. I am probably the one using the wrong language, with it, here... as I'm sure you guys speak to it in the docs, that I just haven't found, yet. :)

These are usually called "virtual desktops." They are not a Qubes-specific feature (rather, a feature of Xfce4 in this case), so we don't maintain our own documentation about them. Xfce4 calls this widget the "Workspace Switcher."

[brendanhoar]

This is a very exciting conversation!

1. The Qubes menu design ideas are lovely.

2. I 100% agree with changing the devices icon, if only for a selfish reason: every time I glance at it, I can't help think that I'm looking at the WINZIP icon and being confused.

3. I just wanted to note that "spaces" aka "virtual desktops" are configurable. They default to 4, but I like to spread out my work and usually run with 20. For my use case, I therefore prefer the more compact widget icon spacing as I'm already using quite a bit of the real estate for the virtual desktops.

[ninavizz]

Nominating for discussion in near term UX Meeting #5523

[ninavizz]

Current iteration. Includes consolidating the Open Domains and Disk icons into a unified System Health widget, and a clearer Whonix icon. I really like this direction for the updater; with a number indicating the number of updates, and a simple green check if everything's been updated. Keeping the existing battery icon, as that's such a time-intensive one.

Devices widget and clipboard widget, still exploring other things on. Need to open unique tickets for each. I like Marta's idea for scissors for the clipboard one. The binder-clip still feels too fussy. For Devices, the chain-link speaks to behavior, but is also one of those "uugh, used for so many other semiotics, too" things. The USB feels like the most intuitive, even though it's also dreadfully inaccurate; wd need validation in testing if pushed, but more exploration still being done.

The Wifi icon I'd like to also simplify to this no-gradients direction... that also uses this same "bars" graphic for nothing connected. The two-computers semiotic I don't feel is intuitive for users looking to connect their wifi (which is likely the most common network task need to access), but I do feel users needing to access Ethernet/etc things will be able to find them up there. For the "connecting" animation, just pulsing the bars cd work. I can easily make animations, if you guys tell me what size/format.

[ninavizz]

Re-framing as an EPIC and cross-referencing with other issues, so that a majority of these things can ship together for a smoother change-management experience for existing users.

[ninavizz]

FYI, these awesome icons now exist from the good folks doing UX for the Gnome project: https://teams.pages.gitlab.gnome.org/Design/icon-development-kit-www/

I suspect this is where @marmarta got the 'lil flash drive icon used for the Devices widget, but—posting here as its relevant.

[ninavizz]

All icon mockups & delivered artwork related to the AppMenu, are in #5677, #5676, and #5447

[ninavizz]

Where I'm at right now, with noodling on Tray icons. Thoughts?
Below assumes that disk storage widget to be removed and either consolidated with Domains widget, or functionality added to Settings menu.

[brendanhoar]

I’m engaging in “butt-in context” with this reply. </ sorry> </ off-topic>

But more seriously, can the dom0/GUI-vm “group” be indicated by a set-off grouping such that dom0 is always to the right and the rest are forced to be grouped by VM (e.g. all in a VM are adjacent)?

[ninavizz]

So such thing as "butt-in" context; open critique is open. :)

@brendanhoar Is that something you would find value in? I hadn't thought to group things by VM, beyond separating the ones that are dom0/GUI-vm vs the others.

[brendanhoar]

Minor value at least, thought not near the top (wouldn't prioritize it over some other things). Having some colored and narrow [ and ] surrounding each VM-grouped set of icons would help a bit when one might wonder "why do I have two network managers" (reason: ethernet card pci attached to one, wifi card pci attached to the other and both net VMs are the same color). Dom0 ones should also be grouped and have black/grey [ and ] around them as well.

Though Might get a tad more complex on how to designate things once dom0 functions are broken out further: e.g. if there is a GUI-VM, Audio-VM, Storage-VM and "real" dom0 left with just managing all the parts. Though, who is to say you might not have multiples of each of those that should be offset by brackets and colors?

B

[eloquence]

Qube Manager
The Qubes logo is already used in the top bar

This is a significant usability issue in practice. We find in documentation, training, etc., it is difficult to refer in a precise way to parts of the UI like application menu or the Qube manager widget, when those parts have nearly identical icons ("click the Q menu" is ambiguous, so we always have to qualify it with "top left" or "top right", which in itself can be unhelpful for people with right-left confusion).

Does that make sense, and if so, would it be possible to prioritize replacing this specific icon in the near term, before undertaking more ambitious changes?

[ninavizz]

Created issue #5807 to track ALL 2020-possible "Tray UI" things, which are about half the things in this issue. Also created #5806 to address the comment from @eloquence, above.

[krishna727]

@ninavizz qubes app menu looks great but I think it could look even better if we sort the domain app-vms based on color.

[unman]

On Mon, Oct 05, 2020 at 04:45:20PM -0700, krishna727 wrote: @ninavizz qubes app menu looks great but I think it could look even better if we sort the domain app-vms based on color.

Can you explain what the advantage of sorting by color might be? An obvious disadvantage is that it privileges color as a primary signifier, which it is not. If (e.g) I create qubes: work-mail, work-dev and work-browse, and the same for "private" and "school", and assign "red" to browsing qubes, and green to firewalled mail qubes, I would likely want the menu to show them grouped by name, not by color. (KDE makes it trivially easy to sort the menu as one wishes, so I dont believe this will affect KDE users.)

[krishna727]

First big advantage is that there is an pleasing aesthetic look to it if we grouped domains based on color. Also your comment about color not being a primary signifier is not true since the qubes dev team has spent a lot of energy into making sure that the color on borders is secure so that user doesn't accidentally types something personal into a red VM ( like using work-browser VM instead of private-browser VM ) but yes I can see why you might want it to be sorted based on name since you are using a combination of name and color to distinguish between different domains.

[ninavizz]

@krishna727 This issue is for all icons across the Qubes OS experience; the app menu is being tracked via #5677

The above not shared as an admonishment, only for the pingback and follow-up discussion. :)

Semiotics can be highly subjective. As I'm aware, a majority of Qubes users do the color thing as a signifier of risk. As such, "risk" may not be a primary classifier for them; lifestyle could be. What is for work, and what is for personal—and within both, there are high and low risk things.

Ultimately, I'd like to see a fully custom App Menu created, with an option to display along whichever hierarchy a user chooses: color (ROYGBV), alphabet, oldest-newest, or newest-oldest, or use frequence, as an example of ordering options.

Until then, alphabetization is the most universally obvious and thus intuitively navigable to everyone.

I appreciate the suggestion a lot, tho, and will be sure to include consideration of ROYGBV ordering into a redesign of app menu things!

[andrewdavidwong]

@ninavizz, now that you can create and manage "projects" in this issue tracker (:tada:), please turn this into a project instead. (Following our issue tracking guidelines, every issue must be about a single, actionable thing, which means that we should never have "epic" or "meta" issues.)