-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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?
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.
> 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.
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.)
* Omit the list of common Internet connection speeds for the reasons
mentioned above.
>> 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?)
* "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.
> 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
> 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.
> 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: [ ]"?
>> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBAgAGBQJRTiB9AAoJECLJP19KqmFurokP/jSGauDMe6SvLTSWKnqoLMX1
e6qa2ziTWRnbQSSFAJ3h9DO/rvO/umNcbAAD62IUo+qTXWe73oC+2rbvZhhKGhpp
4/WKVorIFX0J+E47aNEFuSMyN0+NL3WDja0itkx4RsDkPbh2Uwqq+uE5bn0uoLTq
iOmsVC6IddIybS5dZ9+qsxTDGaxPC/3nnLhacFZrsYs6jeuu9m4FJery/hZhxV22
p6Djv9zgreHYoBloFv4nvQeDIxnWeSIUJjIVNxg4WNQwnF/9DonyctdMHzFScwcB
jteF0waSs7FQ0fprz8T+ZB4OlPj9qOE3KnpiL6WDqRPhGMm9eWXypzSSt98WSD54
W7E2gNqJ9TDmn1Yq+FMogm6rbaG/TQ/gPMzWJ3Ncn9rwwfAXfRZCnguI71k7Oo5L
E5/hO9BK2q8QEiR4vOWj826dIpDnDajQGZfcSS8zGkPuPsjJUFMRHH45P+TkQFDs
yqV5B8LG3kCyupwsCUqdrap/6IyyzLnflWSba1gnoMUjchwzQKhe6tFNR8T5MctC
HrxB1IRpvB55MjLrAYk/tG8Wreocn5lzo0zROW4nYuWsnz3ck+EDiLmLXjmkZsNK
SXBXsuJ+y0MUuc235rcARDgKZzhfI9dTrFCn7Q3DqSxSkqnQwBN/COeQ/etGP2hO
SHLZEivZDxeL65v/DPKr
=LdTe
-----END PGP SIGNATURE-----
_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
