#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
_______________________________________________
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
