Clean Up the Mess

For people to use our software, they need to be able to find the features they need. We need to unbury the things that make our applications great and put a giant spotlight on them. The best way to do this is to reduce clutter in the screens that comprise our application interfaces.

As discussed in Chapter 7, contrast (often created through color and dimension) is an effective tool for making a particular part of a screen stand out. This is true because some things are seen before a user even begins paying real attention to particular elements. A bright red box on a page comprised of only shades of blue, for example, is seen first because it sharply contrasts with everything else on the screen. Before our brains ever register what's going on, we see the red box. But although contrast is one of the most effective ways to make something stand out from the crowd, it's not the only solution.

Another rather obvious way to ensure that an interface element is seen is to remove anything that takes a user's attention away from it.

Reducing the pixel-to-data ratio

The very same artwork that provides the look and feel for an application is also one of the biggest culprits of clutter in interfaces. The space that graphics take up, the colors used, the proportion of graphics to information, and the overall tone of graphical elements can all detract from the content of an application and take focus away from what matters. Reducing the volume of graphical elements is one of the best ways to eliminate clutter.

Usable, yes. Personable, no.

This is not to say we should all design our applications to emulate the un-design of Jakob Nielsen's Web site at www.useit.com. Nielsen may be a major guru of Web usability, but it's more than possible to design an application that is both clean and aesthetically appealing.

Logos, for example, don't need to take up a lot of room, but they often do. Product names, product logos, and corporate logos are often displayed at rather large sizes near the top of application screens, despite being probably the least important elements on a page.

I understand the urge to spotlight these elements. Marketing departments want to create brand recognition. It's a reasonable request. What they often forget is that by the time the user sees the giant product name and company logo, she's already decided to use the product. Using screen real estate to repeatedly tell her the name of the product is only going to limit how much space can be used for more important content.

The best marketing tool you can have is a well-designed application.

Users appreciate your well-designed application far more than they appreciate having the company name shoved in their faces every time they load a new screen. Feel free to add a logo to the application, but keep it small and bury it in a corner of the page so it's out of the way. Don't focus on logos. Focus on benefits.

Also, try to keep layers of organizational graphics to a minimum. Far too often, Web applications organize individual sections into boxes and end up with so many levels of nested boxes that the simple divider-line graphics used to make such divisions take up dozens of pixels for no reason at all.

If sections of the design can be segregated without the use of boxes, do it. If page elements can be grouped into fewer individual areas and take up less space, do that, too. Whatever can be done to reduce the space used and the ratio of pixels to data will help the application's functionality and benefits shine through.

Minimizing copy

