Provide colorblind options for State column in Qube Manager

[mfc]

The yellow and green of the State column in Qubes VM Manager are hard to distinguish for colorblind users.

thanks for reporting @hdevalence

[marmarek]

@bnvk any ideas? Maybe different shapes?

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?

[bnvk]

I think replacing the green dot with an "On" icon and replacing the yellow dot with something else should work. While not colorblind, I've never been sure what the yellow dot actually means @marmarek ?

[unman]

@andrewdavidwong Confirmed this issue still arises in 3.2 milestone, although it should be trivial to resolve. Who is our go to UX person?

[andrewdavidwong]

Who is our go to UX person?

I'm afraid we don't have one at the moment.

[andrewdavidwong]

This issue is being closed because:

• This issue has the "Release 3.2 updates" milestone.
• Qubes OS 3.2 recently reached end-of-life (EOL).
• This issue has not been updated in over a year.

If anyone believes that this issue should be reopened, please let us know in a comment here.

[mfc]

this is still a problem with the Qube Manager so I will re-open, have changed Milestone to Far in the Future and added "help wanted" and "accessibility" tags.

[ninavizz]

Specifically for Qube Manager, I would advocate for using differently colored and shaped symbols instead of colored circles. So, proper Icons.

Google's (I know, I know) Material icon library is completely free and open-source, and is my go-to resource for icons to use in dense software contexts. Semiotics (metaphors) and decipherable rendering at size are of equal importance for usability and accessibility.

Gnome's icons, I don't consider to be fit for use at 18x18 and below, as they're far too complex with gradients and outlines and other details. They do have smaller icons, but "pictograms" is a better description of icons to meet this sort of need. Something dead-simple, and not very illustrative. Font Awesome is a popular community resource in FOSS, however I'm less a fan of it because its icons are a touch more "fussy" and thus a tad more difficult to cognitively parse, than those in the Material library. As evil as the Big G is, they do pay a large staff quite well to do nothing but sketch, design, test, and iterate on icons. Icon design is very hard to do well, and G's commitment to create and execute them well, shows. When I need to create custom icons, I'll use thenounproject.com as a source-material resource, and also as a generally brainstorming resource.

Coming back to Qube Manager status icons: It would help for me if someone could list all of the different "states" here. What exactly are they, and what do they mean? As I'm aware, there's currently a "green" and a "yellow" state. I can assume a lot from those colors, but would love to know, conclusively, what is really meant by those states. Also, if there are any others.

Happy to take a quick pass, if I can just get some clarity around what is being communicated to the user, first. :)

[ninavizz]

^ @marmarta

[marmarta]

Icons we have signify the following states:

• VM is running (green circle)
• VM is transient, so, either starting or stopping or weird (yellow circle)
• updates available (down pointing green arrow)
• template was changed, so VM needs restarting to reflect changes in template (gray arrows)

[andrewdavidwong]

There's also a gray circle when the VM is paused.

[ninavizz]

Thank you both @andrewdavidwong and @marmarta! And, gosh, that's a lot to depend upon for semiotics.

Questions:

1. Does "updates available" mean updates available for a qubes' template, or somehow for the qube itself, other than the template (or is it only used for templates?). Asking, as my machine is setup to automatically update things everytime I boot it.
2. The gray circle/paused status. What happens when the VM transitions into "weird" mode and is effectively frozen—does it then show yellow, or just "gray but does nothing when un-pause attempted"?

Thx! Looking forward to some happyplace design time, after wrestling smtp weirdness all day. :)

[ninavizz]

@marmarta Are animations an option—such as a pulsing circle, or a vertical barber-pole? Likewise... is moving the column itself, an option? In addition to potentially a few other minor changes to the existing Qubes Manager?

—ADDED BELOW IN EDIT—

Some initial thoughts...

