Pet Theory

A self-evident interface is always Plan A…but a self-explaining interface is a decent Plan B. Here is one in action. (Follow the purple arrow…not optimized for start up yet.)

“As simple as possible, but no simpler.” For my current Flex project I reached this point pretty quickly. Inspired by improv, it is a chat site that creatively orders group chat. There are roles (Host, Quizzer, Conservative, Blind Date, etc.) for a variety of scenarios, mostly drawn from pop culture. Chatterers vote for a scenario leader, who plays one role and picks others for the remaining roles.

For a game, it’s not complicated. For an interface, it is. Some sort of help was required. More… »

In my last post, I reviewed the code architecture of my playground site. In this post, I’ll explain its design.

I fear that the site will have all the charm of exposed pipe for the average Flash designer. My fear is based partly on my primitive graphic-design skills, but mostly on the unusual nature of the interface.

Here is the interface:

More… »

In a tree of modules, some modules will need to load assets when selected…and some will themselves need to be loaded.

More… »

I resent Jakob Nielsen because he is always right, and that is the worst, most infuriating habit.

Take a look at his latest directive at webmonkey. Or just peruse this summary (quoted from the article) of his current complaints about web pages:

* Links that don’t change color when visited
* Breaking the back button
* Opening new browser windows
* Pop-up windows
* Design elements that look like advertisements
* Violating Web-wide conventions
* Vaporous content and empty hype
* Dense content and unscannable text

Flash designers should take these complaints especially seriously, because more than your average HTML designer, they deserve them. How often do you see Flash sites that color visited links…I mean, how hard is that? And how often is a useful back button implemented? (I’m not talking about the exotic browser-integrated “frame label” hack, I’m talking about a Flash back button that actually recalls saved states….not easy, but easier with Flash than HTML.)

So Jakob Nielsen should keep scolding. My only counter-complaint is that his complaints are too specific and HTML-oriented. I’d generalize his specific irritations: a user should be able to orient themselves, yes, God yes. That may be accomplished through back buttons and visited links…but if you have a good design, perhaps you can accomplish otherwise….and if you accomplish it very well, you don’t even have to abide strictly by “Web-wide conventions.” I mean, that’s why Flash is cool, right?

I thought about Nielsen the other day when I let my 6-year-old nephew draw using my Cintiq. I explained the presets to him ONCE and he started drawing and pressing the presets.

I wonder what will be usable for him, ten years on? I’ll bet a lot of carefully designed, Nielsen-friendly sites (meant to hang on to awkward, older users) will make him impatient–and I hope Nielsen will be around to measure this novel round of impatience.

Last week I used Flickr for the first time (obviously I follow the trends rather than make them).

What a design!…fast, easy, imparting a brimming sense of possibilities while remaining clear and directed. Really, it’s delicious.

So being a partisan I immediately wondered why it wasn’t done in Flash. Apparently, it was, originally. Here’s an interview with the lead developer.

Flickr began as a UI for IMing that included photosharing. Since the emphasis was on providing a visual context (dragging and dropping, windows, avatars?) for instant communication, Flash seemed like the natural choice.

However, after the photosharing aspect caught fire, the Flickr team responded quickly, dropping Flash and creating the site as it is, which allows users to build photo journals that other users can view anytime, “asynchronously,” as the techno-literate say.

So Flash was no longer necessary, and, to boot, had two flaws 1) security and 2) USERS COULD NOT LINK TO POINTS OF INTEREST IN THE SITE (so, for instance, they could not email friends to point them to photos of their vacation that they had just posted).

After absorbing this anxiety-producing point, I decided to provide URLS for each part of my coming playground site. (And learn Flash Vars, so the site can handle homing-in URLs).

I want to to be talked about, don’t you? Isn’t that the ages-old vanity behind this new-fangled thing, Web 2.0, social networking, viral marketing, community-building, whatever the latest catchphrase is?

Flash can do at least 2 things better than HTML: 1) create interactive experiences, and 2) create moving pictures (tweens, animations, video).

That's great. Now let me point out that Flash's two great powers are more than not antagonists, and their clash distorts and cripples many a swf.

The example of 1st-person shooters is misleading here, because the experience of ACTING and the experience of SPECTATING are fused in the intensity of 3D immersion into life-and-death scenarios.

Off this peak, spectating and acting are often at cross-purposes. It can be hard to "do" while you "watch," and to "watch" while you "do." Watching a movie while you play racquetball is a bad idea.

