Originally published: Jul 06, 2010
A few years back, the organization AIGA desired to highlight the leading digital graphic artists with a web site showcasing their work experiences. The site, called Gain, was really the first of its kind: a highly interactive digital magazine, intended to interactively tell the stories of the leaders in the digital design world.
In the first issue, they highlighted the great work of Hugh Dubberly, an early pioneer and leading thinker in digital design. The author, David Brown, wrote a wonderful tribute to Hugh's work and the site featured some examples of Hugh's trademark models.
The Gain site designers wanted readers to see David's full article, but it was larger than a screen. This meant the article needed a scroll bar. However, since the site was highly stylized, they opted to design their own scroll bars, instead of using the operating system defaults.
Gain's designers opted to implement their own stylized scroll bars.
Turns out they didn't quite get the scroll bar interaction right. In the initial implementation, the arrows at the top and bottom moved the text only one pixel at a time. If you wanted to see a full line of text, you had to hit the button repeatedly. Dragging the rectangular elevator didn't have the smooth scrolling we're used to, instead it refreshed the content in jagged bursts, making it hard to keep track of what you wanted to read next. And the space between the arrow and the elevator, which normally moves the content a screenful at a time, did nothing.
The effect was jarring for readers. People wanting to learn more about the great work of Hugh Dubberly were constantly drawn away from the content to focus on operating the scroll bar element. Not a good way to highlight digital design.
The Gain site was implemented in Flash and they weren't the first or last to try to duplicate scroll bar behavior. Other Flash designs had crazy implementations, such as reversing the direction of the movement, or rendering the elements in unrecognizable forms. This isn't the fault of Flash, but a lack of realization that scroll bars are complicated.
If you think about it, there's only a half dozen or so popular operating systems in service today. And the scroll bar elements in those operating systems are implemented once and used everywhere. That means that there are probably only a handful of people on the planet who truly know how to implement a scroll bar. It's just not an easy thing to do. Scroll bars are complicated.
To make our designs fully interactive, we want to have elements like scroll bars. We want those elements to work the way we're used to, so we can concentrate on the important things our design does, not the simple manipulation. People should enjoy the articles, not focus on how to make those articles scroll.
Our manipulations need to be invisible to work right. If they are in the users' focus, they are detracting from the true thing the user came to do.
Netflix has been a pioneering site with sophisticated interactions. As one of the first to employ AJAX techniques on a grand scale, they've been a leader in creating natural interaction elements that enhance the users' experience. It started simply with their movie rating mechanism, where a simple click of a star seamlessly updated the server database and indicated the change through a color change. Yet that simple interaction had several important, well timed steps to pull off correctly.
Recently, Bill Scott, Netflix's former VP of UI Engineering, shared with us a technique he's been using to track all those little interactions, which he calls the "Interesting Moments Grid." Created when Bill worked at Yahoo!, the Interesting Moments Grid records everything that happens with the interaction. "The developers really appreciated it," Bill told us, "because they could just look at it and they didn't have to wonder if the designer had forgotten something."
The grid is a large matrix, with the events across the top and the design element pieces down the side. For example, when designing a Drag and Drop, your events would include the page load, mouse down, mouse hover, drag initiated, drag leaves original object, and drag re-enters original object. The design element pieces, which Bill calls the "actors", would include the page, the drag object, a tool tip that might display, and the cursor.
In fact, Bill tells us that a typical drag and drop has at least 16 events and 6 actors. When put into the grid, Bill finds there are usually 96 interesting moments. One interesting moment could be, for example, when the drag starts, having each applicable target object highlight to help the user know where to go. So in the target object cell under the drag starts column, Bill would indicate that action. In the same column, Bill would also indicate that the cursor would change to the ghost of the drag object.
The elegance of Bill's Interesting Moments Grid is how concisely it lets the team track the design. "Originally," Bill explained, "I tried a lot of state diagrams, drawing things out, and here's a drag and drop interaction. And all of the possibilities of permutations just began to explode on you. As the scribe at the meetings, I would go off and try to document all the possibilities that we had talked about, all the nuances, and before long, I had 20 or 30 pages of notes. And I realized quickly that that would be a silly way to come to any conclusions."
"Then it occurred to me, as often is the case that maybe I could apply a little bit of design back to the way we were capturing this information. The thing I saw over and over was that there were many little events, and there are always these objects and elements involved. By putting those into a simple grid I could really point out the time and slow down time and start putting all this under a microscope and bringing out the nuance."
Bill uses the Interesting Moments Grid to refine his interactions. As the developers start to implement the first prototypes, Bill and his design team can try them out. When something doesn't act naturally -- they way they would expect it to -- a simple change to the grid is all that's required. The developers see the change, implement the revised behavior, and deliver a new iteration.
This makes the grid a living deliverable that keeps both the designers and developers on the same page. A simple, elegant design that simultaneously improves the team's communication and enhances the users' experiences.
How do you slow down time when designing your interactions? We'd love to hear your experiences. Share your ideas with us at the UIE Brain Sparks blog.
Read related articles: