Improve RPC dialog windows usability: Window header, text, icon semiotics

[ninavizz]

The problem you're addressing (if any)

When invoking the qvm copy to VM dialog, a very generic appearing window is prompted. This likely feels ok to developers, however to non-developer users a more friendly and contextually appropriate window would be nice.

When I seek to move a file to another VM, however, the window is identical; and the qvm.Filecopy operation is still shown. I filed #5841 to indicate what seems like a proper bug on the latter, however the two very different actions should be more clearly reflected to users.

Describe the solution you'd like

This is a mockup of what I'm thinking:

Per the MoSCoW method of prioritization, it illustrates the below:

MUST:

1. Create 2 distinct windows—one for copy and one for move
2. On each, update title-bar text to reflect operation (move or copy)
   • As a "Should," create additional window states for plural vs singular title bar and supportive texts
3. Eliminate "Operation: qubes.Filecopy"
4. Update window Do you want to allow... text to instruct user appropriately.
5. Remove white background/box behind Source VM; introduces confusing affordance of editability, when that's a static thing.

SHOULD:

6. Update window icon to reflect action (move or copy)
7. Create 2 more distinct windows to reflect single or multiple files (see move example)
8. Add filename
9. If 8, then also change field labels

COULD

10. For all RPC operations, create 1:1 friendly window titles to more clearly reflect back to a user what theyre chosing to do... without having to do the additional mental hops. So, qubes.GpgImport would get the window title of Import GPG key, as an example.
11. Larger ux audit of all RPC dialog window tasks, and how all could potentially be made a bit more friendly.
    • Could the From/To convention replace Source/Target in all instances, w/o creating confusion?
    • Task relevant icons to present a semiotic that's informative? If not, what other icon would work—as this not being an FAQ window, the question mark feels odd.

[marmarek]

This is a hard one.

By design, the part that enforces isolation, which includes qrexec policy prompts, is as simple as possible. This means it intentionally knows only very simple information: "operation A, from source B, to destination C". Everything else stays isolated from the isolation-enforcing engine.

Having filenames there maybe sounds simple, but in fact it opens multiple avenues for attacks (non-exhaustive list):

1. You need to include source-qube controlled string in a confirmation dialog (and in some cases in the policy itself): currently we do allow some of it, but with quite strict restrictions, that doesn't match what could be in a filename (for example space is forbidden, non-ASCII chars too, so forget about file named "zażółć gęślą jaźń.odt"); allowing unrestricted text, exposes that engine to multitude of attacks like injecting HTML, using UTF-8 control sequences (like changing direction of text, or erasing other parts of the prompt), or even exploiting font-rendering bugs (similar to those infamous WiFi names that crashes iPhones).
2. Displaying filename in confirmation dialog means getting it before the actual data stream. And when you approve the operation, something needs to verify if what you've approved matches what is really copied. This also has some potential of going wrong. Things like comparing directory/../../filename to filename. Or all kind of characters that looks alike (that's actually generic issue, not really related to confirmation prompt).
3. Some paths can be quite long - while it's possible to display part of it in the confirmation, this again opens ways to fool the user about what is being copied. To be clear: I think if user confirms operation X, it should allow exactly operation X. Whatever is asked in the confirmation prompt, should be enforceable.

But actually the mockup of multiple file copy could kind of works: having information just about number of files and their size (like 12 files, 7.3 MB) is something that doesn't require arbitrary characters in the prompt, while still gives some info about what is copied; and is also enforceable (at least as an upper limit).

[ninavizz]

@marmarek Thank you for the detailed response! Actually, the filename part of my proposal, is one of the least important components to it. Per my prioritization of all the elements of the proposal above, it's listed as item number 8 of 11. Apologies that I was not clear in my grouping and numbering of things.

Everything you explain above, makes total sense. What stands-out to me as the most confusing part of today's presentation, are as follows:

• Window header should speak to task I have initiated, as a user—as specifically as possible.
• Instructive text should tell me what is needed of me in active-voice and as simply as possible. Asking me if I "want to allow" a task to be completed, is very confusing. Users have been trained to go to the cancel button, if we don't want what a dialog says is needed from us.
• If there is an icon, it should speak to what the window is doing. It's not providing an answer to a question, which is the semiotic queued in most human brains by the question-mark icon.

