On Tuesday 09 February 2010 16:02:21 Ian Clarke wrote: > On Tue, Feb 9, 2010 at 8:22 AM, Matthew Toseland > <t...@amphibian.dyndns.org>wrote: > > > On Monday 08 February 2010 21:49:37 Ian Clarke wrote: > > > I think by "casual" we are referring to people who want to search for and > > > retrieve content, upload and share content, and participate in > > discussions. > > > We are not referring to Freenet developers and testers, who will > > probably > > > need to continue to use FProxy. > > > > I strongly object to this. We do not want to have two completely different > > interfaces with two completely different looks and feels, and with a jarring > > change when you go from one to the other. > > If the requirement is that the new UI entirely replicate the functionality > of FProxy on day one, then I can promise you - we'll never get a new UI. It > has to be a gradual process of migrating functionality.
It is not pupok who is going to be building, integrating and deploying the new UI's code. It is us, even if she does give prototype Java code. The changes can be divided up into those that affect single pages and those that affect everything: 1) Look and feel. This loosely corresponds to our existing themes, which are largely pure CSS. Basic dropdown functionality, such as the status box, can also be implemented largely in CSS, although there may be some small HTML generation changes needed. Changes to the look and feel can and should be deployed globally as a) a new theme, b) minor changes to HTML generation to support any new elements needed (or old ones removed), and c) minor changes to existing themes to deal with those new elements. An interesting point to note is that the minimalist theme uses the existing HTML (admittedly hiding most of it), and looks very similar to pupok's new front page. 2) Structure. What is on what page, etc. Changes here require HTML generation changes and refactoring of the classes that generate them. Generally these are specific to single pages, so we can simply change those pages. For example there will probably be a good deal of work on the homepage. 3) Live updating. This requires GWT. The web-pushing branch implements this for the existing interface, and can likely be adapted without too much difficulty to new forms, on a page by page basis. 4) Interactive features. Clicking a button and having it animate and then update in place. This requires GWT. This will again be implemented on a page by page basis. So far the PDF mockup only deals with the first two items, and only very briefly with the second. Which is fine, I'm glad to have some competent input here. My point is it is bound to be a gradual process, but it need not be a disruptive one which leaves Freenet's UI in a schizophrenic, internally divided, inconsistent state for months on end. It is emphatically not a whole new UI, we do not have time for a whole new UI. > > > And who decides what is casual use anyway? > > We start with the most common use-cases and support those, and then over > time we add other functionality. > > > Casual users in mainline China for example will need to be able to add > > Friends, and set the security levels. > > Yes, obviously this functionality will be a high priority. So should be blogging. But as I have explained above a two-tier interface is neither necessary nor a good idea. > > > And we cannot afford to not ask people: the first-time wizard will have to > > remain in place, and IMHO so will some visible indication of security level > > (preferably via means of easily understood color coded icons, with brief > > explanations in tooltips or dropdowns). Casual users interested in > > censorship resistant blogging (IMHO an important demographic) will need to > > be able to make a blog using FlogHelper. Anyone who uses Freetalk to chat > > will need to be able to set trust levels (although this does not necessarily > > mean we need the Community menu). And so on. > > Its a question of prioritization. We can't do everything on day one. Right, so there are two possible approaches: 1) Break Freenet, make a small part of its functionality perfect, leave the rest as ugly, unmaintained and user hostile, and sacrifice the practical usability of Freenet for a great number of the people who most need it for a larger number of much more casual users who are far less likely to stay or to contribute. 2) Improve the existing interface in a gradual manner. Change the look and feel as appropriate, rewrite the more important pages, introduce new interactivity elements. IMHO the latter is far preferable. > > > And nothing in the PDF actually requires GWT so far. > > Nothing requires GWT, it could all be done in Javascript. GWT makes > development much faster and easier though. Nothing in the PDF even requires Javascript. Updating it dynamically requires GWT, but the drop-down only requires CSS. > > > A two tier system where the advanced tier looks completely different will > > not meet diverse needs, it will segregate advanced users from everyone else > > and put people off making the transition. > > A two tier system is a temporary requirement to avoid having to replicate > all of fproxy's functionality on day one. As I said, if the new UI has to > do that, we'll never have a new UI. I do not see any good reason why we cannot migrate to a better UI in a gradual process whereby we change the look and feel globally, and then rewrite individual pages. > > > Apart from messages, there is the question of where is the rest of the > > functionality? > > As I said in my original email, these mockups are "(very) preliminary". I > don't see the blogging tool as a requirement for day one (since AFAIK its > not even currently implemented in fproxy). All of the other things you > mention will be integrated into the design in due-course. It is implemented today, and in a reasonably user friendly fashion. It will be deployed as soon as WoT is ready to be deployed, which will be long before any hypothetical ex nihilo new UI is ready. One other issue with the UI: "Network: Starting up". It might be nice to have "Downloads: Starting up", or even "Downloads: Awaiting password" as well. As I see it the main things we need help with are: - Making it look good: Building a good look and feel, and a more approachable structure if appropriate. - Dealing with notifications. - A much better Freetalk UI. I have no problem with shifting most of what is now the status line into a dropdown under "Status". Which could include links to both statistics and peers. I have no problem with bookmarks becoming a menu, although in terms of managing expectations I think we probably need to draw some attention to the default sites as search is *always* going to be slow on a new node. I do think we need a "browse" menu, or just an icon, when showing error messages, statistics etc, but perhaps we don't need to show it on the homepage: You need to be able to get back to the homepage with the search box! Clearly we need prominent access to forums. IMHO it would probably be a good idea to indicate which user you are logged in as for purposes of not only forums but every WoT-based application - but this means we don't need the Community menu. As you have already agreed we need to keep a prominent means of getting to the friends/add a friend page. Pupok's mockup already shows the configuration menu (sensibly renamed to "settings", which is shorter and more plain english). Which leaves filesharing, which arguably is misnamed, as it doesn't have a usable file search system, and which probably shouldn't show up unless we have stuff queued. You throw in some sensible means to deal with notifications, maybe with options to subscribe/unsubscribe from different types of notices, and you have something very similar to the current UI, with various useful changes which can be implemented in a gradual manner. And I have no issue whatever with using GWT where it is useful. But nothing I have seen so far can't be implemented with HTML+CSS. GWT is good for updating, and it's good for interactive twiddles (i.e. doing stuff in place rather than reloading the page). And before you say I'm a developer, I don't know anything about UI, IMHO that is the wrong attitude. Most UI is created by developers, and we need to improve our skills at it. And on the whole there are basic principles which are not so hard to grasp, such as looking at it from the user's point of view, de-junking, and so on. Dieppe posted a page about that a while back.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org http://osprey.vm.bytemark.co.uk/cgi-bin/mailman/listinfo/devl
