Redesign and improve the VM Settings: Applications tab

[marmarta]

Qubes OS version (if applicable)
R.4.1

Brief summary
Make it more flexible (including app icons, open-in-dispvm setting and possibly more.

In particular: include way to use QubesOS/qubes-core-agent-linux#290

[marmarta]

Current proposal:

[marmarta]

@DemiMarie , @andrewdavidwong , @marmarek , any critique/opinions? The former tooltip contents (incl. .desktop file name) are the same.
I plan to add icons in next iteration.

[DemiMarie]

@marmarta Looks good! I wonder if “Open Files in a Disposable VM” is a bit too concise, though. What about, “Should this application open files in a Disposable VM?” If that is too big for the actual display, could it be in some sort of discoverable help?

[marmarta]

@marmarta Looks good! I wonder if “Open Files in a Disposable VM” is a bit too concise, though. What about, “Should this application open files in a Disposable VM?” If that is too big for the actual display, could it be in some sort of discoverable help?

I can add a tooltip to the header. I could also add a paragraph describing what's going on in this tab between the refresh button and the table. Hmm, that might be a good idea...

[andrewdavidwong]

I wonder if “Open Files in a Disposable VM” is a bit too concise, though. What about, “Should this application open files in a Disposable VM?”

I'm still not sure what exactly this means. For example, let's say I check this box next to Gedit. What actually happens? Does it mean that, whenever I open a file with Gedit, it gets opened in a new DisposableVM (in which Gedit starts)? What if I already have Gedit open in the AppVM, then I use "File > Open..." inside of Gedit? That instance of Gedit is already running in the AppVM, not in a DisposableVM.

[andrewdavidwong]

any critique/opinions? The former tooltip contents (incl. .desktop file name) are the same.
I plan to add icons in next iteration.

If not already possible, it might be nice to be able to sort the columns. For example, a user might want to sort the applications alphabetically or sort all currently checked boxes to the top.

@ninavizz might be able to offer better UX feedback.

[marmarek]

For example, a user might want to sort the applications alphabetically or sort all currently checked boxes to the top.

Sorting is already possible, I think the current draft (newer than the screenshot above) is sorted by "checked" by default.

[marmarta]

Current draft:

[marmarta]

(Icons are ATM only for previously-selected apps but this will improve)

[marmarta]

I wonder if “Open Files in a Disposable VM” is a bit too concise, though. What about, “Should this application open files in a Disposable VM?”

I'm still not sure what exactly this means. For example, let's say I check this box next to Gedit. What actually happens? Does it mean that, whenever I open a file with Gedit, it gets opened in a new DisposableVM (in which Gedit starts)? What if I already have Gedit open in the AppVM, then I use "File > Open..." inside of Gedit? That instance of Gedit is already running in the AppVM, not in a DisposableVM.

I have an updated description in the screenshot above, is this a bit clearer for you?

[deeplow]

Question: what happens if the Default DisposableVM Template is not based on the same TemplateVM as the AppVM (i.e. may not have the same programs installed)?

[marmarta]

Question: what happens if the Default DisposableVM Template is not based on the same TemplateVM as the AppVM (i.e. may not have the same programs installed)?

The same as when you click "Open in DispVM" in a file manager and the template has no app for a given MIME type.

[ninavizz]

• I would reverse the ordering of the "Description" and "Open in DispVM" columns. Right now it appears like there's 2 grouped-columns of selectable things... then it's confusing that these two groups of selectable things have different categories?
• Not clear why there's an "Ok" and "Apply" button. I'm assuming that might be a Linux/Windows convention, but to keep it simple I'd opt to just do a clean Cancel/Ok pairing of buttons.
• Icon column, I'm not terribly keen on; adds clutter w/o clear value. Also confusing that icons are all colored blue, in a yellow VM.
• Progressive-disclosure pattern for the "Experimental" text, I recommend. Can mock something up for ya.
• A lot of characters and words. I can also think about 'cleaner' language.

Open Question: I'm trying to install Signal in one of my Qubes. I followed the instructions on the Signal website, downloaded and did all the things from the Firefox in that Qube, and Signal is still not showing-up in the list. I want a button or informational panel that can open from here, to walk me through what it is that I'm missing that I need to do. Yes, I've rebooted many times.

[DemiMarie]

• Not clear why there's an "Ok" and "Apply" button. I'm assuming that might be a Linux/Windows convention, but to keep it simple I'd opt to just do a clean Cancel/Ok pairing of buttons.

It’s the difference between “save” (Apply) and “save and exit” (Ok), which might be better names.

[ninavizz]

It’s the difference between “save” (Apply) and “save and exit” (Ok), which might be better names.

Yes, I understand that; I just question the value of that many buttons, vs the clearer 2-button binary. The 3-button pattern is increasingly falling out of favor as more modern and simpler paradigms have become more dominant.

That said, my Qubes machine is shut down and I'd also not want to introduce a new pattern wildly different from all others, if the 3-button pattern is common elsewhere.

[deeplow]

• Icon column, I'm not terribly keen on; adds clutter w/o clear value. Also confusing that icons are all colored blue, in a yellow VM.

Maybe the icon can just on the "Application" collumn, just before the name. Not sure how hard Qt can make this.

[ninavizz]

Maybe the icon can just on the "Application" collumn, just before the name. Not sure how hard Qt can make this.

I question the value of showing icons at all on this panel, but if they are shown they should be structured in their own column; just not with a sortable/visible header, and the checkboxes should be to the left of the icons. Can do a quicky mockup tonite.

[ninavizz]

@marmarta FWIW, I'd MUCH rather work on anything Qubes atm, than the wretched project from 2 months ago that I've been fighting to close out for the past 2 weeks. Really, today has got to be the day I wrap it, so I can come back to Qubesland...

[marmarta]

Maybe the icon can just on the "Application" collumn, just before the name. Not sure how hard Qt can make this.

I question the value of showing icons at all on this panel, but if they are shown they should be structured in their own column; just not with a sortable/visible header, and the checkboxes should be to the left of the icons. Can do a quicky mockup tonite.

Yeah, the header should be empty (this is easy); I can move checkboxes, also easy. I don't think a mockup is necessary (buuut if you will have some time there's the whole menu stuff... ;) )