Then lots of little things... like eliminating the white background-box on the Source VM, because that's not editable. I also just personally dislike icons on buttons, and prefer simpler "Primary, Secondary" paradigm—but that's probably the most unimportant change, of all the particulars I'm offering in this proposal.

See updated mockups, that also factor-in a 3rd specific-window design for GPG Key imports, and a 4th design for "Everything Else." In theory, simply the 4th design could be implemented for everything... but my concern with that, is that common tasks non-technical users are accustomed to doing on our macs and PCs (like copying and moving files) being framed as a "RPC Operation" will likely be confusing. But, that framing to advanced users who'll actually customize their policies, meets their expectations and would totally make sense to them.

Thoughts?

[ninavizz]

Also, some transparency behind my motivations for having filed this: we're currently exploring an "Export to VM" option for the SecureDrop Workstation client app. For my current proposal, the user would select "Export to VM" on a file or message, and the qvm.Copy dialog would be prompted from within Qubes.

Today's presentation of that dialog, then presents a cryptic-appearing window to our users—who will mostly be restricting their exposure to Qubes, to the client we've designed and maybe to a few other apps in other VMs.

Seeking to improve the usability of Qubes for all Qubes users on file-management tasks, felt like a natural extension of a more limited "Just pls do this for qvm-Copyfile" solution. I'm also concerned that it could appear strange to Qubes users not on SecureDrop, if one RPC dialog is done in a very different way, from all the others.

[marmarek]

Generally I agree with most of the above points. The confirmation prompt should be clear about key three things: what action, from where, to where (which user actually selects there). Besides filenames, other points are very reasonable. One minor detail I'd modify, is to emphasize (with bold) action name ("copy file" or "move file") even in custom dialog.

I see two steps here:

1. Improve generic dialog (things like white background on source, reorder elements, reword text etc). This one should be quite easy technically.
2. Custom dialogs for some services. This one will require designing an API to differentiate dialogs. And while at it, do that for notifications for some services too. Not terribly difficult, but more work.

[ninavizz]

@marmarek Awesome! Yes, I like your suggestion to bold the action in copy/move/gpg specific dialogs. Will create updated mockups and create 2 new issues—one for global QVM ops dialog changes, and a second to create task-specific dialogs (dependent on the API)—while closing this one, later this eve. Thx for the rapid feedback to iterate towards a nice set of next steps. :)

[brendanhoar]

Window Header on https://user-images.githubusercontent.com/8262612/82740323-a0b30580-9cfc-11ea-80b3-aa7d3422c6ca.png above should indicate Move, not Copy... <minor point, but just in case it becomes part of the requirement...>

[ninavizz]

@brendanhoar Thank you for pointing out that silly oversight on my part! Will update later tonite in this issue, as well. :)

[SvenSemmler]

Little side-note (maybe not so important in the first iteration): When the RPC dialog pops up to allow a USB keyboard or mouse ("input proxy") it would be extremely helpful to see the name of the USB devices this is prompted for (e.g. many webcams present themselves as HID and consequently trigger this dialog). It can be quite confusing if one sees this dialog multiple times without knowing what one is allowing. I realize this is basically the same as asking for the filename, but maybe a USB device name can be somewhat better filtered/constrained to be safe?

[ninavizz]

@marmarek Actually, I had this thought last night... could the option at right be possible? If I were to get a list of all RPC files that ship with dom0, I'd bet I could compose a whole list of "plain language" translations, no biggie (or, I'd at least like to try... if this is feasible w/o building a whole new API).

Still unsure about what to use as a global Title Bar line of plain-language text, and entirely open to suggestions!

[marmarek]

Little side-note (maybe not so important in the first iteration): When the RPC dialog pops up to allow a USB keyboard or mouse ("input proxy") it would be extremely helpful to see the name of the USB devices this is prompted for (e.g. many webcams present themselves as HID and consequently trigger this dialog). It can be quite confusing if one sees this dialog multiple times without knowing what one is allowing.

Technically very similar thing is already tracked in https://github.com/QubesOS/qubes-issues/issues/3604. And I believe there was some discussion about it too, but I can't find it now.

