Version 21 (modified by lnl, 3 years ago) (diff)



!! Some sections of the wiki still not completed. Linda says sorry. :(


  • Phase 1: Oct-Dec 2015: User Experience Research
  • Phase 2: Dec 2015-Jan 2016: Iterative Interface Designs
  • Phase 3: Feb - March 2016: User Acceptance Testing


  • Linda Naeun Lee: User Experience and Security Researcher,
  • David Fifield: Security Researcher
  • Nathan Malkin: User Experience and Security Researcher
  • Ganesh Iyer: User Interface Designer

+ Nima, Isabel, and everyone else who has been generously giving us feedback along the way. Thank you!

User Experience Research


  1. (under construction)
  2. (under construction)
  3. (under construction)


Qualitative User Experience Research

Most representative behaviors:

  • P3: this participant configured a bridge successfully (obfs3, the default), even though they didn't need to. They didn't know the difference between censored websites and censored internet connections.
  • P11: this participant tries to connect using vanilla tor by clicking connect, which doesn't work against a censor that blocks public Tor relays. Then they try to connect using vanilla tor because they answered that they didn't need or a proxy, which also didn't work. They try connecting with a bridge (obfs3, default) and no proxy, which works.
  • P14: watch this poor user try the same configuration 7 times(?!!) and fail and guess proxy settings. 27 minutes, later, we cut them off. Because they are convinced they need a proxy, they failed to connect because they never bother to pick a different bridge (chose obfs3, required meek or custom).

Linda's favorite 3:

  • P1: this participant makes a correct configuration (obfs3, no proxy), but since bootstrapping took too long, was convinced it was wrong. Then tried "connecting directly" by pressing connect on the first screen, which worked. But the participant was convinced that they made a direct connection.
  • P4: after successful configuration, the participant is convinced that the file explorer on windows IS the Tor browser for a long time, before figuring out what the browser is.
  • P5: watch this participant create an email account on the fly and use the auto responder to use a custom bridge to connect successfully.



Experimental Setup






Interface Designs

Clickable Prototypes

You can see the design decisions that we made from the results of our qualitative user experience research. We based each change on concrete events, trends observed, interview dialogue, etc.

Note: these clickable prototypes are rough, so there may be some missing features (i.e. if you click "help," nothing happens and there is no help window, but that's because we don't plan on changing that, nor did we take the time to re-draft it up). Additionally, there is only one version of each window in the prototype, so the state may seem inconsistent (i.e. in Iteration 4, no matter what bridge you choose, you end up choosing the same one). These were mainly to demonstrate the design changes that we want to make to the interface, so please bear with us! It is quite cool that you can click through the prototypes and explore the paths yourselves.

Tip: Marvel, the site where our clickable prototypes are hosted, will act as a prototype. You can explore the paths manually to iterate through all the windows, but if you want to see all the windows at once and navigate to any window, you can click this icon at the top right corner. It will then display a grid of each window of the prototype. Unfortunately, I can't find a way to display all windows at once bigger than the grid appears. But clicking on a window's thumbnail will navigate you directly to that window, without you having to traverse through the interface path yourself.

No image "marvel-navi-tip.png" attached to doc/TorLauncherUX2016
This is our first iteration of the prototype: just a lo-fi sketch to get out the ideas.

Changes from Iteration 1 -> Iteration 2


Changes from Iteration 2 -> Iteration 3


Changes from Iteration 3 -> Iteration 4

... some more changes, but will fill in later.

  1. Updated text: The researchers agreed on the text that should be on each screen of the windows.
  2. Finalized window versions: The researchers agreed on which of the window options to show the user. (i.e. the progress bar had two versions, with the indicator for progress being different. One with an animated "...", and another with a swirling onion.)

Changes from Iteration 4 -> Iteration 5

We ran a focus group at Berkeley during one of the BLUES (Berkeley Laboratory for Usable and Experimental Security) Lab meetings. 14 researchers, ranging from a spectrum of computer science to pure user experience researchers were in attendance and provided feedback on the design. The discussion started with an overview of various censorship environments around the world, followed by a discussion of how the 3 simulated censorship environments in the lab were representative of these conditions, a walkthrough of Tor's current (5.0.3) version of the launcher and the ideal path for a user in each of the 3 simulated censorship environments would take, and the results of the qualitative user experience research. Then, we presented our new design (Iteration 4), stated our justifications for changes made from the original launcher to our new design, and concluded with a discussion of the design decisions made and possible improvements.

We believed that sanity-checking our design before large-scale testing would be wise, since it is time-wise and financially costly to run such an experiment. During this focus group, the researchers worked out little kinks in the design, discussed alternatives and made a collective decisions to implement or not implement possible changes, and polished the design to look more aesthetically pleasing. Yay! Here are the changes that will be made from Iteration 4 to Iteration 5:

  1. Auto-proxy detection: We plan to automatically and locally detect if a proxy is already configured on the machine. This can be done by looking for some configuration file for other browsers that users have installed. If we detect that a proxy is not necessary, we will inform the users that they do not need to configure a proxy, and show a window which encourages them to go on without configuring one (but they can still do so if they want to). This should help the many users who did not know if they need to configure a proxy or not.
  2. Smarter redirections: Let's make smart decisions for our users. For instance, if a user tries to connect directly and fails, the options should be to retry or to go to the configuration screen, not the home screen. Similarly, if their connection failed due to a misconfigured proxy, they should be redirected to the proxy page. If their connection failed due to a misconfigured bridge, they should be taken to the bridge screen.
  3. Proxy configuration before Bridge configuration: This was proposed for two main reasons. 1) the network topology connects to a proxy first and a bridge thereafter. so having the steps in that order may help build a user's mental model. Our progress bar at the connection screen shows progress in a network topological order, so this would also make our design more consistent. 2) for smarter redirections. If a connection fails because of a proxy error, the person may need to also configure a bridge. But if a connection fails because of a bridge error, then the users do not need to see the proxy screen again. In the current design where bridge configuration is first and proxy is second, a user would need to click back to configure a bridge if proxy error, and see an unnecessary proxy screen if they had a bridge error.
  4. Eliminating enumeration: "Step 1", "Step 2", "Step 3" text at the progress bar in the configuration windows were deemed to be clutter-y, redundant, and a bit confusing. Configuring a bridge doesn't necessarily have to be done before configuring a proxy, and enumeration seems to imply that there need so to be a specific order to things. The little blue arrow shapes will be enough to indicate progress.
  5. Visual guidance: We will highlight the paths that users should take in green (i.e. the "next" button will be the same color bright green as the "connect" button on the first screen). This helps user fatigue, as they don't need to read the words on the screen as carefully to determine which is the most obvious step to do next. We did this to minimize fatigue, since users already need to make a series of decisions and possibly need to troubleshoot their connections.

