Opened 4 months ago

Last modified 15 hours ago

#28329 needs_review enhancement

Design TBA+Orbot configuration UI/UX

Reported by: sysrqb Owned by: tbb-team
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-mobile, ux-team, TBA-a3, TorBrowserTeam201902
Cc: antonela, igt0, tbb-team, gk Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor8

Description

I now have TBA and Orbot glued together. They co-exist, but I'm not sure how they should look or interact together. Where in the TBA app/screen should we have a button that switches to the Orbot screen? Do we want Orbot's onboarding UX or do we want our own?

Please help :)

Child Tickets

Attachments (15)

28329.png (241.4 KB) - added by antonela 3 months ago.
userflow.png (203.6 KB) - added by antonela 3 months ago.
mockups-1.1.png (369.8 KB) - added by antonela 3 months ago.
userflow-1.1.png (214.2 KB) - added by antonela 3 months ago.
mockups-1.1.2.png (371.1 KB) - added by antonela 3 months ago.
userflow-2.png (216.5 KB) - added by antonela 2 months ago.
mockups-2.png (225.0 KB) - added by antonela 2 months ago.
network-settings.png (818.4 KB) - added by antonela 6 weeks ago.
mockups-3.png (813.2 KB) - added by antonela 6 weeks ago.
mockups-4.png (749.0 KB) - added by antonela 5 weeks ago.
network-settings-2.png (420.2 KB) - added by antonela 5 weeks ago.
01-tba-review-1.0.png (147.7 KB) - added by dunqan 2 weeks ago.
01-tba-review-2.0.png (146.0 KB) - added by dunqan 2 weeks ago.
01-tba-review-3.0.png (149.3 KB) - added by dunqan 2 weeks ago.
01-tba-review-4.0.png (184.1 KB) - added by dunqan 2 weeks ago.

Change History (45)

comment:1 Changed 4 months ago by antonela

Keywords: ux-team added

comment:2 Changed 4 months ago by sysrqb

Parent ID: #28051

Adding this as a dependency of #28051, too (we can delete it later, if needed).

comment:3 Changed 4 months ago by gk

Keywords: TBA-a2 added

Moving on TBA-a2 radar

comment:4 Changed 4 months ago by gk

Priority: MediumVery High

Changed 3 months ago by antonela

Attachment: 28329.png added

comment:5 Changed 3 months ago by antonela

hello! I made a first approach to this task:

I know that the current .apk is just a glued version, but is cool to have it as a reference to think about how to improve it.

The current First Time User flow looks like

  1. intro
  2. value proposition #1
  3. bridge suggestion - [Learn More]
  4. vpn mode
  5. start tor
  • browser opens
  1. welcome
  2. privacy
  3. tor network
  4. tips
  5. onions

I drafted a first version of an improved flow. On the big picture, it includes a bridge configuration step and removed the VPN settings. Also, I merged the privacy and tor network steps from the current onboarding into this bigger flow.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/28329/28329.png

I have questions for the Tor Network Settings in TBA. I see four options for config bridges at orbot now:

  • Connect directly to Tor (recommended)
  • Connect through community servers
  • Connect throught cloud servers
  • Request New Bridges.... (If all else fails)

Modo Bridge

Website
Cancel
Email

What is the plan for them? Are we going to carry all of them? Will MOAT work in TBA? Do we want to have a similar Tor Launcher UX?

Don't worry about the UI for now, let's first define how we want the user flow to be, which are requirements, and then we can go deep with screens.

comment:6 in reply to:  5 Changed 3 months ago by sysrqb

Replying to antonela:

hello! I made a first approach to this task:

Thanks!

I know that the current .apk is just a glued version, but is cool to have it as a reference to think about how to improve it.

I have a new version available now :)

http://sbe5fi5cka5l3fqe.onion/~sysrqb/fennec-60.3.0.en-US.android-arm_28051_1.apk
https://people.torproject.org/~sysrqb/fennec-60.3.0.en-US.android-arm_28051_1.apk