I realize this is basically the same as asking for the filename, but maybe a USB device name can be somewhat better filtered/constrained to be safe?

Yes. This is also the reason why the above mentioned issue isn't implemented yet. But indeed for practical reasons, such extra information, even if not enforceable, would be very useful...

[marmarek]

@ninavizz you can easily get the list in dom0 by simply listing files in /etc/qubes-rpc/policy. Anyway, besides plain language, I would like to preserve somewhere actual service call name, as this is the thing that identify the call, is needed for setting up policy etc. Maybe some small print below?

[ideologysec]

A few thoughts (as a slightly-more-technical but still design-minded user):

1. please do not kill the icons on the Cancel/OK buttons. Color and shape are important differentiators to make discerning between buttons easier, and therefore reduce cognitive overhead and decrease likelihood of making the "wrong" choice (updating the icons to red for cancel/green for allow might be helpful, changing their placement, and for colorblind users the shape of the icons still helps immediate discernment)

2. please also either increase the prominence of the operation being performed in the header, or as in the last box "qvm.ExampleOperation" insert it into the main body of the alert - it's much easier again for immediate discernment to see bold text among the body of the paragraph, than it is to try and parse it out on a screen from white text on a questionable background color - or use the updated icon (which is actually an argument for my request in item one, above...)

3. in line with not removing icons, something that might be helpful to consider would be updating the labels on the buttons to speak to the actions to be performed - "Copy" in the case of files, "Import" in the case of GPG keys, "Connect" for USB/etc devices, "OK" for all others. (See e.g. Apple HIG - though the system buttons in macOS don't have icons, but I think it'd be nice to keep them.).

[ninavizz]

@ideologysec Thank you for the feedback! A few thoughts...

1. Red and Green as opposing binaries, is a known worst-practice for accessibility reasons. People with varying levels of colorblindness will flatten both colors to equivocate a similar gray; and a not-insignificant segment of the population does struggle with colorblindness. On an aside from many of the monitors on Qubes supported laptops, having not-awesome color contrast—which is needed for reds and greens to really differentiate (an opinion I have as a Mac user, accustomed to a bright Retina display).

2. The cognitive burden argument can more easily be made when there is too much information in a UI, to parse for meaning. Hence, the "dark/light" binary of "primary/secondary" as a best practice preference. It's a minimal amount of information to still make a clear distinction.

3. Global patterns are really important, for buttons across a broader experience... and "ok/cancel" as a binary imho is important to preserve. That said, how Apple used to do things (before Sir Ive killed their amazing HIG team), I admittedly really loved. For the first implementation as Marek suggested, I don't think that'd be possible—but for the API enhanced iteration that'd come later, I really like this idea. TY!!

4. Icons on buttons are a personal nit of mine, and one of the least important points in this issue. I'm ok punting on the button tidying-up as a global exploration to address in the future, with user research to inform a decision. That will be reflected in my follow-up issue I'll be filling, today or tomorrow. TY again for sharing your thoughts! :)

[marmarek]

As for the icons on buttons - this isn't just about color, but also about their shape. And actually, those OK/Cancel buttons are sourced from the theme you set, to be consistent with other applications. Removing icons from them would actually reduce consistency. As for colors of icons - this is also something that is controlled with a theme - you can set another one if you need it in system tools -> appearance -> icons (very few are installed by default, but you can install more). Anyway, the fact that using colors as an extra differentiating factor (added to button text and icon shape) doesn't improve experience for some ppl, doesn't mean we should make it harder for everyone else.

[ideologysec]

@ninavizz thanks for the insights!

Some responses in no particular order/coherence: Per the XFCE HIG (which basically says, "use the GNOME 2 HIG, so, per the GNOME2 HIG): "Label all buttons with imperative verbs, using header capitalization. For example, Save, Sort or Update Now. Provide an access key in the label that allows the user to directly activate the button from the keyboard."

So, the OK/Cancel buttons are important to preserve for minimum-level functionality/cognitive coherence with the upstream XFCE/GNOME2 HIGs, and with the rest of QubesOS - but when we can get those API-driven button labels all over the place, then we're really cooking with gas as the metaphor goes (that's a very stretch goal - I personally don't much like the GNOME interface choices, but I'm here for consistency and coherence and additional information to help users not violate security boundaries or do something destructive without prior intent).