• Color in Qubes as a differentiating semiotic, feels important to reserve for the qubes themselves. As such, different shapes or animated behaviors (animation for when a thing is launching, for example), feel important to add into the system of visual symbols/icons for Qube Manage.
• The current green-dot icon is very small, and has a gradient. With accessibility, contrast is key; and colors in and of themselves, are much easier to distinguish apart from one another, when objects are not obfuscated with gradients and other decorative elements. Likewise, when the object area is larger to begin with.
• The shape of the arrow icon and the gradient on it, make it too similar to the green dot icon for the two to be clearly distinguishable.
  • This one is easy, and I'll include that icon here, next week.
• As you can see on my Signal VM, the restart/updates icon is still cutting off, too. If it were not, though, it would also share a similar problem with the arrow. For a colorblind user, the dot, the "restart" and the arrow icon, all having the same gradient on it—they would all look too close to one another... even if one were green, another red, and another blue.
  • The cute-qube icons I tweeked the colors on, to make them contrast one another better than the locks did. The colored lock icons are all different hues, but they're hues of the same shade-value... so when reduced to grayscale, they all look very similar.
  • I never did an accessibility audit on those colors, but easily can, once the App Menu testing and pre-handoff tweeks are completed.
• Reducing "visual clutter" and keeping the total number of objects for users to cognitively parse to a minimum in a given view, is also important as a point for generalzed-usability.
  • Omitting the row of icons to the far-left, now that the cute-qube icons themselves communicate what type of qube each item is, seems like an opportune thing to do.
  • With the above, the "Running, Idle, Paused, or in-process" indicator should be in that first row. Then the qube name, then the "Update-y things" item, then the Template name.
  • Likewise, removing the icons on the menu items also feels important. Each of the icons are quite busy for their small size, and only the lower-half of the menu items have icons on them that have quickly intuitive semiotics. The latter is where value is to a user; if they have to work to parse an icon, then the icon only adds decorative value.

I can post mockups sometime next week, probably, once I can get the questions up at the top answered!

Nina's 4.0 and XFCE Qubes Manager

Marta's 4.1 and not-XFCE Qubes Manager

[DemiMarie]

@ninavizz You might want to rename the Fedora 29 qube ― right now it looks like you are running on a really old version.

[ninavizz]

@DemiMarie Unfortunately my Qubes laptop is not configured by me; it just runs a preset configuration customized by another team I work with. Trust me, I'm not fancy enough to have discovered this wonderful project/team on my own. Yes, I really need to get my own laptop to at a minimum run in-progress Qubes builds on. :)

[DemiMarie]

@ninavizz I just hope the Fedora 29 qube actually runs a newer version :)

[marmarta]

@marmarta Are animations an option—such as a pulsing circle, or a vertical barber-pole? Likewise... is moving the column itself, an option? In addition to potentially a few other minor changes to the existing Qubes Manager?

On animations: Generally yes, although I'm a bit wary of introducing moving things to places where they are not needed. One thing is that I have this association that moving thing on a computer screen = something is in progress, and it will end and stop moving. Other thing is that animations introduce visual clutter, especially if someone likes to just keep the manager running on a side screen or something like that - it will make it look like something's happening when nothing is.

On moving the column: sure, not a big problem.

On minor changes: sure, if they turn out to be really minor ;)

I completely agree that we need icons that actually 1. look like something 2. don't have random gradients. However, I really don't agree with removing menu icons. At least for me, they are quite helpful in seeing what a given option does at a glance (much faster to parse than words), and having the same icon on them as on the toolbar is helpful to remind me what things do.

[ninavizz]

On animations: Generally yes, although I'm a bit wary of introducing moving things to places where they are not needed. One thing is that I have this association that moving thing on a computer screen = something is in progress, and it will end and stop moving. Other thing is that animations introduce visual clutter, especially if someone likes to just keep the manager running on a side screen or something like that - it will make it look like something's happening when nothing is.

Yes, my only interest in an animated state, would be for when a VM is transient. Unless I am misunderstanding what "Transient" means? Agreed, an animated icon is only for when a thing is doing something that the animation stopping, will signify to a user "this is done!"

However, I really don't agree with removing menu icons. At least for me, they are quite helpful in seeing what a given option does at a glance (much faster to parse than words), and having the same icon on them as on the toolbar is helpful to remind me what things do.

