Wednesday, November 18, 2009

Pleasing The Brain with Magical Interfaces

I just read an extremely interesting blog by David Sherwin called Data, Delight, and User Experience Design. David talks about the emotion and feeling necessary for magic tricks to actually evoke the feeling of magic. He discusses some websites that have this quality, such as Google's I'm Feeling Lucky, Wikipedia's Random Article, and Flickr's Interesting feature.

Richard Monson-Haefel has also written about Magic Interfaces on his blog, and even started a separate website promoting the idea of Magic as a metaphor for Natural User Interface design, although his approach is a little more literal with roots in magic from fantasy stories (incantations, runes, artifacts.)

I think Richard has a good idea at the high-level, but the Magic metaphor needs to be a little more concrete for developers and designers to implement it. David's idea of designing to evoke the emotion of Magic is a little easier to do than translating fantasy magical metaphors.

Here is my take on implementing a magical metaphor, building upon the ideas above.

Human brains are pattern matching machines. Once you get past the brainstem and low-level wetware regulating our heartbeat and breathing and reflexes, the majority of our brains are dedicated to pattern matching. We detect patterns and meta-patterns and correlate them in several layers just to have vision. That feeds into higher level pattern matching that helps us do things like walk and talk at the same time without tripping.

Even higher up in our consciousnesses we put together patterns and experience in order to predict what we think will happen in the future. That allows us to anticipate the future position of a spinning ball undergoing projectile motion in the influence of wind so that we can start swinging a bat at the precise time to make contact and hit it as far as we can. At least, the professional baseball players can do that, because they have the experience from practice.

The rest of us can use that brain circuitry to, among other things, anticipate the consequences of clicking a mouse and typing keys and touching screens in order to get computing devices to do what we want. We do this dozens of times a second or more. Just watch some eye tracking videos to see how quickly our eyes can move, each time evaluating what we see and deciding if we should take action.

Our brain cells get a little kick out of every pattern they match. That's their motivation. If you design an interface that is intuitive and the users can easily predict, then as they use it, their little pattern matchers will get lots of jolts of happy juice and the user will like using the application!

On the other hand, if the user predicts that something will happen and it doesn't, then those brains cells responsible will be held accountable. Actually, they'll just get rewired a little bit and learn, and the user will get annoyed by the lack of happy juice.

Let's bring back the magic here. How can we design an interface to maximize the user's enjoyment, specifically by matching as many patterns as possible? This is exactly what magicians do during their acts. David's article talks about this, but I want to approach it a little differently.

I want to borrow a phrase from the movie "The Prestige". Watch the trailer below from about 1:05 to 1:50.

Approximate quote from the actual movie:
Every great magic trick consists of three parts or acts. The first part is called "The Pledge." The magician shows you something ordinary: a deck of cards, a bird or a man. He shows you this object. Perhaps he asks you to inspect it to see if it is indeed real, unaltered, normal. But of course it probably isn't. The second act is called "The Turn." The magician takes the ordinary something and makes it do something extraordinary. Now you're looking for the secret, but you won't find it, because of course you're not really looking. You don't really want to know. You want to be fooled. But you wouldn't clap yet. Because making something disappear isn't enough; you have to bring it back. That's why every magic trick has a third act, the hardest part, the part we call "The Prestige."

Now the analogy isn't perfect, but here is how this fits in:
  1. The Pledge - This is where the context is set up. The brain establishes the expectation or prediction here. If the trick is making a coin disappear, then first you have to show the coin exists. If the pressing a button is supposed to make the interface do something cool, then there has to be a button with appropriate icon or text to set that expectation. "That button is labeled 'Push for Awesome' so it will probably do something awesome."

  2. The Turn - This is where the conflict or tension is established. For the magician, it is the moment after he made the coin disappear and the audience wonders if and how it will come back. For the computer user, it is the moment between deciding to perform an action and seeing the result. "I wonder if it will be awesome if I push the button?"

  3. The Prestige - This is where the tension is resolved. The coin returns and the prediction of the audience ("coins cannot vanish") is confirmed. The interface does something awesome and the user's brain is flooded with happy. "Awe-sooome."

The greater the tension is, the more the reward will be. This doesn't mean you should make the users wait before the interface responds. Rather, it means that the larger the conflict between the Pledge that a button will do as it says and any disbelief that it will work as advertised, the more pleased the user will be when he or she finds that it does work.

Over time, the disbelief and thus the magic will go away, but our brains will still get little rewards for predicting and being correct. Peek-a-boo follows this pattern and is a highly-pleasurable activity for babies and toddlers, but eventually the fun decreases. This is also true with the Magic trick. If your job was to watch a coin trick several times a day, five days a week (as often as you check your email perhaps), would you still be as amazed the 100th time as you were the 1st time? No, but there is still a little bit of tension inside the brain. "Will it still work?" After all, we still get pleasure out of re-watching good movies, even though we know the ending, and thus the resolution of the core plot conflicts.

