Is It Too Early or Too Late for an Open RIA Design/Dev Toolchain?

I was playing with the Raphael JavaScript graphics library (a sort of script-based, cross-browser, implementation of SVG) and started thinking how helpful this library would be in creating a browser-based (as opposed to plug-in based) RIA.

That lasted for about 15 seconds before I remembered that creating large, non-trivial RIAs generally involves designers, and most designers don't like creating vector art by coding a set of "path" statements, or animations as a collection of key-value pairs and millisecond-based transition times.

That's why tools like Microsoft Expression, and Adobe Illustrator, Catalyst, and Flash exist.

And why Adobe and Microsoft are investing so heavily in the designer-developer workflow: the ability of designers to turn graphics and animations into app skins and interaction which are immediately available to coders.

In order for an open RIA solution to be competitive and realistic -- whether it's open in the pure-browser sense, using JS via dojo.gfx, or Rapael, etc., or whether it's via an open plug-in (Java/JavaFX seems like the closest, though it's not 100% open yet and may never be) -- this full toolchain needs to exist.

We need to be able to export vector art from mainstream design programs such that they can be incorporated as assets into the RIA. It doesn't matter if this is via SVG, XAML, AI/EPS, or something else entirely. What does matter is that the import/export is robust enough that designers -- whose jobs, after all, include making stuff look just right -- are confident that what they design is what end-users will see. The Microsoft and Adobe tools can do this. To date most OSS attempts cannot.

Next up, we need a truly usable, designer-friendly authoring tool for animations and interactions. It is often argued that some standard tools (*cough* Illustrator *cough*) are not paragons of usability themselves. No matter -- it's hard enough to get converts.

Happily, there seems to be emerging some consensus among the big vendors about how these tools should work (both on-screen and in terms of in intermediate data formats). That blueprint lowers the risk and challenge for an open source contender.

The biggest obstacle remaining is a classic open-source triangle-of-trouble:

1. The toolchain/workflow will not be viable until it is quite solid, since the commercial alternatives (Flash, mainly) are so entrenched.
2. It's hard to get enough contributor man-hours against such a huge project without an active user base.
3. Since the user base is not developers, the bootstrapping for #2 that makes many OSS projects work (devs are tolerant -- even excited -- about getting up on an 0.1 release) is unlikely.

When Corner Cases Attack

Notwithstanding the credit given to MTV's Real World, I think reality TV took off with that Fox special that featured a deer knocking a hunter on his rear. That guy just never saw it coming.

Same thing seems to happen too often when we start making architectural adjustments around a corner case in a software application.

The real problem is how to tell when an exception to the initial model -- the corner case or edge case -- is truly a strange bird, versus when it is a big piece of the model that was missed the last time through.

Sounds like something that should be easy to resolve with proper analysis, whether of the thick-stack-of-paper variety, OO variety, or an agile story-based style.

But it's not.

I've recently been doing some work on a project where this mistake was made. At some point in the past, this team looked at an odd duck, thought hard, and realized it was a big piece of their world. Big enough that the underlying infrastructure -- database, network services, etc. -- should be designed with sufficient generality that this corner case would become a mainstream case.

I understand how the analysis went, and why it made sense.

Only problem is, with 20/20 hindsight we can now see it was wrong. Bringing this edge case into the tent made the system an order of magnitude more complex, and it should have been left as an odd hack in a dozen places ... but as development happened over time, on several different module teams, the problem of the added complexity wasn't clear until it was too late.

To be a little more specific, I'll offer an analogy: you're writing a driving game or simulation. A big part of the fun is the spots where the players catch air, jumping their vehicles over obstacles to get ahead. But how to model the behavior of the cars as they fly through the air? A quick hack? or ... integrating elements of flight simulation or 3-D physics simulation?

Well, this team went the equivalent of the flight simulator route, and their hard-enough-to-code 2-D driving game has become a brutal 3-D simulation. All for a few jumps that in retrospect should have been hacked.

My point is not to complain about a historical decision that probably didn't seem bad given the info available at the time. It's to ask about how to avoid these problems in the future.

If you grant my assertion that, in some cases, no straightforward analysis reveals the problem at the moment the "how do we handle this case?" question is asked, then it seems like we need a set of milestones for a posteriori analysis.

We make a design call when we need to make a call, and then we need some specific questions -- and times or situations to ask them -- that will tell us if we're on the right track.

Specifically: What is the best and earliest way to ascertain if we're

1. monkeyhacking in an edge case that really demands a proper refactor
   OR
2. doing a refactor that way overengineers a solution that really just needs a monkeyhack

What do you think?

Design and Implementation for Longevity: Two 20th-Century Machines

Here are two twentieth-century machines that are beautiful, functional, and still have it after several decades of radical technology evolution "should have" passed them by.

This C2 Corvette is as edgy, clean, and exciting as any vehicle built since. It probably always will be:

This original (1978) Cessna 152 performs at original spec after 30 years and looks great doing it:

So what does it take to come up with a design and an implementation that can hold up like these two?

Certainly sportscars and airplanes are not trivial problem domains with few constraints. And they're not domains lacking innovation and evolution. Yet neither of these machines take it on the chin for lacking digital gauges or GPS navigation.

There's some luck, some genius ... what else? It's more than a design question. If it were only about design, we might get bogged down in aesthetics and cultural theory, which is fun but sort of a sui generis sport. (Why does art deco seem futuristic? because "the futuristic" has irremediably incorporated art deco? what about directly undermining this? or does that form a stucturalist framework that reinforces the duality? ... )

One key piece is the absence of over-engineering. The 'vette and the 152 are fabulous implementations of their times, but never strove to be "ahead of their time" in terms of showy engineering.

Contrast a recent BMW or a Mercedes, which always comes off rather less slick a few years on, because at design time it had been packed with every blinking gewgaw money could buy, and those rarely age well. These cars do ok, though, because the first buyer gets a space shuttle experience during her 39-month lease. And since the drivetrain and suspension tend to be solid on these cars, the cars hold up for the next 25 years -- they just look increasingly tired doing it.