On Saturday 16 Mar 2013 05:56:12 Steve Dougherty wrote: > On 03/12/2013 04:08 PM, Matthew Toseland wrote: > > On Tuesday 12 Mar 2013 19:42:28 irfan mir wrote: > [snip] > >> So, I am confused on which implementation Freenet is looking for: > >> 1.) Questions that result in options or 2.) Questions that > >> result in only one-option that is automatically chosen. But then > >> the user has to entre their security preferences in the form that > >> appears. > >> > >> Please let me know, which option is most popular. Personally and > >> with my experience, I think the first option is better. That is, > >> because I can see the user being confused when they see the > >> security option chosen without them having chosen it. But, it is > >> the rest of the dev team's call. > > This proposal is neither 1) nor 2). Matthew and I discussed things in > #freenet. He approves of a new first run setup which consists of a > single page with small number of questions about the user's security > concerns to determine their settings. [0] It is separate from and does > not add to or replace parts of the existing one. (The existing one > could be a fallback if there is no Javascript.) > > >> Also, what questions and how many questions are to be asked. I > >> think we should keep it under 5 if possible. > > The current draft (below) has 2 checkboxes and 5 radio buttons. > > > Yes. That's why we don't want to have NORMAL vs LOW or HIGH vs > > MAXIMUM. It's an extra question that most users don't need to > > worry about. The current code just does LOW or HIGH (with some > > extra options). Users with particular needs should use the old, > > more detailed wizard (custom settings button). > > Good call. This is reflected in the elaboration below. > > > Probably we should warn users about opennet at some point. We > > probably do that already? > > Explicitly? Sure. Any ideas where? It's already called connecting with > "untrusted strangers," which is a warning of some kind. Is a warning > in the elaboration of that question enough? > > To expand on that, I summon ASCII art: > > ------------------- > | _Freenet Setup_ | > |-----------------| > |Detailed settings| > |-----------------| > > "Freenet Setup" is a larger title. "Detailed settings" is smaller and > a link to the current "custom" setup. (Or a re-imagined AJAXy equivalent.) > > The ">>" after most options expands to further explanation about the > question. > > |----------------------------------------| > |[ ] I know someone who runs Freenet. >> | > |[ ] I am willing to connect with | > | untrusted strangers. >> | > |----------------------------------------| > > The first question, when checked, gives an option to add someone's > darknet node reference, and if we ever get invite bundles this should > probably do something encouraging like already be checked and list the > friend who generated the invite. > > The second question sets network security to normal if checked. If "I > know someone who runs Freenet" is checked and "I am willing to connect > with untrusted strangers" is not, network security is set to high. > > If neither one is checked they have no one to connect to and cannot > complete the first run setup. How is this best represented - having > the second question checked by default?
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 ] 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. > > |----------------------------------------| > | O I have a bandwidth cap. >> | "bandwidth cap" is jargon, isn't it? "I have a monthly bandwidth limit" ? > | O I want Freenet to use up to [ ] KiB/s| > | download and [ ] KiB/s upload. | > |----------------------------------------| > > In the case of a bandwidth cap, it one possibility is for "[ ] GiB > per month" to slide out from under it. Would it make more sense to > have the option itself be "I have a bandwidth cap of [ ] GiB per > month."? I'm specifying units outside of the blank with the > understanding that asking someone to specify units is annoying and a > source of common errors. 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. 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... > > 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. > > 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. 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. Finally, I wonder if we want to delay the choice, ask the user when they start downloading stuff maybe? Not sure... 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. > > The second sets "high" physical security and prompts (slide from > underneath?) for a passphrase (and confirmation of course). > > The third sets "maximum" physical security. > > 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. > > My attempt at following these: > "Connect with a friend" > "Connect with untrusted strangers" > "Limit monthly bandwidth to [ ] GiB" > "Use [ ] KiB/s download and [ ] KiB/s upload" > "Set a passphrase: [ ] Confirm: [ ]" > "Lose encryption keys when closed" > > Perhaps this is better-suited for mobile devices? It seems like it > might be easier to understand.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
