I always figured it was laziness when Flash designers omitted the back button…until I considered implementing one myself. Then I realized that this is another case where the wide-open freedom of Flash leads you directly to ground-up difficulties.

The back-button works so naturally in a browser because HTML presupposes one kind of transition: one page replaces another. Take for example this navigation strand in a hypothetical medical site:

body.html–>organs_heart.html–>cells_heart.html–>cellParts_lining.html

Because pages are essentially fungible nodes in a network structure, users can swap them with ease. This holds for backwards-and-forwards tracking as well as other types of navigation–jumping back in the history, or up to the home page.

Now imagine that a mop-haired designer is charged with designing a Flash version. The result: As a user rolls over a picture of a body, the body becomes transparent. Clicking on an organ zooms it and brings up text at the side. Clicking on links in the text provoke a pop-up with a model of a cell. Clicking on selected parts of cell fades out the body altogether and reveals longer texts…etc cetera.

It’s lame, but there you have it. Now the serious people put their heads together. At this point, they don’t normally consider a back button. What’s “back” in this context? Instead, they insist on keeping an elegant menu visible, and the designer (who just prevailed in a fight over that itty-bitty pixel font) graciously acquiesces.

Unfortunately, I think this is a disaster for the user, and for the Flash format, too. Sometimes users want to consult a menu, sometimes they just want to tap a back button. They rightly expect to have this option continuously, so Flash often frustrates them.

It’s not cake to implement a history in Flash, but we should grit our teeth and do it. Our HTML competition has it easy for now, but their time is coming: as web pages become more like desktop software, “back” becomes more like “undo,” and when it comes to handling the complications, the advantage will shift to Flash.

Here are some solutions to this problem: How do you provide a user access to their history within a navigational structure where transitions are not uniform?

1. The Node-and-Edge Straightjacket

You can approximate page-and-link HTML with these constraints:

a) Uniform transitions. Examples: All blurOut and blurIn, or a zoom function that goes in, out, and across.

b) Uniform nodes. Every target of navigation is essentially the same. What constitutes it isn’t necessarily apparent to the user. (A user works their way through a form, each successful input being recorded in history. Each step is like a “page.”)

Pro: Completely sidesteps the problem.

Con: Only works for simple interfaces. Memory takes a hit if “pages” contain a lot of redundant information.

2. Selective Memory

Reserve the back button for major navigations, which optimally will be visually distinct. For instance, in the example above, the back button would only work for “organ” choices if “organ” choices were the most relevant.

Pro: Easiest to program.

Con: While most users will go with the flow (”I guess that was the heart ‘page’.”), some might be confused about what the history is. Also, the logic of selection gets muddy if it ramifies down the navigation tree: organs are important…and once you’ve picked heart…then some kind of cells are important, others not so much?

3. Transition Brain

Organize your nodes into different types, and filter every navigation, asking: FROM what kind of node TO what kind of node? The Transition Brain will pick the type of transition and handle it.

Pro: There is no difference between history navigations and other navigations. They are all handled in one place.

Con: It’s a lot of overhead to classify all the nodes…and each new kind of node introduces a novel set of permutations.

4. Local Reverse

Create an undo queue synched to the history buttons. As each undo command is popped off the list, its implementation is determined by whatever determined the local “do” or navigation.

Pro: You can add new types of transitions without disturbing existing code. And in many cases, no special undo command is necessary, since navigating back suffices. In other, more complexes cases where each navigation builds visually or logically on the other, this pattern seems necessary (the opening example).

Con: Step-by-step backtracking is possible, but jumping from non-adjacent nodes is not. Moreover, it’s laborious to define both do and undo operations for every possible navigation.

These are 4 solutions I’ve diagrammed but haven’t had a chance to test yet. I imagine that simple interfaces could use any of them, while more complex interfaces would mix them.

Anything else?

Tags: interface · patterns · code2 Comments