Upcoming Talk: Bringing Design to Life (Rosenfeld Future Practices Webinar) - Feb 26th

I am excited about a new online seminar that I will be giving Bringing Design to Life: What Every Designer Should Know about Interface Engineering. This is part of the Rosenfeld Future Practice Webinars series (a joint venture of Smart Experience and Rosenfeld Media).

For the last 25 years I have been solidly focused in the world of user interface creation. At times I have been solely focused on design and at other times on interface engineering. At other times I have held both responsibilities at once (e.g., leading a UX team while leading two interface engineering teams). Having spanned both design & engineering, I deeply understand the challenges is translating ideas into products. For this talk I decided to focus specifically on how web designers can work in the most efficient manner with their engineering counterparts. It is the "stuff" that most engineers wish their design colleagues knew.

This 60-minute webinar is initially available as a live class, and then is made available in a DRM-free recorded, edited format. By avoiding the travel required in attending a physical seminar or conference, you save money and reduce your impact on the environment. You are free to watch the webinar with colleagues in a conference room, making for an even better value. The cost is only $129.

Join me on Feb. 26th (18:00 GMT / 1pm EST / 10am PST) for Bringing Design to Life: What Every Designer Should Know about Interface Engineering.

(Previous webinars include Luke Wroblewski on Modern Web Form Design and Indi Young on Using Mental Models for Tactics and Strategy. Also check their schedule for a complete lineup of monthly webinars.)

Also, if your are interested in purchasing materials from Rosenfeld Media, please use my discount code when you visit the site (good for a 15% discount): SCOTTWBNR.

Photo credit: Auroville: Under Construction from premasagar's flickr stream, Creative Commons License.

Foo Lessons: Kamishibai

Back in the summer I had the opportunity to attend Foo Camp '06 at the O'Reilly offices in Sebastapol, CA. Foo Camp is a loosely organized gathering of folks that O'Reilly invites to flock together for a weekend of discussions, impromptu sessions, etc. Obviously a lot of interesting people (writer/producer of MacGyver series, engineering creator of the Osborne Computer, flickr folks, Jeff Bezos of Amazon fame, and so on...).

One of the interesting talks that I attended was on the Japanese Storycard Theater. Dave Battino billed it as PowerPoint for People.



It's based on traditional Japanese picture-card dramas called kamishibai (paper theater).

Today's kamishibai has evolved from a form of street-storytelling which was popular throughout Japan from the 1920's into the 1950's.

The kamishibai storyteller was also a candy seller. Riding a bicycle equipped with a small stage for showing the story cards, he would enter a village or neighborhood, dismount and loudly strike together two wooden clappers or allow a lucky child to do so. The sound was a signal for children to run from their homes and gather around him for story time. Those who bought candy got to stand nearest to the stage. Then, in a dramatic manner, he would start to tell 2-3 kamishibai episodes. He would not tell the whole story! The stories were told as continuing serials, that is, he would always stop at an exciting moment, leaving the children impatient for his next visit.

From: http://www.kamishibai.com/background.htm

The idea is really simple. A story is a simple stack of large illustrated story cards. The stack is presented so that the front card facing the audience is the current place in the story. On the back of the last card of the deck is the dialog for the illustration on the front card.

Really simple idea. Instead of having to twist your neck to read the text, you simply glance down at the dialog and a miniture version of the illustration. The trick is placing the dialog at the correct location in the deck instead of directly on the back of the card it goes with.

Why is this important?

The Power of Engagement
It allows you the storyteller to stay engaged with the user. Making eyes with the audience is a powerful principle. Think of how many times you have seen a presentation (I have done it many times myself) where the presenter is constantly twisting their neck or turning their back to the audience to see the presentation. It's easy to lose interest while their back is turned. Watching kids respond to a kamishibai presentation versus a typical library book reading lets you see the benefit of this approach. Kamishibai keeps the kids attention, may book readings lose the attention as the reader cranes their neck to read the story. With kamishibai, the storyteller can concentrate on the drama-- the story instead of the technology.

In the world of conference speaking some of the problem is in the very way that conference presentation technology is arranged. Singers have long employed speaker technology arranged in front of them (monitors) that allow the singer to hear themselves and therefore perform more confidently. This would be a nice addition for presentations. Projecting the same material along the back of the auditorium would allow presenters to always face their audience and receive the assurance that the right material is being displayed, timing their talk with the material (this is done in some venues, but rare at conferences.)

The Beauty of Simplicity
Now I use a lot of technology in my presentations. I employ embedded movies and animation. I like this. And based on feedback, others have enjoyed this approach. But there is an argument to be made for simple presentations. Dick Hardt of Sxip Identity has a wonderfully simple presentation called Who's the Dick on My Site. It just employs single words or phrases that are perfectly timed with his talk. During the talk, Dick does not look at his presentation. He simply talks and the presentation reinforces his story.

I work with Karon Weber a designer at Yahoo! (formerly of Pixar). One of the techniques that Karon has employed in presenting her designs at Yahoo! is to use large (and I mean large, at least 4'x6') poster boards each telling part of the story. Instead of wireframes locked inside a computer, they are set free in this large format. In our current war room for a product we are working on it is fully decorated with these large poster boards. It of course does not dispense with the electronic (they are the source for the poster boards), but it makes the presentation of these ideas completely accessible to anyone who walks into the room (or hallway).

The beauty of this approach is that it is highly practical and completely simple. It is focused on telling a story. It is in the spirit of Kamishibai.

The Power of Good Transitions
When Dave Battino told us a story in the Foo class, I really enjoyed how he transitioned between cards in the story. If there was a quick sequence of action, he would rapidly switch the card. If the hero was in trouble and he wanted to build suspense he would slowly...drag...change...cards... Sometimes the slide was left to right, sometimes it was over the top. But it was effective. How many presenters have gotten enamoured with transitions between their slides and pulled out all of the stops. "Hey, it's in Powerpoint, why should I use the fizzling, spiraling, flipping effect??" Yet, with just a quick flip or a slow drag, the story was enhanced in the kamishibai method--not the emphasis. In my talks on cinematic effects I have talked a lot about the temptation to over emphasize these effects. Making transitions too slow, too long, too vivid, etc. I have often advocated the "cut in half" rule I learned from a member of the Motion Graphics community...

Take the effect, transition, luminence change you have enstated and cut the effect in half.

Transitions are for enhanced communication and engagement... Not for the sake of the effect alone.

Happy Story Telling!

Question: How has your background influenced you as a web designer?

As you probably know (if you read much of my blog) I tend to focus narrowly on the world of user experience and user interface engineering. My passion is building great user experiences with a special emphasis on the web.