Orbot now works (or it should work, let me know if it doesn't). I removed the onboarding screens due to some coding issues, but we'll have new onboarding screens in any case. After Tor starts, the user must tap the back button to return to the browser. If the user's device is not running the newest version of Android, then they should have a notification that says Tor Browser in the drop-down list, and they can return to Orbot using that. We have a problem on the newest version of Android, so the notification isn't created and there isn't a way for the user to re-open Orbot except for killing the app and restarting it.

The current First Time User flow looks like

[snip]

I drafted a first version of an improved flow. On the big picture, it includes a bridge configuration step and removed the VPN settings. Also, I merged the privacy and tor network steps from the current onboarding into this bigger flow.

Yes, that looks good! I don't think we should say anything about the VPN mode (and we'll probably remove that in the future).

[snip]

I have questions for the Tor Network Settings in TBA. I see four options for config bridges at orbot now:

  • Connect directly to Tor (recommended)
  • Connect through community servers
  • Connect throught cloud servers
  • Request New Bridges.... (If all else fails)

Bridge Mode

Website
Cancel
Email

What is the plan for them? Are we going to carry all of them? Will MOAT work in TBA?

Yes, I don't know a reason why we wouldn't want Moat available in TBA. In fact, I think Moat provides an even better experience on mobile than on desktop. But, considering Orbot doesn't currently have support for moat, I think we should add it as a follow-up ticket for this, and we can implement it soon (but later).

Do we want to have a similar Tor Launcher UX?

I think we should use the better UX :) (whatever that is)

I think using the Tor Launcher UX is the simplest answer and it provides a consistent experience across desktop and mobile, so that is a good option. On the other hand, (saying the obvious) mobile provides a different UX than desktop, so creating a new experience that is mobile-specific may be better. I'd be happy with choosing the easy/simple option now, and we can iterate on it over the next few months.

comment:7 Changed 3 months ago by n8fr8

Are you just hard forking Orbot code and merging it directly into the Tor Browser repo? I thought you were going to a bit more modular approach?

This library: https://github.com/guardianproject/Tor_Onion_Proxy_Library is probably a better starting point, and something we could both collaborate on improving together. I see how using the Orbot code gives you a lot of config UI, PT's, etc quickly, but it isn't a library.

As for MOAT it is something I'm already looking into tackling with Orbot, and again, seems like it would be best implemented as a library so that other apps can utilize it.

Changed 3 months ago by antonela

Attachment: userflow.png added

comment:8 in reply to:  7 Changed 3 months ago by sysrqb

Replying to n8fr8:

Are you just hard forking Orbot code and merging it directly into the Tor Browser repo? I thought you were going to a bit more modular approach?

No, we're handling this gentler than that - see #28051. In the short term, we'll maintain a patch that we'll apply on top of the official Orbot repo. We don't want to hard-fork Orbot, but using Orbot is the fastest and "easiest" solution given the timeline we set.

This library: https://github.com/guardianproject/Tor_Onion_Proxy_Library is probably a better starting point, and something we could both collaborate on improving together. I see how using the Orbot code gives you a lot of config UI, PT's, etc quickly, but it isn't a library.

We'll most likely use Tor Onion Proxy Library in the future, but that depends on #27609 - and we didn't have time for that within the last two months. I believe we all agree that Orbot (as it is today), is not the long-term answer to our problem of bundling Tor with Tor Browser for Android.

As for MOAT it is something I'm already looking into tackling with Orbot, and again, seems like it would be best implemented as a library so that other apps can utilize it.

Yes, that'd be great. I was thinking we can coordinate this and collaborate, and make sure we're not duplicating effort in this area - but the last month has been focused on building a working MVP where the result isn't worse than TBA and Orbot (separately). After this release, we'll start looking at #27609 and work toward using that instead of Orbot.

Changed 3 months ago by antonela

Attachment: mockups-1.1.png added

comment:9 Changed 3 months ago by antonela

By aiming for the most minimal orbot integration for this release, I:

  • updated the userflow. We are not interacting with Bridges/PT yet.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/28329/userflow-1.1.png

  • made an approach for the Connecting... screen
  • suggested a layout for Tor Network Settings

