On Saturday 23 Mar 2013 21:37:06 Steve Dougherty wrote: > On 03/16/2013 12:38 PM, Matthew Toseland wrote: > > I don't know how important it is that it is all on one page. But > > IMHO we should not ask/show the dependant questions until we've > > asked the basic ones. So: > > > > Do you know someone who runs Freenet? > > > > Yes -> Do you want to connect to untrusted strangers to improve > > performance? Freenet will be faster but less secure. > > > > No -> Freenet will connect to strangers. You can always add > > connections to your trusted friends later to improve security. [ > > TODO FILE BUG Freenet should alert the user when it thinks they > > can switch to pure darknet mode, based on number of connections and > > whether content can be fetched via darknet-only requests ] > > That seems much more straightforward, yes. > > > Implementation? I think you can hide stuff based on which radio > > buttons are active with CSS. Or you could use a separate page, or > > Javascript. Whatever, just keep it simple, and make sure it works > > in some fashion without javascript. > > That'd be Irfan's area of knowledge. I also think that it'd be an > option to use the existing setup as a no-JS fallback, so this setup > could require Javascript if Irfan so desires. > > >> > >> |----------------------------------------| | O I have a bandwidth > >> cap. >> | > > > > "bandwidth cap" is jargon, isn't it? "I have a monthly bandwidth > > limit" ? > > Yes, that's better. > > >> | O I want Freenet to use up to [ ] KiB/s| | download and [ ] > >> KiB/s upload. | |----------------------------------------| > > I *strongly* object to forcing users to come up with numbers here > > with no guidance. This is MUCH worse than the existing wizard. Not > > everyone who tries Freenet is a filesharing geek. Most people > > don't even know what their upload limit is. > > Okay, but how can we possibly help someone input a value they don't > know? Is the goal to get a better guess?
Yes. > > I'm not sure that the list of common Internet connection speeds in the > current setup is helpful. If someone doesn't know their connection > speeds, would they then look them up to match them against that list? > Text blanks assume people are able and willing to do unit conversion, > which might be doubtful. When I get back home I can test this > assumption as I'll have both time and a supply of people who don't > know what their upload rate is. > > That said, most other things I use that ask for bandwidth limits (I2P, > torrent clients, router web interfaces) prompt for values in KB/s, so > maybe at least some people are already used to / expecting it. They also have defaults, and most of them don't try to run 24x7. Fortunately we can autodetect the limits from the router much of the time. Which is later on in the process, since we used to ask users whether or not to allow UPnP; I think it's always on unless you do custom now? Obviously if we've detected it we could provide a default - many users will want to be asked even if we can detect it, so it's probably best not to just skip it completely. IMHO the list we provide is sane, if we can't autodetect. There are good technical reasons why ADSL is usually no better than 8Mbps/448kbps, for example. They might well know that they have ADSL2 - or that they have 20Mbps. > > > Shorter is not necessarily more user friendly. Fewer words of > > explanation can be significantly *LESS* user friendly. It's a > > difficult balancing act of course... > > Yes. My goal in conciseness is not to remove necessary explanation, > but remove needless verbosity and technical detail. > > >> The download/upload fields should be filled with an > >> auto-detected limit if the node can find one. > > > > Good luck with that. > > > > I agree we should autodetect bandwidth if possible, but IMHO > > that's something that should happen at run time, and the user > > should be able to set a limit as well. If we had autodetection we > > could probably get rid of this entirely, have it only in the > > custom settings pages. > > Are we suggesting the same thing? What I'm proposing would happen at > runtime, like the current limit autodetection. My vague assumption is > that the node would serve the HTML/CSS/JS for the setup, then somehow > dynamically inform the page of a limit if it's able to detect one. Yes, if we're just talking about autodetecting via UPnP, that's fine. > > Irfan: Do you think it would make sense to have an autodetected limit > be hint text in the user's input field or do something else? > > Some possible changes: > * Inspired by I2P's setup: perhaps make the monthly bandwidth limit > consideration implicit by listing an estimate of monthly bandwidth > usage after values are entered. (If we ever get bandwidth scheduling > that's able to take a monthly bandwidth limit into account this would > no longer make sense.) Yes, that's sensible. > * Omit the list of common Internet connection speeds for the reasons > mentioned above. You omit it in the design you just proposed, don't you? I don't follow. > > >> For both of these possible error conditions are limits that are > >> too low. > >> > >> |----------------------------------------| | O I do not want to > >> set a passphrase. | | O I want Freenet to require an encryp- | > >> | tion passphrase when it starts. >> | | O I want Freenet to > >> lose encryption | | keys when closed. >> | > >> |----------------------------------------| > > > > This is jargon. > > > > I will repeat myself, since it's important: > > > > SHORTER IS NOT NECESSARILY EASIER TO USE. NOT EVERYONE WHO > > INSTALLS FREENET IS A DEEP GEEK. > >> > >> The first sets "low" physical security, keeping "none" a custom > >> setting. Matthew pointed out that even if someone is using > >> full-disk encryption, it's still advisable to have Freenet use > >> some on-disk encryption to secure temporary files, so there's no > >> need to ask about it. > > > > In which case there is little point in asking about any of this. > > Just set it to LOW. Just like we do now! Have you gone through the > > wizard recently? LOW overall security doesn't ask about this, and > > is actually quite concise. HIGH does, on the principle that anyone > > paranoid enough to use pure darknet might care. > > That's a good point. I wasn't thinking enough - the existing setup > does provide a good distribution of questions and defaults. I also > didn't mean to use jargon - thanks for catching that. > > For reference, the current setup: > > After the initial paragraph describing low, high, and custom levels: > > For low security: > * Datastore size (Dropdown of some values. Could this be a text field?) It could. Is it a good idea? Certainly we will want to show a default. Fortunately there is always a sane default. > * "Does your internet connection have a monthly data limit?" > * If yes, given a list of limits in GB, one of which is the minimum > Freenet can work with, and another a numerical blank for "GB". > * If no, given a list of common Internet connection types and > speeds, the last entry being text fields. (These assume bytes/s > unless a unit is included, which is undesirable.) > > For high security: > * Required to check a box saying "I trust at least one person already > using Freenet, and I will add them through the Add a Friend page." > before continuing. > * Choose physical security level: > * Encouraged to use full-disk encryption like TrueCrypt. > * None / low / high (with password; no confirmation blank) / maximum > * Node name > * Datastore size > * Bandwidth limits > > As this new setup will be able to dynamically change, the question > flow you mentioned near the beginning seems to me an excellent merge > with requiring someone to check the box at the beginning of high security. > > I noticed jargon when prompted for the "old password" to change from > high security: "In order to un-password the client cache etc, we need > the old password." I think "client cache" is jargon. True. Hmmm... I guess it's better to talk about "your downloads etc"? > > > Also, the whole point of "I do not want to set a passphrase" is > > "because I've got Truecrypt installed", isn't it? If we're asking > > at all we should tell the user to use full disk encryption. Sadly > > it's more complex - some encryption solutions do solve the above > > problem, some don't, depending on what level they operate at. If > > encryption only operates at the block level then the above > > complaint is probably valid. > > Irfan: Any ideas for ways to convey this recommendation? The first > thing that occurs to me is a few lines of recommendation in the top of > the physical security selection Over-complex. We should mention Truecrypt if we're asking for a password. > > > Finally, I wonder if we want to delay the choice, ask the user > > when they start downloading stuff maybe? Not sure... > > Maybe! Then again I could see some advantage to putting all the setup > questions at the start instead of having surprise questions as someone > starts trying to use it. Hmm. Dunno. Ideally we'd A/B test that. > > > More generally, if we're trying to improve the wizard, it must be > > clear what it expects of the user, not use ANY jargon, unless it > > is critical and we define it (I'm of two minds regarding darknet, > > for example), and *don't ask the user to make more decisions than > > the wizard asks now*! > > > > I think the best compromise is probably to always set LOW, but > > have a box where the user can set a passphrase if he wants to. > > These things seem reasonable to me. > > How's "(optional) Set a password: [ ] Confirm: [ ]"? Sure, if you can put it somewhere where it isn't a big deal that's fine. > > >> I think it's worth considering the Android user interface > >> writing style guidelines. [1] This would mean using second person > >> and working toward extreme conciseness (30-character limit) while > >> avoiding confusing language. > > > > I don't think this is possible. It certainly isn't possible > > without using multiple screens. > > How so? I don't follow. 30 characters may not be long enough to explain some of the things we need to ask users about. We should be as concise and clear as possible, but clarity is (slightly) more important than conciseness.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