[marmarta]

It’s the difference between “save” (Apply) and “save and exit” (Ok), which might be better names.

Yes, I understand that; I just question the value of that many buttons, vs the clearer 2-button binary. The 3-button pattern is increasingly falling out of favor as more modern and simpler paradigms have become more dominant.

That said, my Qubes machine is shut down and I'd also not want to introduce a new pattern wildly different from all others, if the 3-button pattern is common elsewhere.

Yeah, we do use that pattern, and it's fairly useful because some changes may have lasting effects, applying other changes can influence other things etc. - also, it's nice to say "ok, current changes are fine, let me save the work before doing more changes". It's also a common pattern among Linux (and Windows, for the matter) tools.

[ninavizz]

Yeah, we do use that pattern, and it's fairly useful because some changes may have lasting effects, applying other changes can influence other things etc. - also, it's nice to say "ok, current changes are fine, let me save the work before doing more changes". It's also a common pattern among Linux (and Windows, for the matter) tools.

This is a frequent topic of discussion at design conferences, with UX researchers and designers shuddering everywhere and Microsoft people quietly strolling away while whistling and staring at the floor... lol. If it's a common pattern in Qubes, then users will expect it and such I say stay! I just won't tell my friends who've wrote entire thinkpieces, attempting to bury the paradigm, hehe.

Yeah, the header should be empty (this is easy); I can move checkboxes, also easy. I don't think a mockup is necessary (buuut if you will have some time there's the whole menu stuff... ;) )

The menu stuff is absolutely thee priority, especially per emails last week. You shall receive PDFs within a few days, and my brain very much looks forward to returning to its interaction design happyplace. :)

