Am Dienstag, 3. April 2012, 18:43:51 schrieb Matthew Toseland: > From > http://127.0.0.1:8889/USK at > X1LyFuoMhnKY7KLK5-RBQ3IHtNJLAUSV~IjzRuxi6Kw,x9otzn > rH7Y8R42TzfAqDHv5Fda2ojIhqJw7iPRzimz8,AQACAAE/Volodya/28/ > > > Old friends coming back, freenet is moving > > Some friends that i've known from back in 0,5 era have been coming back. > There are also new people who are moving onto this network, so we must > think about what is the main goal for this place. I believe that the major > challenge right now does have to do with the user interface (on this i > agree with people like Ian Clarke); however, when he says that Javascript > is a requirement or that user interface means how things look like, i am in > total disagreement.
You are in good company with many other freenet users on this, I think. > So what is "user interface" if not look and feel? Well, it's simple we need > to have an interface which fits the purpose. The purpose of talking, for > example, is to be able to receive messages from other people simply and > then send messages oneself. At the same time the purpose of inserts is to > announce that insert, so there needs to be a way to simply announce that > insert to others. None of this requires changing any look and feel, it's > all about functionality. So the interface rework must start with actually > implementing the features that the interface requires. I fully agree. One relevant point might be to reduce context switches for users: Make it possible to use everything from the same UI component. It can also mean to make writing mails possible from the email reader, so the user does not have to switch the context between writing regular mails and freenet mails. And I think that what we need is not a completely different interface but rather tons of polishing: All those small things which for example Apple did right (let?s ignore the golden chains they added to that for the sake of the argument?): All the common tasks just work and are completely polished down to killing the last disturbing flickering. An interface has to be fast and it has to work without workarounds (like clicking the knobs for all uploads one-by-one to be able to delete them). And it must have progress bars wherever it does not react in under 1s. A general reaction time of less than 300ms would be preferrable. Under 30ms would be an ultimate goal (then any lagging would not be noticeable anymore: it would feel instant). Essentially it is about user-stories just working and about killing off paper- cuts: https://wiki.ubuntu.com/OneHundredPaperCuts Note that completely rewriting the UI will likely increase the number of paper-cuts! Also it?s important to make any non-essential decisions optional: Don?t force the user to decide stuff for which we can offer good defaults. Also don?t force him to decide wether to take a decision for each option (yes, I think this has to be said?). This also means to provide all essencial features by default and have single-click activation for features. The single button to activate Freetalk and WoT is a good example for that: The user wants forums, so s/he needs a button to activate Forums (and have the node guide him or her through the rest when he or she has time ? notification). We need the same for Sone. Also solving captchas has to be integrated in the notification system: If you want to To recap (also from old discussions): * Make the UI react fast. Where necessary and possible with progress bars. * Get rid of small inconveniences. * Reduce the number of clicks to do a given task. * Make non-essential decisions optional. * Reduce the number of headings. Best to 4. With images.? Best wishes, Arne ?: The reason for reducing the headings to 4 is to make them instantly graspable for humans: http://web.mit.edu/press/2011/picower-brains.html I learned that when searching to find ways to write code so it?s easier to understand: http://draketo.de/node/482 -- singing a part of the history of free software: - http://infinite-hands.draketo.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20120410/b04ccccb/attachment.pgp>