Fair enough. I disagree, but in this moment that is just the two of us speaking anecdotally in regards to our own preferences. Yes, if the funding existed, I would want to go to town on icons in user testing, lol. As a general rule, if an icon is not clear in its semiotics, it won't serve that useful purpose for users and is "visual clutter." The current toolbar icons are both unclear to me, and feel like tasks better suited to an actions menu. But, those are things for a bigger discussion at another time. :)

[marmarta]

On animations: Generally yes, although I'm a bit wary of introducing moving things to places where they are not needed. One thing is that I have this association that moving thing on a computer screen = something is in progress, and it will end and stop moving. Other thing is that animations introduce visual clutter, especially if someone likes to just keep the manager running on a side screen or something like that - it will make it look like something's happening when nothing is.

Yes, my only interest in an animated state, would be for when a VM is transient. Unless I am misunderstanding what "Transient" means? Agreed, an animated icon is only for when a thing is doing something that the animation stopping, will signify to a user "this is done!"

Oh yeah, then definitely! and you have understood correctly - transient should never be permanent, it means that VM is starting or stopping or completely exploded somehow :D

[ninavizz]

Okee doke @marmarek @marmarta a first stab at this!

Within this direction, are also a few minor tidy-ups of Qube Manager. The goals, being 1. Facilitate improved legibility, and 2. To align semiotics used here, with the new app menu (so, bold/not-bold = running/not-running, same use of icons).

• All fonts now use Source Sans Pro family
• Qubes that are not running are a dark gray
• Qubes that are running are black
• The far-left two column headers are visibly gone
• The top sortable column header row is taller, and the gray divider lines have some white padding above and below them
• The column header text is semi-bold
• Column widths expand to support stupid-long qube names (such as those darn Buster templates the SD team uses)
• A "sort" control was added to the row of buttons at the top, as an itterative step towards the most recent mockups in #5679
  • Categories in this sort dropdown would be: Status, Color, Type, Ascending, Descending
  • "Type" would include roles (so App, Template, Disp-Template, Service, Standalone, Admin, Manager)
  • "Status" would prioritize in order: Launching, Running, Paused, Frozen/Borked, Needing Reboots, Needing Updates

States

• dom0, personal, sys-firewall, sys-net, sd-app, and sd-proxy are all running
• signal is launching
• personal needs to be rebooted as its template has been updated
• work is borked/frozen
• fedora-29 and fedora-31 and fedora-33 all have available updates, that upon clicking the icons will take the user to the Updater tool per #6635

[marmarek]

Currently the table in our Qube Manager has alternating white/light gray rows. Which is useful to follow which info on the right is about which qube on the left. Is this intentionally gone in this design? Without that, it requires some effort to, for example, find what is IP of qube 'untrusted' on the picture above.

[ninavizz]

@marmarek I do not have those alternating white/gray lines on my own 4.0 Qube Manager—but I used to. You guys had them, took them out, then put them back in again? Oyy!

So: personally, I dislike them, because they feel busy and heavy-handed—but to your functional issue cited above, they do serve a purpose. I updated my wireframe to show pale gray lines that do not go the full width of the table—such that the icons on the left are not made too busy.

Also of note, the pale blue icon for launching a VM, is supposed to be an animation.

What do you think about this? I'd also forgotten to bold a couple items to be consistent with their rows, fwiw, in the PNG above.

[SvenSemmler]

You guys had them, took them out, then put them back in again?

This might depend on the theme you choose in XFCE?

Which reminds me: how will your new design interact with themes? ... will there be a dark mode?

Dark mode is very important: I sit 10+ hours a day in front of the screen. My eyes just can't take all the white. Light themes look a lot prettier but after a while my eyes and head start to hurt. Even with Redshift etc.

[ninavizz]

@svensemmler I have been running the Atlanta theme in XFCE, and changed it to the default—and, no lines. Regardless... it feels weird that desktop themes would impact core UI components, such as how tables are rendered.