[andrewdavidwong]

Some notes (mostly on language):

• Let's please use our own terminology more consistently (Use our own terminology more consistently throughout the system #4723). It should be DisposableVM, not Disposable VM or DispVM.
• "in a Qubes menu or desktop shortcut" is confusing, since there is nothing called "the Qubes menu." I think the former is referring to the "Applications Menu" (as Xfce calls it).
• There should be no comma in "...shortcut, and performs..." (since what comes after the "and" is not an independent clause).
• "This feature is experimental and may not always work" is a turn-off to users seeking a stable, reliable system. Such users do not want to mess around with something that may not work. I suggest hiding this feature by default and perhaps making it opt-in for users who wish to experiment.

[deeplow]

Was the opacity selection a result of user feedback? I feel like this approach is too granular. I would suggest instead an option in the qubes global settings (or menu settings) called "colorize applications". Just with a toggle. No %. It then would apply to all qubes.

[ninavizz]

@andrewdavidwong It is a UX best practice to addend words for things like table headers and buttons. The full text "Disposable VM" is problematic as a full table header or button because of its lengthy character-count, and yet "DispVM" or "DVM" are problematic in regular writing contexts because they are unclear. In a UI (vs in a paragraph) word length matters, both for the increased cognitive friction in users making decisions in the context of other tasks, and with placement on the objects. Obvs, this is a bigger discussion than just for this pane, and I'd love to have that discussion now, so that we can clarify the standard to apply across the board.

In the black bubbles, my suggestion is to dynamically input the named disp-vm from the user's chosen setting on another pane; not to put the word dispvm there. :)

@deeplow Yes, I believe there should also be in the Applications Menu Preferences pane as a global option, but when it is enabled we then introduce the usability problems with today's feature: different colors obfuscate app icons, differently. That's just the nature of a global aesthetic treatment applied to a multitude of different backgrounds and overlay colors.

Today's coloration of icons is a very problematic "device" from a usability perspective, and yet is a critically important security vehicle for current users who've already trained themselves to today's Qubes UI quirks. Sure, we could just not do icon overlay coloration and do little dots next to each icon, instead—but in the appmenu that becomes quite busy, so more holistic solutions were offered in the new design options. And understandably, such a significant shift in semiotic markers from one place to another, felt problematic to many users. Do you design to meet existing user needs, or to suit product growth and new user needs? This feature would help meet both needs.

I also do not know when Marta might be able to implement the global-level feature, so until then this could still help ease the burdens with today's coloration. It is also common for accessibility and usability, when an OS does opacity "things," to give users agency in choosing their opacity.

[ninavizz]

Edited (again!) to remove "VM" nomenclature from the UI. Updated layout, too.

[DemiMarie]

@ninavizz Can I just say WOW??? What you are talking about just seems like magic to us tech types 😄. Seriously, thank you SO MUCH for your hard work!

[GWeck]

One more idea about colourizing the icons: You could leave the icons in thier original colour, so that they are easiliy recognizable, but put them on a background coloured like the VM, somewhat like framing the VM's windows in that colour. So for instance, a red and a green firefox would look like that:

[ninavizz]

@GWeck I saw you took the appmenu survey (thank you for that!)... and I did the background-coloration on hover for the Bessie prototype. Yep, background coloring is my preference for how to move forward with the coloration convention—but (understandably) many kinda freaked-out at the idea of not having colorized icons anymore. Baby steps! :)

If the "Favorites Bar" on the left of the menu is ever implemented, I suspect keeping the backgrounds colored not just on hover, but when an app is not being hovered on, will be sought. TBD tho, as that feature is not a priority for a while—and by the time it might be, users will have already adjusted a lot to the new app menu, and other ideas (such as widgets for individual running VMs in the Task Bar) may be in the mix by then. 😃

[ninavizz]

@DemiMarie Pretty much everything you tech types do, seems like magic to us humanbrain/design-y types... so I bow in reverence to your skills-fu, as well. :)