(If you want to know more about specific design decision which seemed like good ideas, but we decided against implementing them for various reasons, you can look in the discussion section of this wiki.)

We hope that Iteration 5 will be the last iteration of the user interface. We're ready to get testing on the impact of these changes on real users!

User Acceptance Testing

Coming Feb/March 2016.



Experimental Setup







"Are there consequences of automating your configuration?"

It IS possible to automate this entire process for our users. If we were only concerned about how easy it was for users to use the launcher, minimizing the time it takes a user to make a successful connection to the Tor network, or even the rate of overall success of making a connection to the Tot network, it would make a lot of sense to automate the entire thing. The system can auto-detect for proxies, and the system can auto-probe to see which bridges would work for that user. The talk of introducing some level of automation into the launcher has been talked about this within the Tor community, has repeatedly come up in discussions among Berkeley researchers, and suggested by members of the focus group which helped the transition from Iteration 4 to Iteration 5.

However, there may be situations where this can be dangerous. For instance, a government could log any unsuccessful attempts to connect to the Tor network and prosecute someone based on this information. To our knowledge, this is pretty rare today, but 1) we must consider the agency of our users 2) this may be a more threatening concern in the future.

If we just knew if our users would be safe if we automatically configured for them, we would! But there's no good way to do this. One straight-forward way to get this information is to ask the users, "Are there consequences of automating your configuration?", but this is imperfect in many ways. Firstly, users may not be aware that there is any danger presented to them. Secondly, users may deliberately and knowingly put themselves in danger. Yes, it would be their choice, but it may have ethical concerns if we put it in our interface as the path of least resistance.

Is there any way to get this information? Is this a good idea? How much of the Tor launcher should be automated (just the proxies, bridges, proxies and bridges)?

"Do you know which bridge to choose?"

An alternate question to ask our users is to ask them if they have enough information to make an informed decision. In the previous section, we asked them if they were in any danger. To ask them if they have enough information to make a decision is a different question which considers the ability of the user to make decisions, but does not take into account their consequences as directly. One could argue that people who don't know how to configure their connection would have made mistakes anyway, but making the mistakes for them is quite a different thing than letting them make the mistakes themselves.

In this version of automation is to auto-detect for proxies and only involve the user if a proxy is configured, and for the bridge configuration to ask the user if 1) they want to not use a bridge 2) If they want the launcher to automatically pick a bridge for them (get some permission to auto-probe for bridges). This would work, but will users have an accurate assessment of their technical knowledge? Would they answer truthfully?

Are proxies configured often?

Generally across the internet, the number of users who are behind a proxy are very, very few. Does this change for users of Tor?

If proxies are very, very, very, rarely configured, then we could automate the detection for if a proxy is required and skip the proxy configuration screen entirely, and only show it when it is necessary. Currently, all users see this screen at some point during the configuration, and during the qualitative user experience studies, proxies were the largest source of confusion.

A More Enticing "Help" Button

In our qualitative user experience studies, we found that not many people clicked on the help button. When asking some of our users about why they didn't, one responded that the help button is 1) usually not useful, 2) a huge block of text, and 3) requires more work from the user. The participant responded that if a help button would actually "help," or perform something on behalf of the user, then the help button would be more useful, and tempting to click on.

Currently, the help button is only on the bridge configuration window, and it helps users enter custom bridges. What about expanding the help button to include other sources of confusion, or making it more useful for the user? I (Linda) don't have any concrete ideas on specific things that the help button should do or should not say, but I think that a discussion could be fruitful.

Miscellaneous Considerations

Some of these points were brought up at one point or another. We didn't find them high-priority, but we didn't want to lose them either, so they live here.

  • Examples of configuration: Would giving examples of configurations in China, Iran, France, etc. help a user?
  • Should the help button be renamed to something like "I'm Stuck!" or something more enticing?
  • Can we and should we fit all the configuration options on one screen?

Impact to Tor's Launcher

  • #11773 : setup wizard UI flow improvements

Attachments (7)

Download all attachments as: .zip