Thank you for the flag on Dark Theme, tho! Generally I don't like this whole (gestures arms in the air wildly while making faces and rolling eyes) theming hootenanny that Linux people love. So, will potentially be a bit of a grouch about it. That said, the Light/Dark theme paradigm I do agree is important, for basic usability things—and I want to support for this!

Which version of Qubes are you running, Sven? I do not believe 4.0 does Light/Dark theme support.

If you're comfortable sharing screenshots here on GH, it would help me a lot if you could maybe send me a couple screenies showing your custom Qubes widgets, and Qube Manager, all in Dark Theme—such that I can work with those as a baseline for how things currently look? Same, with File Manager, just so I have that as a reference? Assuming you use some kind of a very general/basic kind of a "Dark" theme? You also have my email, and if you're not comfortable sharing them here I'd love to see them via email, if you'd be comfortable with that. nina at research.qubes-os.org, or my gmail are good.

Once I have a sense of how Dark Theme works in QM for 4.1 I will hop to making a version of that, for this.

...and, yes, I am getting a machine to run 4.1 and test builds on, hopefully in a couple weeks.

[SvenSemmler]

@ninavizz since that's a different but related task/topic I took the freedom to start #6736

[marmarek]

What do you think about this?

I find white/gray pattern a bit easier to follow in a wide table, but IMO this is good enough too.

[ninavizz]

I find white/gray pattern a bit easier to follow in a wide table, but IMO this is good enough too.

Ohh, but you are @marmarek and I want you of all ppl to be happy with this stuff!

So, the biggest difference between the current table'd layout, and what I'm proposing in #5679, is that the "rows" in the newer design are not literal table rows with 1:1 columns to data-type/column. As such, that iteration on QM has a far narrower total-width of the view, which makes it easier to visually scan and to find things. I have much of the information hidden in my own QM (as you can tell from the mockups), to keep that burden low, for myself, but I could see how for power-users that could be problematic.

TL;DR, I'm fine exploring how to do the alternating line background colors, as it would clearly make you happier. :) Will do for both light and dark, in a next iteration.

[ninavizz]

Updated. Needs adjustment for accessibility contrast!

[marmarek]

I love it! The reason why I like this alternating white/gray pattern is that now I don't need to follow the whole row until the last column. I can look at the first column, see that "untrusted" is gray, and then look for gray at the last column around that height.

[ninavizz]

@marmarek Hooray! My only bias against it the gray background across the whole table, is that it reminds me of old DOS-era interfaces, lol. :)

Will post artwork for icons, here, at some point. Who will be building this—@marmarta? If it is not Marta, I'll need to invite whomever else it is, to my spec tool, Zeplin, so that they can get all the hex and pixel values, and the gradient from the headers.

Would also love to know how to best get the spinner handed-off... altho for SecureDrop's client (also done in QT) I just delivered an animated GIF. If that's ok, will do the same, here!

[andrewdavidwong]

It's also helpful if hovering the mouse cursor highlights that whole row.

[ninavizz]

A unique hover color for the row the mouse is hovering over, I definitely want @andrewdavidwong! One thing I have learned while working with the SecureDrop team building their SD client in QT, is that QT is a pain to work with for UI styling. So, I wanted to keep the scope on this initial push, lean. I don't know how the existing QM does things (and my qubes laptop is packed as I just returned from travels), but if that is not currently in QM I definitely want to see it added, at some point!

[DemiMarie]

Is GTK easier to work with from a styling perspective? Also, does SecureDrop have any ideas on GTK vs Qt and/or GNOME vs KDE?

[ninavizz]

@DemiMarie I would love to discuss and compare the detailed differences between Anabaptist communities, on GitHub (my favorite of all Issue segues), but promised Andrew I'd be better about staying on topic, myself—while also encouraging others to do the same.

Yes, the entire SecureDrop team has many opinions on many things. Too many, in fact, for their own sanity, some of the time.

I'll work on coordinating a knowledge-share between teams, sometime. But let's keep the GTK vs QT and GNOME vs KDE chatter to the forums or Wire, for the while. Especially since this issue is soooooo close to being closed. <3