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.

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