On Wednesday 24 February 2010 22:05:37 Janie Mehew wrote: > 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.
Okay, that's great. > > I'm fine with my work being added incrementally. Ok. > 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? The web-pushing branch on our main repository on github. The client side code is in the generator/ directory, the server side stuff is in src/freenet/clients/http/ and particularly the ajaxpush/ and updateableelements/ subdirectories. http://github.com/freenet/fred-staging/tree/web-pushing Basically we use GWT to track whether a page is still open, to push top-of-screen notifications, and (mainly) to update elements on screen. In other words we don't use any GWT widgets and basically use it as a compiler. This stuff will be merged soon to keep sashee happy and get rid of some maintenance issues, but it does have some nasty bugs so won't be enabled by default for a while. > > Thanks Thanks for all your work and input! > > 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 -------------- 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/20100226/f7a08d86/attachment.pgp>
