Joeflash’s Enigmacopaedia


More Reasons to Use Flex

Posted in Business, Flex, RIA by Joeflash on the January 7th, 2008

Following my post the other day on reasons to use Flex for RIA development, I stumbled upon an excellent post by InfoQ regarding Top 10 Adobe Flex Misconceptions, as well as an excellent blog comment regarding why to use Flex (as opposed to certain supposed \*ahem\* competitors).

Why Flex for RIAs?

Posted in Business, Flex, RIA by Joeflash on the January 4th, 2008

A colleague of mine recently emailed me asking if I knew of what amounts to an authorative Flex adoption whitepaper for RIA development for a client of his. My reply to him was:

They can check out the Adobe Flex Product Page, but I guess one authoritative text could be this O’Reilly booklet by Effective UI, even though it is a little dated: Flex Early Evaluation: Assessing Flex and Your Project Needs, which the benefits of RIA development in Flex in a formal, documented fashion.

You can also refer them to this tongue-in-cheek expose of Top 10 Myths about Adobe Flex 2.0 by Adobe’s Ted Patrick, and this video overview of the technology by James Ward entitled Flex, Flash and Apollo for Rich Internet Applications. If you want a great examination of real-world capabilities, check out James Ward’s Ajax and Flex Data Loading Benchmark application, which tests data transfer benchmarks for a variety of technologies.

Proof of Flex’s rising ubiquity can be had by going no further than Google Trends, or a recent news announcement that NATO now used Flex in its information delivery systems, or that Adobe has just been inducted into the Intelligent Enterprise 2008 Editors’ Choice Awards, as one of “the 12 companies that will matter the most to the intelligent enterprise in 2008.”

What more evidence do you need?

:)

Thermo a Threat to Developers

Posted in Usability, Flex, RIA, Workflow, Thermo by Joeflash on the December 4th, 2007

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.