Rich clients are more than just about user interfaces, argues Adobe's James Ward in this JavaOne 2008 interview with Artima:

http://www.artima.com/lejava/articles/javaone_2008_james_ward.html

What do you think of the current state of developers working with designers when building Web applications? Do you agree that rich-client technologies, such as Flex, make that collaboration easier?

I think rich-clients - using Flex or whatever, have their place in a certain class of applications. Usually for 'enterprise' type UIs which perhaps need a richer set of UI controls than the typical web app.

I don't think rich clients are the best option for your 'consumer' or 'social-network' type webapps. For e.g., can you do mashups with a Flash/Flex generated site? Or display on a mobile device?

btw, 1000 engineers working for 5 years to develop an Ajax app - surely that's a typo in the article?!

-jb

it's always good to have designers and programmers in co-op (games are good example). some tools, like adobe's tools (notice that i left out the technology part) should make it easier, otherwise i'd not call them tools :)
what can adobe, or any other company offer to make the co-op better while working on rich client (not on ria)? isn't all about people communication? you can have hundreds of tools and technologies, but if people won't speak to each other, the tools (and techs) will not do the work alone.

Well, once again, folks who either weren't there or haven't read the history.

What Rich Client is/should be about is re-creating the world of VT-220s connected to *nix databases, circa 1990; albeit now with pretty pixels instead of characters.

It is specifically not about client-server; which was created to solve a very different problem: how to distribute processing (and NOT data) to this (then) new fangled thing called an engineering workstation. CAD/CAM systems (on *nix, of course) were an early (perhaps first) use-case. Previously, CAD/CAM was done on dumb graphics terminals connected to 370s.

C/S offered the opportunity to off-load *non transactional* processing of sparse data sets from the mainframe to engineering workstation (client). This allowed the mainframe to be a mini-computer, and thus made DEC, etc. very profitable. These systems were semantically unlike the Web of today, or any sensible Rich Client of tomorrow.

The notion that graphic rendering is "client" of client-server melieu is factually wrong. It just happens that client workstations in CAD/CAM systems in client-server did a lot of rendering; but this is not the same thing.

The current Web is exactly the same system model as the mainframe/3270 of the 1970s (with a longer, slower wire): a disconnected block mode client with downloaded edit programs for the user screen. Just pretty pixels today.

The ability to have a *connected* client (pixelated terminal now) interacting in real-time with the datastore over a much longer wire is what's being attempted. For transactional processing, it's the connectedness (and not the ability to have state) that matters. As my Pappy used to say (with regard to having transactional state on the client): just because you can do something doesn't mean you should.

Anyone who asserts that storing transactional state on clients should read up on distributed database. It will save you a lot of pain.

I steered the designer that does UI concepts for my Flex dev teams to a Visio template for mocking Flex UI.

He ended up telling me that he preferred to just use Flex Builder to mock Flex UI as it was more productive for him and gave him a more functional result to mess around with.

When I brought in professional Flex training for my dev staff last year, I also let this designer and a UI usability person take this training too. They didn't always follow all aspects of the training as when it dived into deeper programming concepts. None-the-less, it did pay off for them (and the company).

Perhaps Thermo will ease all this for designers, but the approach we're using now is not so bad.

Is Flex RIA only suitable for business application interfaces, or apps like Buzzword (a highly functional word processor)?

Often it's believed that a web RIA approach is perhaps not so optimal for content heavy web sites (the blogging and social web sites, etc).

However, there are two aspects of Flex that could be leveraged to integrate content and yield a more dynamic UI.

First is that a Flex app can be built like a portal. A Flex form can dynamically load other Flex forms in a nestable like manner. The sub forms loaded can be determined by logic that executes at runtime. The loadable modules can be built as totally standalone components. They can bind into the hosting portal environment using Flex properties, events, and declarative data binding features. So the coupling layer can be well abstracted so as to not be overly brittle.

Second, one can incorporate a popular iFrame Flex control into a Flex form, which, of course, the iFrame can be used to load HTML/JavaScript content. So highly dynamic web content can be integrated into the UI of a Flex RIA application.

Thirdly, Adobe AIR has WebKit HTML engine built-in, so an AIR app can also ready make use of HTML content in a integrated fashion.

Fourth, there are already mechanisms that can be hosted in Apache httpd and IIS that will compile Flex forms from source code on the fly. So some aspects of even the Flex RIA could be generated dynamically at runtime. Currently these mechanisms are intended for development phase purposes. The compilation is not considered fast enough for production sites. However, in time this will likely improve.

In the meantime, my preferred approach is Flex form modularization and Flex control iFrame for embedding HTML content.