Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Web Development

Designing Web-Based User Interfaces

, March 01, 2001


March 2001: Designing Web-Based User Interfaces

How important is user-interface design? Based on Palm Beach County, Florida's recent fiasco with the "Butterfly Ballot" during the 2000 U.S. presidential election, the design of a user interface, in this case the design of a form, can clearly be critical to your success. Had the designers of that ballot understood the basics of user interface design, there may very well have been a different outcome to the election. Granted, this is an extreme case, but the user interfaces that you design can have a significant impact on the success of your company, particularly in the competitive environment for e-commerce systems on the Internet. This month I describe techniques that can help you to improve your Web-based user interface designs, hopefully helping you to avoid a debacle of butterfly-ballot proportions.

Figure 1. Initial Page Design

This screen is difficult to read because it applies dark text on a dark background.

Figure 2. Improved Page Design

This screen is easier to read, but it still needs improvement.

Consider the design of the data entry form depicted in Figure 1 and compare it with the improved design depicted in Figure 2. Both HTML pages accomplish the same task, enabling definition of basic employee information, although by making a few simple changes the second version of the form is easier to understand and hence to use.

The most noticeable change between the two designs is the use of color. If you use color in your application, you need to ensure that your screens are still readable by following the contrast rule: Use dark text on light backgrounds and light text on dark backgrounds. Figure 1 is difficult to read because it applies dark text, black and red, on a dark blue background, whereas Figure 2 is easier to read because it uses dark text on a light blue background. Many organizations make the mistake of forcing their Web designers to use their corporate colors as the basis for their user interface color scheme—you only have to surf the Web for a few minutes to discover this. The colors of your corporate logo may look great in a magazine ad but will often prove to be horrendous for your corporate Web site. EBay has a very colorful logo, yet the company uses black text on a white background for the majority of its Web site, the same color scheme used by Amazon.com, Chapters.ca and the Barnes & Noble (www.bn.com) e-commerce sites. Black text on a white background provides the greatest range of contrast available.

Figure 2 also addresses a second misapplication of color, the solitary use of red to indicate required fields, by introducing asterisks as a secondary indicator. A small but significant percentage of the population is either fully or partially color blind—for many people, the red text looks black, making it impossible for them to distinguish the required fields from the optional ones in Figure 1. I also moved the required fields to the top of the page, grouping them together to hopefully increase the chance that they are filled in the first time. The problem with this approach, however, is that the fields may not be in a natural order, something that user-interface walkthroughs with my users would reveal.

Figure 2 depicts improvements to the wording of several of the field labels. The text you display on your screens is a primary source of information for your users. If your text is worded poorly, then your interface will be that much more difficult to use. Using full words and sentences, as opposed to abbreviations such as "dt" for date and "Addr" for address, makes your text easier to understand because your users don't need to perform any translations. Furthermore, each label is capitalized the same way in Figure 2, a minor but important improvement as it promotes consistency, which in turn makes your user interface easier to understand and to learn. Figure 2 also drops the extraneous use of "Employee" in front of the "First Name" and "Last Name" fields—it's an employee editing screen, so the user knows he is inputting the name of the employee. Similarly, any messages displayed to your users should be worded positively to imply that the user is in control and provide him with insight into how to use the application properly. For example, which error message is more appealing: "You have input the wrong information" or "A phone number should be ten digits in length?" Furthermore, your messages should be worded consistently and displayed in a consistent place on the screen. Although the instructions "The person's first name must be input" and "A start date should be input" are worded well when considered separately, together they are inconsistent. A better and more consistent wording of the second message would be "The start date must be input." Although neither of the figures shows a message, wording is an issue for any results returned by your data validation routine for this HTML form—either a descriptive error message or a confirmation that the system has received the information.

I also changed the order in which the data entry fields appear in Figure 2. First, the fields pertinent to describing the person—first and last name, start date, gender, birth date, and home phone number—were grouped together, and the fields pertaining to the employee's mailing address were also put into their own grouping. I placed a box around the address fields to make it visually explicit that they belong together, allowing me to remove the extraneous use of "Addr" for those field labels. I could just as easily have grouped the address fields by introducing white space, in this case a blank line, above the fields (the approach taken in Figure 3).

