ID: 963 PHID: PHID-TASK-wcfz6uz4kpejrb6x6tfv Author: ninavizz Status at Migration Time: open Priority at Migration Time: Wishlist
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.//
{F12274155}
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
{F12274158}
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.
