Jan Miksovsky’s BlogArchive AboutContact


The Shared Suffering Hypothesis, or setting things up the way everyone else does

Tinkering endlessly with computer hardware and software can be fun… if you have the time. As for me, I eventually came to the paradoxical conclusion that the more I tuned a product to my specific needs, the less likely the product would actually work as intended—and the less likely I could find someone to help me when a problem did arise. Product manufacturers often tout the ability of their products to be configured to a user’s idiosyncratic needs, but maybe users can most effectively minimize heartache this way:

The Shared Suffering Hypothesis: You’re best off configuring a product so as to maximize the number of other people who can help identify and resolve problems with that configuration.

Here’s an example: A number of years ago I set up a media PC, eschewing the small number of commercial media PCs then available to get a tricked-out gamer PC. I maxxed every spec—video card, hard drive, etc.—and for its day, this machine rocked. What didn’t occur to me was that, with each component I picked, I was reducing the number of other people who had the same device I had. And upon receiving the box, I wiped it and installed an early beta of an obscure OS version. Fantastic! Now I had a blazingly fast PC, the likes of which were possessed by no one else on the planet!

I was a user community of one. When sorting through the inevitable driver weirdness and other nightmares, I had no one to turn to for help, because no one else shared this configuration or anything like it. The OEM and its component manufacturers, of course, had no experience with that OS, nor had the OS manufacturer ever tested on any of that hardware. The nascent media PC user community couldn’t help either. This left me solving every configuration issue on my own. I spent hours on exciting tasks like trying to see if the PC motherboard would cope better with the hard drive configured for RAID 0 or RAID 1, or maybe I should try RAID 5? Damn, and all I wanted to do was watch TV on this thing.

Lesson learned, when I bought a new media PC a couple years later, I abandoned impressive computer specs in favor of amassing the largest number of people who could share my problems. If I ran into a problem, I wanted a hundred other people to have already hit it and collectively solved it. I purchased a basic media PC from a huge OEM—not because they made great media PCs, but because they sold a lot of them. I purchased the most vanilla configuration possible, more or less blindly accepting the OEM’s self-serving default hardware recommendations. The more defaults I could accept, the more likely it was someone else would have something like the same box I did. When the box arrived, I tried hard to avoid changing anything from the default config, and in generally avoided installing funky apps on the box. In the end, the new PC wasn’t a perfect media experience—but it worked, and I spent very little time keeping it that way.

(And now the impending forced cutover to digital cable in the U.S. is going to kill me. It’s forcing me to rebuild a perfectly good media PC setup, all so that our seldom-watched analog cable TV can now be a seldom-watched digital cable TV. Once again I’ll be searching for the solution that involves the least weird configuration.)

The problem here are the economics of configuration. You’d think you’d benefit by tailing a product to your needs, but I believe in most cases that benefit is overwhelmed by the benefits of not customizing. And the issue has implications for software designers: each time you add an option to your product, you might be making things worse for your users, not better. I’ll take a cut at that question in the next post.

Next time: The economics of configuration

Transient controls: a delicate balance between discoverability and visual clutter

Last week Cozi posted an update to our family calendar that included a small but significant usability fix to the UI for entering appointments. In addition to a traditional form-based UI for entering appointments, the bottom of the main calendar page offers a text box in which a user can type an appointment in English:

In general this UI for entering appointments works well, but usability testing had indicated that a sizable population of users would hesitate when entering an appointment. They would type the text of the appointment, then move their mouse over the right end of the text box, apparently searching for a button they could click to save the appointment.

These users were likely conditioned by web browsers, which generally have a Go button to the right of the address field. Advanced users generally don’t click the Go button (and may take steps to hide it), but many users navigate with it. We had originally left off a Go button in the interests of reducing visual clutter, and expected people would be able to figure out they could just press the ENTER key to save the appointment.

In testing, it became apparent that we were correct, but only to a point. Most users would, in fact, eventually try pressing the ENTER key. The issue is that it would take a second or two of uncertainty before they would figure it out. We didn’t like the thought of producing any uncertainty or anxiety, especially in relation to the natural-language appointment feature. That’s a star feature in our calendar, and we want to show off. (Yes, Google Calendar and others have a similar feature, but we think ours is better.)

We were reluctant to add a permanent button to the page if we could avoid it. Instead, we opted to follow the lead of Internet Explorer and Firefox and use a transient control: a control that’s only visible part of the time. Both IE and Firefox used to have their Go buttons visible all the time, but both changed the Go buttons to a transient control that is only visible when the user is actually typing a URL.

Here’s how it works in Cozi’s case. When the user enters the page, the focus is in the appointment entry text box. The text box sports hint text to let the user know what the text box is for. (Significantly, the hint text does not disappear when the text box has the keyboard focus—since the text box has the focus by default, hiding the hint text on focus for this field would mean the hint text was invisible when it would have been most valuable. If the user clicks on the text box, we do hide the hint text, so the user doesn’t waste any time trying to delete the hint text before typing their own text.)

When the user starts typing, the transient Enter button appears on the far right:

When the user moves the mouse (not shown below) over the Enter button, the Enter button exhibits its hover state:

The user presses the button or types the ENTER key, and the appointment data is sent to the server to be parsed. During this round-trip to the server, the text box and its associated change to a quasi-disabled state to suggest that: a) something is happening, and b) the user shouldn’t type again until the text box has left this state.

When the updated calendar data returns from the server, the calendar view updates to show the new appointment. The appointment entry text box resets to its original state to let the user know they can type again:

So far, this transient Enter button seems to work well, but we will continue to watch that button closely in testing. We’re cautious about employing this UI technique, because it’s easy to accidentally sacrifice discoverability in the name of visual cleanliness. Here the transient control works well because it manages to appear just when a user is about to start looking for it. In other cases, a user might hold their mouse still while looking around the page, and if they didn’t see the control they were expecting, they might jump to the reasonable conclusion that such a control did not exist.

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:

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

Updated 6/22/08: A big thanks to Michael who in the comments posted links to a pair of relevant papers. Those papers were very helpful to us in deciding whether to accept animated advertisements. We ultimately did decide to accept animated ads, but did put in place some guidelines that we hope will keep out the more egregious uses of that medium.

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:

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’m no hardware guru, but the Zune device itself seems well designed.

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

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

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.