I was having a hallway conversation at UI11 with Joshua Porter. Lots of fascinating discussion (during which my voice finally played itself down to a rasp). But one of the things that I took away was a renewed interest in reading outside my field for inspiration for my field. You know learning from other crafts to inspire my craft. (In a separate article I will publish my reading list.)

I had started thinking along this line earlier in the year. In fact, Brian Kromrey (Yahoo!) and I were tentatively planning to convene a panel of Yahoo! interaction designers carefully chosen to represent very different design backgrounds. Backgrounds in design from gaming, industrial, motion graphics, theatre, software, comics, and so on. We had tentatively called it, "A Different Box of Tools." Since most of us did not start out as interaction designers/information architects/web designers our craft is certainly enriched by this varied tapestry.

How has your former design training influenced:

• The way you solve problems?
• The way you document solutions?
• The way you communicate design?

I'll go first.

Solving Design Problems
My strong background in software architecture led to a passion for clear vocabulary and a deep appreciation in the powerful nature of patterns. The famous Design Patterns book for software was formative in the way I thought about solving problems. No surprise that patterns make up a lot of the way I approach design today.

My exposure to the agile community (eXtreme Programming in particular) reinforced the principles of simplicity, iterative problem solving, and pairwise-thinking. Not surprising that I value doing the simple thing first, communicating via the design in the simplest manner to start with and adding the effects as needed to tune the interface. Iterative problem solving is key to good interaction design. Having the user and other stakeholders early in the loop and rapidly iterating to a solution is critical. Pairwise programming (although I confess the religious adherants of this practice almost made me loathe this approach) can be seen as a reason that I latched onto Alan Coopers "designing in pairs" approach so easily.

Documenting Solutions & Communicating Design
Agile software approaches taught me the lesson to only document what others will read :-) Another way of stating this is who are the users of your documentation? That will determine what and how you document. This has influenced me in trying to keep documentation simple or create tools that make it feel more lightweight. My engineering background also taught me what developers need in documentation, so my background has helped me create solutions that can bridge the gap between design and development.

That's enough for me. Now it's your turn!

Share Your Lessons
So why not share? How about stepping up and telling me how your passion for art or your training as a clown or your training as an architect has crafted your craft. We could all learn an amazing amount from each other.

The Best Way to Communicate Patterns

Pleased ignore if you already syndicate the yuiblog.com.

But for those who don't, check out the five-part series by Jenifer Tidwell, Luke Wroblewski, Martijn van Welie, James Reffell and myself as we answer the question, "What is the best way to communicate design patterns?"

Mind Hacking Visual Transitions

When I attended Kathy Sierra's workshop on Creating Passionate Users, she mentioned the book Mind Hacks. I quickly added it to my Amazon wish list. However the next day at O'Reilly's booth they were giving away books. I could only choose one-- guess what they had-- that's right, Mind Hacks.

Mind Hacks is all about short experiments or hacks you can do to discover how your brain is really working. There are 100 hacks. For example, hack #59 discusses how we actually hear with our eyes (you can check out the McGurk Effect for yourself). Or try #65 which explains Why Can't You Tickle Yourself? And goes on to describe how to build a self-tickling machine.

But the hack that really got my attention (no pun intended) was hack #37 Grab Attention.

Sudden movement or light can grab your attention, thanks to a second region for visual processing.

It turns out that besides our normal visual processing region of the brain (you are using the occipital lobe right now while reading this blog) there is a second region that deals with attention capture.

We experience it everyday. While talking with a friend at a park someone throws a frisbee to another person in the background. Without trying you notice this change of motion even though you are not looking directly at it. You can thank the superior colliculus for this little attention interruption.

As the authors describe it this region of the brain is not very sophisticated. But it does a good job of telling you to pay attention because something may be coming at you. You aren't sure what it is but you had better pay attention to it.

One of the next set of patterns I am working on getting out the door at Yahoo! covers the idea of Transitions (also known as animated effects or cinematic effects.) The connection between hack #37 and its application to transitions was immediately obvious. This is one of the reasons that moving something on the screen or causing it to fade or rapidly show up can get the attention of the user so readily.

So this fed into my thinking, "how do I use transitions for good and not for evil?" How do I use transitions to communicate the correct intention to the superior colliculus? As Kathy Sierra likes to say, "Learn to speak to the BRAIN, not to the MIND."

So a few days passed after reading this. I was starting to write up the rationale for the parent Transition pattern using the research cited in the Mind Hacks book. While doing some more research I stumbled across an article on 24ways that discussed the transition effects in the Scriptaculous library. At the beginning of his article, Michael Heilemann writes:

...let me just take a moment to explain how I came to see smooth transitions as something more than smoke and mirror-like effects included for with little more motive than to dazzle and make parents go ‘uuh, snazzy’.

Earlier this year, I had the good fortune of meeting the kind, gentle and quite knowledgable Matt Webb at a conference here in Copenhagen where we were both speaking (though I will be the first to admit my little talk on Open Source Design was vastly inferior to Matt’s talk). Matt held a talk called Fixing Broken Windows (based on the Broken Windows theory), which really made an impression on me, and which I have since then referred back to several times.

You can listen to it yourself, as it’s available from Archive.org. Though since Matt’s session uses many visual examples, you’ll have to rely on your imagination for some of the examples he runs through during it. Also, I think it looses audio for a few seconds every once in a while.

Anyway, one of the things Matt talked a lot about, was how our eyes are wired to react to movement. The world doesn’t flickr. It doesn’t disappear or suddenly change and force us to look for the change. Things move smoothly in the real world. They do not pop up.

Turns out that Matt Webb is one of the authors (along with Tom Stafford) of Mind Hacks (duh!) Well that made sense. I listened to his talk and got very excited. I had been writing and talking about how to use and not abuse these effects on the web. Matt's talk and his writing in the Hack book (and other articles online) finally gave me solid grounding for those propositions.

A couple of examples stand out from the Broken Windows talk.

Dodging the Apple Widgets
Matt pointed out the odd effect used to dismiss the Apple Mac OS X Widgets. Instead of going away from you when dismissed, instead they fly out at you and fade out. The effect is as if the widgets are coming straight at you (like a star field) and whiz right by your head. Matt's point is that the action is "put the widgets away" but the effect communicates "look out their are flying widgets that are about to hit me." The action is for them to diminish in importance. However the superior colliculus is screaming "incoming-incoming-look out!".

What Just Happened?