Figure 3. The Page Design Further Improved

The biggest improvement in this design is a more efficient adjustment of the editing fields.

Implementations of several of the data-entry fields were improved for various reasons. The birth date entry field was replaced with drop-down list boxes, consistent with those used for the employee's start date. The lengths of the fields are now consistent; for example, the first and last name fields are now the same size. The phone number field was combined into one, making field navigation easier, although increasing the need for data-formatting logic to handle input such as "(905) 555-1212," "905.555.1212" and "9055551212." Finally, the gender field was changed from a drop-down list box to a set of radio buttons; this widget is appropriate for a small number of mutually exclusive options. In general, it's important to understand the available widgets, so you can use the right one for the right task. The best way to learn how to use widgets properly is to read and understand the user-interface standards and guidelines that your organization has adopted.

Although the page design shown in Figure 2 is a significant improvement over that shown in Figure 1, it can still be better. Figure 3 shows the improvement, the biggest change being a more efficient alignment of the editing fields. When a page has more than one editing field, I have always found the cleanest way to align them is to left-justify edit fields or make the left-hand side of each edit field line up in a straight line, one over the other. I then right justify the labels and place them immediately beside their corresponding fields (many people will also left justify the labels but this can be harder to read when the labels are of differing lengths).

I added example text—for example, (905) 555-1212—after some fields to help explain the format of information that the user should input. This is an easy way to make your system easier to understand, while improving the quality of the data being input. I removed the use of red text for required fields because the use of asterisks is sufficient for this purpose. I also removed the box around the address fields: Had the page been more complicated, I likely would have left it in.

Beyond a Single Page
The most important thing you can possibly do is ensure your user interface works consistently. If you can click on items in one list and something happens, then the same sort of thing should happen when you click on items in any other list. Put your buttons in consistent places on all your pages, use the same wording in labels and messages, and use a consistent color scheme. Consistency in your user interface enables your users to build an accurate mental model of the way it works, and accurate mental models lead to lower training and support costs.

You should consider supporting both novices and experts. For example, you may decide to build two versions of the employee editing page, one to support data entry clerks in your human resources department and one for employees to edit their own data. The editing page for data entry clerks may be very simple, removing lookup features in favor of quick-entry text fields, whereas the page for employees may have more lookup features and offer links to available help pages.

Navigation between pages, screens and report items is important. If it's difficult to get from one page to another, then your users will quickly become frustrated and give up. When the flow between HTML pages matches the flow of the work the user is trying to accomplish, then your application will make sense to your users. Because different users work in different ways, your system needs to be flexible enough to support their various approaches. User interface-flow diagrams ("Extreme Modeling," Thinking Objectively, Nov. 2000) should be developed to further your understanding of the logic flow of your user interface, enabling you to address areas that need improvement.

Similarly, navigation within a page is important. In Western societies, people read left to right and top to bottom; therefore, if this is your target audience, your user interfaces should be designed to reflect this reading pattern. In short, navigation between widgets on your screens or pages should be organized in a manner that your users will find familiar.

When designing systems, expect your users to make mistakes. How many times have you accidentally deleted some text in one of your files or the file itself? Were you able to recover from these mistakes or were you forced to redo hours, or even days, of work? To err is human, so you should design your user interface to recover from mistakes made by your users.

An important factor in user interface design is considering access for the disabled, particularly people who have impaired vision. At a minimum, you should always have text representations for any graphics displayed on your Web pages. Further reading on this topic can be found at the W3C Web Accessibility Initiative site, www.w3.org/WAI/References/.

Functional, Not Flashy
Chaos theory tells us that the flapping of a butterfly's wings in Thailand can cause a hurricane in the Caribbean; user-interface design theory now tells us that the poor design of a butterfly ballot in Florida can embarrass the U.S. throughout the world. If there is one message you should take away from this column, it's that you don't need to make your user interface flashy to make it effective. The page design of Figure 3 isn't fancy, but it gets the job done. In fact, the most successful e-commerce sites on the Web focus on functionality over flash. Techniques such as the appropriate use of color, field alignment, text wording, consistent field design and the appropriate use of user interface widgets go a long way to the development of good user interfaces. Take the time to learn the basics of user interface design: Your users will thank you for it.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.