essential code #5: pacing
[this example is a prototype I made for an internal design discussion at UW DUB. Only works in FF ... that's right, prototypes are exempt from browser compatibility etiquette!]
Stasko and Hudson wrote a great introduction to coding for animation. In this article, I want to explore some ways to apply one of their abstractions, pacing, to help engage people. My examples appeal to expectations in several ways. Pacing helps actors in a visualization resemble analogous entities in the physical world, by moving pixels as if under similar influences as in the physical world. Pacing can help you cast a transition into a familiar mold, established by cartoons or pop culture, that helps viewers understand your message.
Before I begin, it’s good to have an expressive pacing library. When choosing or coding a pacing library, I like to have the five core pacing functions listed below. I also like a knob on each pacing function to control the “strength” of the effect. My personal pacing libraries for JS and AS are based on trigonometric functions, which are just a personal choice (I like their slight “bowiness”).
linear([optional composition]) slow_in_slow_out(amount, [optional composition]) slow_in_fast_out(amount, [optional composition]) fast_in_slow_out(amount, [optional composition]) fast_in_fast_out(amount, [optional composition])
From here on, I’m going to abbreviate these linear, soso, sifo, fiso, and fifo.
Also, a useful property of pacing functions to be aware of is that they can be composed with themselves to amplify their effect. For example, soso(2, soso(1)) will give qualitatively different behavior than soso(3). You can use composition to morph the basic functions into more complex, and subtle, functions.
the psychology of pacing
This section is from personal observations as a UI coder.
People are sensitive to position changes and velocity changes (acceleration). Discontinuities in position and velocity cause viewers to focus. But too much change can blow away the their internal orientation. That is, when too much is changing from what the viewer expects, the flow between the viewer and the program is lost.
In broad terms, “SO” and “SI” are smooth. They keep the interface flowing (you’ll hear, “that’s slick” due to the increased understanding your fluid interface engendered). “FO” and “FI” and “linear” are jarring. They change rapidly (you’ll hear, “whoa, what just happened”).
From a cognitive perspective, pacing might be applied mechanically (like GOMS, for pacing *shudder*). However, I don’t have that framework, and I typically just feel out the interactions under two criteria:
- transitions don’t interfere with flow (which usually means they’re under 300ms, unless the transition is displaying information without requiring further user interaction)
- jarring transitions are used to either draw an analogy or highlight some value
Bringing it back to the example,
pacing is applied in a few ways.
SISO is used for mouse over on the icons. Since we’re changing the position of possibly several elements when we expand out an icon, we have to make sure we expand only what the viewer wants (to avoid erasing orientation excessively). The SOSI accomplishes this by provising some slight visual feedback for mouse over, while not engaging in a full transition unless the mouse hovers for some time.
FOSI composed with SISO is used for mouse out on the icons. The reason is twofold. First, we want inactive icons to quickly go away (FO). Secondly, quickly dropping is in some way analogous to physical objects. I want the entire resizing interaction to feel physical.
Many user interfaces use pacing extensively. If yours doesn’t, you should think about what transitions in your interface are breaking flow (harsh; cause you to wince). For many websites, which don’t utilize the full range of visual parameters (like size and movement), this doesn’t come up. That is, the most common interaction, changing the color of a link, isn’t visually jarring to begin with.
Just like smooth noise, pacing is about smooth transitions.