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:
When the user rolls over a button on the home page, information about the potential destination appears in a centralized “hotbox,” temporarily replacing the title. A hotbox is like alert, except that it is statically integrated into the design and–like a status bar–is continually updated by user actions. A hotbox is especially useful when a user wants to quickly browse a bunch of options and make decisions with more information than a label or a sentence can impart:
When a user clicks, if the content is loaded, it immediately appears in the center; otherwise a progress bar intercedes between the click and the content:
Notice that controls special to the content appear above the default controls, a home button and a history slider. Either control allows the user to restore home quickly.
Not the most complicated site. But deliberately so. Let me point out several unusual simplifications:
The default transition animation is none. Why animate a transition? Web browsing and desktop applications have accustomed users to content that blinks into existence, displacing existing content. There might be a few occasions where animations orient users, but how many add cognitive value on the average Flash or Flex site? 1 in 50?
Worse than unnecessary, animation transitions are slow and typically impede the interaction. Who wants to wait, even half a second, especially for content the happy-clicking user is just checking out? Also, it’s repetitious. The same animation plays every time the user loads the same content, or–cue gritting of teeth–every time the user loads any content. Hey, Flash designer, say something once, why say it again?
Often transition animations hide downloads. But this sleight of hand is weak. It forces the designer into a foolish consistency (playing the animation again even when content is already loaded), or into a foolish inconsistency (the second play differs from the first). Better to be candid and show the progress bar or a content-specific preview.
The slickest Flash designers have already started abbreviating their transitions. Many employ now what I think of as “last, longest yard” animations: the animation is essential completed before it begins, like the fade-in that starts at 75% alpha and briskly reaches 100%. I wonder why these designers don’t–like Cosmo Kramer trying out boxers, then going commando–take the next logical step and abolish the animation altogether.
Could it be that they fear that if they took all the transition animations out of their bag of tricks, it would be empty, and HTMLers could take their jobs? I think that Flash has become an entire, powerful platform, and there are tons of potential designs that don’t require the tedium of transition animations or the tics of motion design.
You might think I’m talking about applications, not traditional rich-media sites. Actually, no. Even on a movie site, for instance, superflous, self-import transitions make me want poke the designer in the eye. There are a multitude of expressive ways to use Flash on such a site, and I’ll bet designers would find them if they weren’t busy shaking Adobe Inc.’s moneymaker.
History is absolutely necessary. HTML has its virtues. One of the most outstanding is the history. Because users know they can always hit the back button, they carelessly explore. Another winner is scrolling. The don’t-look, can’t-miss scroll bar nicely separate the action of the eye and the hand so the two can work together, the eye scanning while the hand drags.
I’ve combined these two HTML powers in one Flash widget: a history slider. Notice how the darker regions indicate the extent of the history:
Designers now enjoy a sliding history in the Flash IDE. Why not let users enjoy it, too? Since historical content has already been loaded (or at least browser-cached), it should be available for users to slide backwards and forwards.
Of course, for the slider to work, all the navigation transitions need to be immediate. Theoretically, a slider could scrub through tweened transition animations; practically, a long slider and cinematic reverse would be awkwardly literal.
Obviously this straight-to-content requirement is no deal-breaker for me. But you might wonder if I’ve put on a straightjacket when it comes to transition animations. I haven’t. In you peruse the playground site, you will see that I employ them when warranted.
To ensure that every navigation can be immediate, I created a two-track navigation system. In it, each navigation can take a slow track (if reacting to a click), or a fast track (if reacting to a slide). In practice, since I favor immediate transitions by a wide margin, the slow track is identical to the fast or immediate track in the majority of cases. On occasion, a separate “slow” navigation (a fade-in, for example) is separately defined.
After making the history slider, I become so psyched about sliding that I constructed a slider-inspired widget, the “puller.” The puller looks like a button, but acts like a slider. As the button is pulled (in any direction), content–whether texts, pictures, audio, or a combo–cycles through the hotbox:
The advantage of the puller is that it takes up less space than a slider. It’s best for unlabeled or easily identified content. In my site, each experiment is accompanied by an information or “i” button that can be pulled.
Controls should be grouped together. Whether Flash- or HTML-based, web sites differ from electronic gizmos because, instead of grouping controls, they disperse them.
The reason for this is obvious: a site has divided content, and the controls follow the content. Think of a typical site whose home page is divided into boxes, each with a link button at the bottom right of the box. Nothing could be more natural than examining the contents of the box, then clicking on its link.
Still, up against the principle of “controls follow content,” I propose a countervailing principle. Just as developers have sought to divide form from content, I think designers should attempt to “divide controls from content.” The obvious example is a navigation bar, which remains in its own static space while the content changes.
In my playground site, the default controls (home button, history slider) sit at the bottom center. As new content is selected, the controls for the content typically appear above these default controls. This arrangement has two advantages:
1) When users wants to exercise control, they know where to look.
2) Controls are often used together (pause/play, home/new selection, last/info/next). Grouping them together allows the user to move easily from one to the next, and to form temporary habits, even muscle memories, which speeds up the tempo of action/reaction. Jerking a cursor from one control to another far-off control breaks up this tempo.
Notice that I have taken other measures to increase user confidence in the controls:
1) The controls are big for quick, brainless access. (Users can also right-click for a context-sensitive control menu.)
2) The controls are stylistically uniform and contrast with the content.
3) The controls are conventional, so, for example, the home button is like the browser home button.
4) Form follows function, so irrelevant distinctions are dropped. So video controls (play, pause, scrub) look exactly the same as audio controls and slide show controls.
Here are some controls:
I realize that these screen captures convey a definite exposed-pipe look for the controls. That I don’t mind: I prefer Flash as vector punk (The Sex Pistols) to Flash as wannabee After Effects (Pink Floyd). Besides, my overarching aim was to create a mean, lean content-delivery beast that can deliver a wide range kind of content (video, audio, red, green, sad, happy) and curl up in the background without slanting the content.
A better, more graceful designer with a more restricted range of content to deliver could make a prettier site out of the same interface. And that is my hope! I don’t intend this interface as a quirky personal expression, but as a template for forward-looking designers. Instant transitions, included history, and separate, grouped controls are formal structures that can be modified, mixed and matched.
For the next post in this series, I’ll discuss the experiments on the playground, and speculate more generally about what Flash content can be.
Tags: speed · interface · Flash8 Comments
8 responses so far ↓
I have to disagree. There is lots of research that shows that using transitions in the correct areas helps users understand the context of the content. You can clearly see this in OS’s, TV etc. That aid it is important to make sure the transition is smooth and quick, and is adding to the experience, i.e. avoiding “skip intro” type transitions.
From a usability/user experience point of view, having buttons with no labels is not good. It hides the value of the button, until it is used (i.e. rolled over).
I haven’t seen this research, but I’ll bet it’s on OSs where the animations are definitely much better, “in the correct areas,” rather than on Flash or Flex sites.
If OSs and TV are the standard, however, you are on weak ground: OSs eschew transition animations and let content just appear far more often than they use animations, even Tiger. And as for TV, since about 1910, moving pictures have been fundamentally based on the arbitrary “cut,” not on the iris transition or tracking shot.
As for unlabeled buttons coupled with a reactive”hotbox,” my notion is that if the user can quickly roll and see where she might be going, that’s more browsing power and more mnemonic association. It’s an idea. Try it out, you might like it. I’m way less dogmatic on this point.
Thanks for the reply.
Here’s a couple of links I came across on a quick google search
http://uxmatters.com/MT/archives/000187.php
http://www.designinginterfaces.com/Animated_Transition
http://gizmodo.com/gadgets/columns/frog-design-mind-140886.php
http://www.cis.strath.ac.uk/cis/research/publications/papers/strath_cis_publication_207.pdf
By TV I meant the sort of UI stuff, i.e. the animations you would see when you bring up guides, or the sort of stuff they do when the advertised the next program etc, not the cut of the actual film.
What just appears for you on Tiger? I’ve just been clicking around mine and I can’t seem to get anything to just appear on the OS. Also nearly all the software has draws that animate out etc, right down the the users in my IM list animating when they go on and offline. You will also see a lot more transitions in Vista than in XP (pretty sure these companies would have spent a lot of money researching this stuff). The same goes for phones etc, in fact most UI devices.
I’m also presuming the html developers understand the importantance of transitions due to the advances in dhtml.
You can also see the importance of transitions in any of the example RIA’s that Adobe do (obviously just because they do it, it doesn’t mean it is correct, but again I’m sure they have very experienced people and will carry out a great deal of research).
“As for unlabeled buttons, my notion is that if you can roll and see where you are going instantly, that’s more power and more mnemonic association for the user. ”
So the theory is that the user is more likely to remember what the button does by hiding its function until rolled over, as opposed to them being able to glance at its label at any time?
Seriously unlabelled buttons are unintuitive.
Hey Tink,
You caught me exaggerating. Mea culpa. Here’s what I should have said:
Transition animations are often useful UI elements. They can orient users, and they mimic the real world (stuff fades in the from the distance, you stop walking with inertial-type deceleration, etc). That’s why big companies with smart R&D staff are using them more and more as the technology (processor, bandwidth, Flex, etc) becomes available.
However, not every state transition needs to be animated. In an OS like Tiger (mine and yours, too, apparently), for instance, which uses plenty of animation, application windows just pop up. In Finder, new column material just appears on selection.
What I should have said: I think Flash designers should show more judgment and exercise the non-animation option more often, just as the Apple OS designers do.
The main reason they should do this is speed. Speed allows users to act quickly, so they feel free to explore and interact. Speed is a huge factor in usability. Even a badly designed site will be ranked higher in terms of usability if users can thrash around with sufficient speed.
In terms of a UI interface, even a 500 millisecond animation can be a drag.
So I’m not just criticizing excessive or superfluous animations. Even a fast, cognitively helpful animation should be scrutinized: is it worth the cost in time?
If you take a look at my playground, you’ll see that I’ve optimized it for easy browsing and absolute speed: I have history on a slider, a background loader, no transition animations…and those un-serious un-labelled but easily browsed buttons.
I meant the site to be a demonstration that speed and directness can feel intuitive. Even if I failed to do that in this case, I think that better Flash designers will eventually use the non-animated transition more often, even as–as you say–animated transitions are conquering the UI world.
Thanks for the clarification.
‘ you’ll see that I’ve optimized it for easy browsing and absolute speed’
How can there be any ease of browsing when I have to roll over something to see what it will do. Ease of browsing would be knowing what something does, and therefore not having to roll over something to find out I’m not interested in it. Neither is the site direct, i.e. if I when into an area and found something interesting, but then tried to manually find it at a later date, i would struggle as we don’t remember things by, ‘the second dot, then the 9 dot on the second row of dots etc’, we remember by labels, and names.
“Seriously unlabelled buttons are unintuitive.”
Looks like Adobe have a chapter on transitions pending over at the Flex Developer Lab, which should be interesting.
http://www.adobe.com/devnet/flex/?navID=fig
‘Part 6: Guiding with motion (Coming soon!)’
Here’s another link for designers who’d like a clearer idea about how and why a particular transition should be used:
http://developer.yahoo.com/ypatterns/atoz.php
As for the unlabelled buttons, in principle I think you have it wrong: it is awkward to find something by remembing or following a series of names (the “string tree” that flows like this “Home”>”Section”>”Subsection”). That is why google beat yahoo. Conversely, remembing by physical location (top left, a couple over) is more intuitive. Do you remember in college trying to find a page in a book to cite–you could remember where physically a line was on a page, but not in which chapter it was in?
As for the first, fresh browsing, my idea was that rolling quickly over a series of buttons is nearly as quick as reading them, and the hotbox would actually provide a lot more information than a label for the user to scan. This is especially apropos for playground site, because the sections are not obvious like Contact, About, Camcorders, and just a title could not impart enough information for a user to make a decision. In this case, a labelled button does not help much.
(BTW–the hotbox is the kind of feature that a designer just wouldn’t think of if they were stuck on animations–another reason to keep the non-animation transition at hand, it frees up your mind…)
Of course, I could combine the hotbox info with titles, too. It’s an empirical question about this site. Tink votes NAY. A few more NAYs and I’ll change my mind.
The cover of a book provides a lot more info than the spine (i.e. like you concept), but going into a bookshop and seeing a load of blank spines would be a nightmare, and like your site take loger to acually find the content you are interested in.
This is proven in everything we do, i.e. having blank tins in a supermarket with the label on the bottom would be a nightmare, so you have to pick each tin up to see what it is, unlabel buttons on a phone, unlabeled keys on a keyboard, unlabelled buttons and controls in a new car, unlabelled buttons on a stereo system, unlabel buttons on your software and OS etc etc.
As you can see these all follow a clear simple rule.
This is also the same for web content, i.e. the Adobe site or BBC site would be a nightmare if they removed all the labels from their buttons.
“my idea was that rolling quickly over a series of buttons is nearly as quick as reading them”
Yup nearly, but definatly not as quick. Yes the rollOver gives more info, but hinting at what that info is before rolling over would be a lot more intuitive (i.e. see book anollogy at the beginning of this comment).
I can’t imaging any more of a nightmare than when i first started using eclipse, it having no labels on buttons, and it just using rollOvers alone, and then having to remember the location of each.
Thats why your have labels on the buttons on this blog right, instead of empty buttons that when rolled over give the title or the post or function of the button.