Redesign about:preferences#tor following user feedback

changed milestone to %Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibet

added Doing UX Team Sponsor 96 UX labels

assigned to @duncan

changed the description

mentioned in issue #40773 (closed)

Broadly speaking, I've tried to satisfy three main requirements in this iteration of about:preferences#tor:

Implement the basic changes needed to ~~Tor Network~~ Connection settings to accommodate the new, mostly automatic connection method offered by Connection Assist and its corresponding user flows (see #40781 (closed)).
Take the opportunity to apply more general improvements to the user experience, using the feedback we've collected through interviews and usability testing for Sponsors 9 and 30 over he past few years – based on the understanding that there will always be connections issues or censorship that Connection Assist cannot overcome.
Improve the visibility of configured bridges, including a more shareable UI to help censored users share and distribute secret bridges within their own networks.

Although this is a work in progress, here are some initial screens:

Not connected

Changes include:

Inheriting the changes made to display the browser's connection state in the browser chrome as detailed in #40780 (closed).
Updating the name of the tab from Tor to Connection, as per #40568 (closed).
Surfacing the connection state itself within ~~Tor Network~~ Connection Settings, featuring connection states for both the Internet and Tor Network (referred to as the "status board" hereafter).
Improving the description that accompanies the quickstart setting to clarify its functionality in light of the addition of Connection Assist.
Tidying away the Bridge configuration and network settings fields behind four buttons, each of which will open in a modal window (pending design). The final design for the Provide a Bridge modal in particular will seek to satisfy #40552 (closed) in particular, with the combination of modals and light validation solving #40551 (closed).

Connection error (specifically Tor being blocked)

Further changes include:

Changing the message-bar color to red and displaying new strings in the event of a connection error.
Updating the status board to reflect any changes to connection state – in this case, featuring an inbetween state warning that Tor may potentially be blocked.
Revealing a new option within the Bridges section to launch the Connection Assist UI (see #40781 (closed)) from within ~~Tor Network~~ Connection settings. I imagine when pressed the Choose a Bridge For Me button would open Connection Assist in a new tab, and self-initiate its first attempt to find and apply circumvention settings (i.e. the user doesn't need to press Try a Bridge again).

Bridge configured

Further changes include:

Again, updating the status board to reflect the current connection state – which in this instance is fully connected.
Revealing a card within the Bridges section to display the user's active bridge. However the contents of this card will require review and input from the wider team before we build it, which I'll follow up with in a separate ticket.

Hi, @duncan! Great work

In the last test (see full report here tpo/ux/research#52 (closed)), users felt the need of highlight warning indicating the need to configure a bridge, and this will probably make it.

One point of attention tho: after the bridge is configured and the user is connected, the message bar (not connected: purple, error to connect: red) disappears? Have your considered turning it to green instead?

Also, for manually choosing bridges some users missed a save button (see https://gitlab.torproject.org/tpo/ux/research/-/issues/58#note_2767225)

marked this issue as related to #40774 (closed)

mentioned in issue #40774 (closed)

mentioned in issue #40781 (closed)

mentioned in issue #29590 (closed)

mentioned in issue #40568 (closed)

mentioned in issue tpo/ux/research#20 (closed)

marked this issue as related to tpo/ux/research#20 (closed)

removed Sponsor 96 label

added S96-maybe-O3 label

marked this issue as related to #40777 (closed)

@pierov I've updated the mockups, notes and Figma files above to reflect the decision made in #40568 (closed) to go with Connection as the new name for this preferences tab, instead of Tor Network.

Okay; is this an answer to #40777 (closed)? Or is it okay if I fix this for #40774 (closed)?

Oh this is just a fix for #40774 (closed) at the moment, I'll update #40777 (closed) separately today.

Consider this ticket and #40774 (closed) inherently linked :)

Okay, I just wanted to be sure :)

Based on the conversation @richard, @meskio and I had in #40781 (comment 2772219), it turns out we're not going to know the browser's Internet connection state unless the user has attempted to connect to Tor first.

So, I thought a "Test" button could work here for users who have not attempted to connect yet, which would (in theory) perform the same ping we discussed when bootstrapping fails:

How do you feel about that richard/meskio?

Sounds good, as @richard proposed (#40781 (comment 2773967)) we could just call the domain we use as domain fronting to do this test.

mentioned in issue #40796 (moved)

mentioned in issue tpo/ux/design#39 (closed)

marked this issue as related to tpo/ux/design#39 (closed)

marked this issue as related to fenix#40189 (moved)

We discussed the practicality of human-readable bridge IDs in today's meeting, and @shelikhoo made a good point that basing these on an English-language dictionary would lead to poorer recognition by non-English speakers. @n8fr8 suggested replacing these with emojis instead (similar to how matrix.org handles key-comparisons, which is a nice analogue), which would have the added benefit of still being a11y friendly

@gus also suggested that we should make clear somewhere (e.g. on the bridge card design itself, the bridge input modal and/or our documentation) that human-readable bridge IDs cannot be used as inputs and are only there to validate that the intended bridge has been added successfully.

Next steps: I'll take a look at updating the bridge card design following the feedback above.

Thanks!

@gus also suggested that we should make clear somewhere (e.g. on the bridge card design itself, the bridge input modal and/or our documentation) that human-readable bridge IDs cannot be used as inputs and are only there to validate that the intended bridge has been added successfully.

I think we could either mention this in the learn more that the cards have, or we could add a tooltip on the emojis themselves (although I do not think that any other Firefox component does something like this...).

Also, is there a list of emojis to avoid?

Also, is there a list of emojis to avoid?

That's a good question, I'll give it some thought. Flags come to mind initially though.

Full unicode list here: https://unicode.org/emoji/charts/full-emoji-list.html

It might be easier to pick subsets to include based on their usefulness, rather than identify specifically what we want to exclude. Subsets like alphanum, for example, probably won't be very helpful here.

We could just use a restricted set, instead.

We can express a 32-bit hash with 4 emojis taken out of a 256 emojis group. So we can choose the ones that are easy to describe, e.g., only one kind of smile, instead of different variations that are difficult to describe, fruits, tools.

(I had a look at the Telegram source code to verify calls, and they have a pretty small list of emojis as well).

Yep, sounds good!

I've split this task into a new ticket here: #40860 (closed)

Some other interesting experiments on visualizing keys (via @arma) here: https://github.com/mailpile/Mailpile/issues/1093

marked the checklist item Design card providing a snapshot of the “active” bridge in about:preferences#tor as completed

mentioned in issue #40833 (closed)

mentioned in issue #40836 (closed)

mentioned in issue tpo/anti-censorship/team#69 (closed)

mentioned in issue #40838 (closed)

marked this issue as related to #40568 (closed)

marked this issue as related to #40551 (closed)

marked this issue as related to #40552 (closed)

marked the checklist item Design “Select a Built-In Bridge” modal and user flow as completed

I've been doing some design QA of @pierov's recent builds (as part of his work in #40774 (closed)), and realized we need to iterate on the designs for about:preferences#connection a little further.

One of the bigger issues with the original design was the assumption that we could display only one "active" bridge even when multiple bridge lines have been loaded. However, we won't be able to tell which bridge Tor has magically chosen until after connecting, and therefore need a UI that can support multiple bridge cards instead. Most of the time this will be three-ish, but in the case of built-in obfs4 it'll be more like ten.

We initially considered carousel-ing the bridge cards when multiple are presented, however due to the poor discoverability carousels we decided an accordion would be more useful:

Not connected, Collapsed list

Changes include:

Shifting the toggle switch to enable/disable bridges (without removing them entirely) into the section header to enable or disable all saved bridges simultaneously.
Adding a new "compact" card state that expands into the full bridge card when clicked (see demo below for an example).
Collapsing the stack (when >4 bridges are saved) with the option to expand to view the full list in order to mitigate the potential for large stacks to bury the options positioned underneath on the page.

On the accordion's functionality itself: I think in this instance it would be useful to restrict the accordion to a single expanded item only – meaning expanding a compact item would collapse the previously expanded item. This would also limit the height of the page jumping around when the accordion is interacted with.

Not connected, Expanded list

Changes include:

Displaying the full list when "Show all bridges" is selected.
Revealing the hidden option to "Remove all bridges", clearing the entire configuration.

There's a rather buggy demo of the accordion when not connected here: Figma link

Connected, Collapsed list

Changes include:

Adding a "Connected" label to the bridge that's currently in use.
Automatically expanding the "Connected" bridge as default, and positioning it at the top of the stack.

Connected, Expanded list

There's another buggy demo of the accordion when connected here: Figma link

QR code modal

Changes include:

Applying a #000000 background at 50% opacity (however please use whatever overlay style already exists within about:preferences if this is incorrect).
Opening a modal with an enlarged QR code for easier scanning.

Also: I've incorporated the bridge-moji IDs proposed higher in the thread in this iteration of the designs too. Although I'm worried it's too abstract as a concept to be practical, being able to differentiate between bridges at a glance feels extra useful when their stacked together like this, and I think it's still worth pushing into Alpha for feedback.

Lastly, I've moved the whole redesign into a dedicated Figma file viewable here instead: Figma link

Created a new ticket for implementation here: #40861 (closed)

Here's a quick mockup of the disabled state for the "...current bridges" section too:

Connected, bridges disabled

Changes include:

Appending the subsection header with (disabled).
Switching the accordion to 40% opacity when disabled. However if that feels too extreme, we could use 60% for the cards and 40% for the button.

One extra note: this feature is intended to replace the current "Use a bridge" checkbox, which requires the user to enable bridges as a prerequisite before the bridges themselves can be added. Instead, the "...current bridges" subsection and toggle switch should only appear when a bridge configuration is present – hopefully saving users an extra click :)

Do you want the switch just on the right of the writing, or would you prefer having it aligned to the opposite side, like the bridge cards?

Do you want the switch just on the right of the writing

I think this works better, please.

I tried aligning it to the opposite side like the switches in about:preferences#privacy (in Firefox) initially, but I ended up ditching the precedent as its functionality felt clearer when positioned directly alongside the section header itself.

I've updated #40837 (closed) to reflect the new designs

mentioned in issue #40860 (closed)

mentioned in issue #40861 (closed)

mentioned in issue #40837 (closed)

mentioned in issue tpo/ux/research#71 (closed)

added Q2 label

I've built a slightly more interactive prototype for use in the next phase of Nah's user research in Brazil & Mexico (see tpo/ux/research#71 (closed)):

Figma prototype

In it, you can add an automatic bridge (when selecting either "Automatic" or "Brazil"); any of the built-in bridge options; or request a bridge. Adding a bridge manually isn't hooked up yet, but I'm hoping to look at that modal soon.

One part of the user journey Nah will be scrutinizing in particular is the point at which the user has successfully added a bridge, but still needs to connect (ideally by clicking the "Connect" button in the purple message bar at the top of the screen). If usability testing suggests this is a pain point, we could consider replacing the "OK" button with a "Connect" button within the modals themselves.

Although this research won't dive into sharing of bridges, we should keep an eye out for any interesting reactions to the newly-featured bridge-moji too

mentioned in issue fenix#40215 (moved)

marked this issue as related to fenix#40215 (moved)

added Sponsor 96 label

mentioned in issue tpo/ux/research#42 (closed)

mentioned in issue #40890 (closed)

removed Doing label

added Next label

changed the description

The last piece of the about:preferences#tor redesign – the "Add a Bridge Manually" modal – will be tackled here: #40552 (closed)

closed

Redesign about:preferences#tor following user feedback

Designs

Child items ...

Activity