https://trac.torproject.org/projects/tor/raw-attachment/ticket/28329/mockups-1.1.2.png

Last edited 3 months ago by antonela (previous) (diff)

Changed 3 months ago by antonela

Attachment: userflow-1.1.png added

Changed 3 months ago by antonela

Attachment: mockups-1.1.2.png added

comment:10 Changed 3 months ago by gk

Parent ID: #28051

Unparenting so we can close #28051.

comment:11 Changed 3 months ago by gk

Keywords: TorBrowserTeam201812 added

comment:12 Changed 2 months ago by gk

Keywords: TBA-a3 added; TBA-a2 removed

comment:13 Changed 2 months ago by gk

Sponsor: Sponsor8

Adding Sponsor8 tag.

Changed 2 months ago by antonela

Attachment: userflow-2.png added

Changed 2 months ago by antonela

Attachment: mockups-2.png added

comment:14 Changed 2 months ago by antonela

Hello team, matt and I discussed yesterday what could be our users' best scenario when starting TBA.

We think we can aim to bootstrap tor during the initial screen and then open about:tor.

As you know, I'm working with a designer to have our new icon animated, and we can use it as a loader while tor is bootstrapping. A progress bar is a good option too, but the right speed on the icon animation will make our users feel that it is loading faster.

I updated the user flow, and I approached some mockups for this flow.

What do you think?

https://trac.torproject.org/projects/tor/raw-attachment/ticket/28329/userflow-2.png

https://trac.torproject.org/projects/tor/raw-attachment/ticket/28329/mockups-2.png

comment:15 in reply to:  14 Changed 2 months ago by gk

Replying to antonela:

Hello team, matt and I discussed yesterday what could be our users' best scenario when starting TBA.

We think we can aim to bootstrap tor during the initial screen and then open about:tor.

As you know, I'm working with a designer to have our new icon animated, and we can use it as a loader while tor is bootstrapping. A progress bar is a good option too, but the right speed on the icon animation will make our users feel that it is loading faster.

I updated the user flow, and I approached some mockups for this flow.

What do you think?

I like the animated icon. However, I think we should not only rely on it indicating that Tor Browser is starting up but rather having some kind of progress visible seems useful to me. (especially given the bootstrap could take quite some time).

So, the overall idea is to just connect directly and only try other ways once the direct connection fails? What about scenarios where users need to hide the fact that they are using Tor in the first place by using things like the built-in meek PT right from start?

Changed 6 weeks ago by antonela

Attachment: network-settings.png added

comment:16 Changed 6 weeks ago by antonela

Hi folks,

I have been working on the Connecting flow and also on Network Settings.

As we signed, this version will follow this user flow
https://trac.torproject.org/projects/tor/raw-attachment/ticket/28329/userflow-1.1.png

Essentially, we will still have a Connect button.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/28329/mockups-3.png

1.0
It is the first screen when TBA start. The Connect button will start the bootstrapping. Users need to trigger it manually. The settings icon at the top right will go to Network Settings.

2.0
Once the user taps to connect, the icon will get animated and we will show the bootstrapping messages. We want advanced users to be able to see/copy tor logs. We will expose it by swiping to the left. If Tor fails, we will move users to the Settings Network screen.

For the unsuccessful scenario, we can take different paths:

a - Have a retry button
b - Suggest users to move to the Network Setting screen to config a Bridge
c - Move the user to the Network Setting screen with a message about what failed and some encouragement on how to fix it.

Do we have data about why bootstrapping fail in mobiles? Which are the most common failing cases?

3.0
If users arrive here after a failed connection, the copy at the top will change to encourage users to take action to fix it. I made the first approach on this screen. My idea is to divide this section into two: Bridges and Advanced Settings. With this split, users are lead to tap the first option instead of start exploring options that they don't know what are.


Network Settings

Since we want to have a balanced experience compared with desktop, I include the same options we have on the desktop. We'll not have moat for this version, so I skipped it.

