On Sunday 11 October 2009 21:39:48 Juiceman wrote: > On Sun, Oct 11, 2009 at 3:33 AM, Clément <cvol...@gmail.com> wrote: > > On Saturday 10 October 2009 23:53:52 Matthew Toseland wrote: > >> On Thursday 08 October 2009 00:49:11 Clément wrote: > >> > Hello, I felt bored tonight, so I wrote this. > >> > > >> > This is just a beginning, but in order to have a good UI, we need to > >> > adress those questions with all the attention they deserve. In > >> > particular, the raison d'etre (why a new UI?) and the model of the > >> > user (what is our target audience?). > >> > >> This is logical. > >> > >> > FREENET UI > >> > > >> > => Raison d'etre: > >> > > >> > "To allow the user to access all (or the more of) the services > >> > provided by a Freenet node. > >> > >> Or the functionality that they will commonly want to use, with the rest > >> being provided by third party tools etc? > > > > Sure > > > >> > Current limitations: > >> > - A lot of users complain about Freenet being complicated to use > >> > >> Freenet is complicated, period. Many important things about Freenet are > >> hard to safely simplify. :( > > > > Well, we should find out which things are hard to simplify : are they > > essential to use Freenet ? > > I started coding a "help" servlet for Freenet, accessible if you go to > http://127.0.0.1:8888/help > but became discouraged when I had to start worrying about licensing > issues with copy pasting text from the various Freenet wikis. My > original idea was to use the l10n language files to contain the > information and allow translation, but it is an ugly kludge and would > only allow translation of English to other languages keeping the exact > same formatting and wouldn't allow other languages to be expanded > beyond without editing the code of Freenet itself and not just a text > file. > > It was my desire that the information be accessible even if a node > couldn't connect or was in a secluded darknet that couldn't reach a > Freesite in the main network. > It's clearly the way to go. The thing is, I'm not sure we should document Freenet right now if we plan to change the UI. Btw, as Evan said in another thread, we should also think of all new terms we use in the UI, and ask ourselves if they're self explanatory or if there is a better term for that (dunno who did this, but I think someone already proposed that for some things). If we manage to reduce the number of complex terms, we also reduce the size of the help.
So, first thing first : do we agree that the UI need reworking (I'm not saying we should start over of course, but it may involve a lot of work). If so, we should ask the users what they don't like about the current one (after all, if almost all users are ok with it, why change it....), and for that we should find a way to do that : if we ask only on user on fms, it will be biased, because it needs some technical skills to have it up and running. Maybe the best thing would be to have a poll displayed on Freenet startup for a given version (or more, dunno...). It won't be anonymous (not in the freenet way I mean) since it would require a spam protection we don't have atm. So, what I propose is that we ask the user if he is okay helping us improving Freenet, if yes, we display the poll. As an option, but I don't see why now, we could also grad usage statistics, with the agreement of the user of course. But that's out of the scope for now. So, basically, as any other software who do that, we upload the results on the freenet server, with no identification of course. Would that be ok ? If so, we just need to know what question we will ask. First we need to determine how often they use the software, why they use it mostly, if they're fine about the current ui, if they have the feeling that freenet is too complex, and also an open question like "what would you do to improve freenet usability". I never did that before, so I don't really know what else to ask, but I'm sure that with some time and some help, we'll find more ;) > A better way I now believe would be to ship html files as part of the > node, with the node loading the local pages like it was a Freesite, > only I don't know how to code that. It also doesn't answer my > licensing questions. > > >> > - Some menus/sub-menus contain too many elements, when other contain > >> > too few > >> > >> True, but please consider simple mode, new users will not use advanced > >> mode... > > > > We may want to focus on simple mode at a start, but I think we shouldn't > > work on advanced mode just because it's for advanced users and they can > > deal with it. It should be comfortable to use for both. > > > >> > - Some informations presented to the user are complicated, and make > >> > him ask a lot of questions > >> > >> If you have any ideas on this, I'd be interested, but in a lot of cases > >> it is unavoidable... > > > > I don't have any ideas yet. That's just a remark. But I think that is an > > important point we should keep in mind. > > > >> > - Some informations presented to the user are related to the node's > >> > internal logic > >> > >> True, should be avoided in simple mode in general. > >> > >> > - Feel free to complete > >> > > >> > Success criterion (measurables): > >> > - Users complain far less about Freenet being complicated (Freenet > >> > loses its image of a complicated software) > >> > >> Not possible, but some progress can surely be made. > > > > If you start with "not possible", we won't go far :p Apart from that, as > > I said above, we should find what users find complicated right now, to > > simplify things as much as we can. > > > >> > - Users are capable to accomplish all the action they want in a small > >> > time (we can ask a user to do some action an measure the time it takes > >> > for that (both in old and new UI), ...) > >> > - Feel free to complete" > >> > > >> > > >> > => Model of the user: > >> > > >> > General knowledge: > >> > The user can read/write his own language and perhaps english. He knows > >> > how to use a computer. > >> > > >> > Knowledge in the application domain: > >> > Weak: the user only knows the basics : some general vocabulary, no > >> > technical detail. Do not know any specific terms. > >> > > >> > Computer skills: > >> > Basic +: the user knows how to use a computer and may have already > >> > used some P2P softwares before. Mostly run windows and is used to > >> > basic actions. > >> > >> Seems reasonable. > >> > >> > Feel free to complete > >> > > >> > => Activity modeling: > >> > > >> > Here we need to do some polls, ask people on irc, if possible watch > >> > them using freenet. We could also refer to the state of the art: we're > >> > not the only p2p application, and even > >> > though freenet is different, I'm sure we could reuse some things. > >> > > >> > SO, we need questions to ask in order to know what peoples do on > >> > freenet, and how they do it. If we can get some scenario from existing > >> > users (in our target audience), > >> > it would be also great. > >> > >> So we need more usability testing, we need to look at the UI of other > >> apps, and we need to find out how people actually use Freenet? > > > > Yep. The most important part (according to my (basic) course) is to have > > people telling us how they work know with freenet, i.e. make them write > > scenarii. A poll is surely a good thing too, since we may have a larger > > audience. I'll try to write down some questions if we agree on the basics > > here. > > > >> > I stop here for now, since this point also depends on the two previous > >> > ones. > >> > > >> > If you have any question, please ask :) > >> > > >> > Regards, > >> > > >> > Dieppe > >> > > >> > P.S. : I have to say that it's been a while since I didn't go to the > >> > channel or saw message on frost (I'm waiting for Freetalk for that > >> > ;)), so I may have a truncated view. > > > > _______________________________________________ > > Devl mailing list > > Devl@freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > _______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
