Re: Current thinking on Best GUI development platforms
Justin Ryan <[email protected]>
| Newsgroups | gmane.comp.web.chi-web |
|---|---|
| Message-ID | <[email protected]> |
On Dec 7, 2007 7:42 AM, Juan Lanus <[email protected]> wrote: > There is also the GWT, the Google Web Toolkit. As this one is pushed by > Google, and because it's really good, it might be the one. > > The GWT lets IT developers, Java programmers, to develop an application > using pure Java. > But hold on! Yes I know that most Java applications are horrible, but > refrain and keep reading, it's solved. > Let's not fool ourselves into confusing "solved" with "addressed" ;) What if you don't want to have any Java programmers? What if you are a smarter programmer than most Java programmers? GWT is a neat way of injecting google-supported ajax into the heart of your app, but by no means does it solve all your problems, or even necessarily encourage best practices. > The Java developers are not supposed to design nothing, just code an already > designed interaction in the form of flow of screens. > After the application works the graphics designers can apply format to the > resulting screens by means of CSS. In fact, they have to write pure HTML > pages and set placeholders for the input forms and data output structures. > It's curious to me that people *hate* this approach of developing for Plone, but somehow will love it with GWT. > The GWT developers code and test in Java. This is an advantage because Java > is a well known, scalable, standarized, freely available, widely accepted > language. And there are Java developers averywhere, now and in the future. > Albeit GWT easily integrates with backends written in PHP or any other > language. > I really don't like when people who are clearly not programmers say that something is "easy", or purport to really know what defines a good choice of software platform. In short: don't tie the front-end to the back-end. If you don't know what's best to use, make decisions that won't impose limitations on people solving software problems. There's a Good Reason(tm) we don't call them "CompuServe Pages". ;) Remember that a very usable tool that doesn't perform any useful function, doesn't perform it properly, or doesn't change efficiently, is pretty much as worthless as a useful tool that is cryptic to use. > The developers are required to separate the client part of the code from the > server part, in different "packages." > The server part is the server part. The client part, instead, gets a special > handling. > In the design of the interaction one can include that desktop-like features > like for instance making the rest of the form react and adapt to the values > of the data already entered by the user. There are many tools for doing this, KSS is also a good one which doesn't tie you to any software platform, or even javascript library. > The simplest example would be an intelligent "state" entry control filled on > the fly according to the country (USA, Canada, Argentina, Brazil or disabled > if the country is not divided in states.) > > Thus, one designs as if it were a desktop application and the developers > implement such interaction in Java. Enter GWT: the client part (remember it > is in a special package) is translated to JavaScript and sent to the browser > as AJAX applications do, because the outcome is an AJAX application. > Also beware of systems where, instead of, as with Flash, letting Adobe be the artist, you let your software engineers be the usability artist, and then come back in a year and ask why they didn't exhaustively write ui functionality into every aspect of the application. Bootstrap your demands in! KSS is designed so that you can hand a working UI demo to your programmers and ask them to make it save to a database. ;) > GWT produces HTML and JavaScript files, the JS implements the desired input > forms and data outputs in the HTML pages where directed to by the > placeholders. > I thought, actually, that one advantage of GWT was its' use of XSLT.. > One nice feature of GWT is its multibrowser support. The system builds many > js biles, one for each browser type (one specifies the list of supported > browsers) and a sniffer in the pages downloads the single file that fits the > detected user agent. > > GWT is free and open source. It can be reached It´s featured in .. not to be confused with Free(tm) and Open-Source - GWT is "free beer" and also "open source". Most of you will never care about this, sadly.. > http://gwt.google.com or http://code.google.com/webtoolkit/ and the site is > horrible, too geeky, suited for techies not for humans. > > Anyway, the product has it all to be a winner. My contacts tell me that > Google is fostering the usage of this tool internally. This means that an > important part of the web will run on GWT soon. > Actually, GWT is mostly based on GMail, I think, and then was used to Google-ify Writely and to launch new services. Speaking as an individual who also prototyped some ajax interfaces with no external guidance or php|architect articles, around the same time as the GMail folks, they have made some interesting strides, but also suffer from many mistakes that I left behind long ago. Sometimes I am nostalgic for this old project that I worked on, but it *clearly* benefitted me to leave the organizational bubble that I first conceived these ideas in.. > The designers book on GWT is still to be written, a book less centered in > the technological aspects and more on the interaction design possibilities, > for designers that understand the HTML "click and refresh" interaction model > but have no experience in building desktop applications. > I would really like to see a book by someone in the CHI community talking about general web interaction patterns, where there is overlap from highly publicized tools like GWT and other projects, and where people may *actually* -- believe it or not -- be innovating from outside the Googleplex. ;) I know, they say my wild ideas will get me in trouble one day.. > As Frank said, this tool is not going to make hight usability applications > by itself but IMO it lowered the threshold for real AJAX as in Gmail and the > like, for talented designers & developers teams. GWT is interesting, but I think it's a much weaker separation of concerns than some other solutions. I like systems which just try to keep concerns separate in a general fashion, rather than trying to define some "roles" that people will fit into, e.g. "programmer" and "designer". I am a programmer, but I do not really think I want to generate JavaScript out of Java. I would write Java, or, actually Python, and then I would write JavaScript. For a designer to wire some JavaScript into a CSS-designed page, I would really say to take a look at KSS, which can let you pick and choose from all sort of existing javascript toolkits and assign event handlers and behavioural modifiers declaratively, using CSS selectors. I am not one of the authors of KSS, and in fact can't even rattle off KSS yet myself, but I've been following it for a long time, know a lot about the sort of problems it's trying to solve, and have seriously weighed its' value against a full re-implementation of GWT in Python, which I just don't think i would enjoy using, and which I have already written something similar to in the pre-ajax world - something I'd be very embarrassed to let you see. Cheers! J -- Justin Alan Ryan Interaction Architect, VonGogo Foundation Volunteer, ASA SF http://www.bitmonk.net/ * : +1-415-226-1199 -------------------------------------------------------------- Tip of the Day: Use the archives to research common questions CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[email protected] MODERATORS: mailto:[email protected] SUBSCRIPTION CHANGES & FAQ: www.sigchi.org/web/faq.html --------------------------------------------------------------