Make colorized app icons optional

[ninavizz]

This is a child issue within the epic #6665

---

The problem you're addressing (if any) Colorized app icons to communicate a qube's color in a user's App Menu, is a longstanding convention in Qubes OS. However, doing as much obfuscates the app's icon. Because the app icon provides visual information users may desire access to in the task of either selecting an app in the App Menu, or a window the Task Bar, this presents a non-trivial usability problem.

The primary "problem" the colorized app icons sought to solve for, is reinforcing with users which colored qube they are about to open an app into, in the App Menu. A secondary problem the colorized app icons solve for, is showing which qube a window belongs to in the Task Bar. A sibling issue I opened to follow-up this up with, proposes updates to the Task Bar buttons, to adjust for this issue's suggestions going in.

Two different solutions to the first problem, Bessie and Jackie, were developed for the App Menu Redesign project. Solution opportunities have also been explored for the second problem, but those should be discussed in their own issue. With a new App Menu launching with (hopefully!) 4.2 the time is right to make this forced convention optional, with a better solution to the original problem also being deployed.

Describe the solution you'd like It had been my hope to eliminate colorized application icons altogether, in our updated App Menu. However, enough users in the App Menu Redesign Survey felt strongly against that. As such, a compromise to both meet the needs of longtime Qubes OS users desiring colorized app icons, as well as newer users that find colorized app icons to be problematic, is to make the colorization of app icons to be optional.

1. A global "Colorize app icons in menus" control in the Qubes Global Settings panel.
2. If users check this box to turn-on this feature, then the below setting would become enabled in each qube's individual Settings pane. I would suggest placing this control on the Applications tab, and not the first tab, so that as the user chooses different opacity values the icons colorize to that opacity in real-time... thus ensuring the legibility/coloration balance they desire.

Where is the value to a user, and who might that user be? For people who depend upon "visual" information more than upon "written" information, it is frustrating to have the visual information of an icon obfuscated when looking for an app to open in the App Menu, or a window item in the Task Bar.

The design problem that the colorized icons sought to solve for, will be solved for differently when the new App Menu is deployed in 4.2. Creating yet another problem by forcing the colorized-icons solution upon users, is therefore problematic.

As an example: when I go to open Signal, I look for the cyan ovular icon; when I go to open Firefox, I look for the fire-orange and electric-blue swirly-circle icon; GIMP, is black and gray and an irregular shape. It is a cognitive strain for me to have to read every app name, always—to find an item to select. My own habit, is to first find the icon, and then to read the name to double-check I have the correct app. In Qubes 4.0, I cannot do that.

Related, non-duplicate issues

Lots about how coloration is done of windows and icons, in Qubes OS, has been discussed in #2523. However, coloring over existing colored information, is not the only solution to the core problem colors seek to solve for, in the context of a user seeking to open an application from the appmenu.

[ninavizz]

In the recent AppMenu Redesign Survey, of 880 completed responses the question that received the strongest negative response to any of the questions, asked users if they liked that the app icons were not colorized per qube in each of the two prototypes presented.

EDITED after discovering a copy/paste error in my data sheet. Yet to QA everything, but the below/newer numbers better reflect what I've been observing as the trend, for the weeks the survey was live.

6% of users responded that they Strongly Disliked the omission of colorized app icons. 16% responded that they simply Disliked the omission of colorization.

11% and 24% of users responded that they Loved or Liked the omission of app icon colorization, and 11.6% of respondents simply had not noticed the omission in the two prototype videos.

31.3% of all users felt Neutral towards the omission.

While the combined 22% negative sentiment to removing the app icons was the strongest negative sentiment in the survey, the 31.3% Neutral was also the strongest indifferent sentiment in the survey. A 35% positive sentiment, given the negative and the indifferent sentiments, has me hypothesizing that with a good alternative to reinforcing qube color in the new app menu, that in the use context of selecting an app on one's own device, visual access to each app's uniquely colored icon will be desirable.

