Ruining the User Experience

While in Seattle for a recent business trip, I spent two nights sampling the local cuisine. I enjoyed each meal immensely, however one clearly stood apart from the other. But why?

Reflecting on the meals, I saw a great deal of parity: each dish was attractive and stylishly plated; each venue offered a friendly, cozy atmosphere; each menu offered a wide assortment of choices, all of which were reasonably priced; each had charming wait staff. So what made the experience of the second restaurant so much better than the first?

As with most things in life, it’s the little things that matter most. Take a water glass for example. A careless server might let it dip quite low or, worse yet, go dry before coming by to refill it. One who cares about your experience will make sure the meniscus never passes the halfway mark. And the best servers will leave you surprised to find the glass you just drank from is filled to the brim yet again.

There’s a lot we, as designers of the web experience, can learn from something as simple as a water glass.

Who is the customer?#section2

As a waiter, you know people come to your table with certain needs and possibly even a few expectations. In most restaurants, the water glass is the first “touch point” or point of contact with the customer. A good first impression is made by filling it quickly, but that’s just the beginning. Some people drink more quickly than others and will require more refills. Some will not drink until they’ve gotten their food. Others may never touch their water at all, perhaps requesting iced tea or some other beverage. When it comes right down to it, you really have no idea what type of person is sitting at your table. And when it becomes a table of four, six, or even ten, it pays to be prepared.

The web is much the same. We make beautiful websites that (hopefully) make a great first impression, but we need to make sure every touch point keeps the promise made in those first crucial seconds or we squander the small amount of goodwill we were in the process of gaining. This type of thinking birthed the concept of progressive enhancement.

On the web, we don’t know anything about the person coming to our website. We don’t know what browser she is using. We don’t know if she is hitting our site from her cell phone. We don’t know if she prefers using her keyboard over her mouse. We don’t know if JavaScript (or even CSS) is enabled in the device she is using. We don’t know if she wants to print the page. We don’t know if she is using a screen reader. We really don’t know anything.

So what do you do when you don’t know anything? Anticipate.

As web developers, we need to be able to meet our users’ needs. And if we’re really sharp, we can do it without them even realizing it.

Like pouring cold water in a customer’s lap#section3

Lala.com is a website built around a community of folks who love music. Its system facilitates the swapping of CDs through the mail within that community.

I hesitate to call their website (Figure 1-1) attractive, but it is usable…unless you have JavaScript turned off (Figure 1-2).

You gotta love the fact that there’s a “loading” message even though nothing’s loading.

Now granted, that screenshot was taken a bit ago, but in the intervening months since I first began hoisting them as an example of what not to do, all they’ve managed to cobble together is a message (Figure 1-3) reminiscent of those heady days amidst the browser wars.

The problem here is not that Lala is using JavaScript, but that they are requiring it. The reason? Well, they apparently like the idea of loading all of the content into their pages using Ajax. In their rush to cram all that Web 2.0 stuff under the hood, they’ve alienated a good portion of Web 1.0 users and a sizable chunk of the mobile market. And they’re not alone.

Consider this: you’re a Lala user and you’re browsing around a record shop and stumble upon the new Arcade Fire album. You didn’t realize it had come out and you want to add it to your Lala wishlist before you forget. If your phone’s browser doesn’t support JavaScript (or you keep it turned off to reduce your download time/usage fees), you’re gonna be staring at a screen with good information about what Lala is (Figure 1-4), followed by that message saying you need JavaScript to use the site.

You’ve got no access to your wish list or anything else on the site. Even the search box (way at the bottom of the page) fails to function. For a closed application or service, this might be acceptable, but for a public website it’s a disaster.

Think before you pour#section4

We’ve already established that as web developers, we’re generally flying blind when it comes to our users’ needs. The best we can do is anticipate what their needs may be and meet those needs at every level, trying to give them the best experience possible. This is where progressive enhancement comes in—we need to think about possible levels of need and how to deliver on each of them.

Level 1: No frills#section5

Some users just want the content. They might be surfing on a mobile device, looking to print out some information, or using some sort of assistive device to browse the web—they may even be browsing with images off. Keeping your markup clean, well-ordered, and semantic is key for this user. They want to consume light, fast-downloading pages without distraction.

Level 2: Make it pretty#section6

Some users like a little window dressing (or a slice of lemon). For them, you can provide a nicely designed and well layed-out website. You could even add a few visual flourishes or a bit of Flash and they will be happy. As long as your design doesn’t confuse the visual hierarchy of the page, you’ve been diligent in your browser testing, and you’ve provided some basic styles for alternate media, you should be golden.

Level 3: Make it sing#section7

Other users may want the full monty. For them you can pull out all the stops and create a marvelous Web 2.Oh-my experience replete with yellow fades, sliding widgets, and Ajax galore.

Keep in mind, however, that levels aren’t always that clearly demarcated. You may need to support an intermediate step between levels one and two, giving Netscape 4.x and IE5/Mac some basic typographic styles and colors. Or you may want to consider offering JavaScript enhancements to browsers as they can handle them, injecting a creamy nougat between levels two and three.

Moving unnoticed#section8

Once you’ve decided on the rough levels of support, you can go about constructing your site.

Start with the content. Sometimes designers and developers forget that this is why people come to your site to begin with. Craft it lovingly and serve it to your users with a minimum of distraction, like a well-plated dish; don’t just heap it all together like it’s a buffet. You worked hard on your content… celebrate it.

Once you’ve got your content in order, you can begin to establish the look and feel of your site. Using the various techniques at your disposal, style your site in a way that reaches your users at their level; hide certain CSS files from older browsers and deliver browser-specific styles to those that need a bit more attention. Conditional comments have been a real boon in this area, but dig out old favorites like @import  and specific media combinations, which can allow you to selectively offer some flavor to the folks in older/problematic browsers.

Be sure to consider the presentation of your content in print and on mobile devices. Do you give them layouts or just some basic typographic and color treatments? How do you handle images? Forms? Try to anticipate which features a mobile user would want and streamline the experience for them by removing the cruft. And if you use style :hover on a link, don’t forget to give equal consideration to :focus, keyboard and mobile users will thank you for it.

Once the design is pulled together, add some sparkle with a bit of clever JavaScript. You already know to use object and method detection to determine if a script can run in a user’s browser, but consider how your scripts may interfere with common browser interactions like bookmarking or using the Back button. And don’t forget about script interdependencies either. Will your site become unusable if one script can run and another can’t?

If you’re creating a widget or other interface control, generate the additional markup you need once you’ve determined that the widget can run and everything else is in order. And if you separate your widget-related CSS from your JavaScript like a good little standardista, make sure the styles are not active until the script has indicated that the widget can be used. A good way to do that is to engage in class-swapping (see Table 1).

Finally, if you plan on using Ajax, use it wisely. There is no need to suck in all of a page’s content via little Ajax calls; it just ends up being yet another roadblock between the user and your content. On top of that, it can lead to increased overhead on your server, makes your content invisible to search engines, and can render your site unusable to someone requiring a screen reader and most people on mobile devices.

Don’t get me wrong, Ajax has its place, but it’s important to know where that place is and even more important to know where it isn’t.

Collect a big tip#section9

Carefully anticipating your users’ needs and addressing them in as stealthy a manner as possible is key to leaving a good impression. As with the water glass, your users should never have to wave you over to be served.