Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#23136: moat integration (fetch bridges for the user)
---------------------------------------+-----------------------------------
 Reporter:  mcs                        |          Owner:  brade
     Type:  defect                     |         Status:  needs_information
 Priority:  Very High                  |      Milestone:
Component:  Applications/Tor Launcher  |        Version:
 Severity:  Normal                     |     Resolution:
 Keywords:  TorBrowserTeam201711       |  Actual Points:
Parent ID:                             |         Points:
 Reviewer:                             |        Sponsor:  Sponsor4
---------------------------------------+-----------------------------------

Comment (by antonela):

 Replying to [comment:15 mcs]:
 > Replying to [comment:13 antonela]:
 > > Hi all!
 > >
 > > I think is pretty clear when you have 3 options.
 > > ...
 >
 > Thank you for creating a new mockup.


 No problem, we're here to help :)


 >
 > When viewed at a high level, it is definitely clearer to have 3 radio
 buttons. But for the following reason that I mentioned in comment:10,
 Kathy and I do not think a radio button is the correct UI element to use
 here:
 > * What do we do after a bridge is received via moat? The obvious answer
 is that the bridge configuration line will show up in the "Provide a
 bridge I know" text area. But that means that having a radio button for
 the moat interaction does not make a lot of sense; it is a short-lived
 modal interaction (stop what you are doing, interact with BridgeDB, done)
 rather than a state that needs to be maintained.
 >


 Yes, I understand. I think that is what we do after the bridge is received
 is where we are missing. If we replace the content with the bridge phrase
 seems more clear that you are going to connect to this bridge. If the user
 wants, again, another bridge, he can click on [New Bridge]. After that,
 the captcha block will appears again.

 I that way we are not compromising the other options if they are the
 needed ones.

 Take a look at this mockup
 https://trac.torproject.org/projects/tor/attachment/ticket/23136/23136-1.png


 > Also, *not* using an overlay approach will require either a really large
 window or a small CAPTCHA image (and neither of these is ideal).
 Got it. We can still have the overlay if we keep the 3 options.

 Definitely is something we could test with users :)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23136#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs