Usability Challenge Day 2008

Today is Usability Challenge Day. I'll just repeat the words from the Facebook group instead of trying rephrase the idea in my words.

1. Find a usability problem. It could be a poorly designed toaster, a confusing or redundant letter from your bank, or even a problem with your experience boarding, flying and disembarking an aeroplane.
2. Design a solution. Solve the usability problem, and write your solution down, sketch it up or (if you're feeling particularly keen) make a quick prototype of the improved product/service.
3. Share it with a person who can solve the problem by implementing your solution. Write to the toaster designer, call your bank manager, or talk to a stewardess. Hand him/her your idea. Encourage them to implement it. Be persuasive! And don't forget to post what you've done on the Google Group or the Facebook group).

Who can participate?

Anyone can participate in the 2008 Usability Challenge - whether you're a design professional or a simply someone who is driven to improve things that don't work as well as they should. Join us in making the world a better/safer/less annoying place.

A little bit of legal stuff

The creators of the Usability Challenge take no responsibility whatsoever for any direct or indirect consequences as a result of your/anyone's participation in the Usability Challenge or related events. All aspects of your of participation are your responsibility, so take care.

So there! Get started, what are you waiting for!

Use Appropriate Native Form Controls

It almost never makes sense to use non-standard widgets and form controls. In case of native applications, not only is it more confusing to the user to see widgets that are not part of the UI toolkit of the native platform, it also contributes to a feeling of "this program was not written for my platform". Applications such as iTunes for Windows choose to reimplement Mac-style widgets, blatantly disregarding Windows Human Interface Guidelines.

The most common reason (excuse, perhaps?) used by applications developers when choosing to use non-standard widgets is branding. They want to make their application look like none other. You see the problem right there, don't you? When an application looks like none other, it stands out like a sore thumb.

Standards are set for a reason. Branding can be achieved by several means, many of which do not impact usability negatively.

Even when using standard widgets, make sure your usage of it aligns with the purpose it was designed for. Otherwise we end up with widgets like this, where a simple checkbox would have been the logical choice for a yes/no answer, not a pair of radio buttons. This screenshot is from the Security Preferences of Facebook.com. It lets you pick which of several notifications to send you. There are exactly two options in each of several sets of notifications, but each uses a pair of radio buttons instead of a single checkbox.

Car dashboard switches: And now for something completely different.

I had rented a Dodge minivan for the weekend, and took a few minutes to get acclimatized to the unfamiliar arrangement of buttons and switches and toggles and levers on the steering wheel column. I was testing out what I thought was the dimmer control for the dashboard lights — move it up and the speedometer and odometer backlights would glow brighter; turn it down, and they would glow dimmer.

But while I was doing that, my cousin seated behind me pointed to the lights in the passenger compartment, and wondered aloud why they were turning on and off alternately. I hadn't even noticed because these lights are located behind the driver.

It turns out that on the speedometer backlight dial, if you go past the highest point on the scale, it switches on the lights in the passenger compartment. I have no idea why.

In the photo above, I'm referring to the tiny up-down regulator control, to the right of the giant knob.

What good reason is there to map two such dissimilar functions onto the same physical control? There aren't even two different modes of operation; just that an arbitrary position on the up-down dial is mapped to an entirely unrelated function.

URL Design Sins: Top 16 things that don't belong in URLs

(Because 16 is as good a number as any.)

Much has been said for a long time about making your URLs easy to use, remember, type, hack, and spread virally. There is still no dearth of ugly URLs all over the Web. A few very popular content management systems also engage in dirty URL practices, and it's a shame. To aid you in cleaning up your URLs, here's a list of specific things that do not belong in a URL. A later post will examine the various ways in which you can fix this without disturbing your web site directory layout much.