Of course, we multi-task all the time, and I believe there are literally infinite ways to fashion experiences that mix the two so that they complement each other…but I don't believe that designers blind to this elemental conflict will be the ones who create these new experiences.

There are many details that grate on me: the slow drop down menus, the ugly gray gradient background, the pictures with people wearing sunglasses that I can barely see, the labels that use all caps, the small, blurry font, the lack of a true home page (just a splash-page picture of a girl with wild hair, which, truthfully, would mollify me some if I could get back to it), and the totally boring implementation of the backwards/reflection/different view theme.

But what really gets me down about the site is the way the use of Flash actively detracts from my experience of the site.

1) It's slow. Each navigation entails the same transition animation. In the beginning, this animation acts as a preloader…but then, once the content is loaded, I STILL need to wait. WHY?

2) It's repetitive. How many times do I have to see the same transition animation? It gets old quick.

3) It's confusing. I want to see sunglasses. Where are they? The searches often yield nothing. It's not clear what I had been searching for. Once I make selections, I still need to press GO. Once thumbnails are loaded, I need to scroll (and the scrolling sucks). If I press the thumbnail, I get a medium-sized picture. Then I can press various buttons to get an even larger picture in a pop up (!), or some meaningless measurements, or (the button with the refresh symbol!) I can rotate a smallish 3d image of the glasses (talk about burying the lead).

It feels like every poorly designed site–arbitrary and disempowering. I always feel like I'm a dizzy, drunken trail of clicks away from where I want to be.

Thing is, I'm not some useability prude or text-obsessed Slashdot geek…I actually believe in the potential of Flash. This site could make shopping for sun glasses pleasurable and efficient. It does not…in fact, its html version is heads-and-shoulders easier to use.

I was trying to explain to my skeptical sister-in-law why I quit my proofreading job and started up with Flash.

When I explained Flash to her, she said: "Have you seen the Ray-Ban site?" Then she groaned and made quick, couple-ish eye-contact with my brother, as in "What silliness is your brother up to now"?

Later I went to the site. And the truth is, I was embarrassed.

Most transitions should be handled in Flash without animation, because most transitions are driven by perusals and not commitments, and for perusals, animation is laborious.

Let's say I'm mousing over a menu; why not have text or images come up immediately, on rollover? If your design is logical (where does the material come up?) and your programming suave (you've loaded in the background), this immediacy will free users to look around (focusing here and there, backing out with ease) without having to commit.

But let's suppose the user commits and selects; even then, the question should be asked: why animate? It's useful, because at least if know why you're animating, you'll have an idea how to animate.

Let's say the content that loads is melancholy, perhaps a slow blur tween can calm the user and prepare him to squeeze out copious tears…for comic content, perhaps bounciness, elasticity…for corporate efficiency, exact, efficient motion.

Of course, the meaning of transitions often resides in the logic of the interface itself rather than any content per se. Transitions can orient the user. An event happens, the state of the interface changes, and the user is supplied with a visual correlative of this change.

Let's ignore the fact that 95% of the time, designers use this visual correlative just because they can (animations for the hell of it, dude!), and focus on a few ways that animations can orient users.

1) They can make emerging graphics less (not more) prominent. (As thumbnails load, the user might already be looking at a thumbnail…so the currently loading thumbnail should materialize like a docile child waiting to speak, fading in rather than popping in).

2) Morphing shapes can retain references to consistent layout elements while changing according to state. (The back button used to be on the green square…now it's on the green rectangle…the shape is different, but the same).

3) To anticipate content before the content is loaded. (Preloaders should combine standardized and custom elements, if you ask me.)

There are other reasons–though not so many as "LA Flash" designers assume–to use animated transitions.

Keep in mind that these animations should play quickly if they are intended to be an integral part of the user's interface experience. A plurality of our neurons are devoted to processing visual information, which we do faster than PlayStation to the power of xBox. If you are using an animation to orient the user, the user is probably going to be oriented (or not) in milliseconds.

A rule of thumb: since we see before we verbalize, the visual cueing we give users should be accomplished in less time than it would take them to internally articulate it ("oh…that's still the back button"). Otherwise, the normally slow verbal part of the brain gets to the finish line, has some gatorade and takes a squat before the normally speedy visual component of the brain finishes up. And that's perverse.

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.