#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 --------------------------------------------+------------------------------ Changes (by gk):
* keywords: TorBrowserTeam201802R => TorBrowserTeam201802R, ux-team Comment: Replying to [comment:56 mcs]: > Replying to [comment:55 mcs]: > > I think the only reason it works how it does right now is that we were trying to stay faithful to Linda's design, which tried hard to reduce the number of clicks needed (by removing the wizard and generally streamlining things). But let's require the second click. Kathy and I have two questions though: > > a) What do you mean by "then showing the available bridges?" Do you mean offering a choice of bridge types (e.g., obfs3, obsf4) or do you mean showing bridges that the user has already obtained? The latter, i.e. showing bridges they already have obtained. > > b) What text should we use for the radio button label? Introducing "BridgeDB" without explaining it does not seem ideal, although the current design is somewhat cryptic as well. And it would be nice to keep the word "Request" because it avoids making the user think they need some knowledge ahead of time to use the middle radio button. Anyway, Kathy and I will see what we come up with for the label. > > Assuming you didn't have anything fancy in mind for "then showing the available bridges", here are a couple of possibilities for the radio button and button labels: > > [[Image(BridgeDB-UI.png)]] > > Thoughts? We are open to other ideas as well. I like A but don't feel strongly here. Would be good to include the UX folks into the discussion I guess. That said I am more than fine if we keep this as one item to think about for a proper inclusion into the stable series as it might be longer to get right. Leaving that part as currently envisioned for the upcoming alpha(s) does not sound bad to me. And, hey, maybe I am the only one that is surprised here. :) -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23136#comment:57> 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