1. www. We've spent enough time with the World Wide Web to know that web pages reside on the WWW. Adding those four characters to the beginning of every single URL not only requires users to type them in every time, but also requires 4 extra bytes in every single database that stores URLs. Think for a moment how many bytes that would be. Get rid of them! And after you do that, make sure all your www. URLs redirect to the non-www. version.
2. Port numbers. Unless your site is under test, there is no valid reason for hosting it on a non-default port (i.e., a port other than 80.) Apache on Mac OS X has a performance cache that runs on port 16080, and makes every URL of the form http://your-site.com:16080/. Unless you find a mechanism to run the performance cache on port 80, it is a good idea to dump the cache. It's not worth the confusing URL (to most users, if not to you.) Standard well-known port numbers are there for a reason.
3. Index filenames. Filenames such as index.php and default.asp do not give us any more information than the rest of the URL. Drop them.
4. Details of the server-side technology. Your users don't need to know what software you're running behind the scenes. They couldn't care less about whether your pages are .php, .jsp, .aspx or .do. It's best to configure your server to hide these extensions, and then make sure none of your URLs contain them.
5. Special directories for special scripts. You no longer need to place your scripts in a cgi-bin. Get rid of that directory and any others like that. If your server requires you to do something like that, either find a way to configure it correctly, or upgrade to one that will let you do that.
6. Document maintainers' names. Often, when each document has an assigned maintainer for some duration of time, those documents end up being in that particular person's web space. Later, when the maintainer moves on or someone else takes over the maintenance, you're left with a different URL than what you started with. To avoid this, it's best to categorize documents by topic and subject instead of under ~username/document.html.
7. Internal database IDs. Sure, your content management system needs those IDs to locate your content, but your users don't need to know. If it takes an extra database lookup to get the ID from the URL, then so be it.
8. CMS Module Names. Use a CMS that is intelligent enough to render a page without needing all sorts of information stored in the URL. Joomla is particularly notorious at this. What does this URL tell you about where it will take you?

   http://www.joomla.org/content/section/1/74/

   Now what if it were:

   http://joomla.org/news