The second example is the Flickr Daily Zeitgeist a blog sidebar plugin (Matt discusses this in detail here). When new photos show up they fade slowly in place overlaying four photos within the tile of photos. Not bad. You may or may not notice the photo showing up but that's ok. Its very secondary. However when it goes away it rapidly scales down revealing the images underneath while replacing one of the four images. The sudden rapid movement once again gets the superior colliculus to say "What the..." You look and by the time you glance you are not really sure what happened.

How the Real World Works
Matt also makes the same observation that I have discussed before. That real world objects don't just pop in and pop out, appearing and disappearing suddenly. We usually see them go away or go somewhere in particular. By creating an online space that never behaves this way it makes for a more brain-intensive experience in trying to determine "what just happened."

A Few Transitions
Just so we are all on the same page, here are some of the transitions that are being reviewed for the Yahoo! Design Pattern Library:

• Brighten. Raise the luminosity or opacity of an object. Used to call attention to an area. The opposite of dim.
  
• Dim. Lower luminosity or opacity of an object.
  
• Expand. Animate an object growing.
  
• Collapse. Animate an object shrinking.
  
• Slide. Show an object move out from another object while being attached to that object.
  
• Self-Healing. Once an object is removed from an area a hole is left. Once the object is placed elsewhere the hole seals up, effectively healing itself.
  
• Animate. Simply animating position.
  
• Fade In. Cause an object to appear by fading in the object's opacity.
  
• Fade Out. Cause an object to disappear by fading out the object's opacity. Often the Self-Healing transition is used to close the hole left by the object.
  
• Spotlight. Usually used to momentarily highlight a region that has changed. The highlight is often combined with a Fade Out to create a One-Second Spotlight pattern.
  

What Transitions Communicate
To me the key thing that any interface must do is communicate clearly and effectively.

Transitional effects should communicate the state of the interface or the actions that have just taken place.

• If an object fades away we know it changed state from visible to invisible even if we are not staring directly at the object.
• If an object fades into view then we know the object has arrived. It was not there but now is here.
• If an object fades rapidly it is seen as more important. If it fades slowly its importance is lower.
• If an object is coming at us (getting larger and appearing to go past us) then we think of it as something that is important (and dangerous).
• If an object zooms down in size rapidly and disappears it will capture the user's attention immediately. However if the object was not in the user's immediate focus (user was not directly manipulating the object) they will glance to see the change but may not even be able to tell what object went away.

Purpose of Transitions
First, they are primarily for communication. Keep in mind that transitions reinforce communication. Having said that, it is important that the goal of communication be kept in mind regarding any transition effects.

Second they can be used for engagement.
Interacting with an area on the screen that responds by slightly growing or seeing an accordion pane "snap" into place creates a slightly richer and compelling experience. The interface seems more alive. Of course going slightly overboard can be the equivalent of blink for Web 2.0 (blink 2.0?)

One can imagine situations such as in games where engagement can take a more important role. However, in most web sites, communication is the most important purpose for transitions with engagement being second.

Guidelines for Transition Effects
From the discussion above we can extract some general principles for transitional effects.

1) The more rapid the change the more important the event.
2) Rapid movement is seen as more important than rapid color change.
3) Movement toward the user is seen as more important than movement away from the user.
4) Very slow change can be processed without disrupting the user's attention.
5) Movement can be used to communicate where an object's new home is. By seeing the object moving from one place to another we understand where it went and therefore will be able to locate the object in the future.
6) Transitions should normally be reflexive. If an object moved and collapsed to a new spot, you should be able to open it and see it open up with the reverse transition. If you delete an object and it fades, then if you create an object it should fade into place. This creates a concept of symmetry of action.

I would love to have feedback on what you think are the proper usages for these kinds of transitions.

Technorati Tags: ajax, design, patterns, design patterns, ria, user+experience, interaction design, scriptaculous, ypatterns, billscott

All I Really Need to Know I Learned from a 128K Mac

On Monday I had the wonderful opportunity to speak at the Real World Ajax Conference in NYC. During my talk on Designing for Ajax, I mentioned how I got my start in the world of user interface and user experience -- writing the Macintosh game GATO in 1985.

Several attendees came up afterward and told me that they had played and enjoyed GATO. That's always fun to find someone who has enjoyed something you created.

One of those that spoke with me was Blake Patterson. I didn't recognize the name but after an email followup I connected him with one of his sites that I have frequented, ipodhacks.com. I also found out he runs ByteCellar a site that covers the history of early computing. Blake requested that I give some of the history behind creating the game and the experiences of early Macintosh development. I pointed him to some comments I posted on Andy Hertzfeld's Folklore site.

Blake wrote up a nice summary of those comments. You can read his article here.

After reading his article it really came home to me how defining the event of writing that game was in my life. Like the famous book, All I Need to Know I Learned in Kindergarten; I can say that really All I Need to Know I Learned from a 128K Mac. So what did that Mac teach me?

• Passion. I fell in love with computing on that puny Mac. I caught the passion of folks like Guy Kawasaki and Steve Jobs for this insanely great computer. Heck that phrase "insanely great" I continue to use to this day.
• It's Possible. Look when we started development we were green. We did not know the "C" language. We made horrible mistakes. It looked like we would never succeed. We had unrealistic deadlines. But one by one we solved our problems. And we did it.
• Event-Driven programming. The Mac introduced me to the world of event-oriented development. This underpins everything today. It is the re-introduction of the possiblity of finer-grained events via Ajax that makes it possible to build cool apps on the web.
• Object-Oriented programming & design. While C was not object oriented, the Mac had an object-based feel to it. It got me into reading the book on SmallTalk, the purest Object-Oriented language.
• Model-View-Controller. The powerful pattern that taught me the concept of separation of concerns, pub-sub concepts and the power of abstraction.
• User-Centered Design. The original PC GATO was divided into many screens. When we sat down to do our brainstorming on how to write a submarine simulation game we thought a lot about how submarine crews need access to their controls/panels. We interviewed a GATO class captain from WWII. That drove us to design a display that never lost the most essential controls. You could flip between a map and other less important controls but never lost the gauges, controls and dials.
• The Importance of Understanding the Deep Magic. What I mean is after GATO was released we went under the hood. We disassembled the ROM code. We documented it. We reverse engineered everything we could. We learned exactly how memory management, regions, event management and so on worked from the bottom up. This need to demystify the complex was first learned on my Mac.
• Where to Optimize. Learning from the master, Bill Atkinson. His drive to have a solid design approach and then optimize in the 5% of the code was a lesson I took forward into many projects in the future.
• Use the Tools. There weren't many tools available on the Mac. But we put MacPaint, MacDraw to use to create backdrops and vector shape files to create the graphical aspects of GATO. I have since always tried to use tools in novel ways to get my work done (see my VISIO toolkit as one example).
• Being Pixel Perfect. Design is made up of nuances. Apple always has gotten this. I fussed over every pixel in drawing the GATO screens (although I will admit the explosion routine was horendous -- it was created the night before our first public demonstration.) To this day it drives me nutty to see something one or two pixels off.
• Minimalism. Heck we only had black and white. It forced you to think about designs without having tons of colors and shading, etc.
• Principles of Interactive Design. Directness, Immediate Feedback, Modeless Design, and so on. Writing one of the first complex games utilizing Windows, Menus, Icons and Pointers (WIMP) was an exciting playground to learn within. We had the Mac & Lisa to thank for inspiration.
• Pay Attention to Real World Constraints. Hey it was a 128K Mac. Its one thing to design for the sky, its another to design for an extremely memory constrained system.
  

