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

Delete this message

Reply to this message
Author: Spencer
Date:  
To: ux
CC: lnl, tails-ux
Subject: [Tails-ux] Tor Launcher UX wiki page is now live! + Updates
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