9. MiXeD-CaSe NaMeS. Don't confuse your users by-Mixing-Upper-case-and-Lower-case-Characters-in-the-URL. Stick to lower-case letters, and don't make them guess. If your user actually types in a URL in mixed case, normalize it on the server and serve the appropriate case.
10. Random gunk. Unless you are a URL-compressor service such as Tiny URL or SnipURL, forget using random characters in your URL. Nobody wants to visit http://yourdomain.com/WijHyYQnVPWNs and guess what it might lead to.
11. Session IDs. Make sure no user-session-specific identifiers end up in your URLs. This makes sure that users can pass on URLs to other users via email or IM, be able to bookmark them, and be sure that they represent a single resource. There are better places to keep session state in.
12. Punctuation. Avoid punctuation that might make it difficult for people to tell others about your wonderful site over the phone. The only punctuation you may have is a hyphen ("-") and HTML entities that have special meaning (e.g. ?, #, :, + and @). No underscores, commas, periods, brackets, parentheses, braces, quotes, less-than, greater-than, equals, or pipes.
13. Database query details. If your web pages have even a hint of database query language in the URLs, you should be on The Daily WTF.
14. Repeated domain name. If the address of your web site looks like http://your-site.com/your-site/your-page.html, then you should have a chat with your web hosting provider about how to shorten it to http://your-site.com/your-page.html.
15. Inconsistent naming. If you sell several products, then make the subdirectories below each product name exactly identical. If someone were to replace a product name by another, the rest of the URL structure should still continue to function. In other words, strive for consistency in naming.
16. Missing content at each level. When a URL is several levels deep, users should be able to chop off parts at the end ("hack the URL") and still be able to get to a usable page. E.g. if you're a news site, and if an example URL looks like: http://my-news-site.com/2008/05/21/news-story.html, make sure you include a list of news articles from 21 May 2008 at http://my-news-site.com/2008/05/21/, and a list of links to daily articles for the entire month of May 2008 at http://my-news-site.com/2008/05/.

There are some easy technological solutions to make this work. Many of these do not require you to change the underlying file system structure or database structure. I will summarize them in a future post.

But most of this comes with discipline: there is nothing here that is technology magic. It is just an application of common sense to a common domain (no pun intended.) Google for mod_rewrite and content negotiation to get started, while I write that blog post.

Update: Google's Blogger, that hosts this blog, leaves something to be desired about Rule #16, that of providing valuable content at each level of the URL. I would love to see archives show up at /2008/05 as well as /2008 at this blog. Until then, please accept my apologies for not being able to practise what I preach.

Parallax Errors on ATM Screens

Oh, drive-through ATMs! How I dread them. Often, they're designed for an SUV or a truck, hardly ever for a sedan or coupe. Only at a few select ATMs have I managed to operate the machine sitting in my car, without having to open the door and remove my seat-belt.

One of the specific problems caused by the height differential between different classes of users (SUV drivers versus sedan drivers) is a type of parallax error with non-touch-screen ATMs — the ones lined on both sides with buttons that map to certain actions on the screen.

As in the figure above, the buttons are not at the same level as the screen, they usually jut out a few inches. So, when an SUV driver looks at it, each button maps to a spot slightly lower than when a sedan driver looks at it. I've often clicked the wrong button because of this.

As with most unusable designs, there is an attempt to apply a band-aid over the real problem. In this case, it shows up as 8 parallel lines drawn from the buttons to the screen. They don't help much, but simply illustrate that the designers have at least realized that this is a problem.

Why not use HTTP usernames meaningfully?

Try typing yourusername@gmail.com in a browser. Go ahead, do it now. Though this looks like an email address, it is an equally valid Web URL^[1]. The part before the hostname, yourusername, is interpreted by Web browsers as a username, and is passed to the web server as part of HTTP header information (WWW-Authenticate:)

So how about Web applications start using this meaningfully? Web mail services such as GMail and Yahoo! stand to benefit the most, since the username@host.com syntax looks exactly like an email address. By letting users type email addresses into the browser window, they can automatically pre-populate the username in the logon page that they display, so the user only has to type in a password. Other applications that display semi-public user information without requiring credentials can use the username to customize content. How about manastungare@orkut.com as a link to my Orkut profile?

This idea came up in a discussion with my advisor, Manuel Pérez-Quiñones. He mentioned that he saw a family member type their email address into a browser window, and before he could intercept and correct it, the right page had loaded anyway. Which brought us to the part where this information is discarded by the Web server, and how it could be used meaningfully to make the interaction more efficient through fewer keystrokes. Since such URLs can be bookmarked, the username need not be typed every single time.

Note that I'm not recommending sending passwords this way, because although that is possible, it is a security hazard. If not using SSL, these credentials are transmitted as plain text, and thus frowned upon. It's best to have the user type in the password at login time on a Web page directly, but there's no reason the username needs to be kept secret.

(In case you're wondering, the screen shot is fake; I simply typed in the URL after the page loaded. It's meant for illustration purposes only.)

[1]  Pedantically speaking, this isn't correct because RFC 1738 does not mention usernames in HTTP URLs. However, most browsers include support for HTTP Basic Authentication, and thus, this can be considered a de facto standard.

Hundreds of Billions of Extra Keystrokes

Why do billions of people have to type "www." before the domain name of every site they access? Isn't it obvious that, if they're typing the address into a web browser, that they're interested in the World Wide Web service (and not, for example, FTP or SSH)? These 4 characters may be trivial to each individual Web user during the course of a day, but if we pool together the entire Web-using population of the world, and measure the total person-hours lost in entering 4 extra keystrokes for each site they visit, the number would be mind-boggling.

The history
In the past, there were individual servers for each service, and DNS-based load-balancing and other advanced techniques were not invented yet, so it was prudent to have one server dedicated to serving WWW requests. It gained the obvious subdomain of "www". But here we are, in 2007, still shackled to having to type these extra characters every time.

What you can do to help fix the problem
If you're reading this, and own a website (or have considerable influence over such things), please try and get your website to respond to requests addressed to yourdomain.com in addition to www.yourdomain.com. It is an easy DNS-level and web-server level configuration change that your sysadmin can perform within minutes, and none of your application code needs to be changed. In addition, you can help communicate the change to your users by removing the "www." from all hyperlinks, marketing and promotional material, and wherever else the "www." prefix used to appear.

Save the world ...
... from these shady characters! ;)

