Wednesday, May 28, 2008

A common language for interaction design

Information Architecture, Interaction Design, Working better by Austin Govella

A common language for interaction design would improve the clarity and speed at which we communicate design.

0 Comments

Working on a way to get a group of people to annotate simple and complex web interactions in a similar/common way. There would seem to be two parts to this kind of Sisyphanic exercise.

1. The group would need to communicate using a similar format. The medium constrains the message so there would be fewer ways to be different. More of the same.
2. The group would need to communicate using a common vocabulary.

This is a quick sketch at a common vocabulary for talking about interaction design on the web. It assumes several pieces are required to talk about most interactions.

1. You have an object,
2. A user or system triggers something,
3. The system has a response,
4. That response has a target, and
5. Transitions usually make it better.

So, for each of those five steps, I’ve collected a common vocabulary.

Common triggers for web interfaces

A trigger happens when a user or system does something that is noticed by another user or system. Web interfaces have a collection of common triggers. 

• On mouseover (and/or on focus)
• On mouseout (and on blur)
• On (left) click
• After a time interval

Common triggers for form elements

• On focus
• On blur
• On submit
• On reset

Page level events (more rare)

• On page load
• On page unload (when we leave this page, but before we see the next one)

Special interaction events

• On resize
• On scroll
• On mousedown or mouseup
• On right click
• On double click

Interface responses

When a trigger is, uh… triggered, the interface really only has a few responses.

• Show something
• Hide something
• Change/update something
• Go somewhere else (change the page)

Response targets

When the interface responds, it does so via an object on the page, its target. We have several possible targets.

• An element (displays in the page)
• An overlay (displays over the page)
• A lightbox (displays over the page, modal)
• A popup (displays in a new browser window)
• An alert (alert display in browser, modal)

Transitions

If users need to know the interface has responded, it’s often important to highlight interface response. (Norman and Cooper have frameworks for when and what you should communicate to users.)

On the web, a common set of transitions has emerged.

• Fade in or fade out
• Slide in or slide out
• Enlarge (from something or nothing)
• Shrink (to something to nothing)
• Highlight
• Play sound
• Shake

It’s often good to combine transitions. For example, if an autosave is successful, you might fade in a highlighted confirmatin message. Similarly, 37 Signals popularized the "Yellow Fade" technique where a highlighted confirmation message appears before the highlight fades away.

Using the vocabulary

Use is pretty easy. Annotate as usual.

Let’s say you have a header. You would annotate interactions for each applicable trigger (much as you probably do already), but you make sure to use the above, approved list of words.

So, for our header, on mouseover change the header to a highlighted state. For our header (element), on mouseover (trigger) change (response) the header (response target) to a highlighted state.

So, there’s no rocket science here. The benefit would be everyone communicates the same way about the same things. Not tested. The next bit is about a common format.

Talk About "A common language for interaction design"

Register or Log In to comment