<div dir="ltr">Spencer:<br><br>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. <div><br></div><div>Responses: </div><div><ul><li><span style="font-size:12.8px">For clarity, I agree that "</span><span style="font-size:12.8px">Users pick up on unintentional messages from the UI" should be reworded to </span><span style="font-size:12.8px">"People come to their own conclusions about what to do next when the appropriate information is not available in the interface".</span></li><li><span style="font-size:12.8px">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. </span></li><li><span style="font-size:12.8px">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 <span class="" title=""Do or do not. There is no try." --Yoda"><span class="" title=""Do or do not. There is no try." --Yoda">try</span></span> certain transports before others. </span></li><li><span style="font-size:12.8px">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. </span></li><li><span style="font-size:12.8px">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. </span></li><li><span style="font-size:12.8px">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). </span></li><li><span style="font-size:12.8px">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). </span></li><li><span style="font-size:12.8px">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. </span></li><li><span style="font-size:12.8px">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: <a href="https://blog.torproject.org/blog/ux-sprint-2015-wrapup">https://blog.torproject.org/blog/ux-sprint-2015-wrapup</a>, <a href="https://trac.torproject.org/projects/tor/query?keywords=~uxsprint2015">https://trac.torproject.org/projects/tor/query?keywords=~uxsprint2015</a></span></li></ul><div><span style="font-size:12.8px">Cheers,</span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 24, 2016 at 3:46 PM, Spencer <span dir="ltr"><<a href="mailto:spencerone@openmailbox.org" target="_blank">spencerone@openmailbox.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I reviewed the content and the available work, snipped bits from the wiki as needed, and made comments below (:<br>
<br>
Copied tails-ux, once, for the record.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Linda Naeun Lee:<br>
Tor Launcher UX work<br>
<a href="https://trac.torproject.org/projects/tor/wiki/doc/TorLauncherUX2016" rel="noreferrer" target="_blank">https://trac.torproject.org/projects/tor/wiki/doc/TorLauncherUX2016</a><br>
<br>
</blockquote>
<br>
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.<br>
<br>
I am reminded of a quote from architect James O'Toole "Finish before you begin".<br>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Users pick up on unintentional messages from the UI<br>
<br>
</blockquote>
<br>
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".<br>
<br>
Or something similar that is more clear about people's choice to use abductive logic to resolve uncertainties.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Users don't read the text much<br>
<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Users get easily discouraged<br>
<br>
</blockquote>
<br>
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.<br>
<br>
The 'The Psychopathology of Everyday Things' section in Don Norman's 'The Design of Everyday Things' touches on many facets of why this is.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Users don't have the background to make these decisions<br>
<br>
</blockquote>
<br>
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.<br>
<br>
Even in the same realm, an electrical engineer won't [can't be expected to?] know what a network engineer does.<br>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Interface guidance doesn’t match the ideal path<br>
<br>
</blockquote>
<br>
I couldn't locate any experience flow that details the steps in the 'ideal path'; where can I find this?<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There’s no design for failure cases<br>
<br>
</blockquote>
<br>
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.<br>
<br>
Each of these can have ideal and non-ideal paths within.  Overlaying these in some way helps to target risk areas.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Linda's favorite 3<br>
<br>
</blockquote>
<br>
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.<br>
<br>
Quite challenging given the infinite spectrum of people that use Tor.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
You can see the design decisions<br>
<br>
</blockquote>
<br>
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?<br>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Auto-proxy detection<br>
<br>
</blockquote>
<br>
This is a good thought but requires giving more control to Tor when the user needs to maintain control.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Smarter redirections: Let's make smart decisions for our users<br>
<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Proxy configuration before Bridge configuration<br>
<br>
</blockquote>
<br>
I think a whole-system process flow would provide valuable insight into the most suitable order of things.<br>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Eliminating enumeration ... "Step 1", "Step 2", "Step 3" text [are]<br>
clutter-y, redundant, and a bit confusing.<br>
<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
on real users<br>
<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
knowingly put themselves in danger<br>
<br>
</blockquote>
<br>
This is a must.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
A More Enticing "Help" Button<br>
<br>
</blockquote>
<br>
Tails has encountered a similar issue [2].<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Can we and should we fit all the configuration options on one screen?<br>
<br>
</blockquote>
<br>
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.<br>
<br>
...<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks for putting all of this up and I look forward to more awesome work!<br>
<br>
Wordlife,<br>
Spencer<br>
<br>
[0]: <a href="http://renelee.net/pico/" rel="noreferrer" target="_blank">http://renelee.net/pico/</a><br>
[1]: <a href="http://renelee.net/pico/2/" rel="noreferrer" target="_blank">http://renelee.net/pico/2/</a><br>
[2]: <a href="https://labs.riseup.net/code/issues/10990" rel="noreferrer" target="_blank">https://labs.riseup.net/code/issues/10990</a><br>
<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><font size="4" face="times new roman, serif">Linda Naeun Lee</font></div><div dir="ltr"><font face="times new roman, serif"><br></font></div><div dir="ltr"><div><br></div><div><div><br><div> </div></div></div></div></div></div></div></div></div></div>
</div>