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
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:[log in to unmask]
MODERATORS: mailto:[log in to unmask]
SUBSCRIPTION CHANGES & FAQ: www.sigchi.org/web/faq.html
--------------------------------------------------------------
|
