Spencer:
Thank you for your enthusiasm and valuable feedback. I do agree that
documentation is quite important, and I am doing my best to document
progress along the way.
Responses:
- For clarity, I agree that "Users pick up on unintentional messages
from the UI" should be reworded to "People come to their own conclusions
about what to do next when the appropriate information is not available in
the interface".
- I agree that people don't like to read. We tried to decrease the
amount of text, but when working with such a big technology gap, there
needs to be a balance between usability and utility (communication of
critical information). I would personally lean toward an interface which
irritates users with text initially but provides helpful information right
at the interface to people who get stuck.
- The "Ideal path" I was talking about was implicit, so it may have
seemed unclear. Ideally, people who don't need to circumvent censorship
will click connect, and people who do need to circumvent censorship should
try certain transports before others.
- We have data on various error cases from our participants (i.e. unable
to connect due to clock drift, correct bridge configuration and
misconfiguration of a proxy but a proxy wasn't necessary, etc.), but it
isn't processed. It is on the list of things to do, however.
- auto-proxy detection is something that can be done locally (so not put
the user at risk), which is why it has been discussed as a reasonable
things to hand over to Tor rather than leave at the hands of the user.
Especially when it was the biggest source of confusion, we believe this can
have great impact.
- I don't think smarter redirections are making decisions for users, but
helping users make better decisions. You are right. No decision has been
made, but we are optimizing the flow in which they can make their own
decisions to fix their configuration. (i.e. if the user wants to fix the
bridge configuration, they don't need to click through the proxy
configuration screen again).
- we added a progress bar to help build a mental model. We did keep the
arrows to give the idea of a workflow, but chose to not number the steps
(since technically, you can configure bridges before proxies and visa
versa).
- changing user behaviors to not put themselves at risk or ask for help
is hard. But it's something we should talk about. I'll look into the links
provided.
- I agree that a whole-systems work can be beneficial. Due to personal
timelines, scoping, and to not bite off more than we can chew, we have
chosen to focus on the part of the interface which deals with
censorship circumvention. We did do some previous work to improve the
usabiilty of Tor more generally, which you can find here:
https://blog.torproject.org/blog/ux-sprint-2015-wrapup,
https://trac.torproject.org/projects/tor/query?keywords=~uxsprint2015
Cheers,
On Sun, Jan 24, 2016 at 3:46 PM, Spencer <spencerone@???> wrote:
> 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
>
>
>
>
--
Linda Naeun Lee
