[tor-dev] Tor Launcher settings UI feedback request

[Mike Perry]

Thus spake Adam Shostack (adam at homeport.org):

> On Sat, May 04, 2013 at 12:54:35PM -0700, Mike Perry wrote:
> | > I think this might be the right direction.  The person running Tor
> | > knows two things: if they're worried about someone monitoring their
> | > network right now, and how technical they are (and their desire to tweak
> | > settings).
> | > 
> | > The UI could thus start:
> | > 
> | > "Should Tor do our best to figure out how to get connected, at risk of
> | > drawing attention and response if you're on a heavily-monitored
> | > network?"
> | > 
> | > [I need to be careful, I'll configure things (Recommended) ]
> | > 
> | > [ Probe the network (Riskier) ]  
> | > 
> | > [ I'm not sure, please help me decide]
> | 
> | I like this direction. I think it can capture all of our concerns.
> | 
> | Right now, "Probe the network" would just mean "Try the public network".
> | Later, it can mean more extensive probing (of perhaps a selected subset)
> | of pluggable transports. At that point, we could break it out into "My
> | Internet connection is not censored or filtered" and "I am censored:
> | Probe some common circumvention mechanisms for me (Risky)"
> | 
> | That would capture Naif's request of having a one-click option that
> | allows people to just connect to the public network if that works for
> | them (which is still the lion's share of our userbase), and has an
> | explicit option to help people through any confusion.
> | 
> | I think we're getting closer!
> 
> What else does it need?

Well, this is a difficult piece of UI, but it is not a large one. 

I think we need to dial in the actual verbage for the strings and the
help text for this first-run Wizard, and the specific stages and steps
we actually need for the first time, vs what we can additionally ask if
network bootstrap fails (the firewall question, for example), vs what
should we present in the more compact UI in the settings menu. It's all
the same UI, just different presentations.

We also need to freeze the strings as early as we can to avoid driving
the translators nuts (or worse, end up with misplaced/inaccurate
strings). Commonality for strings between UI elements might be nice
here.


On ther other hand, we also need to be careful not to over-engineer it,
so as to delay getting this into the hands of people who currently
cannot use gettor (because of the Vidalia+TBB bundle size). As I said
previously, we burned 4 months deliberating the "Don't touch the
network" option before, and still ended up with something we're not
satisfied with.

It is my belief this is because the underlying circumvention and bridge
discovery mechanisms simply require too much user input right now, and no
amount of deliberation over the UI to support these systems will truly
solve that problem.

So far, this has led me to decree that "Let's just keep this damn thing
simple enough to capture what we can actually do now, and worry about
pluggable transports, probing, and autodiscovery later."


If everyone really believes should instead decide about as much as we
can up front, we should design the general structure of the Wizard such
that it is enough to handle both the situation now, and once we have
more sophisticated pluggable transport and bridge discovery machinery.

However, if this process even begins to smell like it's going to take
more than a week (let alone 4 months) before we can arrive at a solution
we can deploy in an alpha, I'm going to cut it off. At that point, it
would be better just to design a new Wizard once the transport discovery
and probing mechanisms are actually ready, and we better understand
their exact form, capabilities, and configuration requirements.


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130504/beafb61d/attachment.pgp>