Improve "Use Bridges" UI based on feedback and testing

We're likely to run into a few issues with the "Use Bridges Bridges" UI once users in various localizations try to use it. One issue we've already noticed is that people can become confused by the type selection dropdown, and may think it applies to bridges they enter in the "Enter custom bridges" textbox. We should probably make these radiobuttons behave such that they are more clearly mutually exclusive (ie when one is selected, all children of the other are greyed out).

I've tried to improve the situation a little with basic layout changes, but I am not sure those won't look worse in RTL languages and in very verbose localizaions, so that may be another issue to address: https://people.torproject.org/~mikeperry/images/Settings.jpg

added component::applications/tor launcher owner::brade priority::medium resolution::fixed severity::normal status::closed tbb-usability-stoppoint-wizard type::defect labels

What do you think of "Connect using built-in bridges" or "Connect using default bridges"?

Replying to Sherief:

What do you think of "Connect using built-in bridges" or "Connect using default bridges"?

We just finished discussing this extensively on IRC. We went with "Connect with provided bridges".

I would like to avoid any further string changes except in cases of dire need.

Trac:
Cc: N/A to mcs

Replying to mikeperry:

We just finished discussing this extensively on IRC. We went with "Connect with provided bridges".

That sounds OK to me.

I would like to avoid any further string changes except in cases of dire need.

Eventually, for consistency we will want to replace the phrase "default bridges" with "provided bridges" in more places (e.g., within the prompt text that is shown above the radio buttons and within error messages).

Replying to mcs:

Replying to mikeperry:

We just finished discussing this extensively on IRC. We went with "Connect with provided bridges".

That sounds OK to me.

I would like to avoid any further string changes except in cases of dire need.

Eventually, for consistency we will want to replace the phrase "default bridges" with "provided bridges" in more places (e.g., within the prompt text that is shown above the radio buttons and within error messages).

Thanks for spotting this oversight. This consistency update is better done earlier rather than later (before more languages get translated). I changed all the occurrences of 'default' that I could find into 'provided'. I pushed these changes to origin/master.

Recording a small annoyance here so we do not lose track of it: when custom bridge configuration lines are long, they wrap. That is OK but a little confusing. We should make the textbox wider or consider using a slightly smaller font to make line wrapping less likely to occur.

A few comments about the currently checked-in version of the wizard:

1. I'm concerned about the location of the Transport Type drop down menu (for the provided bridges). It's currently located right above the custom settings and I don't want people to think of the drop down menu as a filter for the custom settings. I think it would be more closely tied to the "provided bridges" if we kept it in the same row. Alternatively, we could add more empty vertical space between the drop down menu and the custom bridges radio button... but the wizard and network settings dialog are getting taller and taller. Another idea is to insert an additional wizard page that only asks about provided vs. custom (just the two radio buttons). That would make people click through more screens though.

2. For enabling/disabling various items in the bridges view, I think we should disable secondary text labels and the transport type drop down menu. But I do not think we should disable the custom bridges textbox since that will make an extra step for users before they can paste in their custom bridges.

3. The current wording for custom bridges is:

 (•) Enter Custom Bridges
     Enter one or more bridge relays (one per line)

It is not ideal that both lines start with the same word. I'd also like the text next each of the radio buttons to be fairly symmetrical. If one choice is to "Connect with provided bridges" then maybe the other choice should be "Connect with custom bridges".

There will be more to do as we receive feedback, but brade and I went ahead and added the enable/disable logic:

https://gitweb.torproject.org/tor-launcher.git/commit/7e006125569a58b4793c2950fb0a22d9b196a917

Trac:
Keywords: tbb-usability deleted, tbb-usability-stoppoint-wizard added

Trac:
Reviewer: N/A to N/A
Sponsor: N/A to N/A
Severity: N/A to Normal
Cc: mcs to mcs, mrphs

moved remaining child tickets to #31283 (closed) and Sponsor30.

Should we close this in favour of #31283 (closed) now?

Replying to pili:

moved remaining child tickets to #31283 (closed) and Sponsor30.

Should we close this in favour of #31283 (closed) now?

I say "yes" especially since (1) all of the child tickets are closed and (2) the configuration UI has been improved based on the user feedback sessions that Antonela and her team led. New tickets should be opened to cover specific issues that we learn about.

Trac:
Resolution: N/A to fixed
Status: new to closed

closed

mentioned in issue #11222 (moved)

mentioned in issue #11343 (moved)

mentioned in issue #12783 (moved)

mentioned in issue #14638 (moved)

moved to tpo/applications/tor-launcher#11180 (closed)