[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)
#23136: moat integration (fetch bridges for the user)
---------------------------------------+--------------------------
Reporter: mcs | Owner: brade
Type: defect | Status: new
Priority: Very High | Milestone:
Component: Applications/Tor Launcher | Version:
Severity: Normal | Resolution:
Keywords: TorBrowserTeam201712 | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor: Sponsor4
---------------------------------------+--------------------------
Comment (by isabela):
Replying to [comment:22 mcs]:
> Unfortunately, Kathy and I did not know that you were planning to do
more design work. We have already proceeded down a different
implementation path (using the overlay approach, as we discussed). Since
we are already well past our engineering deadline for this task, I don't
think it makes sense to switch right now to the inline flow that you have
designed. Also, our implementation includes most of what you suggested.
I know this project is running late. We understand it and is ok to go with
the flow you implemented. I think we will do better with timing on new
projects, we are actually doing it with the roadmap coordinations which is
giving time for design work etc.
Here is some info about our flow:
> * When the user clicks the "Request another bridge" radio button, a
CAPTCHA prompt is shown. This prompt is overlaid on top of the other
content that is in the settings panel.
> * If the user cancels without completing the CAPTCHA, the prompt is
closed and a "Request a Bridge…" button is displayed beneath the "Request
another bridge" radio button.
> * If someone who is interacting with the CAPTCHA prompt enters an
incorrect response, we keep the same CAPTCHA but display the following in
red below the CAPTCHA image: "The solution is not correct. Please try
again."
> * After the CAPTCHA is solved and a bridge is obtained, the overlay
disappears and the bridge info is displayed beneath the "Request another
bridge" radio button. We also change the button label to "Get a New
Bridge…"
>
> This is very similar to what you proposed, so I think we are actually in
agreement on most points. Hopefully we will have a test version available
soon, although we have a BridgeDB dependency and we are not 100% finished
with the Tor Launcher code either.
>
Yes, is very similar indeed. Our only concern is with the pop-out because
its not always a nice experience and takes the person out of that wizard
window (not as bad as we had before where the user would have to go, open
their email client, type the email etc).
But I think we can totally work on testing it later on, and see how our
users goes about it and if it needs any improvement. We will always be
iterating with our work and we can look into that on a new iteration
later, after we have the feature out and working.
> In the meantime, please let us know if you would like us to make some
screenshots. I know it is difficult to visualize the interface based on a
textual description.
If is not too much trouble I would like that. But if its, don't worry we
can play with it once is in alpha.
Question! If all goes well this implementation will be on a alpha release
around Dec 15?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23136#comment:23>
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