[ux] Tor Launcher UX wiki page is now live! + Updates

[Spencer]

Hi,

I reviewed the content and the available work, snipped bits from the 
wiki as needed, and made comments below (:

Copied tails-ux, once, for the record.

> 
> Linda Naeun Lee:
> Tor Launcher UX work
> https://trac.torproject.org/projects/tor/wiki/doc/TorLauncherUX2016
> 

Let me first applaud the effort to document the work at this point in 
the research, given how difficult going back and organizing things can 
be.

I am reminded of a quote from architect James O'Toole "Finish before you 
begin".

When applied to a design problem this philosophy can, in addition to a 
providing more efficient workflow, aid in the mapping of the problem 
internally in the mind, which helps to better understand all of the 
information being juggled at once.

An example can be found in the work of Reñe Lee [0][1] who documents 
clearly both the research and the findings along the way.

> 
> Users pick up on unintentional messages from the UI
> 

This isn't that clear.  Maybe it could be "People come to their own 
conclusions about what to do next when the appropriate information is 
not available in the interface".

Or something similar that is more clear about people's choice to use 
abductive logic to resolve uncertainties.

> 
> Users don't read the text much
> 

People prefer to have stories told to them.  Pictures are often next in 
preference, as people can tell themselves a story by interpreting the 
images.

Reading requires thinking. "Don't make me think" is how many people feel 
when doing something, even though I recommend against designing to 
accommodate this in its entirety.

> 
> Users get easily discouraged
> 

People don't handle uncertainty well and it is quite common for people 
to blame themselves for not understanding how something works, for many 
reasons.

The 'The Psychopathology of Everyday Things' section in Don Norman's 
'The Design of Everyday Things' touches on many facets of why this is.

> 
> Users don't have the background to make these decisions
> 

This is not the fault of the people using the software but the fault of 
us, those building software, for presuming what others should know.

Even in the same realm, an electrical engineer won't [can't be expected 
to?] know what a network engineer does.

Besides, the definition the Tor Project uses for its various types of 
network servers is self and industry conflicting at times, e.g., the Tor 
Bridge is an unpublished network router.

> 
> Interface guidance doesn’t match the ideal path
> 

I couldn't locate any experience flow that details the steps in the 
'ideal path'; where can I find this?

> 
> There’s no design for failure cases
> 

This is where an experience flow would be valuable.  One for the 
existing [or what was existing before this] flow, [n] number of flows 
that result from pattern mapping the observed path of each user during 
testing, and one [or more] ideal flows.

Each of these can have ideal and non-ideal paths within.  Overlaying 
these in some way helps to target risk areas.

> 
> Linda's favorite 3
> 

These all support the thought that the interface can teach, in addition 
to using Tor, about these other concepts, even if by clarifying what Tor 
in not.

Quite challenging given the infinite spectrum of people that use Tor.

> 
> You can see the design decisions
> 

I can see designations but not decisions.  Is there a record of the 
logic behind the designations that detail every thought and the 
applicable decision; pictures of the interfaces with adhesive notes or 
something attached?

The 'Changes' section does this a bit by detailing that a change was 
made but does not offer the reason or alternative thoughts regarding the 
change.  The 'Discussion' section does this a bit more by detailing the 
main thoughts regarding a change but does not do so clearly.

> 
> Auto-proxy detection
> 

This is a good thought but requires giving more control to Tor when the 
user needs to maintain control.

> 
> Smarter redirections: Let's make smart decisions for our users
> 

This could be "Let's help people make smart decisions" or something 
similar that addresses the problem of people not knowing what is 
happening.  Keeping people un or under informed is not the highest order 
of usability.  The tools should teach, not do the opposite.

The appropriate resolution in this case is to explain to people what 
happened, why, and what options are available to choose from, not make 
the decisions for them.

> 
> Proxy configuration before Bridge configuration
> 

I think a whole-system process flow would provide valuable insight into 
the most suitable order of things.

The progress bar seems like an appropriate place to emphasize the actual 
model, inherently addressing the mental model downstream. This could be 
the core element to design.

> 
> Eliminating enumeration ... "Step 1", "Step 2", "Step 3" text [are]
> clutter-y, redundant, and a bit confusing.
> 

Knowing the entire path in a journey is valuable.  The arrows, or 
something similar, are enough if the complete journey can be mapped by 
something like the progress bar.

> 
> on real users
> 

You are all real users, too.  Do not forget that.  Design-by-committee 
and user-driven-designation are like any other tools; use wisely, as 
they can cause as much damage as they intend to prevent.

> 
> knowingly put themselves in danger
> 

This is a must.

> 
> A More Enticing "Help" Button
> 

Tails has encountered a similar issue [2].

> 
> Can we and should we fit all the configuration options on one screen?
> 

Have a look at Virtual Box's configuration flow.  It separates the flow 
into two equal paths.  One step-by-step path and one all-in-one path.  
Different context but insightful.

...

I understand that this effort focuses on bridges, or at least started 
there.  Given David Fifield's involvement and his recent research on 
China's internet firewall, I see the connection.

However, it seems beneficial to take a more whole-systems approach with 
this work, which seems to be the case since Kathy Brade and Mark Smith 
jumped in.

The value of putting as much into the original effort as possible lies 
in being able to more effectively anticipate what the risk areas are 
going to be, ultimately conserving resources.

Thanks for putting all of this up and I look forward to more awesome 
work!

Wordlife,
Spencer

[0]: http://renelee.net/pico/
[1]: http://renelee.net/pico/2/
[2]: https://labs.riseup.net/code/issues/10990