setup wizard UI flow improvements

Tor Launcher does not saved modified Tor network settings if you change them while backing all the way out of the setup wizard. It should save them (if they have been modified) before attempting to connect (i.e., before clearing DisableNetwork). Steps to reproduce using a new TBB 3.6.1 installation:

Click Configure Choose "Yes" to configure a proxy Use values that will fail to work, e.g., HTTP/HTTPS 127.0.0.1:1234 Continue Continue Connect

The connection will not succeed. While tor is trying to connect, click Cancel.

Go Back Go Back Go Back Change the proxy setting to No Go Back Click Connect

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

Trac:
Keywords: N/A deleted, TorBrowserTeam201407 added

Trac:
Keywords: TorBrowserTeam201407 deleted, TorBrowserTeam201409 added

Trac:
Keywords: TorBrowserTeam201409 deleted, TorBrowserTeam201410 added

Trac:
Keywords: TorBrowserTeam201410 deleted, tbb-usability added

Trac:

first wizard panel with improved text

Trac:

bootstrap progress dialog with improved text

Trac:

bridges Yes/No wizard page with improved text

Trac:

bridges config wizard page with improved text

Trac:

proxy Yes/No wizard page with improved text

Trac:

new Reconfigure prompt (displayed after bootstrap failure)

Trac:

new "Remove Settings" prompt (displayed if "Connect" is clicked and bridge or proxy settings exist

Kathy and I started to work on this ticket, saw the early results from the Berkeley UX researchers, and ended up making a number of small improvements to the text and flow of the configuration wizard. We think these changes are a nice improvement, but we are open to better wording for the text and we probably will need to undertake a larger redesign after we receive more data from the planned usability studies.

Here is a walkthrough.

Change 1: Improved the text near the [Connect] and [Configure] buttons on the initial wizard page:

Change 2: Added text to the bootstrap progress dialog to let users know connecting may take a while:

Change 3: Improved explanatory text on the bridges Yes/No page: (we added "if you are unable to connect to the Tor Network without a bridge, you can add one later")

Change 4: Improved explanatory text on the bridges config page: (we added "Each type of bridge uses a different method to avoid censorship. If one bridge does not work, try again using a different one.")

Change 5: Revised the explanatory text on the proxy Yes/No page:

Change 6: Added a new "Reconfigure" prompt that is displayed after bootstrapping fails: (the idea here is to not leave the user on one of the proxy screens after a failure but take them back to the beginning of the configuration process so the sequence is consistent)

Change 7: Added a new "Remove Settings and Connect" prompt: (this is displayed if the user clicks "Connect" while some bridge or proxy settings are present and fixes a bug where the resulting connection was not direct)

Trac:
Severity: N/A to Normal
Sponsor: N/A to N/A

Trac:
Cc: N/A to gk

Trac:
Cc: gk to gk, dcf

Trac:
Cc: gk, dcf to gk, dcf, whonix-devel@whonix.org

Looks like good improvements to me. One thing I was unsure about is "If one bridge does not work, try again using a different one." You really mean "bridge" here and not "type", right? I think I got confused as you are talking about bridge type in the preceding sentence.

Replying to gk:

Looks like good improvements to me. One thing I was unsure about is "If one bridge does not work, try again using a different one." You really mean "bridge" here and not "type", right? I think I got confused as you are talking about bridge type in the preceding sentence.

Good catch. We are actually cheating a little by trying to use "bridge" so that the user can apply the thought of "using a different one" to both transport types and to specific bridges (e.g., if they are using custom bridges already). Maybe we are being too subtle though, and maybe the double meaning will be lost in translation.

Trac:
Summary: settings not saved after backing out of setup wizard to setup wizard UI flow improvements

Here is the patch that implements the changes described in comment:5: https://gitweb.torproject.org/user/brade/tor-launcher.git/commit/?h=bug11773-01&id=bca44eff3d0c8546ce25a0a366c2c823ff45710a This is ready for review but it is a Tor Browser 6 item due to the need for localization and user testing.

Trac:
Status: new to needs_review
Cc: gk, dcf, whonix-devel@whonix.org to gk, dcf, whonix-devel@whonix.org, arthuredelstein
Keywords: N/A deleted, TorBrowserTeam201601R added

Let's suppose I choose the configure option using the default obfs3 PT and Tor Browser is giving me an error back (as seen in #18066 (closed)). I click on the "Reconfigure" button but realize I might want to try to connect directly. Maybe it works. I click on the "Back" button on the Tor Bridges Configuration panel and am back at the first dialog (not counting the language selection one I had in my test build).

I click on "Connect" and am confused now as I see two "Back" buttons which as it turns out behave differently as well. The one next to the Remove-Settings-and-Connect-button gets me back to the previous pane where I'd been coming from. But the other one brings me to the Tor Bridges Configuration pane with the bridge selection. Huh? :) And I only have a "Back" and a "Quit" button there. If I click "Back" and "Next", voila a "Next" button shows up again...

I guess the Back button "built into" the dialog (i.e. the second one) should be hidden as well?

And one coding style thing I thought we should improve

  if (gIsBootstrapComplete)
    close();
  else if (wizardElem)
  {
    // If the user went down the "Configure" path and another error (e.g.,
    // Tor Exited) has not already been shown, display a generic message
    // with a "Reconfigure" button.
    let pageid = wizardElem.currentPage.pageid;
    if ((pageid != kWizardFirstPageID) && (pageid != "errorPanel"))
    {
      let msg = TorLauncherUtil.getLocalizedString("tor_bootstrap_failed");
      showErrorMessage(false, msg, true);
    }
  }

Could you put the if-clause in curly braces as well? Mixing both styles is error-prone.

Trac:
Status: needs_review to needs_revision

Thanks for the review! We fixed the "two back buttons" problem by adding a missing call to showWizardNavButtons(false) to the discardSettings wizardpage (via the onpageshow attribute).

We also added braces in more places within if/else constructs. Our revised patch is here: https://gitweb.torproject.org/user/brade/tor-launcher.git/commit/?h=bug11773-02&id=e18194b1622b4d8ef1b7a9674b63d1213e678199

Trac:
Status: needs_revision to needs_review

Thanks, applied to master (commit e18194b1622b4d8ef1b7a9674b63d1213e678199).

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

I tried a nightly build (specifically https://people.torproject.org/~linus/builds/tbb-nightly-2016-01-22/) and it didn't seem to include these changes. Any idea why? versions.nightly has TORLAUNCHER_TAG=master.

Replying to dcf:

I tried a nightly build (specifically https://people.torproject.org/~linus/builds/tbb-nightly-2016-01-22/) and it didn't seem to include these changes. Any idea why? versions.nightly has TORLAUNCHER_TAG=master.

Based on timing, it does seem like that build should include these changes. But it does not.

It seems ln5's machine is not properly updating master, hm... Anyway, https://people.torproject.org/~boklm/builds/6.0a1-build1/ has them.

closed

mentioned in issue #18154 (moved)

mentioned in issue #20795 (moved)

mentioned in issue tpo/core/tor#18154 (closed)

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