On Friday 13 Jul 2012 07:48:01 Steve Dougherty wrote: > Inspired by ArneBab [1] I had an idea for the first run setup. Here's > an attempt at drawing it in text: > > |------------------------------------ > | Setup | > | ----- | > | | > | o > Low Security | > | o > High Security | > | o > Maximum Security | > | o > Custom | > | | > |------------------------------------ > > This is intended to convey a box titled "Setup" containing a list of > radio buttons with security options. Each option has, to the left of > the text, a rightward pointing arrow. > > |------------------------------------ > | Setup | > | ----- | > | | > | o V Low Security | > | Blah blah blah blah | > | blah blah blah blah | > | o > High Security | > | o > Maximum Security | > | o > Custom | > | | > |------------------------------------ > > When an arrow next to a section is clicked, it turns downward as a > pane slides down from under the label containing an explanation of the > setting. Clicking it again toggles the explanation to slide up > underneath the section and the arrow to turn rightward again. > > |------------------------------------ > | Setup | > | ----- | > | | > | . V Low Security | > | Blah blah blah blah | > | blah blah blah blah | > | o > High Security | > | o > Maximum Security | > | o > Custom | > | | > | > Blah blah |___________| | > | > Blah blah |__________V| | > | | > | [Done] | > |------------------------------------ > > When a radio button is selected, if not already expanded the > explanation of that option slides down and the arrow turns. This would > be nice because it would allow the interface to demonstrate the > functionality of the arrows during normal operation in addition to > mouseover providing hints. Another pane slides out from underneath the > list of options which contains the necessary settings for that option. > Each setting has an input to the right of the label. To the left of > the label is an arrow which provides explanation for that setting like > the arrows in the option list. > > As this idea would already involve great amounts of Javascript, inputs > could do useful things like turn valid values green and invalid ones > red, or show estimated monthly bandwidth usage next to the bandwidth > limits. > > The "Done" button at the bottom would of course complete the setup, > and perhaps also present the option to generate a randomly named WoT > identity. > > Also shown here is a maximum security option. This could do things > like have the maximum security level for both network and physical, as > well as disable probes, disable routing by claimed peer locations, and > so on. The explanation on this one would make it clear the > ramifications of such an option, as well as mention which settings are > likely to be deemed impractical or have undue performance impact. > > One possibility - provided darknet invitations are implemented - is to > have a field for an invitation in the settings. It'd be fantastic if > that field was automatically filled in when setting up a node using an > invitation package. > > This design seems really exiting to me, though as I'm working on the > probes currently I don't have the time to work on this. > > Thoughts?
On the whole, this is a good idea. Expanding the explanation and detailed settings when the radio button is chosen is sensible. Several issues: It is essential that we explain, clearly, and as early as possible, the need for friends, e.g.: High Security (only if you know people already on Freenet) Low Security (faster, you can use this even if you don't know anyone on Freenet) Custom (advanced settings) Is there any good reason to not use the old wizard for Custom? It's not THAT bad, and asking *everything* on one page would make it a rather gigantic page and/or unusably terse. Do we need Maximum? We can ask for an (optional) password on High. Network seclevel maximum doesn't do much, a few minor things e.g. probes. Physical seclevel = maximum arguably is a separate concern anyway - we might want to ask about it on High, and like the above, we can be concise ... E.g.: Downloads password: [ enter password ] Repeat password: [ enter password ] Warning: You cannot recover your downloads if you forget the password! (The above two lines only show up once the user starts entering a password) (All three are greyed out if the user clicks the next checkbox) [ ] Encrypt downloads and local cache and delete them on restarting Freenet (safer if computer is seized/stolen) Warning: You will lose your downloads when restarting your computer or Freenet! Also, Freenet will be slower and less secure against an attack over the internet. (PLAIN ENGLISH - WHAT DO WE CALL ATTACKERS ???) (Warning only shows up if box is checked) [ ] Don't encrypt anything, I am already using full disk encryption Warning: Checking this box will speed up Freenet a bit, but is slightly less secure, especially for temporary files (Warning only shows up if box is checked; I guess some full disk encryption software has secure deletion, I don't think it's true in all cases?) I'm not convinced that we need the last box, it's popular with freenet geeks but they can use custom. The middle box is probably useful for users in hostile environments, even if they are not very computer literate, so arguably should show up for High Security. We should definitely allow setting an optional password on High Security IMHO. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20120728/1d9c7779/attachment.pgp>
