Last week I saw a BayCHI talk by Elaine Wherry of Meebo, in which she used the history of classical music as an analogy for the evolution of user interface and interaction design of web-based user interfaces. The parallels she established between the Baroque era and what we have experienced in the last decade of “Web 2.0″ interfaces are compelling.

Baroque music arose during the Renaissance as a reaction to the impoverished musical forms characteristic of the middle ages, an era dominated by monastic chants and songs of Troubadours. The Renaissance brought a revolution in music-making technology with the invention of a range of musical instruments. Unlike the sparse music that preceded it,  Baroque music is characterized by a profusion of notes that, while initially interesting, tend to overwhelm and can render the composer’s melody unrecognizable.

Similarly, Web 2.0 interfaces, enabled by the introduction of AJAX technology, made it possible to break out of the constraints of impoverished interaction characteristic of old-style web pages. This technology made possible a whole range of experimental interactions, but lack of design guidance characteristic of desktop applications made it difficult for users to make sense of this profusion of interfaces.

Wherry gave a fun talk, punctuated by recordings to emphasize her points. Her slides lack the auditory aspect, but make up for it with detail that was sometimes hard to catch in her rapid presentation style. The focal point in her talk is slide 37:

What would Haydn do?

She describes the role that Haydn played in giving structure to music, and suggests that we are now faced with a similar challenge in web-based interfaces. Her take is that Haydn postulated the following four rules to govern (effective) musical expression:

  1. To flout the rules, you must know the rules
  2. Minimize ornamentation to maximize effect
  3. Use design principles for internal iteration
  4. Prototype in your medium

As applied to interface design, this means you should understand the effect on the user of your interaction design. and consider whether departures from users’ expectations will produce a dramatic or confusing effect. It means that you must not only pay attention to user testing (for you certainly should test with users), but also you should not be enslaved by user testing because user testing won’t tell you how to innovate, just how to refine. Finally, while lo-fidelity prototyping is useful in early stages of idea testing, being able to put together high-fidelity prototypes efficiently enough to have a tight iterative design loop will result in better insights and more accurate understanding of the interaction you are trying to design.

While these lessons are known in the HCI literature, they bear repeating because in many cases they are hard to put into practice effectively. You must have experienced designers (to know the rules), you must understand users’ needs and  have considerable freedom to innovate, you must trust your own instincts as much as the data, and you must have flexible tools to help you experiment with new designs. This is a tall order for most organizations that are responsible for the conception and design of user interfaces.

It will be interesting to see if (in parallel to the evolution of western musical expression) web-based interface design evolves a more constrained but more effective vocabulary. The bottom-up nature of design and innovation on the web is a key strength of the medium, guaranteeing ongoing innovation. But it is also its Achilles’  Heel, mostly caused by a lack of a rigorous testing and evaluation feedback. Thus one enduring challenge is the lack of codified design specifications (such as Apple’s human interface design guidelines for the Macintosh or for the iPhone) that have traditionally been associated with coherent (and usable) designs.

Elaine WherryElaine Wherry

Comments are closed.