Hi Toad. There are a lot of questions and options in here, but Ian said there were 2 main things you wanted to know.
My plan was to keep doing mockups, and focusing mainly on the things we discussed (status, igoogle-type widgets to display different things). I haven't had a chance to do any more work lately but when I have more to share I will send it. I'm fine with my work being added incrementally. There are a lot of implementation options laid out in this email and it was a little confusing to me. I'm still not sure if I understand the way you want to use GWT as it sounds very different from the way I have used it in the past. Could you point me to where I can have a look at Sashee's code, so I can get a better idea of what you mean? Thanks Janie On Mon, Feb 15, 2010 at 9:19 AM, Matthew Toseland <toad at amphibian.dyndns.org > wrote: > 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 -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100224/82f2c8c5/attachment.html>