That's the list of things that immediately come to mind. I am sure there are others. For folks who did not live through the Mac & Lisa revolution I hope this little walk down nostalgia lane can capture the magic I felt when working on GATO and my lowly 128K Macintosh.

I should add that the other two developers/designers were James Rhodes and Sean Hill. James was (and I am sure still is) one of the finest developers I have ever worked with. Sean was a master at marketing and creativity. Sean later led the game unit at Sphere (formerly Spectrum Holobyte). As I understood it he was lead for the highly successful Falcon game.

Nine Tips for Designing Rich Internet Applications

Recently I was asked to provide input into a presentation. The question was asked, if you were going to provide some quick basic guidelines for designing rich applications what would they be.

Here were the nine thoughts as they originally came to my head.

1) Make it directly interactive
Instead of page to page interactions think direct interaction. Use in context editing as much as possible. Use drag and drop only where it makes sense. Barring a selection model, put tools as close to the objects being edited as possible. Cooper states it as "Where there is output, let there be input."

2) Make it inviting
Use hover to invite users to the next level of interaction. If the interface responds well to light events (like hover) it can be used to entice the user to interact.

3) Use lightweight, in-context popups instead of page transitions where possible
Although they will eventually get over-used, lightweight popups can be your friend. Think of them as annexed areas for your page.

4) Use real-estate creatively
As mentioned popups help. But slide outs have long been allies in desktop tools, they can be an aid in the world of the web.

5) Cross page boundaries reluctantly
Think of a page switch as a context boundary that the user may or may not want to cross. Think of it as a place that many of your users will lose interest and no longer follow you.

6) Create a light footprint
Make it extremely easy to interact. Rating movies or news with just a click on a star with no-refresh is awesome. Checking hostnames without leaving the page is an excellent way to keep a user engaged. Shopping by clicks that only add to a container on the page (instead of going to a new page) are like impulse aisles in the grocery store.

7) Think of your interactions as storyboards
As the designer you are the director. Think about the event states as acts in a play and your interface elements as actors. Get them all moving towards telling your story. Putting the frames down on a storyboard is a great way to rehearse your script. Think of the interesting moments as opportunities for engagement.

8) Communicate transitions
Keeping the user informed during lightweight operations (that don't leave the page) with spinning wheels, busy or progress indicators keep the user engaged with a living page.

9) Think in objects
Instead of thinking about content and pages, think about Rich Internet Objects. The travel log in Yahoo!'s Trip Planner is a good example. Once created it can be searched for or shared. This will help you create more interactive applications and make the user's work recognizable and sharable.

These are not exhaustive. Even as I go to publish this I can think of other tips to include... but I will resist adding to the list. Perhaps you have some tips/principles that have helped you solve design challenges?

Designing and Building With Ajax

In December, Adaptive Path started a new series of conferences specifically addressing how to design and engineer rich Internet applications with Ajax. At that conference Ben & Dion (ajaxian.com) did a wonderful job of presenting the world of Ajax from the technical perspective.

I am excited to announce that I will be following in their footsteps and will be presenting along with Jesse James Garrett, Dan Saffer and Ryan Freitas at the Designing and Building with Ajax conference in LA on January 26th and in Miami on February 8th.

Based on feedback from the first conference we are revamping some of that curriculum and I am very excited about what we will be presenting.

So who should attend? Well we are desiging the material for both designers and web developers. If you are solely focused on design there will be lots of great ideas and tools presented that will enrich your work. If your bag is development, I aim to whet your whistle with some technical goodies as well as attempt to de-mystify the world of Ajax and DHMTL. And if you wear both hats-- well you will have a double-treat.

Why should you attend? Well, I think one really unique aspect of this conference is that instead of hearing 5 or 6 different speakers talking about individual topics, we are weaving a story through the day that is meant to build a mental model in your head to help you take a problem from conceptualization to design to implementation. The other unique aspect is presenting design and development in a wholistic manner. This is the context in which problems must be solved. This is also a great way to really understand the technology-- in light of our user's goals and needs.

Oh and one more thing. At the conference in LA, there will be some exciting news announced!

Would love to see you there!

Interesting, Seducible, Teachable, Engaging Moments

James Govenor pointed out a connection between my blog about Interesting Moments and Kathy Sierra's blog on Is it Interesting? (see also her discussion of the tie-in). Her angle is about engagement and delight.

Also, Joshua Porter from User Interface Engineering pointed me to an article by Jared Spool from back in 2002 on The Search for Seducible Moments.

As a parent I learned a long time ago there are times when a person is especially receptive to learning. These are called Teachable Moments. If one is prepared for those times, more can be accomplished in a few minutes that a lifetime of nagging would ever accomplish.

Putting these thoughts together, we should look for the interesting moments of interaction that open the door for us to seduce and engage our audience.

I have written about some of these moments in general. Like the thought of providing an invitation to the user through lightweight events (like hover). Getting users to review a movie by making the interaction with the movie rating control fun and engaging is one example.

I am curious, what sites, products or features have you found engaging-- or even seducing?

Distracting or Narrowing: Looking a Little More At Live Search

Ajax opened the door to immediate actions. One of the first types of problems that immediate action was applied to was in the area of search. Here are a few examples.

Google Suggest
Google Suggest was an early demonstration of the concept of Live Search. As the user types in the Google search box, the top search terms that match the user's input are shown in a drop down. If I am looking for 'Tom Cruise' only 5 characters are required to match this search term ('tom c').



I have never used Google Suggests for anything more than a demonstration of how live search works. I rarely need help in finding search terms based on four or five characters I have typed. Don't get me wrong, I think it is wonderful code, snappy response and perhaps has some purpose. I just have never found it personally useful. I mean if I am going to look up Tom Cruise, I perhaps might find it useful that it completes it for me and spells it correctly. But I think I know how to spell Tom's name.

