#23136: moat integration (fetch bridges for the user) --------------------------------------------+------------------------------ Reporter: mcs | Owner: brade Type: defect | Status: needs_review Priority: Very High | Milestone: Component: Applications/Tor Launcher | Version: Severity: Normal | Resolution: Keywords: TorBrowserTeam201802R, ux-team | Actual Points: Parent ID: #24689 | Points: Reviewer: | Sponsor: Sponsor4 --------------------------------------------+------------------------------
Comment (by antonela): Replying to [comment:64 brade]: > Replying to [comment:61 antonela]: > > Thanks @mcs for the explainer. > > So, in that case, my recommendation is to use a select > > Hi Antonela. I think you misunderstand what we need your help with (and I apologize that you are coming in at the end of the process and working with someone else's design). > Yes. > We need help with the words that appear next to the radio button and the words that appear in the button (see image in comment:56). > > Linda's UX design and the implementation by Isis do not intend for the user to choose among the bridges returned from the BridgeDB server, so a select control would not be appropriate. Each time the user requests bridges (see steps below) they receive a set of three and all three are used at the same time (the tor deamon figures out which one to use). > I see. Thanks a lot for sharing with me the technical background. > > About the captcha, will it show after the user selects which kind of bridge he wants? > > Here is the sequence of steps for displaying the captcha: > * user selects the radio button (currently labeled "Request a Bridge") > * user clicks the "Request a Bridge..." button > * [network activity occurs to obtain and display the captcha] > Here is what the captcha prompt looks like: https://trac.torproject.org/projects/tor/raw-attachment/ticket/23136/moat- Dec8-A-prompt.png > > The ASCII art in comment:59 happens after a correct solution for the captcha is submitted and a set of bridges is returned by the BridgeDB server. So basically, the flow is going to be as following [[Image(https://trac.torproject.org/projects/tor/attachment/ticket/23136/BridgeDB-1.png)]] [[Image(https://trac.torproject.org/projects/tor/attachment/ticket/23136/BridgeDB-2.png)]] > If all of the bridges from BridgeDB stop working, the user can "Request a New Bridge" to ask for a new set (which replaces the previous set). Honestly, I see the idea about to have double steps with a kind of rejection. But if this friction can improve the security, I'm in. IMO, the best label is the option A. Also, if at some point we want to offer a different source to get a bridge, it is easily extendible. I'm afraid that it could be converted into an infinite loop between not working bridges and request a new bridge button, which seems confusing. I'd like to review error user flows and see how they are working on with this iteration. Could we have a nightly build to reproduce locally? That could be useful :) -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23136#comment:67> 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