Thermo a Threat to Developers
Actually it isn’t. But some people think it is. I’ve heard the argument a few times, mostly by developers who have a chip on their shoulder about designers, as demonstrated by this fictionalized conversation with a developer about Thermo. (I gather the names have been changed to protect the guilty ;) )
Normally I don’t bother commenting on fictionalized arguments, it reeks a little too much of he-said she-said flamewars one sees so often. But I’ve heard this argument before, and not just about Thermo threatening the livelihood (read: dominance of) developers over designers, so I felt compelled to add my 2c.
Personally I think the whole argument of whether UI is the exclusive domain of either the designer or the developer, is a waste of time. I used to be a designer, trained in design, went to art school, yada yada. Back in ‘97 no one doing web apps knew anything about UI design on the web. We were all doing it by the seat of our pants. How did most of us learn UI design? By observing what works, what we personally find usable, as well as reading about emerging standards, and emulating that.
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 trained in design, I am not shy at tackling a UI design, and do a pretty competent job at it most of the time, but I’m very clear that I’m not an expert in Interaction Design. 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 Flash projects this generalist approach works well; but when you get into large scale Flex 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.
on December 17th, 2007 at 9:19 pm
Joe, I couldn’t agree with you more.
You sound as if you have been listening to my recent conversations with some clients educating them on the pitfalls of hiring either a Designer or Junior Level Flex Developer and expecting Senior Level results.
I have been working in Flex for the past 3 yrs or so, at all levels.
I have migrated to working primarily with Architecture, Framework, and training Flash as well as Junior Flex developers and designers who wish to make the change to developing in Flex.
Awhile back I fought the good fight, Flash Designers vs. Flash Developers.
Now of course in Flash usually the two were quite a bit different and most of the great people I worked with knew their limitations.
Over this year I have watched the demand for Flex Developers quadruple.
This of course will bring out the people new to Flex.
As well as the people who think that Flex is Flash and the Designers that although very talented in their own right are not coders.
That being said, I think after watching the presentation on Thermo, I am VERY excited about the prospect of its potential.
Now of course there will be clients who “pinch a few pennies” and hire a “non-coder” type person who can design in Thermo and then just “presto” you have a Flex application.
But in my opinion that will as always be a mistake, and in the long run the company will end of having to call on a full Flex Developer to fix the issues and get them back on track for deadline at twice the cost.
It’s not worth the risk.
But as you said, Thermo will only do so much then the coders will have to take over.
Even at the end of the presentation on Thermo at MAX, the statement is “so-in-so would then hand off the application to me to add functionality to it” (not of course a direct quote but you get the idea).
From my perspective, my design skills are intermediate at best, certainly not to the level of some of the FANTASTIC and creative designers I have worked with in the past.
So the ability to cut down on SEVERAL hours of skinning, styling, and creating custom components that I could just take a PSD, drop it into Thermo and “WA-LA” there you go a great looking Flex UI (shell that is) that looks just like the clients specs.
This would cut down on time for UI manipulation and allow me to focus on the Architecture and over all Development Design that is where my focus should be for my client.
I think Thermo is going to be a great addition to the growing number of tools at a Flex Developers disposal.
As usual, a great product requires several great people collaborating on what is best for the client.
Thanks for listening,
Kenny
on December 17th, 2007 at 11:49 pm
I think you have a few good points there Kenny. One misconception which I am pleased to see is dissipating somewhat, but I still hear once and a while, is that a designer can write good code if they have a good tool, and also that a coder can make a good designer, “because it’s all intuition anyways.”
Designers don’t always make good coders no matter how fancy the tools, and coders don’t necessarily make good designers, no matter how easy it is to splice up a few proofs in photoshop, and soon in Thermo.
I used to be a designer, so I know how easy it is for some deselopers-turned-coders to take design for granted. Then one day several years ago before the term “Flash developer” existed (there was only ‘Flash designer” back then), I did a print job for a client after not having touched print or graphic design in a while, thinking that because I used to be a designer that my designs would always be good. I was wrong. It sucked, really bad (and so I hired a real designer for the job I thought I could do ;). That was a very humbling experience for me.
That’s not to say that I suck at design, but I am now aware of my limitations. I became a coder simply because that’s where my passions took me. If I had kept up my skills, kept up with the tools, kept working at my craft, I’d still be a designer. The point I’m making is this: the person who underestimates their skill level or area of expertise, and thinks that a tool alone can compensate, will fall on their face. And a professional, be it designer or coder, doesn’t blame their tools, only their assumptions.
That’s not say that falling on one’s face is not useful every once and a while. But I try as much as possible to do all my falling down on my own time, when I’m learning something totally outside my comfort zone, not on a client project where reputations can be made or broken on the success of my code. And I never blame my tools.
So some people really need to stop bitching about Thermo and get excited about what it can do for them. This is a very fast paced industry, and either that change excites you, inspires you, propels you to excel, or you’re in the wrong line of work, bub. That’s what I say to the whiners out there.
So to them I say: don’t be a whiner. Get inspired, and figure out how that works for you. And Thermo sure as heck has me be inspired.