On Saturday 13 February 2010 21:39:47 Ian Clarke wrote: > On Sat, Feb 13, 2010 at 11:34 AM, Matthew Toseland < > toad at amphibian.dyndns.org> wrote: > > > > They will be able to continue to work with FProxy, the new UI will be > > > designed in parallel and will only become the default when it has reached > > a > > > sufficient level of functionality. > > > > Which practically means that any work to improve the current UI is shelved > > because eventually we might have a shiny new one. This is bad, because it is > > the developers who will be maintaining the new UI in the long term. > > The alternative is that we never get a new UI, and we are stuck with the > current monstrosity for the rest of eternity.
Okay, I'll try to explain my current position as reasonably as possible. First, I agree 100% that we need a new UI, both structure and appearance, which is built from the user's end backwards and not from the internal data structures forwards. We are agreed on that. Second, at this stage, pupok is producing non-functional mockups, for instance the PDF file we've recently seen. There is much useful work to be done at this level IMHO. The first draft PDF is interesting and mostly immediately applicable: 1) It looks a lot like the minimalist theme 2) It solves the minimalist theme's achilles' heel by moving the bookmarks to a menu 3) It renames Configuration to Settings in the interests of plain english 4) It confirms the widespread demand for an in-freenet global news system 5) It introduces the status dropdown. All of these things can be implemented reasonably easily within the current framework and they will all make 0.8 more user friendly. I've had useful discussions with pupok on IRC about the front page and what to do with alerts / status information; I am hoping that a new non-functional mockup will address this in some detail, we were discussing some sort of dashboard. This is one of the biggest issues with the UI at the moment, but there are several other areas that will need to be looked at at the non-functional-mockup level. In conclusion, there is limited time and much work to do just at the non-functional-mockup level, and that work will be immensely valuable whether or not it comes with an actual implementation. Obviously having the mockup as HTML would help matters, but even that is not the most important gain here: The most important thing is thinking it out from the user's point of view and addressing the various areas where the current UI is very messy, such as status updating. *IF* pupok has time for implementation, then we get into the question of what technologies would allow us to implement the new UI most easily and most maintainably. As I see it the options are: - Change the existing HTML generating code to produce different HTML. This is probably the least work if we already have a template in HTML. It means we do not have to rewrite *everything* and thus adapts best to limited timescales. It can be completed by anyone, not just by pupok, if she runs out of time. It has the lowest overhead in third party libraries. It doesn't involve large scale direct use of Javascript. It produces plain HTML, and thus is compatible with security conscious users (and developers!), disabled users etc. And it lets us keep sashee's work on live updating, which uses GWT as a low level java-to-javascript convertor. Update in place javascript based stuff would be implemented with GWT but at a low level i.e. probably no widgets. The main downside is that the current code is regarded as messy, and a full rewrite would force us to abstract everything involved in the UI into a set of clean APIs. - Use GWT at a high level complete with widgets. This intersects with sashee's work to the degree that they both use the same library, so the impact on the download size and the build process is minimal given we want to merge sashee's work. The downside is that it does not produce plain HTML in any circumstances; no Javascript, no UI. This excludes users and developers who have an issue with javascript - paranoid users, geeks, some disabled people, etc. It also increases overheads on the server and especially the client, which may be a serious issue for many users in hostile regimes with slower systems. Given that the vast majority of the UI will look and behave like ordinary HTML anyway, this is less than optimal. Clean APIs for the UI have their downsides, most notably a significant amount of work up front and whenever they are changed, although of course there are also advantages. - Use Dojo. Combining this with sashee's work might be messy, and requires us to pull in a library at run time, as well as GWT at build time. Also, it involves a good deal of Javascript, which may make maintenance harder. The upside is that the UI can cleanly fall back to pure HTML when javascript is not available. We can use dojo's javascript based widgets. But as far as I can see, Dojo is simply a big Javascript library. Using dojo does not guarantee a clean rewrite of the backend and in fact it provides no obvious tools with which to do such a rewrite: You are expected to provide the HTML! So really Dojo is a mix-in, it has very little to do with refactoring the backend. I'd prefer to use GWT for modifying existing HTML because sashee's work is already using it and writing stuff in Java is probably easier to maintain, but I see no serious issue with pulling in Dojo to make update-in-place stuff easier, provide widgets etc. - Use some third party HTML templating engine. These tend to be large, but this may not be a problem as our download is already rather large. This would enable us to rewrite the backend in such a way that themes could change the structure of the web interface i.e. what is on what page, rather than only being able to style what the Java code says is on a particular page. I am not convinced that introducing a query layer and a specialised language for writing themes gains us very much, especially as pupok is already fluent in Java. -------------- 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/20100215/d78719f4/attachment.pgp>