Here are a few thoughts I have on this.

• If I am typing a term I probably already know the term I am typing
• The drop down can be annoying as it distracts me from typing
• It is really only useful for common searches. Since I find myself typing fairly qualified search terms; and there the suggestions start to trail off rapidly (at the end of the long tail)
• Once I find matching terms I just get a second pile of results. So in essence I have searched twice.
  
• The usefulness seems to be if I just want to see what is hot that starts with a few characters ;-)

I am just not sure how often I am searching for search terms rather than search results. Did it really help me narrow on results or just distract me along the way. (Hey sometimes distraction is intended for a purpose-- don't see its value here.)

If you have found Google Suggests useful please let me know. I am sure I am missing something. I would love to understand common use cases in which this is the case.

Yahoo! Instant Search
Yahoo!'s Instant Search takes a different twist on this. A balloon popup shows up with a single best match (based on Yahoo! Shortcuts). Kind of like a 'google suggests' for 'feeling lucky' only your lucky day is on Yahoo!

Typing 'tom cruise' yields the following:



Ok, the difference here is a candidate result is shown based on what I have typed. But here are the caveats.

• I have to type fairly specific, complete search terms. 'tom c' does not cut it. 'tom cruise' does. And do I really want the imdb database result for Tom? Interestingly, the Y! Shortcut is his fan page, which is what I was looking for in this case.
• The balloon can be distracting since I am personally conditioned to multiple results to look at. Giving me just one seems to make me think harder about whether this is the right place to go. I tend to compare results before picking a term to drill into.
• With the balloon in place, hitting enter just takes me to the results. Which seems reasonable but there is amiguity about where I am going when I hit Enter. Ctrl+Enter is supposed to go to the link in the balloon. But on the Mac with Firefox it does not seem to work.

I think the instant search is a slightly better idea than showing search terms that match the characters I type. Perhaps if Google Suggests showed synonymous search terms around what I am trying to search for (hard problem) it might be more useful.

It is interesting that the instant search provides a nice interface for those with screen readers. The popup triggers visibility and is read by the reader. Those without sight can know the best result found instantly. Nice side effect.

Now I am on the fence overall about its narrowing capability vs. the distraction it causes me. For popular items it seems to have a 50/50 chance finding me exactly what I want. However, I tend to be someone who is searching for more obscure items so to me it is distracting (though cool!) The fact that it narrows to 1 item causes it to have this sharp distinction between distraction vs. narrowing.

Do you like or not? If I understand correctly, it did well in user tests. What say ye?

Kayak Auto Complete
Kayak.com is a good example of live auto complete. Say the user is wanting to fly into New York city. They seem to remember that the airport they want is called LaGuardia (not sure how to spell it or what the airport code is). When I type 'New Y' I get the following results:



Ok, this is nice. I hate remembering the airport code. And I hate having to go to another page to find out that the site could not figure out what I meant. Jakob Nielsen states as one of his ten usability principles, Error Prevention. Providing the feedback instantaneously to cue me to what the system thinks is great. Saves me time and makes me feel like I am narrowing in on the right thing. This probably ties in with Jared Spool's research on The Confidence Game which shows that users are happy to click and click as long as they feel confident they are reaching their goal. Here I have the best of both worlds. Raise my confidence and do it with the minimal effort!

Hey Travelocity, FareChase, Orbitz, Hotwire, Expedia-- this is good stuff! Get this feature in your sites!

Without a question this helped me narrow to my result and did not distract me.

Of course I have compared apples and oranges. Both Google & Yahoo are dealing with an enormous body of information that it is trying to give you instantaneous feedback on during your typing. Much to infer. Kayak has an extremely limited (though hard to remember) set of data. Perfect for an instantaneous narrowing opportunity.

Yahoo! Mail & Why it Dumped LiveSearch
The new Yahoo! Mail Beta (still in limited release--and no I can't get you in the beta! :-) has a nice search box for finding content in your mail. It works extremely well. When you search for some content you thought came into your mail messages, the results show snippets of the conversations with the matched text highlighted.





Now you will notice that the search box has a little "Go" button beside it (and when activated, the an inline progress indicator shows). So how can I call this live search? Well it really isn't. However, they started with a live search in the Alpha version. The user would type a few characters and then the search would trigger. However, when the product went beta they went with a more traditional "submit" model. In other words instead of key events (or losing focus) implicitly triggering a search, the user has to now hit the "Go" button to get a search initiated. Why the change?

The primary reason was performance. Supporting the scale of users within the Yahoo! Mail network would be an enormous hit on servers. However, I think there is also something to be learned from this on the user experience side.

Now this is not scientific. It is my observation. But when confronted with a live search box that will return results (not suggestions) I immediately expect a button to trigger it. So at first I am a little unsure. Ok, that can be worked around by learning the interface. But next as I start to type a string, say "liberty mutual", it would start matching 'liber' finding things about liberals, liberality, liberty and so on. Now it starts changing as I continue to type. I get through the first word 'liberty' and now I find mail that discusses liberty in the U.S. and elsewhere as well as finding an email from my insurance company. Finally I type the whole thing in and get what I am looking for.

Now here is the point. How helpful was the constant feedback loop?

Did the feedback help me narrow to the message I am looking for or did it distract me during the task of entering what the term I knew I was going to type?

I vote that it was distracting.

I feel like I am in a race with the instantaneous search engine to get my term in before it starts returning the wrong results :-(

Thankfully it was replaced by this more traditional (yet Ajax-based) solution.

Amazon Zuggests
Using the Amazon API, Francis Shanahan created a way (Amazon Zuggests) to search amazon using the similar approach of Google Suggests and Yahoo! Instant Search.



This is really nice since it shows the results to my search terms as I type. Since the results usually have cover thumbnails and some text, it is easy to use it to explore to find books on a topic without ever leaving the page.

But does it really help me narrow quickly? Well, yes & no. Since it seems to not try to search too fast (on my pausing to type) I don't get into the race I felt like in the early Y! Mail Alpha. I can type a word, say "football." What I get back is a bunch of books on football for NFL and college. What I really want is college football. So I continue typing, adding the word "college". Now I get a bunch of college football results.

By not narrowing too quickly (to one result as with Y! Instant Search) and not trying to return results to fast (like Y! Mail Alpha did), the feedback loop is nice and allows me to refine by typing keywords.

Summary or What I Think I Have Learned So Far

To kind of sum of the lessons I think I see here. Live search is useful when

• The results are direct results-- not indirect results (as is the case with Google Suggests)
• The results are narrowing and not diverging (as in the case of showing more search terms in Google Suggests)
  
• The results are narrowing and not distracting (as was the case with Y! Mail Alpha, Google Suggests and potentially Y! Instant Search)
  

There are other ways to refine search. Nice examples on the Yahoo! site include the new Yahoo! Shopping and Yahoo! Travel which allow you to select & unselect filters on the left and see the results on the right in real time. One of the early examples of this was on the kayak.com site in refining flight searches.

So I am interested in feedback. What other general rules am I thinking of? What other examples come to mind? What do you like or hate about live search examples?

Feedback appreciated.

Storyboarding Interesting Moments

In a previous post, I discussed the idea of an Interaction Matrix. I described its purpose as documenting the event states that occur within drag and drop, inline editing and other types of interactions.

However, the term event states is a rather dry and sterile way to think about this really important concept. In fact the term comes from the programming world (which I lived happily in for many years.)

Recently, I was at a talk where Nate Koechley presented about the new vocabulary of user experience in the world of Rich Internet Applications. He used the term Interesting Moments (which was coined by Eric Miraglia) to describe the event states within an interaction that are points of user engagement or interest.

I really like that term. Wish I had thought of it first ;-)

Thinking of storyboarding interesting moments within an application, an interaction, or a widget simplifies our thinking.

It actually turns event states inside out and focuses them instead on the user. It asks the question, "What is interesting to our user?" and "What is needed to engage them (invitations) and aid them (feedback) through our story?"

Nate also pointed out that designers have the role of director. As such we have a cast of characters (our interface elements) and the timeline (interesting moments) on which to play out our interface.

Let me know what you think...

Tags: storyboarding interactiondesign prototyping article

Y! Trip Planner & Web 2.0 Content Objects

A couple of weeks back, Yahoo! announced Trip Planner

If you haven't had a chance to use it, I strongly encourage you to get your hands on it. In a nutshell, you can plan day trips, weekend trips, vacations into a trip plan. You can build the trip plan collaboratively with a group of fellow travelers or if you are a control-freak, all by yourself ;-)

At a later time I may blog about the details of the interface. Others have gone into lots of detail. And the team has lots of really cool features planned. On top of that, the team is full of talented folks and they are jazzed about this product. I am too.

Trip Planner is a good example of how an older idea can be transformed as it moves to become a Web 2.0 tool.

I used to use Microsoft Trip Planner. However it was limited since the maps and travel guide information were based on a snapshot on my CD. I loved it but it was severely limited in what it could give me as well as rapidly growing out of date.

There are a lot of things I love about this product:

• Collaborate on trip planning
• Share trips publicly
• Pulls trip planning into a single location
  
• Can find other's trips
• Uses the ever expanding Y! Maps products (map view)
• Has enormous tie in potential to other Y! products (watch for upcoming features!)
• I just love travel. Hey I live in the Bay Area. Lots of places to explore!
  

Web 2.0 Content Objects
But I think what has really excited me about this product is how it illustrates the power of Web 2.0 Content Objects.

In Microsoft Trip Planner the trip plan was a file on my disk. I could send the file to a friend and if they had the same application they could access it.

But think of the power of the web as a platform for these Web 2.0 style files. I can create trip planning content, share it publicly, and allow others (of my choosing) to collaborate with me on it. And once good trip plans surface over time, there will be less and less need for me to create trip plans from scratch.

This is what del.icio.us (and later furl.net and myweb2.yahoo.com) did for bookmarks. Shareable and findable.

Microformats
microformats.org is an attempt at defining the underlying data format for sharing user generated content. I don't want to discuss the merits of whether it should be in HTML or XML format. I just find the idea of movie reviews, restaurant reviews, trip plans, news clips, and a host of other content being in a format that is shareable, bloggable, findable to be really exciting.

Challenges for User Experience
So that leaves several challenges for us in the User Experience world. Here are just a couple of issues.

• Discovering Content Objects. Progressive disclosure (giving the user just the amount of features they need at the beginning and growing with the user) will help. Finding other trip plans while just searching around travel related items lead the user to explore.
  
• Getting folks to share. We all have suspicions about sharing information on the web. Do I want people to know where I travel, what I like to do? To some of us it is not an issue. To others that is terrifying. How do we create assurances (and more importantly we had better do the right thing with their data!) that there can be some anonymity? Trip Planner allows you to choose to share or not. But perhaps there should be a way to share anonymously. Have Trip Planner only post the outline of the trip and no user generated comments (only from other sources).
• Understanding collaboration. At Y! we struggle with who your community is. Is it Y!360, address contacts, IM buddies, flickr friends and family? And do user's really understand how they would work with other people (or how many will do this?)
• Avoiding feature bloat. We are building full-scale applications. Yet most user's engage us ligthtly. How do you make feature rich, discoverable applications? Providing "feature invitations" unobtrusively at the moment they need it.
• Getting users to understand how other tools might work together to solve their problem. Trip Planner uses Y! Local, Y! Maps, Y! Travel, Y! Search, Y! Travel Guides. It will use more properties in the future. How do you take a slice like trip planning across all of these products? Obviously you have to treat the other properties like services and build a complete application out of this slice. That leads to understanding how to present robust applications (without undue clutter, etc.) as a web application.

I'm sure there are other issues. As well as other solutions than those I briefly touched on above.

What do you think the challenges are for these types of applications? For these types of shareable content objects? Other examples you have seen?

The Blurry Line
And, one more thing. I notice that Microsoft has Streets & Trips 2006. Looks to be very full featured. It seems to pull its content from the web. This raises a number of questions about what is the right approach. Do I build a product like this as a desktop application or as a web application? Sounds like a good topic for another blog...

Animating Interactions With Photoshop CS2

Sometime in the next month my article for boxesandarrows.com will finally appear. It discusses using Microsoft Visio for animating rich interactions. I discuss this briefly in a prior blog.

Photoshop CS and CS2 introduced some new features that make it easy to simulate complex interactions including animated transitions.

Layered Comps
Photoshop CS brought us the wonderful world of layered comps. You can now name the layer configuration. The layer order, visibility, layer styles, and element positions are saved.

It is sort of like being able to take a photo snapshot of the current state of the design.

Its purpose is to create alternate designs and give them a name. Then the designer can walk through the different comp designs with a customer to choose the best one among them.

In the world of rich interactions, we can take a snapshot of the user interface at each interesting event state or user interaction.

Animation Palette
Photoshop CS2 brought an animation palette. By adding layered comps to the each frame of an animation, you can play the various layered comps. Think of it being able to play back a set of complex interactions.

A cool feature is the ability to create tweening between frames.

An example is I could have two rectangles positioned and named as a layered comp called rectangles. The next comp could switch these rectangles. This could be called swapped_rectangles. Dragging these two layered comps into the animation palette will create two steps to the animation: rectangles in their original position and rectangles in their final position. Not too exciting, right? Now select both frames in the animation palette and tell it to tween and allow it to create 10 frames. Now we have 12 frames total.

When you run the animation, notice that the rectangles look like they are swapping. The in-between frames make the animation look convincing.

Capture the Movie
Simplest way is to use a video capture tool (like SnapZ Pro for the Mac) to create a movie file of the interaction as it is played in Photoshop. The movie can be distributed to illustrate the interaction.

The combination of layered comps, animation, and video capture create a simple way to illustrate cinematic effects and complex interactions in a page.

Interaction Matrix

Recently, I have been exploring drag and drop and inline editing for the web.

At Yahoo! I am fortunate to work with some incredibly bright folks. We get together for brainstorming sessions to discuss interactions like these that have application all across the Yahoo! network.

When I started capturing our sessions and writing up documents for these two interactions, I was really struck with how non-trivial it was to define exactly how a drag and drop or inline edit would operate in every case.

Let me take drag and drop to illustrate my point.

With drag & drop there are at least ten interesting event states.

• Page load
• Mouse hover
• Mouse down
• Drag initiated
• Drag over valid target
• Drag over invalid target
• Drag over parent container
• Drop accepted
• Drop rejected
• Drop on parent container

And there are a number of elements that get involved in the interaction sequences. Let's call them our interaction actors. I count at least seven of them.

• Page
• Cursor
• Tool Tip
• Drag Object
• Drag Object's Proxy (ghost of object being dragged)
  
• Drag Object's Parent Container
• Drop Target

That means that there are 70 possible visual states or transitions in a single drag and drop sequence. If you eliminate ones that don't make sense (e.g., tooltip on mousedown) you end up with about 40 possible states.

So defining this in a meeting is non-trivial.

To simplify this, I created the concept of an Interaction Storyboard Matrix. For simplicity I created it as a Microsoft Excel document. Each row corresponds to an actor; each column corresponds to an event state. Each cell in the grid represents a different visual state or animation providing feedback or affordances during the interaction.

Here is what the drag and drop interaction storyboard matrix looks like:


Events and Actors Reveal Interaction Storyboard Frames

So how do you use it?

Just fill in the non-gray cells with how each actor will look or behave during each event state. The interaction storyboard matrix is just a way to show different visual channels against the backdrop of event interactions. Think of it as a choreographed dance and each state being a difference scene in the play.

Feel free to download both the drag and drop template and the inline editing template.

Let me know if you find this useful.

Special thanks go to my fellow Yahoos. Matt Leacock, Kiersten Lammerding, Lance Nishihira, Eric Miraglia, Rob Aseron, Kathleen Watkins, Eric Costello, Anja Krombholz, Ericson DeJesus, Greg Rosenberg and many others...

Popups With a Twist

If you lived through the desktop UI boom of the 80's and 90's, you will recall the history of popup windows. You will recall the rise and fall of their popularity. And now with the web we are seeing popups growing in popularity. Are we headed for the same problem? Or are these popups different? While I believe that once can create annoying popups, what we are starting to see on the web are popups with a slightly new twist.


Example of a Lightweight Popup from Yahoo! Local

So here is where I want to say (with a nice, slow, southern, raspy drawl), "Back in my day, we didn't have no popups."

But in reality we did. With the advent of windowing we kind of went popup crazy. We had moved from a world of ASCII terminal based applications that went from screen to screen (or if you were clever you could tile in an area of the screen using some IBM font characters to draw the popup border and create a simulated dialog) to a nice environment with menus, windows, mice, and icons. With that sudden power applications started adding popups everywhere.

In Alan Cooper's original About Face book, he used the term, Idiot Boxes, for unnecessary dialogs that interrupt the user's flow asking pointless confirmation questions or asking for information that they system should already have.

One key design goal that I have always strived for is to minimize modes, context switches and windows for the user to manage. Direct manipulation helps to realize this goal. But another technique is to avoid going to other screens or pages to get information from the user.

In the web world, for the longest, we were plagued with two types of popups:

• Javascript alert box. Your basic ugly dialog box
• Javascript open window. Which created another browser window (that you could leave fairly undecorated)

Later, two varieties of popups came on the scene

• DIV based lightweight layers
• iframe based layer

iframes provided some advantages and disadvantages. With iframes you can specify a separate HTTP connection and an iframe can cover native browser components (e.g., in IE/Win the combo box shows above any DIV layer and while you can mess with z-ordering to resolve it, other issues are introduced.) The problem with iframes is that they can be slow. The HTTP request and render cycle can cause a second or more delay to populate an iframe's content.

The use of a DIV that is absolute positioned and given a higher z-order index, styled with a title and perhaps made draggable has come into vogue of late.

And for good reasons.

• They allow the user to input more information without leaving the current page context
• They allow the user to look at more information without leaving the current page context

Notice the interesting twist.

On desktop apps, dialogs seem to be disruptive. In web apps, popups (when done correctly) can actually minimize the need for breaking the user's concentration by bringing in information in context quickly and easily. (Obviously abuse will not be far behind.)

In my previous post I illustrated the Hover Detail. Luke Wroblenski commented about using Hover Detail + In Context Tools to make more complex related commands readily available to the user without disrupting flow.

This is really intriguing! These really are not your father's popups!

Its the same basic idea. Just popups. But with a light twist. So what is this light twist that makes these web popups so much better than the old style? Here are some of the things that I think make them better.

• Their goal is to minimize disruption to the user
• They are virtually instantaneous. No waiting like in the old days.
• They can be styled to feel lightweight
• They can be styled to match the page they are part of (this makes them feel like they are part of the page, but yet not at the same time)
• They have enough familarity with normal popups that users know how to move and close them (hopefully!)
• They are often triggered with just a mouse hover and dismissed with a mouse out
• They remove the fear of where a link might lead me.
  
• They remove the need to load a new page
• They often bring information at the point of interaction and at the point of curiousity
• They remove the need for getting back to the context by using a back button
• They provide information in context-- a powerful information architecture principle.
• Couple with Ajax, they provide a world of information at the user's fingertip (or mouse point ;-)
  
• And they just feel great! No, seriously, after living in the land of page to page navigation it is refreshing to be able to pull content in quickly.

Several nice examples are in order.

Yahoo! Instant Search

Yahoo! Instant Search Uses a Lightweight Balloon Approach to Show Shortcut Matches

Netflix

Netflix Movie Details

MarketWatch

Lightweight, Quick but Substantive. From MarketWatch. Illustrates Information & Commands in a Single In Context Popup

Musings on Mouse Hover

I've been thinking a lot lately about mouse hovers. Yeh, I know I really should get out more often ;-)

A mouse hover is a really simple event. When you get a mouseover event you do someting. When you get a mouseout event you usually restore things to the original state.

Mouse hovers were virtually unheard of in the desktop user interface world. I remember writing some very sophisticated applications (games, graphical drawing packages, etc.) and only using mouse hover for some very basic operations. Tooltips & mouse coordinate feedback are two that come to mind.

It was a while before rollovers showed up. In the original Macintosh Finder and in Windows 3.1, rollovers were not used to indicate an object was actionable. It was the advent of the web and the need for discoverability that really opened the door for the lowly hover to be come to the forefront.

In the desktop world, hovers were not that immediately useful. It seemed gratuitous and redundant in those early days to do something on a mouse hover. Traditional desktop apps have always been structured around user interface controls providing the structure with data poured into this mold. Web sites & applications started with content. With hyperlinks and images embedded in the page, it was not obvious what the 'control' or navigation structure of the page was without some visual clues. Over time rollover effects that made it into the web found themselves migrating to the desktop.

Windows 95 flattened toolbars to remove the visual speed bumbs created by beveled button borders. In its place, the mouse hover showed the border and gave the essential clue that the object was clickable. As more and more folks have got used to exploring with a mouse hover, it became a more acceptable a way to discover functionality.

Ajax, DHTML and the Lowly Hover
Now that interactions are even more dense, the hover has become our friend to discoverability. We are introducing new idioms to the web space. Things like drag and drop and inline editability are not immediately expected. The hover can provide vital clues to the behavior of an application at the moment the user is curious about it. Hovers are also the lightest event for the user (they just move the mouse.)

Let's look at some places that hover is showing up more and more (not an exhaustive list!)

Hover Invitation
We can use the hover to cue the user what is going to happen next.

Inline editing
How would you know that parts of a web page's content is editable? We could be overt and just say it on the page. But that gets busy if there are lots of places that are editable. We could make everything look editable. But that also makes for a cluttered page. Hover lets us do just-in-time functionality feedback.

In flickr, hover over the photo title and you will see the color change to indicate the area has some interaction to offer. Coupled with the tooltip the user is invited to click to edit the title.


Flickr's Photo Title Before Hover


Flickr's Photo Title After Hover

Pretty obvious if the user ever hovers over the title.

In backpackit.com, the 37 Signals folks take a similar approach. They shad the area editable with a gradiated yellow background and add a lightweight inline, incontext toolset. It becomes obvious that you can edit, delete (trash can not shown below), etc. the content.


Backpackit Note - Non Editable


Backpackit Note - Showing Editability

In Yahoo's trip planner (travel.yahoo.com/trip) you get the same style of in-context toolsets on hover.


Y! Travel's Trip Planner - Itinerary Item


Y! Travel's Trip Planner - Showing Editability

Ratings
Yahoo popularized ratings. Just check out how the hover helps guide a user to rate a movie.


Yahoo! Movies Ratings - Not Rated


Yahoo! Movies Ratings - Invitation to Rate

By visually engaging the user in rating possibilities the user only needs to click to participate. This lightweight approach to engagement is the advantage the hover has. Hover requires little effort. The next step is just to click.

Hover is nice because it allows you to hide lots of controls and show them only as needed. Showing them in a light enough manner makes it much more engaging to participate.

One more example will suffice from Yahoo! Local's Reviews.


Yahoo! Local Review Rating - Before Hover


Yahoo! Local Review Rating - During Hover

Flagging Mail
In the new Y! Mail, hovering over a message's column for flagging shows a lightly shaded flag. Clicking turns the flag on.


Yahoo! Mail (Beta) - Unflagged Mail


Yahoo! Mail (Beta) - Inviting to Flag

I think gmail's star could have been greatly improved with the addition of a hover. Although I don't believe that Google believes in the hover event at this point in time ;-)


Gmail's Star - No Hover

In all of these the hover creates an invitation, a call to action. It shows what the user can do right now, right where they are at.

I call this the Hover Invitation.

Hover Zoom/Focus
There is another use for hover. Since the mouse can indicate where I want to look, the hover can say, hey I want to focus here... I want more detail.

Getting More Detail
local.yahoo.com does this with the map. Try searching for 'restaurants' in some locale and you will see a map to the left. Hovering over the map enlarges it. Leaving the map area shrinks it back to the normal size.


Yahoo! Local Map Inset - Before Hover


Yahoo! Local Map Zoomed - After Hover

This pattern is about Mouse Focus or Mouse Zoom. In this case the hover is the interaction. While it might lead to more interactions, the Hover Invitation is a specific call to action, an invitation to click.

However, there are problems with this approach. Once the area is zoomed up it can cover other important areas, controls on the page. The user also has to move a lot further to exit the now enlarged area to get it to shrink down in size. You have to be certain that the user really wants to interact with an object to zoom on hover.

This is also common with photo organizing software. Hovering over a photo automatically enlarges it slightly.

A very slight variation on this is enlarging an area on hover to make it more apparent it will be the object selected. The Macintosh OS X Dock does this. Although with mixed results. Part of the problem is the area is just magnified. If the icon is 32x32 and it enlarges to 64x64, you still only have 32 pixels of mouse movement to traverse the object. This causes people to zoom past tools by accident.

Hover Detail
And yet another variation is the hover detail. By hovering over something I get a separate view that shows up in a lightweight popup allowing me to see or read more data about an entity. Not too much unlike a the hover zoom, but with more emphasis on letting me peek at more information without changing the page at all.

You can see an example of this in netflix.com.

Netflix Hover Detail

Also, it is used to get more of the story in news.yahoo.com.

Yahoo! News Hover Detail

Going Forward
Of course, hover will be abused. Once could imagine a page with no controls showing and they only show their action on hover. This is the idea of mystery meat interaction a wonderfully hideous approach to engagement.

But used wisely, the hover can

• Engage the user at the point of interest
• Reduce clutter on the page
• Give specific previews as to what will happen if the user clicks
• Provide a lighter way to zoom in on things with little effort
  

Take-Away
Use hover to create a more lightweight but engaging way to cue the user to hidden functionality. Use it as a way to provide just-in-time details. Use it to keep your page visually simpler providing what is needed when they are most curious.