On Saturday 04 Aug 2012 18:21:53 irfan mir wrote: > Hello, I am Irfan? a friend of Steve Dougherty and he had asked me to further > > design his idea for Freenet's security setup. One can view his idea here: > > https://emu.freenetproject.org/pipermail/devl/2012-July/036466.html > > > > In this email I will reiterate Steve's idea and add screenshots of my design > of > > this security setup idea.
Thanks, web designers are a very rare commodity around here! > > > > > As seen here, this is what the setup will look like in the beginning: > > http://cl.ly/image/1U0I1s1z3P18 > > As you can see, there is a main container with the title "Security Setup" > which contains a list with security options. Each option has, to the left of > the text, a toggle-switch to turn it on, and a rightward pointing arrow. > On click of the right-ward pointing arrow, a description of that option > will appear, but more on that later. > > > > This is what the setup will look like when an arrow is clicked: > > http://cl.ly/image/2d1x3r3V0a27 > > As you can see, when an arrow next to an option is clicked, it > turns downward as a pane, that contains a description, slides down > from underneath the option's label. Clicking the arrow again causes > the description to slide up and the arrow to turn rightward again > (as seen in the first screenshot). One thing I am concerned about here: The physical metaphor (switches) should not get in the way of the user doing what they want to do. I.e. however pretty it is it should be OBVIOUS what to do. > > > > Here is what the setup will look like when a toggle switch is clicked. > > http://cl.ly/image/111i2b0X3b3M Have the other options gone away? The user may see the configs and the explanation and decide they want to use a different security level. So either we want to show the other options at the same time, or make it obvious how to get back to them ("Cancel" maybe?) > > Now, the html behind the toggle-switches will be radio-buttons. This > way only one toggle-switch can be turned on / one security option can > be turned on at a time. Which is not obvious from the slider/switches. But I don't think it matters much. > When a toggle-switch is clicked / radio-button is selected, if not already > expanded the description of that security option slides down and > the arrow turns downward. This is good because is allows the > interface to demonstrate the functionality of the arrows when clicked > in addition to a mouseover providing hints. Right. The user clicks on the security setting, and then they can see the explanation and the options for that setting. If they don't like that setting they can change to another setting. If they are happy with it they fill in the config options and then click Done, or something like that. > Secondly, the other security options fade-out of the way. They can > and will return when the toggle-switch is clicked again or turned off. Okay ... is this sufficiently obvious? I don't know. Maybe you should test it on somebody. :) I'm just a bit concerned that it could be pretty but not obvious what the next step is, especially in the common case of clicking the wrong security setting and then having to change it; if they then can't change it, they may conclude the only option is to go with it, and then we get people running darknet who should be running opennet and uninstalling ... this costs us users. The easy solution is a Cancel button. The other possible solution is that the other options remain visible so you can just click on them. But I'm sure there are other possibilities. > Thirdly, another pane slides out from underneath the options. This > contains the necessary settings for that option and a submit-button > at the bottom. Each setting has an input to the right of the setting's > label / name. To the left of the label / name is an arrow which provides > an explanation / a description for that setting like the arrows of each > security option did when clicked. Again we are risking conciseness beating usability. One possibility is: - A detailed explanation of the setting is shown for the selected setting box. - When the user moves on to the next option, it goes away, and the explanation for the next option becomes visible. Even with this there is a risk that the user will see an option, not understand it, and so not click on it and not see the explanation... It seems that tidiness and explaining everything adequately are in conflict? But maybe we don't need explanations now that we've got rid of most of the hard questions, and most of the settings have sane defaults? E.g.: How much disk space should Freenet to use? [ drop down list ] Do you have a monthly data transfer limit? [ No ] How much bandwidth should Freenet use? [ 64KB/sec download, 16KB/sec upload - half your detected bandwidth ] > The done button would complete the setup. > > Javascript and jQuery are already going to be implemented to style the > radio-buttons (toggle-switches) on clicked, as there isn't a well > supported way to do this in css, and preform the sliding and fading > effects. Right, that's good. > We can also use JS and HTML5 to do useful things like keeping > the form valid but turning valid values green and in-valid one's red. > Its actually a better UX (User-Experience) to keep valid values the > way they are and turning in-valid ones red. Yes, validation is good. > > Although challenging, this seems like something I would be willing to > develop as well. However, before I begin doing so, I would like to know > the answer to 2 questions. > > Would the freenet-devs prefer there to be support for when scripts / > javascript is disabled or turned off? Yes, definitely. > An idea to handling this is directing the user to the current setup if > so. Yes. Or just show all of the settings in noscript. > > And secondly, to what IE would the freenet-devs want this to be > supported? > Meaning should something as low as IE6 support it > or is 9 and above fine. In my opinion, it would be easiest and > best if we build the setup to be supported in IE9 and above and > other modern-browsers (Chrome, Safari, Firefox, and Opera). > And then later-on make additions for support in IE8 and below > when possible. I agree with Ian. We don't need to worry about old versions of Internet Explorer. Mainly because we don't really support them anyway, because of an obscure bug related to MIME types. > > Thoughts? > > I appreciate and welcome any and all feedback. > > Thanks in Advance & Best Regards, > Irfan. Many thanks, my comments are intended to be helpful rather than critical! It would be great if we could have a better first time wizard ... some javascript and a little bit of graphics would help a lot! -------------- 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/20120806/191e276d/attachment.pgp>