A final note: Should we choose to launch with colorized selection bars in the new App Menu (as suggested in the Bessie prototype), such a visually radical option would be made to be optional in a control panel for customizing options within the new AppMenu. So, yes, the feature this issue suggests, would effectively compliment that (and any additional colorized sub-menu pane decoration).

[GWeck]

Letting the user select icon coloriztion by VM is a good idea, because some VM colors and/or classes might be good for colorization, while other might be more expressive if the original colors are kept. For example, a red, untrustworthy VM might color its icons red in order to warn the user, while a template VM, usually black, might keep the original icon colors inorder to help the user find an application more easily.

On the other hand, it could be useful to provide a system-wide colorization option additionally, for users who would like to have everything look the same.

[marmarek]

Yes, global and per-qube options are totally possible. The interface would need to carry this information, though - we need three (four?) states in the qube settings:

• enabled
• disabled
• using system default (which is: enabled/disabled)

Technical note: In practice, I think the "global" option should really be set for a GUI domain, not really global. In most cases it is the same in practice (user have just one GUI domain - whether that is separate one, or dom0 doubling as such). But in the future, if we'll ever have multi-user option (with separate GUI domain per user), then it will become natural part of the user's settings. Plus, it will be more convenient this way, as the icons are in fact handled in GUI domain itself. It doesn't change anything regarding the UI.

[ninavizz]

@GWeck I had not even thought of that, great idea!

@marmarek I don't so much consider "Default" to be a state, however, with allthings involving policy files, I think surfacing to users whatever the "default" settings are, is important. Context matters a lot. Also, I have yet to get 4.1 on a test device to really poke-around to see what this GUI VM is like. Yet to procure a test device to enable that... but I look forward to seeing how everything looks in 4.1 just as soon as I can. :)

[marmarek]

I don't so much consider "Default" to be a state

I mean, if we have some global knob, that can be overridden on per-qube basis, we have now those states of a per-qube setting:

1. it is controlled by the global knob (whatever its state is)
2. it is overridden for this qube, with state "enabled"
3. it is overridden for this qube, with state "disabled"

The final effect will be the same whether the thing is enabled via per-qube override, or via the global knob. But the distinction does matter when you toggle that global knob - for qubes with "controlled by the global knob" it will change their setting, but for qubes with setting specifically overridden, it will not.

That's the interaction of global setting and per-qube setting we use in various places already (see for example "networking" in qube settings - there is "default" value, which follows the value in global settings). It is totally possible to design it differently, if you have some specific interaction in mind.

[ninavizz]

@marmarek All helpful context—TY for sharing! I'm not sure the Network Settings stuff is 100% analagous, but I'll look closely at both, together, along with the rest of the per-qube vs global settings paradigms, while working on these.

[ninavizz]

@ffsec I like this idea, as a possible iteration to making any app icon decoration optional. However, it also misses the reason why the optional colorization is being pitched, in the first place.

Important context: I began looking at what the colorized-icon feature exists to solve for in the first place, by considering the core design problem the existing feature sought to solve for: "How to communicate the domain an app is about to be opened in or is running within through color." This core design problem I feel, should remain the focus, vs how to make the current solution in production suck less. If that makes sense.

The new solution to the aforementioned design problem that is proposed with the App Menu redesign, is through colorizing other/related UI bits, while leaving the app icon entirely alone. The solutions you offer, are certainly an option—but will introduce other problems. Namely, that in a list-view it will create a very cluttered list for users to make their initial decision from.

I'd like to get an updated app menu developed, first—and work to solve the core design problem, by looking at other areas of the UI not as loaded with semiotic details important to the user as app icons are. If that makes sense. If users remain unsatisfied with that, then I'm ok exploring an additional feature to iterate on the existing solution—but I don't want to remain locked-into one feature that is only one solution to the core problem.

If you have thoughts on other ways to solve for the core design problem, I would love to hear them! I just really want to get away from the existing solution, before zooming-in on how to improve the existing solution—because the existing solution is so problematic, for the reasons expressed above. If that makes sense.

[ninavizz]

So imo the icon decoration is an essential (security) feature in Qubes OS and it won't go anywhere. It just can't.

