Page MenuHomePhabricator

Make Whonix GUI usable for high-risk non-technical Qubes users
Open, NormalPublic

Description

Problem

As a non-technical high-risk user, I will need to understand how to perform basic network performance improvement or risk mitigation tasks, having to do with my network connection through Tor—without being fluent in Tor, Whonix, developer, or opsec unique concepts or language.

Sidenote: For the team, this has to be easier to execute, than the history of tickets suggests. No initial implementation is ever perfect. The existing implementation is simply too fraught and problematic, for non-technical users. None of this ask is about many of the things the existing tickets speak to; it's about isolating and surfacing basic from more advanced tasks, and using clearer language with more usable interactions, for all users to navigate towards things.

Solution

working sketch that illustrates the below concepts, not a dev-ready solution.

1. Clearly surface a GUI control for Whonix among the Tray icons.

  • Semiotic should speak to the broadest possible concept (Whonix or Tor), not a sub-functionality within it (the clock for TimeSync, as it is, today).
  • Icon should be actionable via same interaction other Tray icons are.
    • Today, all tray icons but the TimeSync icon, are acted upon with a simple click. The TimeSync icon, however, requires a right-click. Much as that may be easier to implement, it is a dealbreaker for user adoption. That's just the reality of how non-technical human brains work. :(
  • Icon should not break (and thus show as a different graphic to non-developer users), when clicked upon.
    • Qubes bug. Boo.
  • Tooltip should simply say Whonix, not either how to open it or other info.
  • If redundant Whonix instances exist on a user's machine, build the Whonix widget enacted from the tray to elegantly handle that w/o redundant widgets showing-up.
    • Possibly a super-duper-edge-case, but currently how the SD Workstation is architected.
    • As an edge-case thing, this is the lowest priority part of these solution opportunity points.

2. Follow human centered design best practices for the behavior and layout of a Tray widget.

  • Waves ohai, I don't know a lick of code but this is my area of expertise... so, just ask! ninavizz-at-riseup-dot-net. :)
  • Per below mockup: widget's GUI should descend below the Tray, not lay atop it; and, too many things are "squished" too close together, which is problematic for users with dexterity issues (arthritis, or simply an input device they're not comfortable with). It's good to put read-only things at the very top of such a menu, to give some space for movement downward. Also, always requiring the lateral movement of navigating into a flyout is a major problem. It's preferred to have more things in the parent list, and ideally no flyouts, if at all possible. But, no, that's not reflected in many Linux GUIs that are out there.

2. Clearly label functionalty within Whonix GUI

  • Use the label Time Sync, instead of sdwdate, which is a team-facing/dev-name a lovely widget a community contributor built. :)
  • If a bit of functionality is rarely used (such as I'm guessing Restart sdwdate is), locate it within a control window's UI—not in the menu options.
  • There shouldn't be an "exit" button within a menu. That's just odd—unless it's a convention for right-click menus in Linux, but a Tray menu is not supposed to be a right-click menu.
  • No icons except 1 or 2 (and those should not be any of the Gnome icons, most of which were not designed for 16x16 use). Linux GUIs use way too many icons as it is, and too few of them are meaningful and only cause to distract.

3. Where possible, show the status itself—not a link to showing a status in a window.

  • Connection Status. Just say what it is, in one word. :)
  • Again, this is my area of expertise—just ask at ninavizz-at-riseup-dot-net, if there are questions. :)

4. Clearly describe functional outcomes and guiding concepts in text w/in Connection Wizard.

  • The Wizard is a great first-step, but its use of written language is overwhelming and likely confusing to non-technical users. Developers and "maker" types are very curious, and happy to read. Non-technical users often feel like imposters in technical environments, and such an overwhelming volume of text may trigger greater feelings of alienation that will have an effect opposite to helping them. "Progressive Disclosure" is a good concept to google and to learn about. Surface the simplest possible phrases to describe things with, then make longer descriptions about those available for the user to dive into and learn more about if they desire.
  • This complete flow should receive user testing and subsequent text iterations to simplify.

5. Get user testing and subsequent design iterations funded.

  • Funding may exsist on the Qubes team to implement usability enhancements to existing sdwdate tool. It would be great to get some rudimentary user testing and iteration done on solutions, so that funding is used wisely.

