CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"ACM SIGCHI WWW Human Factors (Open Discussion)" <[log in to unmask]>
Juan Lanus <[log in to unmask]>
Fri, 7 Dec 2007 14:10:48 -0800
Justin Ryan <[log in to unmask]>
Justin Ryan <[log in to unmask]>
text/plain; charset=ISO-8859-1
text/plain (170 lines)
On Dec 7, 2007 7:42 AM, Juan Lanus <[log in to unmask]> 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

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,

> or 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

> 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.



Justin Alan Ryan
Interaction Architect, VonGogo Foundation
Volunteer, ASA SF
* : +1-415-226-1199

    Tip of the Day: Use the archives to research common questions
     CHI-WEB: POSTINGS: mailto:[log in to unmask]
              MODERATORS: mailto:[log in to unmask]