Right. That's why this issue seeks to make it optional. For many users, it is a hinderance; whereas for others, it is embraced. The new app menu is likely to have a "Favorites" tab and possibly a "Recents" tab. In both, VMs and their colors are signified differently than colorized app icons (shown below).

As I'd said, the same "Problems" will always exist. They can be solved better, though, than taking information away from one place (the application's icon) to replace it with other information—and only in a fashion available to fully sighted users. I encourage you to follow the development of #5677 and to cite additional design problems you feel may have been overlooked and are in need of addressing, once alternate means to handle the primary two design problems are in place.

[ninavizz]

@ffsec

1. Again, this issue is to make colorization "optional." Not to outright eliminate it.
2. In order to best support a goal of eventually eliminating it, I am keen to understand all the design problems the icon colorization is sought to solve for with users, today. I identified two, up above in earlier comments—with the App Menu's functionality, being only one of them.
3. A design brief was written at the outset of the App Menu project (and is in its issue), clarifying its scope of reach.

Should you read it, you'd see that, yes, this capability does seek to prioritize the needs of users new to Qubes. Which does not mean that it's ok to also make things suck for power-users; but, it does mean that we are seeking to optimize the adoption experience to reduce new user attrition, and to better support "regular folks" (not developers) with high security needs (so, Journalists, activists, people who are not Linux native users, etc).

I understand that you're not speaking to the App Menu. What would help me understand your concerns more tangibly, would be if you could simply form a "design problem" statement for each and every concern.

Example: "I want to see which VM an app belongs to, when I have many app icons on my desktop to open those apps from."

Is the problem in the above cited use case the only other one you can think of, beyond the two I identified (App Menu and Task Bar buttons)—and supporting users in DEs other than the OEM configuration?

A design problem statement does not factor in approaches to solutions, it only summarizes the problem. That keeps things open to understanding the breadth of solution opportunities to consider. The colorization "sucking" is not why I consider colorization to be a poor solution to all problems; the inadequacy of colorization as a solution, is that it removes some information to show other information—when both pools of visual information should be able to co-exist. I'm not trying to make colorization suck less; I'm trying to solve the problems it's currently embraced as a solution for, with better solutions.

Finally: None of this has been done, without proper research. In the survey of +880 users, most use an XFCE app menu or i3's DMenu. I will be publishing my formal research findings (from the survey and interviews with trainers), in the next week or two—but please do know they are forthcoming, and that none of this is being done in a vacuum. Below is what the users who participated in the AppMenu survey, said about how they use Qubes:

[ffsec]

I give up. Good luck with whatever you are trying to accomplish, you will need it.

[alimirjamali]

I have been working on additional Icon Effects. The default tint, anti-aliased high quality Thin/Thick bordered icons, icons overplayed on VM label color, inverted icons for untrusted qube as well as untouched icons which I use for my highly trusted personal qube.

Project consist of a forked version of qubesimgconverter python library with my additional effects, forked qubesappmenus library and custom qvm-appmenus-tt to apply the per VM effect to the Appmenu. And a forked icon-receiver daemon to apply per VM effect to the icons of running applications.

The tools look for an special key in VM features (i.e. ttfilter) to apply custom icon effect per VM. I have been using it during the last few couple of weeks personally and I am happy with how it turned out. Screenshots are available on the Github README.md pages I shared above. Here is a sneak peek (two tinted Firefox icons, two thin-bordered ones, one thick-bordered, one overlay, one untouched (Firefox from my personal qube) and one inverted paranoid icon (Firefox of untrusted qube):

Additional idea would be alpha-compositing small VM Icon on bottom right of the Application icons. I have written the alpha compositor for the qubesimgconverter library (used for high quality thin-borders). But I am looking for more ideas.

I am working on other aspects of the project. Like adding the ability to send App Window of qube to the desired Workspace (e.g. by have a ttworkspace tag in target VM features and getting PID from qvm_run subprocess. I am also working on rewriting my custom label maker in Python. Once the project is fully finished, Hopefully I could submit it as a potential community project in a separate Github issue.