[tbb-bugs] #28329 [Applications/Tor Browser]: Design TBA+Orbot configuration UI/UX

[Tor Bug Tracker & Wiki]

#28329: Design TBA+Orbot configuration UI/UX
-------------------------------------------------+-------------------------
 Reporter:  sysrqb                               |          Owner:  tbb-
                                                 |  team
     Type:  enhancement                          |         Status:  new
 Priority:  Very High                            |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3,         |  Actual Points:
  TorBrowserTeam201902                           |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor8
-------------------------------------------------+-------------------------

Comment (by sysrqb):

 Replying to [comment:27 dunqan]:
 > Hey everyone,
 >
 > Antonela asked me to review the designs above. I'm not as knowledgeable
 about TBA & Orbot as most of the people in this thread though, so please
 take these recommendations with a pinch of salt!

 Thanks for the feedback!

 >
 > Firstly I agree with everyone who's suggested that the connection (and
 bridging) should happen automatically without requiring any input from the
 user. However the following review assumes there's a good reason for
 requiring manual prompts, since it seems to be the route we've gone down!

 This is a long-standing/outstanding question we have. In the general case,
 we can likely start connecting automatically. But there are some
 situations where that may put the person in harm's way, and we don't know
 in which situation we're operating, so we default to being safer.

 >
 > == 1.0 (Start screen) ==
 >  * Is there enough affordance in the settings cog as an icon alone, or
 should we be presenting users with two clear options instead?

 This is an interesting question. In my testing on a physical device, I'm
 finding it difficult to press the settings cog because it is a little
 small. This wasn't apparent when I was testing with an emulator. I think
 I'll make the settings cog larger or maybe we should consider using a
 different button. I like the existing design, I think it's more
 aesthetically pleasing than showing multiple large buttons.

 >
 >
 > == 2.0 (Bootstrapping) ==
 >  * Should the settings icon be accessible from here at all, since it's a
 transitionary screen with a process already underway?

 I think this is helpful. Pressing that button would effectively cancel the
 current process and restart the bootstrapping process after the person
 changes the settings and returns to this screen.

 >  * Increasing the contrast of "Swipe ~~to~~ left to see Tor log" will
 greatly help our visually impaired users (also note the wee typo in there
 too).

 Yep, I saw that too :)
 >  * Do we need a link to cancel this process in case it hangs? Or provide
 a back button to screen 1.0?

 Ideally, we'll detect when the process hangs and we automatically bring
 the user to the settings screen so they can change the configuration
 (assuming they know what they should do such that it'll work).

 >
 > == 3.0 (Network) ==
 >  * Are users knowledgeable enough to understand that censorship in their
 location is responsible for Tor's failure to connect?

 Right. This is a hard problem. Tor Browser *should* know and be smart
 about how it handles connection failures. Unfortunately, we don't have
 that information at this time, so currently we put the burden on the user.
 Hopefully this will improve in the future.

 >  * It may not be obvious enough to the user that the browser has
 successfully connected after hitting the switch, as the success state is
 quite subtle.
 >  * Users may not understand that they need to hit the back button to
 continue (which seems a little counter-intuitive), and could erroneously
 hit "Change" instead.

 Yes, I agree, my implementation of this takes this into account. I used
 the switch (enabling) as a button. If the switch is currently disabled,
 and the user presses the switch, then bridges becomes enabled and it
 instantly moves to the next Bridge configuration screen. If the user
 returns to this screen after configuring bridges (so the switch is
 currently enabled), and they press the switch again so it becomes
 disabled, then the bridges are disabled and the user is returned to the
 first bootstrapping screen.

 >

 >
 > == 4.0 (Combined Network/Bridge proposal) ==
 > It's my understanding that there are basically three mutually exclusive
 options on the table for when Tor's blocked:
 >
 >  1. Automatic selection
 >  1. Select from list
 >  1. Enter manually
 >
 > So with that in mind, I've wireframed a proposal that combines both the
 "Network" and "Select a bridge" screens into a single menu to:
 >
 >  * Help address any ambiguity about censorship in the UI
 >  * Reduce confusion about how to proceed once an option's been selected
 (as selecting an option will automatically advance to the next screen to
 attempt connection).
 >  * Better surface manual selection and entry for more advanced users.
 >
 > In this scenario, hitting the automatic option would cycle through the
 built-in list until a bridge can be successfully connected to.
 >
 > However nested radio-buttons may not be the best way to do this –
 thoughts?
 >

 Our idea with this is Tor Browser should detect when bootstrapping stalls.
 If the user tried connecting directly and that failed, then there's likely
 no harm in automatically trying some of the built-in bridges. If any of
 those result in successfully bootstrapping, then we're done. If none of
 them work or if the user already configured a bridge and it failed, then
 we'll show them the configuration screen so the user can configure an
 addition bridge for use. In the future, when we have Moat support, we'll
 be able to automatically query bridges.torproject.org for new bridges, as
 well, and that'll improve this flow, too - except for the added CAPTCHA,
 but that's what we have right now.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28329#comment:29>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online