Now that I’m a developer through and through, and see things from a more code-centric viewpoint, I notice that although a lot of designers are trained in the tools they use, and are generally very good at design, many of them aren’t any better trained or experienced at UI design than a visually-oriented developer. So there’s a misconception out there that a) all designers made good good UI design, and b) all developers make bad UI design. I’ve see absolutely horrid UI design by very experienced people on both sides of the fence.

As a developer I might not be shy at tackling a UI design, but I’m very clear that I’m just guessing. If an enterprise level app were dependant on my UI design, I would definitely get an UI/Interaction designer on the case. Unfortunately this kind of approach seems to be lacking in both RIA designers and developers alike. And most of it, I think, is simply because traditionally, it has been left up to the “creative person” on the Flash project team to do any of the visual stuff, or to the “deseloper” to manage both UI design and development. For small to medium-scale projects this generalist approach works well; but when you get into large scale projects with dozens of people on a team, specialists will need to be brought in, if for no other reason than to guide certain aspects of the architecture, whether it be visual or data-oriented.

And really, so what if Thermo produces code that needs to be tweaked a little to integrate within a larger project framework? It’s not like we’re talking about designing an HTML site in Word or Front Page or anything: Adobe is well aware of this concern, and is addressing it. And would that not give more work for the developers to do, not less? Developers who feel threatened by Thermo need to get a clue. And clients (or designers) who expect to develop full-blown data-enabled applications in Thermo without a developer are also out to lunch. Tools don’t make good RIAs, no matter how sci-fi they get. Only a good team can do that.

But Thermo might, just might, enable the fledgling “one person web shop” to pump out a few decent applications for acme co., or a enterprise RIA project development team to shave the time required to skin and visually design a Flex/AIR app.

I guess the point I’m making is that neither the “designer” nor the “developer,” or even the architect or the interaction designer, should be in charge of the UI design to the exclusion of other people’s input, even though most large teams have a hierarchical structure. It’s got to be a team effort; the moment you start posturing and “excluding” specialities as this piece demonstrates, your project is doomed to failure.

This is such an obvious axiom of RIA development, I wonder if the entire piece was intended as satire, to illuminate just how ridiculous the designer/developer divide really is.

VB5 and VB6 days, where you would have a “Forms” developer that would take the application design from the analyist and work with the UI up to the point of raising events.

The “back end guy” would take it from there, all the way back to the database.

what’s the main beef? generated code (= fat file size), which for something delivered in a browser is a fair cop (you couldn’t say that VB forms were “thin”)

What else? fear of losing control/ground. Fear of designers dictating what the application is and how it works, just because they created the UI.

If the “UI guy” also designed the app (instead of the analyist), it would be a covoluted mess. If the back-end guy also did the UI, it was almost unusable.

personally, I’m quite happy to get the “UI guy” to do his stuff… provided I design the application first…

this “battle” has only just started, methinks…