Pet Theory

Recently I was plotting bitmaps in 3D space, trying out various kinds of motion: linear, curved, inertial…and it got me thinking about how motion was integrated into interfaces.

Take the simplest, most common example: the sliding-out motion of a drop-down or fly-out menu…

Even though I now turn this effect off when I can (it's too slooooow), I was captivated the first time I saw it. Why?

Basically, motion implies weight, and weight implies thingness…and the sliding felt right because the menu is a thing I'm handling. So the motion functions like a kind of drop shadow for user interaction.

Inertial motion–easing in, a Flash staple–feels especially right in this context, because objects with inertial motion are more natural–on earth at least, things with weight come to a stop. It also nicely combines an intitial burst of speed with an ultimate delicate accuracy (the easing in).

When I was working with 3D, I was surprised to find linear motion fetching too…even as an object recedes and its 2D speed slows, your mind knows its 3D speed is constant. It vibrates with sustainable energy, like Stereo Lab, or Bach, or whatever your working music is.

Linear motion is great in 2001, but it clearly wouldn't work in an interface. An object in constant motion isn't an object you handle…and if it stops, where does that energy go? Our minds would add a clank and a shake if a menu slid out in linear fashion and just stopped.

Motion is a powerful tool to orient users…and disorient them, of course. Does motion makes "things" on the screen separate, self-propelled things, or things we can handle, tools?

Obviously, both…the trick is to separate or mix them for the particular experience you are trying to create, right?

If you work at a company with an intranet, I'll bet you remember the first time you called the IT guy for help and he (smirking?) started using remote desktop and wagging the cursor around on the screen and telling you how to fix the problem. It's a creepy moment, and a feeling of disembodiment, when your motion, your cursor and your power, is transferred abruptly to him.

Flash makes me feel that way, a lot.

Until I looked at Flex this weekend, I didn't believe Jesse Warden when he predicted that Flex would retire Flash into a Director-like, niche position.

Well, now I believe. And I feel a pang for Flash. Not because I give a damn about the technology–there will always be another technology–but because I hoped Flash would be a uniquely powerful tool for creating new kinds of interfaces, whether in art, education, or entertainment.

I don't know Flex at all, really, but I've seen enough to know that its strength relies on HTML-like standardization of interface components. Sure, I bet (though I don't know) that Flex is a great tool for fashioning new components, and high-level AS coders will be able to find work tweaking Flex and bringing it beyond itself…but that won't go to the essential strength of Flex.

Standardization is a win-win for developer and users: develops can develop more quickly, and a la Nielsen, users can use more quickly.

So what's to gripe about? Nothing, I suppose. In the years since Flash 5, when complex interfaces became possible, has Flash become a great font of interface innovation? For instance, what has the opportunity to create your own widgets added to the broader vocabulary of interfaces?

The preloader progress bar used in iTunes music store? Occasional spasms of industry self-congratulation notwithstanding, there's little to celebrate.

What's to conclude from this failure? Well…the people who specced out HTML really hit the nail on the head. (When something Flex-like kills HTML, we should say, the king is dead, long live the king.)

Or…progress in interfaces is much, much slower than progress in technology, because it's cultural. Designers have to get beyond their assumptions, and users have to form new expectations.

Unfortunately, after Flex, the institutional impetus for innovation will be momentarily stalled. Flash developers will become Flex RIA developers, HTML will get tweened transitions…and the Flash designers left behind will be the least able to deal with interactivity.

Just to be obnoxious, I'll designate their Flash "L.A. Flash" because it is mostly produced by advertising agencies and movie studios. It's basically Flash meant for broadcast. One damn thing after another.

When I was at the Jobstock (that's a L.A. Flash job fair), all the employers that presented said they required Flashers who avoid "flashturbation" and thought interactively…then went on to show their material, which was 99% "flasturbation" with a pinch of interactivity.

I don't blame them; it's especially difficult for people who think in pictures or moving pictures to think in interaction…but it's hard for ANYONE to think in interaction. We are at the beginning, I think.

One slight reason for hope is the pressure that On2 and broadband will put on Flash designers. So much of what they do is basically crappy faux video…but when Flash can port high-quality video over broadband, what's the point? Let the After Affects people do their thing…and then Flash designers can focus more on interaction, and hope their best work will be integrated into Flex.

I have to admit that the official description of Flex always left my head spinning with buzzwords and corporate breathlessness: RIA…bundled technologies…enterprise scale…presentation tier…standards-based.

It took this short video (the Kuwamoto one), in which a Macdobe engineer builds (in about 15 minutes) a visually arresting application that searches Flickr and fades in the resulting pictures, to bring me to face to face with the astonishing truth of Flex.

After seeing this promotional video, I bet that Flex will ultimately displace HTML, whether "Flex" remains an Adobe technology, or is superceded by a rival company's technology or (optimally) an open-source format.

Why? Because it's EASY. I'm sure that it's not as easy as that engineer made it look, but I'm sure it's not much harder, either.

Here's a rough cheatsheet on Flex:

MXML (the XML markup language that produces swfs in Flex Builder)==HTML
Actionscript==Javascript + (parts of PHP and CSS)

If you focus on the differences between MXML and HTML (like, you know, MXML is worlds more powerful), you miss the point of the comparison: MXML seems as easy as HTML to learn (WYSIWYG-able mark-up) and develop (a stable set of components, a quick way to permutate swfs).

Yes, Flash Made Easy does make sense for "desktop on the web" (no page refresh, resizable windows) and enterprise-scale projects (dynamically generating different swfs, like PHP dynamically generates HTML)…but looking at this video, I sensed a more grandiose ambition.

If Flash can be made this simple, why can't Flash be made simple enough to fit into Dreamweaver, and the power of connected multimedia be made available to individuals and small companies? That seems like the logical next step.

I couldn’t take the Flex class at LA Flash this weekend ($$$), but I did manage to treat that envy-induced tic in my eye by downloading Flex Builder 2 and monkeying around with AS3 for a while.

First impressions: It may be true that AS3 takes actionscript to a new level or performance and programmer- and application-friendly logic…but for the practicing actionscripter, the hype is misleading…

For one, when it’s compiled to bytecode, AS3 might be an alien beast, but the difference between AS3 and AS2 is minimal (reshuffled, expanded API, stricter typing, runtime errors, additional data types, packages), and nearly negligible when compared to the difference between AS2 and AS1 (classes!, typing!, standard inheritance!).

For two, AS3 is not some souped-up, sophisticated version of AS2–it’s actually simpler and easier (this goes even more for Flex (my last post), which is astoundingly, even alarmingly simple):

clip:MovieClip=new MovieClip()

Wasn’t that easy? Want to put this clip in another clip?

otherClip.addChild(clip)

Want to control the depth more precisely?

otherClip.addChildAt(clip, 3)

The new XML classes allow you to access XML data by strings/names:

userXML.colorPref

This returns the color preference for a user. Anyone nostalgic for firstChild.firstChild.childNodes[someDamnIndex]?

Another aspect of AS2 you will not miss is explicit delegation.

clip. addEventListener(MouseEvent.MouseDown, callbackFunction)

function callbackFunction() {
//in here, “this” is automatically scoped to where the listener is added…
//your neatly centralized code, that is
}

A class I’m especially interested in is Loader:

myLoader=new Loader()
myLoader.load(new URLRequest(”here/here/this.ext”))

Unlike MovieClipLoader, this class can load pics and swfs without putting them anywhere–they just hang out in the memory, waiting to be used (though how to access them, I’m not sure.)

If you are comfortable with AS2, the only thing that might initially throw you is the display API.

MovieClip no longer has its distorting prominence in AS3; it’s one among many display objects (shapes, bitmaps, texts) that can be mixed and matched.

My guess is that this new API–and the others–will be easy to learn and remember because they are logical and meaningful (where are video, sound and camera?…in flash.media, of course) rather than the arbitrary result of Actionscript’s evolution.

In sum: Adobe has cleaned up their desktop and put the language in clearly labelled, tidy little folders.

[Edit: After becoming comfortable with AS3, I definitely stand by these initial judgments.  But after hearing--again and again--silly, self-serving proclamations from developers about how AS3 will separate the boys from the men in terms of coding, let me make a distinction. IF you are already using AS2-type variable typing and classes, you will NOT find the transition to AS3 difficult. If you are stuck on AS1-type coding, it will be difficult to ratchet up your coding, but even in this case, it will be MORE difficult to learn AS2 than AS3...so if you are making the leap, skip AS2 and go right for the gusto--AS3.]

Last week I had my first freelance Flash gig, and it was more educational than I expected–or wanted–it to be…

The fault lie entirely on my side. The mission specs were vague and the timetable insane, but I understood that going in…and ultimately failed to adapt.

As a Flash hobbyist and learner, I've developed a consistent work process: ponder, plan, execute. Under the pressure and excitement of my first gig, I threw this process out.

This was a mistake. In the context of this particular gig, whether this process is optimal or not just doesn't matter, because it's my current process, and I can't swap it out for a new one with the ease of Keanu Reeves learning kung-fu in the Matrix.

The trick will be to adapt my current process to the task at hand. I should treat my work habits like components, throwing them into projects and parameterizing them accordingly, rather than trying to revamp habits, a longer-term undertaking.

Now I know.

My months-long Goldilocks-like search for a decent AS code editors recently came to a blissful conclusion here:

FlashDevelop

I was in a long, bad marriage to the Flash editor, which I couldn't leave, because I was on OS X and the alternatives were buggy (the SEPY port to Mac, ASDT in Eclipse), expensive (FDT) or undeveloped (XCode, FAMES).

Reading about FlashDevelop (here) pushed me over the OS X edge: I got hold of a copy of VirtualPC, downloaded FlashDevelop (and the Microsoft.NET framework, which installation requires) and began coding…

The experience was trance-like. Now I understand why people get so attached to their editors. This one has all the usual features (code completion, class libraries) plus the almighty F4: press F4 while your cursor is over a word, and the editor brings you back to its origin (function or variable declaration or class definition), automatically opening files if necessary.

Typically coders laud editors because they save them time; FlashDevelop made me rethink their acccolades.

How much clock time does it actually take to scroll back to a functon declaration or open a class file? Yes, it adds up, but does it compare even remotely to the time you spend rubbing your temples or scribbling diagrams?

Rather tools like FlashDevelop make you more efficient by automating tasks that other otherwise interrupt the flow of your thoughts. They allow you to concentrate purely on the task at hand–the programming logic, for instance, not that ugly heap of conditional brackets.

More generally, the need for speed should be understood as a need to think clearly. The speed of Google helps me think: What are the best search terms? What, exactly, am I looking for? Conversely, waiting for a sluggish program to open up, I lose more than a few seconds, I lose the time it takes to re-establish my train of thought (if I can at all…I'm easily confused).

Random exasperation: swfs could be faster and more intuitive than html pages, so why are they almost uniformly slower?