On Wednesday 22 July 2009 16:03:38 Cl?ment wrote: > Le mercredi 22 juillet 2009 16:45:43, brendan at artvote.com a ?crit : > [...] > > > (As far as information design and the presentation of the content on the > > > pages, see the comments below on structure and content. It makes sense > > > to address the larger questions prior to focusing the presentation of > > > page-level content.) > > > > > > That's pretty much my first blush on design. > > > > > > I think there are a couple quick-wins that are usability related, that > > > I've included below (1&2). > > > > > > PAGE: Home page: > > > http://amphibian.dyndns.org.nyud.net/freenet/newsite/index.html > > > > > > 1. Since you've opted to have the app installer automatically begin the > > > install after they click (instead of downloading first) Here are a few > > > preparatory steps you might want to include to prepare the suer. Make > > > the label on the button more descriptive and consider adding a few > > > bullets above the button to describe the installation process. For > > > instance: "Getting started is easy! When you install, you'll do the > > > following: > > > > > > ? Download and automatically open the installer > > > ? Set your security preference and connection speed > > > ? Explore the feature through the Getting Started Tutorial" > > > ["Install Freenet now" = button label] > > > > Hum, that's a good idea, but I can see a problem : we use javascript to > > detect the OS, and display only the right button. But, if javascript is > > turned off, or the browser doesn't send the name of the OS it's running on, > > we show all three buttons. > > So, if we add the little paragraph above, with no js, it will looks like > > this > > > > [Win button] > > [Paragraph above] > > [MacOS button] > > [Linux/unix button] > > > > And I'm not sure it would be clear for the user. > > > > <-- > > Can we auto-detect their platform and just serve them the appropriate > > button (and content) for that platform? (we can include a link to a > > separate download page where they can download for other platforms - "Click > > here to download the app for other operating systems"). I think the main > > idea is to make it as simple as possible for them to download it for their > > platform off the homepage AND to let them know what will happen whne they > > initiate the download/install process. How does that sound? > > -Brendan > > --> > > > In fact, we do detect their platform, but we use javascript. So there are two > issues here : > the user disabled the javascript (we should use server-side identification, > ian's right),
I disagree, php or java reduces performance and increases costs, for all hosting options. If the user turned javascript off then they can expect it to be ugly, we should make it minimally work in that case but we don't need it to be perfect. > the user doesn't send the information we need. > In both case, right now, we show all the buttons. > The problem is that javawebstart is not used for windows, and if we show all > the buttons, we need to show the little description above. But if we do that, > it might be very confusing for windows users. The problem is JWS has to be used on Mac, but it's also the best option for Linux - but only if it works. On Windows we have to show the exe, on mac we have to show the JWS, but on linux either javascript shows that JWS works, and we show the JWS button, and it works, or javascript says it works and then it doesn't and the user needs to click on a button to show more details, or it's not detected and we have to show the more details anyway. The more details being open a command line and type two lines... > So, if we use server side identification, we reduce this to one case. But we > have to think of it, don't we ? We will still need javascript for it to work smoothly. But if javascript is turned off, we can just display all of them - it doesn't have to look good. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090725/c7427b9f/attachment.pgp>