How Much Blue is Too Much Blue?

Apple fans love Aqua, the visual theme for the Mac OS X user interface. The color blue is omnipresent on the Mac, on scrollbars, buttons, menu selections, progress bars, and in many other widgets. That lends a certain consistency to the user interface (if you ignore the brushed metal anomalies in apps such as Safari on Mac OS X 10.4 Tiger).

They went one step further in the blue-ification of the user interface, and added liberal amounts of blue to most of the icons of the default applications. Thus, we get something like the screenshot below:

The problem is obvious: the similarity in all these icons slows you down when switching from one application to another. Because they all look alike, users need to spend a moment or two to make sure they're selecting the correct app. If each icon had a unique color, the color difference would act as a redundant encoding in addition to the shape and appearance of the icon. This can significantly enhance response time, as has been shown in human factors research.

While consistency is desirable for widgets, it is the opposite case for application icons.

A Tale of Two Interfaces

Synergy, a mouse and keyboard sharing utility, has proven insanely useful to us users of multiple machines on a single desk. Think of it as a software KVM switch, but minus the "V" (for video.) You can arrange multiple machines side-by-side and Synergy seamlessly moves the mouse pointer and keyboard input from one machine to another at desktop boundaries. It's a great idea and a great tool.

I use QuickSynergy on my PowerBook and Mac Mini, but later happened to look at the official GUI client on my friend's Windows laptop. It's not often that a user interface provokes a blog post on a Monday morning, but this was it.

Here are the screenshots:

QuickSynergy on Mac OS X

Synergy on Windows

You will notice that QuickSynergy has exactly one dialog box (with two tabs, one to use when running as a server, and another when running as a client) plus one About dialog. Synergy has a total of 9 dialog boxes (plus one About dialog.) The question, I wish, the developers had asked themselves, was whether throwing in a dialog box for every single configurable parameter was the right thing to do. It seems like the UI Designer(s) simply gave up on trying to understand the users' needs, and instead just threw everything out to the user: "here, now there's a dialog box for every single line in the configuration file, go figure it all out." In my opinion, that's the designer shirking his or her responsibility of actually designing.

I wonder how many regular users would ever want to change some of the arcane options. And if there was a savvy user that wanted to, she could just edit the config file! Even as a Computer Science Ph.D. student, I have no idea what the "Relative Mouse Moves" option means, or why I should care about it. (If you say RTFM, that's already the sign of a bad interface.)

QuickSynergy On Mac OS X	Synergy On Windows

Notice how, in the configuration screen, QuickSynergy simply shows you one screen with four text fields on the four sides, whereas Synergy expects you to enter the positions as "Machine X is to Direction Y of Machine Z." The first way is so much more natural, but guess why the Synergy implements the second way? Because the configuration file is written that way.

These are clearly two very different styles of GUI design (though I would strongly argue that a text field for editing a configuration file does not count as a "GUI", it's simply a command-line interface (CLI) inside a text field.) Quick Synergy puts the user first, and is designed to let the user work naturally with his/her mental model of a keyboard/mouse layout. Synergy starts from the configuration file and slaps on a UI on top of it. Thus, Quick Synergy comes closer to the user, while Synergy stays closer to the machine.

UI Design is not about letting users edit configuration files, it's about letting them do what they started out to do. That a config file needs to be edited to make that happen is a side story.