flow|state

Looking for concrete research on impact of animated ads on user experience

I find myself faced with the question of whether to accept animated ads in an ad-based product. An animated ad likely detracts from the user's experience—everyone says they dislike them—but to what degree? I'm finding it difficult to find persuasive research quantifying that effect.

It's relatively easy to find data on the side of the advertiser or the site showing the ad. An animated ad will likely be noticed by more people, and can have higher click-through rates, which is what an advertiser is looking for. Accordingly, a site willing to show an animated ad can charge a higher premium for such an ad over a static ad. Animated ads = more revenue. It's hard to argue with that—especially at an ad-funded startup.

To put the potential revenue upside in perspective, I'm looking for concrete research on the impact of animated ads on the user experience. Here's the kind of research that would be most helpful:

• Hard data. An anecdotal personal claim that, "I refuse to use a site that shows an animated ad", holds little weight. Same goes for claiming, "Everyone hates animated ads... obviously!" If everyone hates animated ads, then it should be easy to find research proving that point.
• Focused on the actual effect on site usage. The little research I can find seems focused on user opinions. (Example, from Jakob Nielsen's AlertBox) I don't want to know whether people like animated ads—I want to know how much they actually impair site usage, or diminish a site's brand, or drive people away.
• Recent. I can't use a study done way back in the halcyon days of 1997 when the web was fresh and new and people didn't think there should be ads in it anywhere.
• Expressed in money terms. It'd be helpful to find, for example, a case study comparing a site's gain in ad revenue from the introduction of animated ads with the monetary downsides (if there are any) of those same ads.
• Objective. A tiny study done by a user interface designer with a personal bias may not help. A large study done by a company that's taking the long view, and trying to balance revenue with customer satisfaction would be better. A peer-reviewed scholarly paper on the topic would be ideal.

Any timely pointers here would be helpful in making this decision. Thanks.

Showing the complete range of choices in a grid

The previous post on Cozi’s updated family calendar reminded me to point out a small but interesting aspect of the Cozi calendar UI that’s worked out rather well. As it turns out, the UI in question is in the Settings area of the product—an area where interesting design opportunities are often overlooked in the haste to get that peripheral stuff out of the way so one can get back to designing core features.

During Cozi's early family research, we met parents who liked to color-code calendar entries according to the person or people involved in the appointment. Accordingly, Cozi lets families color-code appointments in the calendar. (Color is used as a shorthand; it’s not the only way of seeing who an appointment is for, so color blind users need not worry.) Cozi picks a color for each family member by default, but since color is a highly emotional element, we wanted to offer a way to let family members choose their own color. 

We had the following constraints in mind for our color settings UI: 

1. The available colors should all be attractive and work well with the overall Cozi color palette. 
2. The UI should ensure each family member ends up with a unique color for each family member, otherwise the family won’t be able to tell whose appointments are whose when scanning the colors.
3. The colors need to cover a sufficiently broad range that each family member can get a color they like. 
4. The palette from which colors are chosen shouldn’t contain colors that are too similar. If one family member chooses dark blue and another a slightly darker blue, they’ll never be able to tell them apart. 
5. It shouldn’t be hard for a family to collectively choose a set of colors that all work well together. This is a challenging design constraint: once you’ve got about 6 colors in a palette, your choices for each additional color are either going to start running close to your existing colors, or else create the potential for ugly combinations. Some applications like Microsoft PowerPoint have a sophisticated color model to help people create reasonably attractive combinations of colors. (Alas, they still can’t prevent the determined user from creating something hideous.) We didn’t have the capacity to develop such a model, and needed something simpler. 
6. As a consequence of the above point, the palette of choices should be as small as possible. The smaller the palette, the smaller the chance of a clashing disaster. Here Cozi’s targeted focus on families works in our favor, since we can optimize the UI for the demographics of a family. Our database schema allows a maximum of 10 people per household, but in practice our sweet spot is families with 2-4 children. A family with two parents and two kids gets 5 colors: 4 colors for the family members, plus an additional color to represent appointments for the whole family. We eventually settled on a palette with 16 colors. This is sufficient to satisfy the above constraints and still leave some breathing room. (In any given family, there are certain to be colors liked by none of the family’s members.)
7. A family should be able to have some fun picking the colors.

Our starting point for the design was fairly standard: we listed out the names of the family members, and next to each name put a dropdown color picker. You can see something similar in other applications that let users choose a set of colors from a large palette. Here's a clean example from Microsoft PowerPoint 2007's "Create New Theme Colors" dialog, which lets users select twelve colors from a large palette that is revealed when a dropdown color picker is clicked:

 

One wrinkle in using a design like this for our calendar settings UI was created by requirement #3 above: the need for unique color mappings. This is an instance of a cross-field validation rule: the validity of one field value may depend upon another. In a UI like the one above, it’s hard to come up with a good design to communicate cross-field validation rules without confusing or irritating the user. Suppose the colors must be unique, and the user wants to swap the colors in field A and field B. They try to change B’s value to the value in A, but the field complains that B's value duplicates A's value—and forces the user to fix field B before they can leave it. This is terrible! They’re forced to clear B (or assign some temporary value to B), go to A, change it, and come back and enter the desired value in B. 

One solution is to leave such cross-field validation rules until the user tries to commit the whole form. Alternately, you can deliver the feedback about the need for uniqueness modelessly. The problem with either solution is that the user ends up being surprised: just at the point they think they’re done, they have to go back and rethink their entries. You can try to let them know the uniqueness requirement up front via instructional text, but most users aren’t going to read it, so you’d probably just spend some screen real estate for nothing. 

Our strategy in such a dilemma is always to refer back to our family domain and see whether we can optimize for it. Here, we see that the above UI allows for an arbitrarily large palette, but we don’t need that: we only have 16 choices for each color. And the typical user will only need to pick 3-5 colors. Instead of displaying the palette in a dropdown, we display all the available choices in a row: 

 

The immediate advantages of this approach is that the user can see all the color choices at a glance, and they can make a choice with a single click (instead of having to spend one click revealing the dropdown palette, and another to make a selection). But the true benefit of this approach is that the user will infer the requirement for uniqueness without it needing to be enforced. In usability tests, we see users intuitively grasp that they should pick a color from any given column no more than once. They can work that out on an intellectual level, of course, but the UI makes that easier to see. With that in mind, we were able to relax the enforcement of unique color selections—the user takes care of that on their own. This lets us deal handily with situations like the need to swap color choices. And, finally, people seem to enjoy using the UI to pick colors.

This design approach could be applied in other situations. It's quite similar to what you find in online surveys. The design requirements here are slightly different, but the final result still shares the presentation of the complete range of choices:

from SurveyGizmo

It's well understood that a dropdown control will generally be more compact than a set of radio buttons, but in situations where the same dropdown control is repeated across multiple rows, a grid of radio buttons can be efficient as well. Each column only needs to be labeled once, so the individual radio buttons don't need their own labels. (The color swatches in the Cozi design are effectively self-descriptive radio buttons that don't even need column labels.) And though the repeated controls take up considerable space, they afford the user the ability to quickly apprehend relationships between field values. In the Cozi color UI, the user can spot-check whether each color has been used only once. And in the survey UI, the user can quickly perceive the balance of their responses across the range of choices.

If you have a similar settings UI in your own product, perhaps with dropdown controls, consider whether the set of choices is small enough that you can display the complete range in a grid.

Cozi calendar UI overhaul

It's been way too long since I was last able to post here, mostly because having three small children equates to having zero personal time. Still, work has been productive. Today Cozi posted an update to the web version of our family calendar. Our web calendar has long lagged behind the PC version, but we've been working hard to correct that, and today's release represents a big step towards that goal.

Before today, the calendar was a bare-bones UI that looked like this:

The new calendar looks like this:

We still have a long list of improvements in the works for the calendar, but this latest public release already includes a range of large feature enhancements and small fit-and-finish details that collectively make the new calendar, IMHO, quite polished for an AJAX UI:

• Asynchronous loading of appointment data. We used to reload the entire page whenever we needed to display new calendar data (e.g., when adding an appointment). Now we just refresh the days we need to. 
• Infinite scrolling. The old implementation would only let you see one week's worth of appointments at a time. Movement between weeks was generally managed with "Previous Week" and "Next Week" links. The new UI uses infinite scrolling, so the user can move as far into the future (or past) as they need to with just the scroll bar. This work dovetails with the aforementioned async loading of data.
• Complete typography overhaul. Improved margins and leading make it easier to visually parse the information into three vertical columns and a large horizontal row for each date. This included details like right-aligning the color-coded family member dots so that they are visually grouped with the appointment subject.
• We took extreme pains to line up the start times and end times by the colons to improve legibility. This was somewhat at odds with our desire to follow proper typographic convention and separate times with an endash instead of a hyphen. Using an endash with vertically-aligned colons produced a situation in which a bit of extra white space would appear before end time that had a single hours digit. That is, "–  3:00" would have more interior space than "– 12:00". We finessed this by using an endash when the end time has a single digit hour, but a hyphen when the end time has a double digit hour:
  
  
  
  For all we know zillions of other people have done the same thing, but we think this bending of the rules lets you produce a clean and highly legible timetable with plain HTML.
  
• Tuned the color of all text elements in the calendar data. Dates are shown in color, body text in gray. For contrast, the subjects of a non-routine appointment (something that doesn't happen weekly) are set in black to make them stand out—since those are the appointments a family needs to focus their attention on.
• Placed the day of the week over the date. Users of a family calendar are extremely interested in what's happening during the coming week, and much less so in what's happening months away. Placing the day of the week over the date reflects that priority.
• Tweaked the background color banding on alternate days to make it a bit more prominent. This is really hard to get right so that it's perceptible on all monitors, but not overpowering on monitors with excessive contrast.
• Revised the UI controls for selecting the family member whose calendar you want to look at. The old design had big tabs, which users immediately understand, but they occupied more space than was justified by their relatively infrequent use. We took the opportunity to more explicitly present the list of names as a legend for the color-coded dots.
• Added gradients to the colored bars at the top and bottom of the calendar. These are done as a series of one pixel-high DIVs so that we can easily swap out the gradient based on the current family member's color without needing to store a ton of images.
• Cleaned up element margins overall.
• Tightened borders around the natural language appointment entry area at the bottom.
• Shifted the little triangle that had been to the left of the text box so that now it's inside the box. That triangle is one of a pair of triangles used to visually imply a connection between the text box and the calendar: the triangle on the calendar indicates the day where new typed appointments will go (if you don't type a date). Moving the bottom triangle inside the box more clearly connects the two triangles: they're now directly horizontally lined up, and they can now both share the same black color. (Users will readily infer a connection between two elements on a page if they share a color.)
• Shortened the hint text inside the text box. Although being able to double-click a day to create an appointment is a useful shortcut, users can find it on their own without instruction.
• In that same area, replaced the "What can I type?" link (which was spec'ed as white, but had ended up as black due to a bug) with a smaller question mark icon.
• Cleaned up the "Home" button script in the upper left. We'd previously used sIFR for this and other instances of "handwritten" text in the product. It's a nice bit of technology, but in this case the text was static, so using Flash was complete overkill. Now it's a simple transparent PNG (or a transparent PNG8 in IE 6.x).
• Cleaned up the mini-calendar on left. The mini-calendar now shows a minimal set of information and controls in its normal state (when the mouse isn't over it). This keeps the UI clean. When the user moves the mouse over the mini-calendar, various navigation controls appear for navigation to the previous month, the next month, and today. In the rollover state, the mini-calendar also shows the dates at the end of the previous month and the dates at the beginning of the next month. This makes it quicker to navigate to dates just outside the current month. We've built this calendar by styling the jQuery UI date picker, which has worked well in practice.
• Added advertising in the left pane. Hey, we have to pay for all this work somehow! We've been careful to keep advertising separate from the family's calendar content on the right.

Overall, we're quite happy with the result. We have more improvements to the Cozi calendar in the works, and are eager for those to see the light of day too.

Looking forward to seeing Facebook apps drop their pointless mystery

Consider the following hypothetical computer experience: 

One day a friend of yours sends you a one line email saying, "Hey, check out FooBar!" That's all the message says. "Okay", you're wondering, "What the heck is FooBar?" You follow the link to the FooBar site, and all you can see is a EULA check box and a "Sign Up" button. You have no idea what FooBar does, so you're reluctant to entrust any information to this site. Before leaving, you notice a tiny link that says, "Learn more about FooBar". You click it, and are presented with the FooBar logo and a short paragraph that says that FooBar is pretty cool. You're still confused about what it does because you can't actually get inside and see it for yourself. Finally, overcome with curiosity about why your friend would recommend the site, you give in and click the Sign Up button. 

Once inside the site, you realize the site is stupid, and wish you'd never signed up. You later discover that all your friends have just received a one line email from you saying "Hey, check out FooBar!"

This, in a nutshell, seems to be the experience of trying the typical Facebook app. Granted, in Facebook, the above experience would generally take place entirely within the world of Facebook (with its own messaging system, etc.), but I think the story captures the basic pointless mystery of it all.

I've been watching with interest how Facebook's application model will pan out, particularly the user experience of engaging with an application: discovering it, learning about it, adding it to one's profile, and using it. A while back I noted how many companies were busily removing hurdles at a site's entrance so people could experience a product's value (or at least a taste of the product's value) before committing to the product. Facebook, in contrast, seems to be confidently bucking this trend with the apps that live on top of its platform.

On the one hand, Facebook users can quickly add a new app to their profile because they don't have to reenter personal information for each app. However, in my opinion, this advantage is overwhelmed by the de facto requirement that a user add a Facebook app to their profile before they can derive any meaningful value from it—or even understand what it does.

The first point of contact you may have with an app may be when it tries to catch your attention in your feed:

Many apps are deliberately coy about what they do before you install them. Many (or sometimes all) of the links in the feed entry will require that you first add the app to your profile:

If the anecdotal accounts of my friends are anything to go by, at this point most people just go ahead and click the big Add button. A curious user can read the laconic and non-descriptive Developer's Description. An especially cautious user can click the tiny "More information about <application>" link to view an About page:

If you do add the application, unless you're careful to uncheck "Publish stories in my News Feed and Mini-Feed", you'll end up telling all your friends that you've just added the app to your profile (in the manner of the original news feed entry shown above). The app has enlisted your unwitting help in perpetuating its pointless mystery.

That mystery would, in fact, seem to be the basis for the viral distribution model of many Facebook apps. I have trouble with this approach, being founded on a disregard for a user's intelligence and precious time.This model relies entirely on mystery to entice you add the application—and then banks on the fact that, once you add an application to your profile, you'll just leave it there rather than remove it. This is fundamentally deceptive.

(The deception is compounded in cases like the one above, in which the app developer has deliberately incorporated a huge amount of white space into their description. Below the app's description, Facebook displays commentary from friends and other users of the app about the app itself. The obvious purpose of incorporating lots of white space into the description is to push all the commentary far below the fold, the better to leave the app's potential users uninformed.)

That a Facebook app would hide information about itself suggests the app offers no persistent, real value. If it were actually valuable, the app would employ all the means at the disposal of a normal web site to balance the amount of value they provide to user with the degree of commitment they require from the user. For example, a normal site might let a curious potential customer: start a process but not finish it; read content but not write content; do something a fixed number of times; use the site for a trial period; perform certain basic operations but not other, more interesting ones; etc. Even the most brain-dead web site at least presents information about itself first, before making you sign up for the site. The first generation of Facebook apps generally forego all these techniques in favor of an all-or-nothing requirement that you add the app to your profile.

Remove a Facebook app you don't like is not hard, requiring a simple click on the little "X" in the app's profile box. Still, it's a tiny bit of work, and the work adds up with every app you try. I have to believe that most people will eventually tire of removing applications, and therefore tire of adding them. That in turn means the Facebook world is biased in favor of the first set of Facebook apps a user comes into contact with (i.e., all the apps used by their initial Facebook friends), and impairs the ability of later apps to succeed.

One could argue that it's in the interests of Facebook and an app's developer to force a user to agree to an app's terms of use before they can use it. And yet somehow the rest of the Internet doesn't have this problem. In the normal web, users implicitly agree to a "browse wrap" agreement whenever they visit the site, conferring a degree of legal protection to the site. Presumably this same level of protection extends to browsing Facebook apps, so it's unclear why Facebook would be more concerned about this than sites on the open web.

I also find it hard to stomach the presumption that, when you add an app on Facebook, by default the platform and app presume to advertise that the app is now part of your identity. That's absurd. You haven't even seen what the app does. What else in the world works this way? When you pick up a book in a bookstore to consider buying it, are you really prepared to declare to everyone you know that you've picked up the book? The news feed entries about adding applications seem like nothing more than spam. They do, however, also also serve Facebook's ulterior goal of giving every user the illusion of social activity, regardless of how many friends they have or how active those friends are.

All the behavior described here appears to stem from a combination of deliberate platform limitations, unintentional platform limitations, de facto conventions that arose around the plaform's first apps, and plain bad design. A newer generation of apps do let you see a tiny bit of their functionality before you the add the application to your profile, but what you can see is generally still a very limited subset of what the app does.

Regardless of their intent, it's fascinating to see Facebook facilitate such a closed app adoption model—and still create a successful and vibrant application platform. Clearly there are a huge number of people who don't mind (yet) adding unknown applications to their profile, nor do they mind (yet) advertising that fact to the world. What's odd is that those same users don't tolerate the same experience on every other web site. I'm hopeful those users will eventually turn away from Facebook's unnecessarily mysterious apps, and eventually force those apps to open their front doors as wide as the rest of the web.

Zune: a fine music subscription device

Last month I received a Microsoft Zune 80 as a gift. (Thanks, Johnny!) Having used the device for several weeks now, I wrote up some opinions of that experience to send to a friend on the Zune team, and have decided to share those thoughts here as well.

My experience with Zune actually goes back a few months, to when I first subscribed to the Zune music service without actually owning a Zune device. I'm partial to having a music subscription rather than "owning" tracks. This is due to personal past experiences wrestling with DRM, and the sense of freedom I find in paying a flat fee for unlimited music. For $15/month I can listen to whatever I want within the reasonably spacious Zune Marketplace. In practice I could use the same amount to buy a big pile of audio tracks from iTunes, but for me a subscription enables a freer sense of experimentation. Case in point: a relative who visited over the holidays wanted to share music by an obscure Chilean musician. It felt great to listen to several esoteric albums through the subscription, and there's simply no way I would have felt good forking over money on the spot to listen to something I might never listen to again.

Nevertheless, owning a Zune in an iPod world feels akin to belonging to an oppressed religious minority. Discussions about the Zune with fellow Zune owners must be conducted in secret, lest the conversation be overheard by the dogmatic iPod-wielding masses. This is too bad, since I found the second-generation Zune client software and the Zune device itself to work quite well in practice.

The Zune client on Windows generally looks attractive. The client UI is designed carefully enough to reward a close look:

• I found it trivial to find new music, download it, and sync it to the Zune. YMMV.
• The original Zune client felt like a warmed-over skin for Windows Media Player, while the new one feels distinct enough to have its own style. The swirly background fractal may not be to your taste, but at least it's making a statement. I like it.
• A very subtle visual orange/pink gradient animates in the background at the bottom of the window when music is playing. I didn't notice this until I tried to take screenshots for the image above and compared them. It's similar to, but much more subdued than, the background effect in Windows Media Center. I assume the effect is there to confer a (slight) sense of movement.
• The UI makes extensive use of elements that come alive or reveal more detail on hover, such as scroll bars, the volume label, the device/disc/playlist icons in the lower left.
• The five-star rating system from Media Player always seemed to be more detail than I cared to supply. The Zune client replaces this with three simple states: neutral, I Like It, or I Don't Like It.
• The client makes good use of web-style navigation, a style I've referred to as a BBOP UI (Buttons, Back, One task, Page-based). My only complaint is that the little back arrow in the upper left disappears in the Settings area, which is treated like a giant modal dialog. I think that's a mistake—if you're going to offer web-style UI with a Back button, you really have to offer the Back button on every page, or you're really going to confuse the user. I can sympathize with the designers' dilemma, though. It's hard for client software designers to accept the fact that a user might want to walk away a page in which data has been entered—without making an explicit command to save their changes or cancel the operation. People do this every day on the web without issue. The Settings area should offer a Back button, and if the user happens to click it and loses it, so be it. That's how virtually all web pages already work.
• I was happy to discover that I could sync recorded TV shows from my Windows Media Center to the Zune. This worked well overall, even if video files did have to go through a slow conversion process. One annoyance was that the Videos view on the Zune client only shows the episode title, not the show title, air time, or episode description. This makes it hard to find the show you want to sync. I assume that essentially no time has been spent designing Zune and Media Center to coexist happily, and that minor issues like this will get resolved as Media Center integration improves in the future.

I'm no hardware guru, but the Zune device itself seems well designed.

• The out-of-box experience was reasonable. 
• The Zune 80 device itself is attractive and lightweight.
• The headphones seem better than most. My only complaint is that, like most headphones, you can't tell the Left and Right phones apart without looking closely at them to find a tiny "L" or "R". It would be great if one could feel which one was which through some means (a raised letter, dots, whatever). Interestingly, the Zune cable already does something similar: there's a raised bump on one side of the connector so you can tell which of the otherwise identical flat surfaces on the connector needs to be facing up as you plug it in. 
• Just once I wish I could buy a device with an expensive screen that came with its own cheap plastic stick-on screen protector in the box, instead of having to hunt for an aftermarket screen protector myself.

The software on the Zune device also looks and feel pretty good.

• The touchpad is an elegant way to scroll up and down through lists—while allowing you to navigate laterally across lists to the left or right.
• The UI uses animated transitions to good effect.
• I wish the Zune device UI weren't quite so minimalist. It feels like Microsoft is trying to out-minimize Apple by pursuing Apple's desire for a UI that's clean to the point of inscrutability. Case in point: I couldn't find the UI for turning on Shuffle. Through trial and error I discovered that pressing the middle of the touchpad brought up a context menu of sorts which included the Shuffle command. If hardware buttons must be context sensitive to keep down the number of buttons, I always appreciate an on-screen indication of what they're going to do if I press them now. Windows Mobile does a decent job of this by always showing what the two soft buttons directly below the screen will do.
• I'm really curious about the decision to have the main menu scroll. In the above image, you can see that the designers have very carefully sized and positioned the menu items so that one item ("podcasts") is clipped at the bottom of the screen. This is a great way to indicate that the user can scroll down to see more items without having to resort to a heavy-handed scroll bar. Very elegantly done, yes? So, how many additional menu items do you think you will gain access to if you scroll down? One. One! If you scroll down, you'll see one more item ("settings"). I'd be inclined to dismiss this as insanity, if it weren't for the careful attention to detail here. It would have been trivial to position and size the text slightly differently to get all the text to fit on the screen without scrolling. More to the point, it would have a been a lot easier to develop. I can only conclude that making the menu feel more dynamic (by forcing the user to scroll) felt better than offering a completely static menu.
• The Photos area was fine, but I was disappointed the device doesn't include a rotation sensor like the iPhone (or most modern digital cameras). This means that, when looking at photos, valuable screen real estate is often wasted, and pictures are shown at a size smaller than that of the screen.
• The Zune offers a modest personalization option: you can set the background of the main menu to a photo. Surprisingly, that was entirely sufficient for me to feel like I'd made the device mine. Many other devices do this, of course, but here the trick felt a particularly effective because the main menu itself is so minimal.

In putting the device through its paces, I ran into more than a few issues:

• The Zune client incorrectly catalogued a few albums under the wrong artist. This appears to be a bug introduced during the upgrade from Zune 1.x to Zune 2.0.
• I was puzzled why the Zune client doesn't offer a context menu on every UI element a user might conceivably want to right-click on. There are no context menus on many online store data elements, for example. A UI that makes inconsistent use of context menus can be pretty frustrating, here all the more so because context menus are a nearly perfect way to offer a rich set of commands without cluttering the UI.
• I'd prefer a Now Playing area in the client that showed what was playing without a distracting album art visualization.
• The Zune Marketplace often appears to get confused as to which online tracks are already in my collection.
• The client frequently hiccups when I move between PCs. One of the major benefits of a music subscription is being able to move from one PC to another and not have to go through the absurd exercise of copying massive piles of audio bits everywhere I want to listen to music. The Zune client sometimes gets confused if I switch PCs and try to listen to music through the subscription. Signing out and back in always fixes the problem, but that's an irritating workaround. I'm hoping the client will eventually do a better job of automatically signing in whenever one switches to a different PC.
• I had trouble syncing over WiFi: nothing would happen, or else I would see a cryptic error message. I eventually discovered that the error message would go away if I got closer to the wireless router, so presumably the error message was just a (very bad) way of saying the WiFi signal wasn't strong enough.
• The aforementioned Settings area pegs its buttons to the lower right, which is a bad idea. On a large monitor, these controls all but disappear in a distant corner of the screen, far from the content they pertain to. This common UI flub occurs when designers optimize too much for a specific window size.
• While home videos on my local PC show up in the Zune library, videos on a networked PC don't show up at all, with no explanation. I still can't figure this out.
• The Zune would make for a decent podcast player—if it weren't for a crippling bug: the Zune sometimes (randomly?) forgets what portion of the podcast already I've listened to. For me, being able to Resume a paused podcast is the feature that distinguishes a music player from a podcast player. The unreliability of this feature on the Zune nearly wipes out it's value as a podcast player.
• Both the Podcast and Videos areas are missing a crucial feature: the ability to remove a podcast or TV show when you're done listening or watching to it. A list of podcasts isn't like a list of songs you want to listen to over and over. It's more like a To Do list of things you want to listen to once. It's tedious to have to go back to your PC just to remove a podcast you've listened to or a TV show you've watched.

Overall, I'm pretty happy with my Zune 80. As a music player for an online music subscription service, the Zune works nearly flawlessly. It's less effective as a podcast or video player, but I'm looking forward to seeing those deficiencies addressed.

I'm not sure what Microsoft can do about Zune's biggest handicap: its brand. People like buying Apple products because of what they feel the purchase says about them. At this point, buying a Zune either tells people that you're a Microsoft-loving sap, or else so uninformed as to be unaware that you've just purchased a second-place music player. Virtually all of this bad vibe is attributable to the unshakable feeling that Microsoft is trying too hard to be cool. I actually think Microsoft has made some bold and innovative moves in designing and marketing the Zune, but all that works has to fight against the grain of the intrinsically uncool brand of Microsoft itself. And for what? I can't think of a single way in which the Microsoft brand has helped the Zune in any way, and one can only wonder how much more successful the Zune would be if it had been marketed as a completely independent entity. To their credit, the Zune folks at Microsoft are painfully aware of this enormous marketing handicap, and I wish them the best of luck overcoming it.

In the meantime, I'll be happily listening to all the music I can eat on my Zune.

Directional keyboard navigation could improve PC-based browsing too

Many thanks to people who shared suggestions in the previous post on keyboard navigation. I'm looking forward to trying them out on Cozi's site.

Continuing a discussion of keyboard navigation, it's worth asking whether the Tab navigation model itself is a problem that needs fixing. The Tab model works well in the small dialogs for which it was designed, but has completely failed to scale up to navigating complex web sites. Consider two user interfaces, one old and one contemporary:

Windows 95 dialog with approximately 10 focusable controls 

Default MSN.com home page with approximately 200 focusable controls

Note that the relative scale of these two screens has been preserved. Both spatially and logically, the user has a much, much larger area to move around.

Modern operating system UIs provide two standard mechanisms for moving the focus around a window using the keyboard: a linear Tab model, and explicit keyboard shortcuts (e.g., Alt keys). The Tab model is the most commonly used for moving between fields in a UI. It evolved from a UI intended for navigating through the modest collection of input fields that could fit on small character-based display (with, for example, 24 rows of 80 characters), and represented an evolution in turn from Tab keys on typewriters. The Tab model hasn't evolved much since the character-based days. A single control in the active window has the keyboard focus. This control indicates its active state in one of several ways: button-like controls and list boxes show a dotted marquis or other highlighting effect, while text controls show an insertion point or selection. Pressing the Tab key moves the keyboard focus through the focusable (interactive) controls on the page in a linear order defined at design time by the programmer. Pressing Shift+Tab moves the focus through that order in reverse.

That the Tab model was adequate for simple dialogs like the one above is evidenced by the model's survival over decades of change in UIs. To my mind this model has completely broken down, however, in its application to typical web pages. The first issue is one of scale: the page above has twenty times the number of focusable controls as the simple dialog. A user trying to use the keyboard to reach a link in the middle of the page might have to press the Tab key 125 times to reach it. (Or, if they were exceptionally efficient, they could tab around the other direction and only have to press Shift+Tab 75 times.) The second issue is that the page has a much more complex two-dimensional columnar layout that the dialog, but that layout cannot be captured in the one-dimensional tab order. To the user, the behavior of the Tab key is therefore quite unpredictable.

The other standard keyboard navigation technique—explicit keyboard shortcuts—are also inadequate for complex user interfaces. Microsoft Windows allows users to move the focus directly to a control on the dialog by pressing a keyboard shortcut, generally the Alt key plus a single letter in the control’s label. (OS/X does this too, although I find it less discoverable and generally weaker in execution.) This system is workable for dialogs with a small number of controls and a reasonable distribution of letter frequencies in control labels, but is obviously unable to scale well beyond a handful of controls. (I remember once running out of available letters in a large dialog and having to resort to using the label's trailing colon as the shortcut character.)

The leading web browsers have adopted these legacy keyboard navigation techniques despite their inadequacy to scale up to modern web-based UIs. Mozilla Firefox, for its part, does offer one more keyboard navigation technique: Emacs-style incremental searching. This lets the user move the focus to a specific link by typing the apostrophe ('), or to specific text by typing a slash (/), then typing the initial text of the desired target. This is quite fast, although I personally find this method less than satisfying. I find it less brain-taxing to just point at the thing I want instead of having to read it and type it. I also have trouble keeping straight the three different keys for the three slightly different kinds of search Firefox offers for searching within a single page. In practice this UI doesn't work well for long scrolling pages: you need to be able to see the thing you want. Once you start typing and move the focus somewhere, you can't easily move the focus to an adjacent element without starting over or falling back to tabbing. The incremental search mechanism can't target controls other than textual links, and then only if the link text is unique. A substantial number of links are images, and don't even have visible text. And finally, because the keyboard shortcuts are unmodified by a key like Ctrl, they don't work if the keyboard focus is already in a text box.

Interestingly, a much better user interface for navigating screens with lots of elements is already ubiquitous—but not on PCs. It's found on mobile phone web browsers, which of necessity do a good job at keyboard navigation. They support two-dimensional directional navigation by using Left, Right, Up and Down arrow keys (or a joystick) to move to the "nearest" element in the corresponding direction. For example, if you press the Right key, heuristics determine whether there's an element you might be trying to reach towards the right, and if there are multiple elements, which element you probably want.

Significantly, these heuristics respect the rendered visual representation of the page, not the structure of the document's object model or the original location of elements at design time. This is necessary to account for the fact that the user may be viewing the page at a different width than the designer used, with different fonts, at different sizes, etc. Directional navigation UIs also tightly connect keyboard focus and scroll position, allowing someone to continually press the Up and Down keys to move through focusable controls and to page over large blocks of text.

The first time I saw a directional navigation UI was actually in the original WebTV browser, later acquired by Microsoft and rebranded as MSN TV. I was inspired by that UI to push for inclusion of directional navigation support in Windows Presenation Foundation ("Avalon"), and was happy to hear that that work eventually saw the light of day in the .NET 3.0 release. (I haven't played with the final result myself, but my understanding is that you can turn it on or off for a page via its DirectionalNavigation property. I'm not sure if that feature made it into Silverlight.)

Directional navigation works so well on mobile devices, I'm hoping it will get built into a browser someday. To avoid conflict with the existing semantics of arrow keys, the final UI could optionally support a keyboard modifier like Ctrl. (So that, e.g., Ctrl+Left means move the focus to the "nearest" control to the left). Microsoft has already filed for a patent on the very elegant heuristics in the WPF DirectionalNavigation feature, so it would make a natural addition to a future version of Internet Explorer. I'd love to see a similar approach adopted by Firefox, or at least developed as a Firefox add-on.

Show mercy to keyboard users (yourself included) by setting the default keyboard focus

As more of my UI work moves from client software to web sites, I'm often struck by the lack of attention most web sites spend on details of UI interactions. As a case in point, compare the degree to which a software company considers its keyboard users. Most client software products do a fair to middling job of keyboard support, but at least provide some basic facilities like keyboard accelerators for input fields, and give at least a bit of thought to the order in which a user will tab through fields. Most web sites, in comparison, apparently fail to give the keyboard user the slightest bit of thought. 

Keyboard support is often considered to be something done just for people who, for various physical reasons, can't use a mouse. That's an important community to serve, but not the only reason to think about keyboard users. Most people use a keyboard at some point in a given computer session. The vast majority of people searching with Google, sending email, IMing, twittering, and so on, every day are doing so with a keyboard. Laptop users routinely find themselves in situations where using a mouse or pointing device is cumbersome. As with many services initially intended for users with disabilities (closed captioning, sidewalk curb cuts, wheelchair ramps), keyboard support benefits the broader public. 

For all people complain about Microsoft Windows, the platform and its applications do a great deal of work in service of keyboard users. As much as I love my MacBook, I'm often frustrated by operations that have no obvious keyboard shortcut. And I was amazed to discover OS/X disables a good portion of its keyboard support by default, requiring a trip to System Preferences to fix. Still, OS/X does a fantastic job of keyboard support in comparison to almost every web site today. 

The very simplest thing a UI designer to help keyboard users is deliberately pick a good control to receive the keyboard focus by default. This is usually a trivial task—just figure out which control the user is likely to want to interact with first, and put the focus there. Often this control will be a text box. In a decent visual UI designer, setting the default keyboard focus is usually something that can be done purely through design-time UI, without resorting to code. In HTML, the default focus can usually be easily set with a tiny amount of the most rudimentary JavaScript in an onload event handler. [Example: onload="document.myform.textbox1.focus()"]

Yet virtually no web pages bother to do this. This is pretty remarkable, even more so for web forms with text input fields. On such pages, almost every user is going to have to click the mouse on the first input field so they can start typing. Every user, every day, will have to spend a second or two to do this. In a minute or so, a web developer could permanently eliminate the need for that extra click. So why don't more people bother? 

As far as I can tell, the most prominent class of web sites that consistently set the default keyboard focus is search engines: Google, Yahoo, Windows Live, etc. Most other sites don't bother, even those like Facebook that have obvious fields, like Search boxes, that could receive the focus. And even the search engines that do set the keyboard focus don't appear to reflect a consistent corporate design goal.

Google home page sets the default keyboard focus

 

Other Google properties generally don't

Google's home page sets the keyboard focus, but the main page for other Google properties like Google Reader, Google News, and YouTube don't. Windows Live does, but Microsoft's corporate home page doesn't. This last example is particularly telling. Microsoft spends untold hundreds of hours every year ensuring that its Windows products comply with regional accessibility regulations such as the wide-reaching Americans with Disabilities Act. American federal agencies generally insist that suppliers like Microsoft create products that comply with these laws if they want to do business with the agency. I have no specific knowledge, but it's reasonable to assume that the Microsoft home page doesn't fall under these regulations—maybe for the simple reason that no one's paying to use the page. 

I think the primary reason web companies ignore keyboard users boils down to expectations. Web sites don't bother to set the keyboard focus because other web sites don't, and because by now users don't expect them to. This double standard is so pervasive that, as much as I care about well-designed keyboard support, the web version of the product I work on generally doesn't set the keyboard focus either. It just never occurred to me as something to worry about, even as I devoted attention to keyboard users of the downloadable Windows client version of the same product. 

Starting to write this post provided me the impetus to finally address this UI problem in some portions of on Cozi's marketing site. Some pages like the Cozi sign-up page had forms that were completely straightforward to fix. The Cozi home page proved tougher to fix. I wanted to set the focus to the search box. Unfortunately, that control happens to use hint text, the light gray text inside a field that serves as a field label. Like most HTML implementations of hint text, the particular implementation we happen to use clears the hint text when the control receives the focus. This means setting the default keyboard focus has the unwanted side effect of removing the hint text, thereby obscuring the purpose of the very field the user might want to type in. As it turns out, we've been developing a better hint text implementation anyway that won't disappear until the user starts typing, and I'm looking forward to eventually using that control for our search box. 

In the meantime, I've at least resensitized myself to the interests of keyboard users, myself included. If your web product has a commonly used form or search box, why not take a minute to put the default keyboard focus in the right place? Setting the default keyboard focus is only a simple tiny step towards designing a good experience for keyboard users, but at least it's a start.

Bill Buxton's "Sketching User Experiences"

I'm reading the book Sketching User Experiences by Bill Buxton. The author's attention to the presentation of examples make for an engaging book, and he covers some interesting ground. I came across an interesting list he presents (pp. 111-2) of attributes that characterize design sketches, in which he asserts that sketches are (or have):

1. Quick: A sketch is quick to make, or at least gives that impression.
2. Timely: A sketch can be provided when needed.
3. Inexpensive: A sketch is cheap. Cost must not inhibit the ability to explore a concept, especially early in the design process.
4. Disposable: If you can't afford to throw it away when done, it is probably not a sketch. The investment with a sketch is in the concept, not the execution. By the way, this doesn't mean that they have no value, or that you always dispose of them. Rather, their value largely depends on their disposability.
5. Plentiful: Sketches tend not to exist in isolation. Their meaning or relevance is generally in the context of a collection or series, not as an isolated rendering.
6. Clear vocabulary: The style in which a sketch is rendered follows certain conventions that distinguish it from other types of renderings. The style, or form, signals that it is a sketch. The way that lines extend through endpoints is an example of such a convention, or style.
7. Distinct gesture: There is a fluidity to sketches that gives them a sense of openness and freedom. They are not tight and precise, in the sense that an engineering drawing would be, for example.
8. Minimal detail: Include only what is required to render the intended purpose or concept. Lawson (1997, p. 242) puts it this way, "... it is usually helpful if the drawing does not show or suggest answers to questions which are not being asked at the time." Superfluous detail is almost always distracting, at best, no matter how attractive or well rendered. Going beyond "good enough" is a negative, not a positive.
9. Appropriate degree of refinement: By its resolution or style, a sketch should not suggest a level of refinement beyond that of the project being depicted. As Lawson expresses it: "... it seems helpful if the drawing suggests only a level of precision which corresponds to the level of certainty in the designer's mind at the time."
10. Suggest and explore rather than confirm: More on this later, but sketches don't "tell", they "suggest". Their value lies not in the artifact of the sketch itself, but in its ability to provide a catalyst to the desired and appropriate behaviours, conversations, and interactions.
11. Ambiguity: Sketches are intentionally ambiguous, and much of their value derives from their being able to be interpreted in different ways, and new relationships seen within them, even by the person who drew them.

Point #9 above states that sketches should exhibit an appropriate degree of refinement, a point echoed in a post I made a while back on matching design sketches to the desired level of design feedback. I found the other attributes listed here interesting food for thought.

OpenID: Great idea, bewildering consumer experience

A while back I tried signing up for an OpenID, an "open, decentralized, free framework for user-centric digital identity." The basic idea is that, instead of needing to choose a user name and password for every site you visit, you can identify yourself with an ID that many sites will accept. It sounds great, but in practice I found the whole process bewildering. In my opinion, it’s not ready for consumer use. 

 

Beyond security criticisms of the scheme that can be found elsewhere, I think OpenID has some significant user experience issues. Some of the problems can be fixed, others are integral to the way the system works. 

• It's way, way too hard to get started. All the sites supporting OpenID point curious users to the home page for the OpenID Foundation. From this site, it’s actually stunningly difficult to find a link to a place where you can actually get an OpenID. A link to a site called I want my OpenID! sounds promising, but the destination page doesn't actually deliver on the promise of getting a user an OpenID either. 
• The content and tone of the OpenID Foundation site is oriented at developers, not end users. The second sentence of the home page boasts, "OpenID starts with the concept that anyone can identify themselves on the Internet the same way websites do—with a URI." You know what? To most people, that doesn't sound like an advantage; it sounds geeky, dehumanizing, and more than a little bit frightening. 
• While there are very cool benefits that come from identifying oneself with a URL (URI), pity the poor consumer. They have dutifully learned that a user name is an identity and a URL is a place to go. Now they must wrap their weary brains around the concept that, when asked to identify themselves, they should provide a location. "Why can't I just use my email address?" they'll wonder.
• The process of selecting an OpenID provider will stump the average consumer. They’re being asked to pick an ID that they will, in theory, use everywhere and forevermore to gain access to everything they own. They’re supposed to obtain this ID by making an effectively random selection from a group of providers they have never heard of.
• Various OpenID sites also promote the notion that users should set up their own OpenID provider. This is fine for a teeny tiny portion of web users, and scary and out of the question for everyone else.
• The lists of OpenID providers are presented in a static order. In some cases this will be alphabetical. The most commonly referenced list of OpenID providers is presented in chronological order of when the service went live, an order that is effectively random. It's not immediately clear in most of these lists why a user would pick one provider over another. None of the lists I've seen are organized around attributes which are relatively easy for a user to base a decision upon, like: Do you have a blog already? Or, Which language do you prefer to speak?
• As an aside, when you ask a normal person to choose a provider from a list for a service they don't understand, most people are just going to pick the first or last entry. (If a default value is provided, they'll pick that. The default value will almost always be the first entry.) So, a static list of providers turns out to be a really good way to screw the bulk of providers whose entries sit in the middle of the list. Microsoft learned this lesson the hard way in various places in Windows, addressing such problems by dynamically shuffling provider names so that all providers spend equal time at the top of the list. More usefully, the lists could reflect community-based provider ratings.
• The ostensible universality and permanence of an OpenID actually makes the task of picking a provider harder. Even if I happen to currently have a SixApart blog with a TypeKey, am I really prepared to use that ID everywhere? Exactly how long can a consumer expect a given OpenID provider to remain in existence? In my playing around on one site, when I remapped a URI from one provider to another, I lost my ID-related preferences. This gives me pause in depending upon any provider that could potentially die before the web service I'm using the ID with. Frankly, many of the OpenID providers seemed like tiny organizations that could disappear overnight. Nowhere could I find anything that would tell me what should theoretically happen to my ID-bound accounts if that were to happen.
• Suppose that, at some point, a visitor to an OpenID-enabled site is really intrigued by this OpenID thing they keep coming across, and decides on the spot that they want to get one for themselves. The OpenID community, and the sites that use it, appear to have given little thought to addressing this scenario. Go to the LiveJournal home page and try figuring out how you’d get an OpenID and come back to use it. I’ll bet analytics on the site will show that, of the tiny percentage of visitors to LiveJournal who go off from there to get an OpenID, only the most determined will make it back. Why would a site operator let anyone leave their site to perform a task from which they will never return? 
• An OpenID is an identity (like a user name), not an account. A consumer still needs an account to use the site. However, this isn't at all obvious to a consumer. When I tried to sign in to Plaxo with my OpenID, I got an otherwise blank page displaying the error, “Unable to verify the specified OpenID.” Some sites do a reasonable job of letting a user who has never logged on before create an account on the spot. When I tried to sign in to LiveJournal with my OpenID, they let me create an account and then start using it. This inconsistency among implementations will confuse a lot of people.
• When I actually tried to use my OpenID on a site, I got a confusing message from the OpenID provider requiring me to confirm that I really wanted to let the site access personal information I had associated with my OpenID. The clarity of such messages varies from OpenID provider to provider, ranging from puzzling to incomprehensible. In the case of Verisign, I was instructed to select which “Trust Profile” I wanted to associate with the site—or did I want to create a new Trust Profile? Wha?

Since most users have never encountered the concept of sharing information across sites, a ton of education would be necessary to make these messages meaningful to the average user.

• Currently, even those sites that do implement OpenID generally treat OpenIDs as a second-class form of identification. They put their own proprietary means of signing in (generally with a user name and password) on their home page, and bury the OpenID sign in facility behind a link. This means that the hip OpenID-using visitor has to make more clicks than the proprietary ID-using masses... which doesn't exactly sound like a reward.

And all this is for—what, exactly? To save me from having to pick a user name and password? As annoying as that can be, it's just not that hard! Remembering an arbitrary user name does cause real trouble, but simply allowing email addresses to be used as IDs can solve almost all of that problem. As more and more sites allow email addresses as IDs, the need for OpenID becomes less compelling to a consumer.

For the time being, I can’t imagine a sane business operator forcing their precious visitors through this gauntlet of user experience issues just for the marginal benefits that accrue to a shared form of ID. I've read numerous claims that all it will take is for someone big like Google to support OpenID to crack this problem open. Unfortunately, there's no business of any size that can afford to direct their traffic down a dead end.

Most service operators will, at best, offer users a choice between using a proprietary ID or an OpenID, creating a terrible economic proposition for a consumer. Faced with the proposition of: 1) struggling once for thirty minutes to struggle through a process they can barely understand, or 2) spending two minutes on every new site breezing through a familiar process they've done countless times before, normal busy people will choose the familiar route time and time again. I’ll bet anything that most people will keep going for proprietary IDs, further deferring the network effects possible from OpenID adoption.

This isn't to say that OpenID isn't worth attempts to fix it. At least some of the above problems can, and should, be addressed head on by the OpenID community. My recommendations:

1. Redesign the OpenID home page for consumers. The page's main content should contain a brief explanation of OpenID in consumer-friendly terms, along with a giant Get an Open ID button. Move all the developer material behind a Developers button.
2. Design an end-to-end process for getting an OpenID from a service operator's site. Since most services won't care which provider the user uses, let these services send the user into a real flow for picking a provider, getting an ID, and most importantly coming back to the original service to use the new ID. When they get back to the service, the new OpenID should be prefilled.
3. Give the above flow a sidebar titled "Do you have a blog?" that explains that, if they have a blog on LiveJournal, TypePad, etc., they can use that for their OpenID. A link in the sidebar should shunt the user into a page that has them pick their blog provider, then tells them what the (blog service dependent) form of their OpenID is. The flow should then return the user to the service they started on (again, with their OpenID prefilled).
4. Organize the list of providers around factors that can actually influence a user's decision. Consider offering provider ratings based on ease of use, uptime, etc.
5. Refine reference designs for the complex range of cases that come up in using OpenID with a service. E.g., define the expected behavior and terminology that should be used when a user tries to log in with an OpenID but does not already have an account with that ID.
6. Define guarantees that services should offer to users in the event their OpenID provider goes out of business.
7. Build an organization that can do real usability testing on this service with real consumers.

UPDATE (October 7, 2007): This week OpenID.net overhauled their site, and the new site addresses a number of the criticisms listed above.

Don't bury the lede: What's the real story behind a UI interaction?

A user interface designer, like a journalist, should avoid burying the lede: engaging the user with an opening question or statement that omits the most critical point of interest. The lede is the all-important opening sentence of a news story, and journalists labor over them. User interface interactions have ledes too, and they should be crafted with as much care.

The Move File dialog in Windows Vista offers a convenient example. (Although a dialog is used here, this principle applies equally well to web pages or other UI modalities.) The Move File dialog appears when a user attempts to move a file into a folder that already contains a file of the same name:

Can you see the disaster in progress? Most users can't either.

This dialog has buried the lede. It focuses the user's attention on the fact that there is another file with the same name in the destination folder. It fails to point out a much, much more interesting condition: The user is about to overwrite a newer file with an older file.

To its credit, this Move File dialog does improve upon the older File Replace dialog in previous versions of Windows: it offers more details that can help the user make a decision, and offers a new option to keep both files. (The latter is particularly helpful when dealing with files like auto-named digital photos, because a user can easily take different photos that end up with the same name.)

Overwriting a file is not, by itself, an uncommon or bad thing. It is a daily occurrence for users to overwrite an older file with a newer version of that same file. The user may be posting an updated copy of a document to a backup location, or to a server for use by others, or to removable media for transportation elsewhere, etc. This is business as usual.

Going the other way—overwriting a newer file with an older files—is a much rarer event. The user might be giving up on work they've done and throwing it away. Alternatively, they could be restoring a backup file to replace one that has become corrupted. Either event is unusual, a point which should be emphasized in the dialog.

The above dialog's text fails at this, as does its layout and typography. There are numerous pieces of text competing for attention, but among the most prominent are the bolded file names. That's a bit odd, since the entire premise of the dialog is that these two file names will be the same. The dialog has carefully drawn the user's attention to information which is guaranteed to be redundant. (If the user is moving multiple files, only some of which have conflicts, the file names are relevant—but that case can and should be handled specially.)

As just a very first cut at revising the above dialog to restore the lede, some text could change. The typography could be tweaked to focus on the salient time stamps. A different sound is probably also in order, to distinguish the invocation of this dialog variant from the more normal one above, and emphasize that something unusual is going on.

(It should be pointed out that the designers of Vista's Win32-based UI can't actually set a run of text in bold, as shown in the dialog's introductory statement, because Win32 is font impoverished.)

This revision would clearly needs a ton more work, but is a start in the right direction. At least the dialog now opens with the lede.