We can try to keep things fresh in certain ways though, by keeping the pattern but varying the inputs. (For those who have seen The Prestige, the New Transported Man was the same general idea as the Original Transported Man, but used a different technique and flourish.) Google's "I'm Feeling Lucky" button does the same thing every time -- direct you to the first result -- but the replay value comes in the game of "Will Google find the best result for this query, too?"

So as you use your computer, think about what actions you enjoy doing the most and what the Pledge, Turn, and Prestige is for them. Figure out how you can apply that to your own interface designs.

Neuron image courtesy

Tuesday, November 3, 2009

Deconstructing: SilverPAC's Multi-Touch Website

[Update 11/9/2009 to reflect updates to the SilverPac site.]

SilverPAC just launched a multi-touch website using Silverlight 3.

There also a bit of write-up about the development of the site by Ciplex in Los Angelas, CA in the press release. They claim it is "The World's First Multi-Touch Interactive Website."

Below is a video for those who don't have multi-touch hardware:

Although when I first read about this, I had a healthy dose of skepticism, after watching the video and in particular trying out the website myself (on my new HP tx2z) I think this was pretty well implemented. I was particularly impressed because I know that the multi-touch APIs available in Silverlight 3 are pretty limited (particularly compared to WPF 4 Touch.) Here are a few notes on their implementation:
  • Introduction animation - When first loading the site, it shows an 8 or 10 second animation that demonstrates the gestures you can use to navigate the website. Interestingly, this intro animation is in Flash whereas the rest of the site is in Silverlight. This introduction is critical to orient the user and show how the multi-touch gestures will work. They are illustrated by using auras identical to those used in the application.
  • Limited gesture vocabulary - The site only uses four gestures: Tap (for selecting a "page"), Pan Up/Down (for text scrolling), Two-finger swipe (for changing "pages"), and Pinch in (for zooming out). I'm glad they only have a few gestures, and they all make sense. I have discussed limiting the multi-touch vocabulary, and Ciplex seems to have done that. The only thing I would have changed is adding the Pinch out gesture to allow zooming in, duplicating the behavior of tapping on a page. This provides symmetry and would be more intuitive. Update: Pinch out was added.
  • Auras - They implemented their own auras within Silverlight. This is important for users to see whether their touches are being recognized by the application. Not a full implementation of Microsoft Surface SP1's auras described in the Ripples research paper, but good anyway.
  • Page layout - The site consists of nine pages with simple free form navigation from one to another. Users can zoom to the large view, either through gestures or the mini-map icon in the bottom left, then select a new page, or use two-finger swipe to change pages. With a more complicated site and more pages, a more complicated navigation scheme, or multi-layer zoom, would be needed.
  • Pages - The pages on this website are more like cards of data than hyperlinked pages. There are no links internally, only to external sites.
  • Mini-map - When zoomed in, there is an subtle icon in the bottom left corner. It serves two purposes - remind the user where they are in the page layout, and act as a link back to the zoomed out view. This is important for users who navigate the page with a mouse.
There are a few things that could be improved. They are mostly implementation issues rather than design.
  • Add pinch out, as discussed above.
  • The auras often get stuck, as if one touch is still down. This prevents some of the gestures from working unless you reload the page. Seems like if a touch or gesture is done too quickly this occurs.
  • The page content and headers could be sized so the user could read them better from the large view. The interface zooms anyway, so it might as well make use of the space.
  • Some pages, such as the top left, have too much text and no indication of the subject of that text. Scroll down far enough and you'll find out the names of the CEO and others, but how would the the user know to look there? Also, the bottom center page is blank. Either put some content there or don't let the user navigate there. Update: The pages were updated to rearrange the text, and allow switching columns within a page.
  • Aura performance is laggy and has a slow frame rate. The animation of the page transitions and product has good performance, though. Update: Aura performance was improved and I haven't seen any more stuck auras.
  • Although the user can navigate the pages using just the mouse, they cannot do the equivalent of the two-finger swipe to change between zoomed-in pages. This may illustrate an advantage of touch, but for users with no touch hardware, it seems like an artificial constraint and switching back to the zoomed out view to switch every page is slow.
Overall, even though there could be a few improvements made , I think the SilverPAC Multi-Touch website is a fine example of a multi-touch web implementation. (Update: Many of my suggested improvements were implemented since my original review.) The bar of excellence will be higher in the future, of course, but this is a good start at this point in the Natural User Interface Revolution. [Thanks to Gene on NUI Group Community Forums for posting a link to this.]
[Thanks x2 to Gene for letting me know about the site updates.]