[ffsec]

Some time ago the reaction to that view would have been "eye cancer". 😉

Yep, background coloring is my preference for how to move forward with the coloration convention—but (understandably) many kinda freaked-out at the idea of not having colorized icons anymore. Baby steps! :)

At first glance this might look like a possible solution, but it isn't.
Icons come in different colors and shapes, so while some might be fine, others won't and the smaller the icon, the worse it gets. At the same time it might open a new attack vector, since the icons are coming straight from the vms. A compromized vm might try to spoof label colors.

For example let's take a completely red icon (32x32), how do you color it if the label color is blue?
If you paint only the transparent background, the blue color won't show at all. Writing complex code, trying to detect shapes and define some area as "paintable background", good luck. So the only possibility would be to shrink the original icon and reserve space around it for the label color. In this example it would result in a large red square with a small blue border around it.
So how much space do you reserve for the border?
1px?

Can you see it if the icon sits on a dark background? Can you tell the color is blue? Or could it also be purple or any other similar color?
Obviously a thicker frame would be needed, which means, you will have to shrink the original icon even further. This will not only result in ugly icons, but is also a huge problem when it comes to smaller icons. How does a 16x16 px icon look like if you shrink it down to add a thick colored border around it? Will you even be able to recognize the icon afterwards? Highly questionable.

Now back to the security risk.
For simplicity I'll just take the icon with the red background from above as example. Let's say a vm with an orange label generates a firefox icon with a red background. If you add the orange border you will get:
1px:

2px:

...

I guess you see where this is going. Just don't do it.

[ninavizz]

@ffsec I'm not sure exactly what you're responding to—but, a few quick points.

1. This issue is for the Applications Tab in the VM Settings window. The topic you're speaking to, is how app icons are colorized by the system. If icon colorization, specifically, is something you'd like to speak to, please create an issue for that—per the Issue Guidelines. Yes, I am a frequent offender of the off-topic segues, but we're all working on getting better about that to keep Issues more focused. :)
2. What @GWeck and I were discussing, was the idea of colorizing the selection bar in the AppMenu, behind an app name and it's corresponding icon—instead of colorizing the icons. As demonstrated in the "Bessie" video I shared on the AppMenu Survey. So, no—not putting a colored square background shape behind icons. Something else, entirely. Forcing colorized app icons upon users, is a major usability problem.
3. Users should also not be making security decisions based on color, alone. If that were a practice we were encouraging, than nothing should be colored by the system. As with the topic of colorizing app icons, that would also need to be a separate Issue.

Thx!

[ffsec]

@ninavizz
You wrote "background coloring is my preference for how to move forward with the coloration convention", which suggested a general coloration practice, rather than just background coloration in one particular area. Afterall the OS should have a uniform look and feel instead of having different practices everywhere, so if you colorize the background of the app menu, you should be willing to use this practice for other things aswell.

From reading your comments throughout github, I feel like you can't handle critics very well, is that possible?
I've already evaluated many things you are coming up with now and I know the problems you will run into in many cases. I'm just looking at the larger picture and try to prevent problems before they even come up. I could explain now why background coloration is a bad idea for the app menu background in particular, but I don't really think you'd like to hear it.
So I'll just summarize it with: Don't do it, thanks!

[ninavizz]

@ffsec I really do want to have these discussions with you, but I also don't see you reading what I wrote—especially just above, and on another issue. Really, the entire team is making an effort to step-up keeping on topic in Issues, and I already asked you once in a different issue to please take the discussion about colorization to #2523 or another related issue. This issue is for the Applications Tab in the VM Settings window. I realize I am a big historic offender of this, but I am also stepping-up my own game to be better at this.