Regarding colors/icons causing cognitive overhead or not, and again from a consistency perspective - (and doing my best to avoid bikeshedding even if we're literally talking about the color and shape of buttons...) keeping the icons on "OK" and "Cancel" are again more in-line and consistent with, the rest of the Qubes interface. Until we're ready to abandon all upstream linux-isms and/or transition all buttons systemwide to a different paradigm, is it possible to keep them as-is and focus on the modal window text/header/dialog presentation?

Heck, even shading the active/ideal button sounds fine! (and definitely what I'm used to) Would also love to see that pushed upstream to all TemplateVMs/Qubes as a whole.

speaking of "decently-designed Linux distros/sane HIGs", have we considered elementaryOS as a possible Qubes template? :)

[ninavizz]

@ideologysec The GNOME HIG guidelines are mostly known best-practices for UX stuff. The guidelines are published to help developers make decisions when direct UX support is not available.

The guideline you cite is a known pattern, and at the heart of why I want some kind of a change to happen. However, more specific button texts cannot be implemented, until the API Mark cites several comments above, can be created—with a unique window for each policy command. Which is, in effect, the richer 2nd phase of this—which I'll be creating a child ticket for, today, but won't publish any solutions against as I don't have the bandwidth at this time for that. Community contrib suggestions, of course welcome, for what appropriate primary button action text for each policy wd be.

Until then, a simple system needs to be shaped with mostly generic, human verbiage, a place for the RPC blab, and probably one space for a plain-language summation of what that action will do.

Regarding the icons on buttons: as noted on my earlier comment, and to your point—that's a thing with global impact, and as they're used elsewhere in the Qubes UI it'd be best to do that one later.

[ninavizz]

@marmarek The point with the color schpeel, is that the way XFCE/Gnome currently does icons on buttons in Qubes, actually does make it harder for everyone when the two buttons are the same color but then have differently colored icons on them with gradients, etc.

One, per the longstanding "Tray icons" discussion... all of the Tango icons smaller than maaaybe 64x64, are too small to meaningfully register to users w/o cognitive strain. Especially users new to Gnome, Linux, or any non-modern UI. I know these icons were the norm in the 1990s. The point of UI aesthetics, is to guide users; and the quickest, most friction-free method to do that, is by expressing clear hierarchies first, more detailed semiotics, second.

The Tango icons have all sorts of stylistic information packed into them, atop the basic form: the check-mark itself appears to be italicized, in a brush-stroke of some sort, it has a shadow, and a glossy gradient of some kind. Users unfamiliar with that style need to cognitively "get past" those distractions to ascertain "Oh, this is a checkmark," while users familiar with the style may find it delivers an aesthetic value that is pleasing.

On the other side of things... GitHub, as an example (If you are reading this in the web UI, begin a comment to see the buttons I'm speaking to) has the deep green with white text as the primary-action button, and a flat grey button w/ black text on it as the secondary-action button. The latter happens to have a small, gradient-free red icon on it.

The icon is very "plain" and clean, so the user can cognitively process what they're looking at while parsing its semiotic, more quickly and easily than a similar icon presented in a more stylized fashion.

If a screenshot were made of this UI and it were to be plopped into GIMP and made grayscale, the "Comment" button still is the clearly darker button. That paradigm, of one button always appearing heavier/darker and the other button always lighter, is the preferred modern "Primary/Secondary" pattern. If icons can be added w/o being a distraction, great! Icons alone, though, create more cognitive friction than I feel is worth it, when that clear primary/secondary hierarchy is otherwise absent.

The way buttons are done today in Qubes, there is rarely a clear primary and secondary button; the only visual distinction, being an icon on the button—and that icon's semiotic requires parsing, after it's been visually parsed. The file box atop a button I saw in Nautilus, is a great example that would likely throw non-Linux users... as it's so out of left field from what Windows, Mac, and Webapp users are accustomed to seeing everyday.

[ninavizz]

Per Marek's comment above, I'm closing this issue and opening 2 new ones: basic no-API-required changes to the dialog, and richer "API Required" changes. #3604 I'll also tag onto the latter, as something—even handwavey and vague—would be nice.