Edit by Patrick
Fix typo sdwsdate -> sdwdate.

Details

Impact
Normal

Event Timeline

ninavizz created this task.Feb 16 2020, 3:35 AM
Patrick triaged this task as Normal priority.Feb 16 2020, 7:04 AM
Patrick updated the task description. (Show Details)
Patrick changed Impact from Needs Triage to Normal.
Patrick added subscribers: troubadour, HulaHoop.
Patrick updated the task description. (Show Details)Feb 16 2020, 10:03 AM

Excellent proposal!

Some minor comments:

Tooltip should simply say Whonix, not either how to open it or other info.

That would be good. It wasn't implemented that way due to technical challenges, lack of resources. Might require changes to sdwdate itself too.

If redundant Whonix instances exist on a user's machine, build the Whonix widget enacted from the tray to elegantly handle that w/o redundant widgets showing-up.

Solving this might require solving other non-gui related issues such as T930 first.

There shouldn't be an "exit" button within a menu. That's just odd—unless it's a convention for right-click menus in Linux, but a Tray menu is not supposed to be a right-click menu.

Can be left out from left click menu but what about keeping it at least in a right click menu?

Reasons: as long as its is not perfect (such as possible/potential sdwdate-gui bugs, message spam, high CPU load, duplicate sdwdate-gui due to multiple Whonix-Gateway VMs) (also avoiding annoyance for users who don't want that systray) it is good to have an "emergency exit" (the right click exit button).

So... keeping an eye on user-needs as the priority driving this story: the list of "What needs doing" is ordered, below, as I see it:

  1. An icon that signifies either Tor or Whonix, needs to be easily recognizable to users in the Qubes Tray.
  2. That icon needs to be easy to act upon, by users.
    • Left-click, not right-click.
    • Any possible right-click functionality has to be de-prioritized until the most basic of basic user needs can be achieved in left-click functionality.
  3. User dexterity needs and ease of information discovery must be prioritized in how this widget's menu is structured.
    • No flyouts, if at all possible.
    • If a flyout makes sense, then it needs to be at the end of the menu.
    • The menu should open "down" and not "up" from the Tray itself.
    • Ideally a read-only piece of information should be the first thing on the menu, so the user does not need to initiate a compound movement (down/click) to access functionality.
  4. A path towards addressing generalized Whonix/Tor things, should be clearly labeled and positioned near the top of the menu.
  5. Users should be able to re-start Tor from the menu—which is guessed to be the most common function users are likely to have, in troubleshooting problematic connections.
    • This decision is based on the acknowledgement, that more users are likely to need this menu to rectify things gone wrong, than to enable advanced features.
  6. More specialized functionality—such as Time Sync—should exist towards the bottom of the menu list, and be more clearly labeled.

I want to be mindful to not embrace the traditional Unix development approach, of "let's do one technical thing and do it really well." The one thing this ticket was drafted to achieve, is a goal for users—not developers. Likewise, the desired changes are requested in lieu of the feature's history—tho all the wonderful historic context provided, is always insightful. I just want to be mindful to not get lost in the history, and to instead keep focused on our goals ahead.

If we can keep our sights on user needs ahead of embracing feature benefits, I feel everything can most naturally fall into place. When we start looking at the benefits of certain features and weighing them as more or less important than the benefits of other features—or considering what's lost if a user cannot access those features—that's when we can get lost in a rabbithole of what we desire as project contributors, vs what known users are known to need.

A harsh truth, is that users really don't care what project contributors want—they just want a thing to work. Which sounds horribly blunt and rude. Especially to a project team that is clearly very, very dedicated to working hard on making a utility that many benefit from using. Many in FLOSS respond to that sentiment with "Ok, then go build your own damn tool!." Because we're all working on our tools in service to vulnerable users, I want to throw this flag with lots of hearts and smiles... only to keep us focused. Not to be a patronizing twat.

When simple user needs are prioritized, the features of a product will naturally align to those—and that's how "what we work on next" can most easily be prioritized, for tangible execution. Admittedly: using this process can de-prioritize features we all understand and know to be incredibly powerful and to pack a lot of value for users that they may not yet appreciate... but that speaks to bigger needs that exist outside the scope of what this focused ask is about. Make sense?