Defending design decisions is part of the iteration process; it's very different from "getting defensive." If I put up a defense on a decision based on systemic considerations I've looked at (and were not communicated explicitly in an issue) and those defenses still don't hold up, that helps push a systemic decision forward as needed—systemic decisions, often being implied in specific solution decisions. On GitHub people are often responding to only part of a design decision and not the full thing, because of limitations with asynchronous communication and time. That also requires the designer responding to better contextualize a decision, in a defense of it. If that defense still doesn't uphold, that is a necessary step in the critique process.

I also (personally) do not understand the technical underpinnings of many things, and it can take other people repeating things in different ways for me to understand those things, some of the time. Async collaboration between technical and ux people is far from ideal, and requires patience all around. Questioning my integrity or anybody else's when your suggestions are not immediately embraced, is just not cool. Your thoughts and contributions are valued a lot, yet stuff like that does not help.

I've already evaluated many things you are coming up with now and I know the problems you will run into in many cases. I'm just looking at the larger picture and try to prevent problems before they even come up.

I'm proposing the background color change only on hover. Only one item may be hovered over at a time, and users do not make decisions against a group of items all being hovered upon at once. No decision will be perfect, and the imperfections of this decision I am ok with; and consider to be far more desirable, than the imperfections of other options. A busy and overwhelming UI when everything is static, is not ok to me (which the colored-dot option atop an icon, creates); as are solutions that are difficult to discern no matter an item's state (the 1px outline).

Critique is critical to making design decisions better. That is what I seek to foster, here. From what you've written, I do not gather that you've even looked at the videos I shared, to see the fuller proposals. We all need to do better and to encourage each other to do better. That can be done, but requires patience—and not capping on the integrity of others you don't feel are listening to you.

[ninavizz]

NOTE: Please do not comment any further on this post, unless your comment is about the Applications Tab on the VM Settings Pane.

Contributing Guidelines are clear about keeping issues on-topic, and for all Qubes OS contributors to have issues to act upon to keep things actionable, it is essential that I and all other frequent offenders of this propensity, tighten up about it.

• Color topics? Comment forth, but on the following (or new) issues...
  • Make colorized app icons optional #6652 to make colorized icons optional
  • Colorblind-friendly window decorations #6526 to make colorblind friendly window decorations
  • Add seven new colors #2523 to discuss colorization in general, as a lengthy segue to extending Qubes' support for colorization to signify domain properties.

Broader process issues, or "how to ux in GitHub?" I (and others!) welcome discussion on, in Discourse. I also need to get better about being more disciplined in time I spend on Qubes, so will likely only contribute to forum stuff 1-2x per week... but I do welcome the dialogue, there.

[rysiekpl]

I would like to say that this is an extremely welcome development, especially the easy way to configure launching anything in a DispVM. For a log time I felt this is a missing piece that would make QubesOS much more usable in a safe way.

For example, @freedomofpress is setting open-in-dvm.desktop as the default handler for all mimetypes for their Debian-based templates. This is a good way of doing this for a locked-down environment like the SecureDrop Workstation, but it's not really user-friendly enough for most regular QubesOS users (and yes, "regular QubesOS user" is a curious term...).

Having such a fine-grained control over things directly in the Qube settings dialogue would be a way better way of dealing with this!

One question: I assume that we're past testing freeze for R4.1-rc3, this is potentially not getting into R4.1? Or could it be expected to show up there anyway even if developed later?

Many thanks for this wonderful work!

[marmarek]

One question: I assume that we're past testing freeze for R4.1-rc3, this is potentially not getting into R4.1? Or could it be expected to show up there anyway even if developed later?

you're right, it's too late to get this into R4.1. But the backend of this features made it, it's just missing documentation (#7130).

[rysiekpl]

you're right, it's too late to get this into R4.1.

Dang. Thanks for making it clear though.

But the backend of this features made it, it's just missing documentation (#7130).

Right. Salt to the rescue, I guess!

[Nurmagoz]

If possible, an additional feature that could be beneficial to the application tab is a search functionality. Since multiple applications already exist within one VM, users could simply input the first letter of the desired application in the search bar, which would then narrow down the list of available applications for the user.