Do sweat the small stuff

Brian Dillard, Monday, October 8, 2007 @ 3:27 pm

In designing user interfaces, it's often the tiny details that can drive your users batty or earn their loyalty. Case in point: Apple's latest iTunes update. iTunes 7.4.2 received plenty of attention for wiping out the black market in iPhone ringtones. I was more interested, however, in a couple of subtle but long-overdue improvements in the iPod syncing interface:

• If you try to sync more data than your iPod can hold, iTunes now tells you, in megabytes, how much you're trying to sync vs. how much room you have. As the owner of a 4 GB nano and 450 GB of music, I've always struggled to finesse as much data into my nano as possible without getting that annoying "not enough room" error message. The process used to be:
  1. Try to sync.
  2. Receive annoying error message.
  3. Agonize over which playlist to uncheck to free up some space.
  4. Repeat ad nauseam, or at least until I stop receiving the error message.

  Now, finally, I have enough information to uncheck the correct number of playlists to achieve a successful sync in one or two tries instead of seven or eight.

• When you sync specific playlists with your iPod, iTunes now retains your playlist folder structure on the sync screen instead of flattening all playlists into one alphabetized list. The consistency of the redesigned interface is a huge improvement if, like me, you have entire directories of archived playlists and no interest in paging through them every time you sync. Even cooler, you can sync an entire folder of playlists with one click.

These little improvements may not seem like much, but they add up over time. The mental cost of switching to different software can be high, but users are more than willing to jump ship if your UI accumulates as many petty annoyances and lingering bugs as it does new features. That's even more true when your software is free and lives in the browser.

As Ajax applications get more complex and desktop-y, users are going to demand the same level of polish and sophistication they expect from traditional software***. Agile development helps us get hot new features into users' hands at regular intervals, but it shouldn't lead us to settle for feature-rich, UI-challenged applications. Iterative development works best when subsequent releases add polish to existing functionality. For every feature release, product managers should schedule a separate maintenance one.

Of course, maintenance doesn't mean just fixing things that are broken; it also means taking things that work pretty well and making them work better. As developers, we should apply the same level of scrutiny to the apps we develop as we do to the ones we use. I learn a lot about UI development by analyzing what I love about the software I use. But I learn more by analyzing what I hate.

Take Zimbra, the powerful Outlook clone. The Ajax version totally rocks except for one glaring problem: its appalling lack of graceful field focus. For instance, when I click the icon to compose a new mail message, the "to" field doesn't automatically receive focus. The result is an app that demands either constant use of the mouse or frequent wild goose chases with the tab key. Other annoyances include the JavaScript confirmation box that pops up every time I try to navigate away from the application. By the time I received this warning for the third time, I was done with Zimbra. I clicked "OK" and hightailed it to the Thunderbird download page. (Not that Mozilla's mail client is free of exasperation.)

Ajax increases the number of UI blunders you can commmit, but some of the most common annoyances date back to Web 1.0. Since the Mosaic days, many sites have suffered from a lack of granular error messaging. Take login pages. They often provide a single error message for a bad login, such as "Invalid username or password. Please try again." The user has no idea whether the username or the password caused the error, so she's left to try random combinations. Often, she'll give up and use the retrieve/reset password dialogue. The result is five minutes of frustration and a trip to her mail client just to get past your front door. If your application let her know the specific problem - "That username does not exist" or "That password doesn't match that username" - then she'd have a lot more luck.

In some cases, field labels are just as much to blame. If usernames on your site are always email addresses, then label the field "email address." Users have to juggle dozens of usernames on hundreds of sites. Give them as many clues as possible about how things work on your site.

Of course, not all user gripes stem from bugs. Often, they stem from lack of configurability. I jumped for joy when Google Notebook finally offered me the option to sort my notebooks alphabetically rather than by date. But I still have to click the "A-Z" link every time I visit the app. The interface defaults to sort-by-date, doesn't store the current sort method in a cookie, and doesn't expose a user preference to set it permanently. Thus a welcome interface improvement leaves its own nitpicky new annoyance.

The same thing happened with the iTunes update I mentioned. As much as I love the retention of my playlist folder structure on the sync screen, I can't believe that the folders are all expanded by default - let alone that they re-expand themselves every time I navigate away from the sync screen and then come back. God truly is in the details.

*** That was meant to be only semi-humorous. Users do expect polish from shrinkwrapped software. Whether they receive it is another story....

Technorati Tags

• usability
• user interface
• user experience

agile ajax

Comments: 3 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   I agree with much of the things you said. Being a webapp developer myself, I often find myself wanting to download and run my own copies of many web applications, simply because I want to change little things that are too annoying for me..

   But with regards to login forms, I guess many application developers still feel the need to be vague. One point that always sticks out whenever discussing user feedback with logins is how much information to share with the users regarding the authentication process.

   It does make sense. If you give only a foggy hint regarding the authentication, you increase the amount of time potential hackers need to break it. The more information you share, the lesser the hackers have to work.

   Of course, it doesn’t follow that being vague secures you application more. Security, after all, isn’t just limited to basic authentication. But many have been taught that this method helps, and I guess that’s why it sticks..

   Comment by Keeto, Monday, October 8, 2007 @ 4:06 pm

2. 

   Until about two weeks ago, I also believed that a login form was more secure if it didn’t tell you *which* field was invalid. After all, why give a potential hacker more information than they need?

   Then I read a blog entry that pointed out what, in retrospect, should have been blindingly obvious: If a hacker wants to know whether the username is valid, all they have to do is click the “Forgot password?” link. Most sites will tell you either “we sent a reminder/reset” or “we don’t know who that is”. And the alternative - don’t even give feedback about whether you’ve sent off an e-mail - is horrid.

   So, yeah, go ahead and tell people which field they need to fix. It’s OK.

   Comment by Jay Levitt, Monday, October 8, 2007 @ 7:32 pm

3. 

   You could just show smth like:
   “If the email address is valid then an e-mail has been sent to this email address with information on how to restore your password.”

   Comment by Weex, Tuesday, October 9, 2007 @ 11:58 am

Leave a comment