The user flow is the same for each option. Users can switch on/off each setting, and then we move them to a second screen where the configuration is made.

When the user returns to the main network settings screen, they can see a status of the changes they made, at the description. If users want to change it, they can tap the entire row.

The copy is up to review. Material Design has excellent suggestions about how to approach this copy https://material.io/design/platform-guidance/android-settings.html

https://trac.torproject.org/projects/tor/raw-attachment/ticket/28329/network-settings.png

Last edited 6 weeks ago by antonela (previous) (diff)

Changed 6 weeks ago by antonela

Attachment: mockups-3.png added

comment:17 Changed 6 weeks ago by pospeselr

The user-flow and ui mockups look great!

The only thing that stands out to me is the language used here in the proxy settings. You would probably only need these settings when connecting via wifi rather than when on using 4G or whatever mobile data. We're sort of implicitly saying that by way of mentioning work or university networks but maybe mobile-specific language should be used here?

comment:18 in reply to:  16 ; Changed 6 weeks ago by gk

Replying to antonela:

[snip]

For the unsuccessful scenario, we can take different paths:

a - Have a retry button
b - Suggest users to move to the Network Setting screen to config a Bridge
c - Move the user to the Network Setting screen with a message about what failed and some encouragement on how to fix it.

c) seems to me the best option from those three. a) I doubt users understand why we just give them a "Retry" button in case things failed. And why should things get fixed just by tapping that button after the first try already failed? b) we could do that but we would move the user to the network settings anyway if they decided to tap the link, so we can do c) right from the beginning...

Do we have data about why bootstrapping fail in mobiles? Which are the most common failing cases?

As far as I know we don't have that data.

3.0
If users arrive here after a failed connection, the copy at the top will change to encourage users to take action to fix it. I made the first approach on this screen. My idea is to divide this section into two: Bridges and Advanced Settings. With this split, users are lead to tap the first option instead of start exploring options that they don't know what are.


Network Settings

Since we want to have a balanced experience compared with desktop, I include the same options we have on the desktop. We'll not have moat for this version, so I skipped it.

The user flow is the same for each option. Users can switch on/off each setting, and then we move them to a second screen where the configuration is made.

When the user returns to the main network settings screen, they can see a status of the changes they made, at the description. If users want to change it, they can tap the entire row.

The copy is up to review. Material Design has excellent suggestions about how to approach this copy https://material.io/design/platform-guidance/android-settings.html

There is no firewall ports configuration for Tor Launcher on start-up. While this is confusing to some users I think this is currently the right choice for mobile users, too. (I think we'll eventually drop that option altogether on desktop). See: #24452 for some discussion.

comment:19 Changed 6 weeks ago by gk

Keywords: TorBrowserTeam201901 added; TorBrowserTeam201812 removed

Moving tickets to Jan 2019.

comment:20 in reply to:  18 ; Changed 6 weeks ago by sysrqb

Replying to gk:

Replying to antonela:

[snip]

For the unsuccessful scenario, we can take different paths:

a - Have a retry button
b - Suggest users to move to the Network Setting screen to config a Bridge
c - Move the user to the Network Setting screen with a message about what failed and some encouragement on how to fix it.

c) seems to me the best option from those three. a) I doubt users understand why we just give them a "Retry" button in case things failed. And why should things get fixed just by tapping that button after the first try already failed? b) we could do that but we would move the user to the network settings anyway if they decided to tap the link, so we can do c) right from the beginning...

Agreed. The three failure cases I foresee are:

  1. The device doesn't have internet connectivity
  2. The network is censoring Tor connections (and the user needs a bridge)
  3. The network is throttling the user's connection (and the user would be happier using a PT)

We can provide different messages in these cases, but I think we can use the same message for 2) and 3). I suspect we can be a little smart here, too. If the user pressed the "connect" button without configuring a bridge/PT, then maybe we should automatically try one of the built-in bridges if bootstrapping fails. We can choose one or two at random from the list (probably obfs4). This isn't any worse than letting tor bootstrap directly (which is already did, and failed).