A lot has been said about minimizing copy online. (Isn't irony fun?) But some of the wisest words have shown up in, of all places, books.

Strunk and White's The Elements of Style, for example, is always a great source for learning to write more concisely and vigorously, and the standards defined by this book apply every bit as much to the Web as they do to print.

One of the guidelines offered in the book is "Omit needless words." Steve Krug had a little fun with this axiom in his own book, Don't Make Me Think, by titling a chapter "Omit needless words" and crossing out the word "needless."

Removing words is a sure-fire way to reduce clutter in an interface, but it can be difficult to decide what to cut and how to revise what's left. Here are some guidelines:

• Move instructive copy into What's This? Help documentation. Much of the text that clutters up interfaces is instructive. Developers often assume that users will thoroughly read the instructions. They don't.

  Users typically skip right over anything textual and go straight to guessing. They click the first thing that looks like it might help them do what they need to do. So instead of cluttering up an interface with instructions, convert them to inline Help documents. Replace the text in the application screen with a What's This? link that either opens a popup window that contains the text or displays the text inline using the inline-expand design pattern discussed in Chapter 6.

• Write vigorously. In a Web application, you have very little chance of grabbing a user's attention with text (applications are about doing, not reading). So when text absolutely must be included, keep it concise. Omit needless words, limit the text to its core message, and try to break up paragraphs into shorter, more succinct bullet lists using as few words as possible.

• Avoid happy talk. "Happy talk" is what Steve Krug calls the text on a Web page that aims only to tell the user how great the company or the application is, without backing it up with any real substance. It doesn't tell the user what to do, how to get started, how to complete a task, or even how an application might benefit the user. Instead, it uses buzzwords and self-congratulatory statements like "We were the first development team to land on the moon while simultaneously eating breakfast, standing on one foot, and patting our heads."

  Happy talk is most likely to be found on the introductory, pre-registration screens for an application, such as the home page (you know, the page that's supposed to be one of the most important marketing tools you have).

  Get rid of the happy talk. Show screenshots, a giant Try It Now button, a tagline that summarizes the application's purpose, and a link to a (well-compressed) video about how the application works and what it does.

• Use trigger words instead of a lot of words. A modicum of trigger words is better than a lot of really informative words. Informative text is informative only if anyone reads it. And no one will. If you must include text in your interface, be sure that text includes words the user might actually look for (according to their mental model and experience level, not yours) or that will jump out and grab the user's attention. And if the text is really important, refer back to Chapter 7 to see how to make it stand out.

Designing white space

Wichita State University's Software Usability Research Laboratory (SURL) posted an article in October 2003 about the merits of white space and how it affects the usability and aesthetic appeal of a Web page. White space is any area that appears blank on a screen. It describes the buffer of empty pixels provided between areas of a page to separate them, as well as the surrounding empty spaces provided to create page margins.

SURL performed usability tests to assess the differences in performance and visual appeal of varying amounts of white space in response to a 1997 report from Web usability researcher Jared Spool that sites using more white space are inferior to more dense sites, with regard to a user's ability to find information. Three versions of the same Web page were created using varying amounts of white space (low, medium, and high amounts). Each version of the page was shown to five of 15 testers, so each person saw only one version.

What SURL discovered in their own tests is that there was no significant difference in the time it took for users to find information relevant to the proposed tasks (such as, "A friend of yours is interested in hiking the backwoods of Alaska or the jungles of the Amazon basin of South America. Find the site that mentions both of these areas."), but there were differences in the aesthetic appeal of the three different versions of the page.

Users were more satisfied with the version of the page that used a medium level of white space. They felt that a high amount of white space made the page slower because it required more scrolling to access content, but also felt that too dense of a layout made the page less readable than the others.

The tests, basically, were the white space equivalent of the story of Goldilocks and the Three Bears (without the part where the user runs out of the lab, never to be seen again). One version of the page had too much white space, while another had too little. The third, however, was "just right."

So, while white space had no apparent effect on a user's ability to complete a task, it had a great effect on how much the user enjoyed the page.

This, as you can see, makes the act of designing white space a bit dicey, because "medium" is a relative term, so a designer's ability to allow a medium amount of white space is contingent on his own definition of the term and his analysis of individual screens.

Incidentally, the part of the report that indicates that the amount of white space had no effect on the time it took for users to find information should probably be ignored. The tasks users were asked to perform during SURL's usability tests all involved searching for an appropriate link within the page, which contained nothing but three columns of black text on a white background, and section headings and a page title displayed in dark red text. Links appeared as default HTML hyperlinks, which means they displayed as underlined blue text.

Blue links stick out like a sore thumb on a page that contains nothing but text on a white background.

As you know from reading Chapter 7, color is one of the best ways to make something stand out on a page, and underlined blue text links stand out extremely well on a page full of black text. A user asked to look for a link on a Web page like this needs only to glance at the page, regardless of how much white space is used, to quickly spot all the instances of underlined blue text. Because the links are so high-contrast, a user actually sees these links before they even begin to pay attention to specific elements. As a result, this test isn't the best gauge of whether white space affects the time it takes to complete a task.

A more realistic test might require users to add a comment to a blog post, using a button graphic (one that blends in with the page's primary color palette) as the trigger to add the comment. In this case, white space would likely have a bigger effect on the time it takes to complete the task, because a denser layout would make the button harder to find.

That said, SURL's report about the visual appeal of white space is definitely worth checking out. The full report can be found at psychology.wichita.edu/surl/usabilitynews/2W/whitespace.htm.

Filling in the gaps

White space is an effective alternative to using graphics to divvy up a page into clear sections because of how the human brain works to fill in gaps. When we watch a movie, the individual frames on a reel of film whiz by us at roughly 30 frames per second. Our brains fill in the rest and fool us into thinking we are seeing real, uninterrupted motion. When we look at half of a broken, ceramic mask, we "see" the whole face. Our brains fill in the gaps.

When we look at a Web page, the same thing happens.

Two elements spread far apart appear to have little or no relationship to each other, while two elements positioned more closely together appear directly related. This is why OK and Cancel buttons are often next to each other, while a Save As button in the same dialog box, which provides a very different function, might appear further to the left, separated from the OK and Cancel buttons.

In both of these examples, we see the separation. We don't need graphics to tell us there's a division between one section and anotherwe can see it just fine. Just like we see the close relationship of two elements positioned next to each other and the lack of meaning between two elements positioned far apart, we can see that there is a difference between this column and that column even without a vertical line to separate them.

White space does a good enough job of clearly separating areas of a page without relying on the use of graphics (which must be processed by the user's brain).

Instead of relying on graphical dividers to segregate sections of application screens, we can usually rely on white space. White space gives us the same separation between elements without the extra visual load of the graphical lines the user would need to process when glancing at the page.

White space also weighs less, in terms of file size, than graphics, so pages can load more quickly.

Cleaning up task flows

Task flows are a prime area for reduction and refinement. Unnecessarily complicated screen sequences go from mildly tedious to flat-out annoying in a very short time, especially when the task is performed regularly. Decreasing the number of screens a user must visit to complete a task improves workflow and makes application more obvious.

In the aforementioned task-management application, a simple Create New Task link would make the process of setting up a new project much quicker. Yes, the addition of such a link on the Task Details screen would add clutter to that page, but the cost is minimal compared to the reward of an improved workflow.

In many Web-based email applications, users have two options for how to view messages. They can either display the Inbox in one screen and open individual messages in a new window or separate page, or they can choose to show a Preview pane on the Index page and read email messages without switching to another screen or opening a new window. The latter of these two options consolidates the workflow, decreases the number of page loads, makes window management simpler (in cases where messages are displayed in a new window), and makes the Inbox screen significantly more useful.

Entire conversations display on a single page in Gmail. Please ignore the fact that I was talking to myself.

Google's Gmail, arguably, does the best job of managing the primary task flow for checking email. There is no option to show message previews on the Inbox screenyou must click through to a different screen to read a messagebut each message is displayed in a thread. All messages from the same conversation are displayed on a single page, so users can get an at-a-glance view of the entire thread, and simply select any individual message in the thread to display it inline, according to its chronological position within the thread. If a message is the third reply in a thread of messages, it is displayed beneath the first two messages and above any messages received later on. This not only consolidates the workflow for users, but also maintains context.

Cleaning up task flows is often as simple as going through various tasks in an application and justifying everything that is encountered while trying to complete it. It can be time-consuming and tedious, but it's not complicated.

On every screen you come across in a task, write a list of everything that exists on the screen and give yourself a 60-Second Deadline (as discussed in Chapter 3). Scratch out anything you think you can get rid of, move those things to a new list, and save that list for later. Then go through the code and rip out everything you crossed off. If the page still works and the task can still be completed successfully, you're done. If not, you may have crossed off too many items.

Once this is done, write a list of the screens required to complete a task, and see if any of them can be consolidated. Can the part of the registration process where you collect a user's address information be moved into the same screen where you collect her preferred user name and password? If so, go for it.

In my task-management system, clients are listed on one screen, while projects are listed on another. If these two screens were consolidated, so that each client listing displayed underneath it a list of projects associated with that client, I could access both the Client Details and Project Details from the same place instead of drilling down.

Next, see if you can create shortcuts from one screen to another. If users commonly access two or three particular screens in the same session, provide links to all of them from each screen to make the jumps easier.

Finally, on screens where editing is allowed (or required), modify the design so the editing can be done inline instead of sending the user to an Edit screen and back to the read-only screen upon completion (known as a round-trip interaction). Inline editing is one of the best things about the rise of Ajax and DHTML. You can eliminate the need for entire screens in task flows, make the application simpler to understand, help maintain context for users (which contributes to a solid mental model), and make common operations more enjoyable.

The process of cleaning up task flows can be done at any point in your development process, including after the product has been released (in fact, this is a great excuse for releasing a new version, regardless of whether or not new features have been added). That said, it's far cheaper to do it before any code has been written. If code has already been written, money was spent to create the things that are now being cleaned up. It also means the tasks must now be retested to ensure nothing fails as a result of the improvements. Overhauling task flows while your application is still in its wireframe state, however, means you can fix things quickly and easily, and make major improvements when it's most cost-effective to do so.

Avoiding Interface Surgery

You may have noticed there is no Interface Surgery section in this chapter. There's a good reason for that.

Many of the topics in this book are related. This chapter applies to each of them, and each contributes to this chapter.

It's all related and it's all important. It's also all been said.

You've already seen examples of how to reduce clutter in an interface. The section about writing use cases in Chapter 2 described how to simplify an interaction. Chapter 3 was all about building only what's absolutely necessary. This reduces clutter by default. I've also talked about inline editing and inline validation, both of which add up to a faster and less cluttered task flow with fewer screens and fewer clicks. And designing screens in a consistent and uniform fashion contributes directly to a refined experience.

No need to say it all again.