There is no firewall ports configuration for Tor Launcher on start-up. While this is confusing to some users I think this is currently the right choice for mobile users, too. (I think we'll eventually drop that option altogether on desktop). See: #24452 for some discussion.

I read through that ticket and some of the other mail. I think the argument "tor will eventually choose a working Guard node" is not very satisfying but I agree it is a much better solution than providing an option that confuses the users. I think it's worth not including the firewall options now.

comment:21 in reply to:  20 Changed 6 weeks ago by sysrqb

Replying to sysrqb:

Replying to gk:

There is no firewall ports configuration for Tor Launcher on start-up. While this is confusing to some users I think this is currently the right choice for mobile users, too. (I think we'll eventually drop that option altogether on desktop). See: #24452 for some discussion.

I read through that ticket and some of the other mail. I think the argument "tor will eventually choose a working Guard node" is not very satisfying but I agree it is a much better solution than providing an option that confuses the users. I think it's worth not including the firewall options now.

On second thought, that isn't completely true. If the user is connected on a network that requires configuring a proxy server (not simply filtering all non-80/443 destination ports), then providing a configuration option seems important. But, maybe we should think more about how we expose this and present this option. Maybe there's a better flow such that a user is less likely to be confused by this option when they need a bridge. I'm happy with deferring this improvement to #24452.

Changed 5 weeks ago by antonela

Attachment: mockups-4.png added

Changed 5 weeks ago by antonela

Attachment: network-settings-2.png added

comment:22 Changed 5 weeks ago by antonela

Great, so

  • we will move users to the Network Settings screen if something wrong happens.
  • I have a +1 about removing firewall options too.

If the user pressed the "connect" button without configuring a bridge/PT, then maybe we should automatically try one of the built-in bridges if bootstrapping fails. We can choose one or two at random from the list (probably obfs4). This isn't any worse than letting tor bootstrap directly (which is already did, and failed).

I like this idea! Though, I could approach the flow differently: If the connection fails, we move the user to the Network Settings screen. Here, the user will be allowed to enable "Internet is censored here" option. Note that I'm not mentioning Tor but Internet. We can discuss it once we'll review the copy.

Once the user switches ON that option, TBA can "choose one or two at random from the list (probably obfs4)". Then the user will back to the main screen, and the bootstrapping will continue/happen.

If users want to have a different bridge configuration, then they can press Change and so do it.

What do you think?

Updated Userflow
https://trac.torproject.org/projects/tor/raw-attachment/ticket/28329/mockups-4.png

Updated Network Settings
https://trac.torproject.org/projects/tor/raw-attachment/ticket/28329/network-settings-2.png

Early prototype (allows tap!)
https://marvelapp.com/33d23hc/screen/52368796

comment:23 Changed 5 weeks ago by sysrqb

Two questions.

  1. Do you have a preference for the gear icon we use? There is one available in Tor Browser already (but it isn't used on mobile, as far as I know). It's slightly different from the gear in the mock-up. This is the icon next to "Preferences" in the menu bar, from the hamburger button.
  2. From the user-studies, is presenting a "connect" button confusing? I know we discussed this and we want something the user may click/press so tor browser doesn't automatically begin bootstrapping, but should we experiment with using another word/phrase instead of "connect"? Or, should we simply use "connect" (because it is good enough)? :)

comment:24 in reply to:  23 ; Changed 5 weeks ago by sysrqb

Replying to sysrqb:

Two questions.

  1. Do you have a preference for the gear icon we use? There is one available in Tor Browser already (but it isn't used on mobile, as far as I know). It's slightly different from the gear in the mock-up. This is the icon next to "Preferences" in the menu bar, from the hamburger button.

Ignore this one. I found it on MD :)

comment:25 in reply to:  23 Changed 5 weeks ago by antonela

Yep, Connect is confusing if users need to choose between Configure and Connect, like our Tor Launcher for desktop scenario. In fact, there is not any hierarchy at the UI that allows users to understand which one will do the main action. This is not the situation here, though.

For sure, the ideal scenario is not having an opt-in from users to start a bootstrapping. We already have this consent when they launch the app.

That said, I'm happy to test other options. I'm thinking about "Start" since a while, but it doesn't change the overall user experience. What are your ideas? :)

Replying to sysrqb:

Two questions.

  1. Do you have a preference for the gear icon we use? There is one available in Tor Browser already (but it isn't used on mobile, as far as I know). It's slightly different from the gear in the mock-up. This is the icon next to "Preferences" in the menu bar, from the hamburger button.
  2. From the user-studies, is presenting a "connect" button confusing? I know we discussed this and we want something the user may click/press so tor browser doesn't automatically begin bootstrapping, but should we experiment with using another word/phrase instead of "connect"? Or, should we simply use "connect" (because it is good enough)? :)

comment:26 in reply to:  24 Changed 5 weeks ago by antonela

Yes, everything is MD! I'm not using custom icons here.

Replying to sysrqb:

Replying to sysrqb:

Two questions.

  1. Do you have a preference for the gear icon we use? There is one available in Tor Browser already (but it isn't used on mobile, as far as I know). It's slightly different from the gear in the mock-up. This is the icon next to "Preferences" in the menu bar, from the hamburger button.

Ignore this one. I found it on MD :)

Changed 2 weeks ago by dunqan

Attachment: 01-tba-review-1.0.png added

Changed 2 weeks ago by dunqan

Attachment: 01-tba-review-2.0.png added

Changed 2 weeks ago by dunqan

Attachment: 01-tba-review-3.0.png added

Changed 2 weeks ago by dunqan

Attachment: 01-tba-review-4.0.png added

comment:27 Changed 2 weeks ago by 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!

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!

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?

https://trac.torproject.org/projects/tor/raw-attachment/ticket/28329/01-tba-review-1.0.png

2.0 (Bootstrapping)

  • Should the settings icon be accessible from here at all, since it's a transitionary screen with a process already underway?
  • 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).
  • Do we need a link to cancel this process in case it hangs? Or provide a back button to screen 1.0?

https://trac.torproject.org/projects/tor/raw-attachment/ticket/28329/01-tba-review-2.0.png

3.0 (Network)

  • Are users knowledgeable enough to understand that censorship in their location is responsible for Tor's failure to connect?
  • 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.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/28329/01-tba-review-3.0.png

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
  2. Select from list
  3. 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?

https://trac.torproject.org/projects/tor/raw-attachment/ticket/28329/01-tba-review-4.0.png

Edits: Sorry, took me a few attempts to figure out how to embed images properly!

Last edited 2 weeks ago by dunqan (previous) (diff)

comment:28 Changed 2 weeks ago by gk

Keywords: TorBrowserTeam201902 added; TorBrowserTeam201901 removed

Moving tickets to February.

comment:29 in reply to:  27 Changed 11 days ago by sysrqb

Replying to 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
  2. Select from list
  3. 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.

comment:30 Changed 15 hours ago by sysrqb

Status: newneeds_review

There's a branch for review on 28329_6. I ran into multiple bugs, and I resolved some of them. The remaining bugs are:

  1. The (spinning) onion image isn't as large as it's shown in the mockup
  2. There is a up button (back button) in the upper-lefthand corner of the settings screen and it does nothing
  3. The mockup shows a dividing line between radio button bridge types, I failed getting that working
  4. When the gear/cog button is clicked from the Tor Log screen, the bootstrap process isn't stopped

(I'm probably forgetting some others, too)

I took a different approach for built-in bridges than Orbot. The bridges are provided by Gecko preferences the same as Tor Launcher. I think this'll make maintaining the list easier. However, as a result of this, the bridges are fetched asynchronously, so I added a placeholder in the radio button list while we wait for the response from Gecko.

I also added a Save button on the "Provide a Bridge" screen, because inputting a bridge into the the text box and then pressing "Back" didn't seem like an obvious flow.

On the branch, you can ignore the last commit. I simply used that for testing the Radio Button creation.

Note: See TracTickets for help on using tickets.