Using published standards and guidelines to catch usability issues.

What can I say? We blew it. The web came along, and we human factors engineers were AWOL. Not that anyone tried to include us. I know I was home at the time, yet CERN never called me to say, “Well, Mike, we’re going to launch the Information Age, and we’re wondering if you had any advice.”  Maybe they thought allowing for the human factor just wasn’t that hard, so they’d take care of it themselves. Typical. And to be honest, it wasn’t that hard. Making links appear bright blue seemed like a reasonable enough standard. In a time when web pages generally appear as black text on a pale gray background, blue would stand out, suggesting liveliness and therefore interactivity, while avoiding the Western emotional associations of green, yellow, or red. Underlining links was icing on the cake, providing a redundant cue that aids accessibility. They were probably pretty proud they thought to do that.

The Web That Wasn’t

Of course, if they had consulted a human factors expert, she or he would have pointed out that bright blue objects can be difficult to focus on, especially for older users -not too good for reading text. She or he would have also pointed out that underlining interferes with reading, owing mostly to masking of the decenders of lower-case letters.

I like to think we would have done better, if we were involved. Maybe we would’ve suggested background shading to indicate links, rather than colored font and underlining, This would maximize readability while still making links stand out and look active in an accessible manner, like highlighted text in a physical book. We could have allowed developers to specify the size of mouse-sensitive areas so that links with short labels could have large targets. Lists of links would appear as unbroken shaded rectangles, like sidebar menus often do today, eliminating the dilemma of choosing between cluttering underlining for link lists and no underlining cues for in-line links in order to achieve a consistent link appearance across the site.

We could have tested and developed a standard set of icons to put with each link text, like a cite or footnote number, that would provide a redundant cue of a link. These would distinguish links from other uses of background shading (which would be rare, much as it is today) and identify links when the presence of shading is ambiguous (e.g., when the entire page is links). But most importantly, the icons themselves would indicate:

• The location of the linked content, whether on the same page, the same site, or another site.
• The medium or format of the content (e.g., html, pdf, image, sound, or video).
• Whether the link opens a new window or not.
• Whether the content had been visited before or not (rather than using arbitrary color, a standard that has fallen into disuse since no one uses standard colors anymore).

With some minor tweaks to HTTP and HTML behavior, the icon could indicate whether the content has been updated since the last visit, which is often what users really care about. Maybe it could even indicate if a link is broken.

Tooltips would provide text representation of the icon’s information, as usual, but with standard icons, experienced users can extract this information with a quick visual sweep of the page. The tooltip would also display the size of the content (or estimated download time) and URL of the content (if no title tag is provided), rather than it appearing far down in the status bar where few users notice it. Animation in the icons would indicate if the browser is attempting to retrieve the content, so users can see the effect of their clicks right where they’re looking, rather than shifting attention to a distant and ambiguous throbber or status bar.

Oh, well, too late now.

Standards for Today

Returning from dreamland, it seems that too many web sites of reality have enough trouble complying with the meager existing standards and guidelines of today. Sites respond too slowly. Trivial input format variations are rejected. Unnecessary navigation and other input are imposed. Lengthy work by the user is discarded without warning or alternatives. Links masquerade as ordinary text and vice versa. Information is shown in no meaningful order to the user.

These are obvious design flaws. Anyone with any UX background could predict that such things will interfere with usability, yet somehow they make it into production. My hunch is that whoever was in charge of the web site just wanted it that way (”it makes perfect sense to me“), and summarily dismissed others’ concerns as merely a difference of opinion or taste. A simple usability test may settle the issue, but you can’t test everything and not every issue is truly testable by a small sample size usability test. Academic research results are great, but some issues don’t interest academic researchers. They want to build general theories of HCI or develop innovative interfaces. Testing something with obvious results doesn’t fit well with that.

That leaves citing authoritative standards and guidelines to bolster your argument against bad design. There are a number of such standards and guidelines you can cite, and they all have their uses, but also their limitations:

• Usability.gov represents the gold standard of web UI guidelines, with each based on cited research. How this became the responsibility of the National Cancer Institute is beyond me, but I’m glad they did it. However, being researched based, they tend to be limited to issues of academic research interest.
• Lynch and Horton’s Yale Web Style Guide provides valuable guidelines, although it tends to focus on graphic design and typography.
• Ameritech Web Page User Interface Standards and Design Guidelines by Mark Detweiler and Richard Omanson has many recommendations that are as relevant today as they were back when most screens were 640 by 480 pixels. That was also back when there was a company called “Ameritech,” and copies of this document are hard to come by now.
• W3C Accessibility standards have done as much to improve the UIs for typical users as it has for those with disabilities. We all benefit from site characteristics like proper use of markup and redundant channels of communication. But, not surprisingly, these standards have limited scope for usability.
• Operating system guidelines, such as those for Apple, Microsoft, and Gnome, may be used. For example, they tell us we should label our buttons with what they do (e.g., “Register”), rather than with a general uninformative term (e.g., “Submit”). However many such guidelines were never intended to apply to the web world, and they’re easy to dismiss as not applicable.
• Guru books, like those by Krug and  Nielsen, contain solid advice. However, some may dismiss them as just the opinion of someone who happens to have a high hourly consulting rate.

Perhaps less well-known are more general human factors standards that also may be applied to web site design. Various major organizations have such standards (e.g., ISO, NASA, FAA, ASTM) that provide a significant supplement to the above standards and guidelines. Among the most venerable standards documents is the US Department of Defense Design Criteria Standard: Human Engineering, known to its friends as MIL-STD 1472. First published around 1968, MIL-STD 1472 has served as the inspiration, if not the source, for many human factors standards to come, making it the literal mother of all HF standards. Originally a consolidation of older standards and updated semi-regularly ever since, MIL-STD 1472 represents the collective research and operational experience of decades of human-machine performance under the most demanding circumstances. There’s nothing quite like life-or-death situations to highlight usability problems.

Human factors as a distinct field came into its own during World War II when the military was confronted with ordinary people having to operate extraordinary complicated and unfamiliar technologies of the time, like radar, multi-engine high-performance aircraft, bombsights, and artillery targeting computers. It was a situation analogous to the recent one with the web, with ordinary people using increasingly capable servers and networks. While there’s a huge gulf separating a 1940s analog electromechanical artillery computer from the modern gigahertz and terabyte web server, the human operators are in many ways still the same. Thus, many MIL-STD standards remain relevant.

MIL-STD 1472 is a standards document, not a best practices document. It specifies the minimal requirements, and as such will only catch gross usability flaws. One has to wonder about some of the standards, like 5.2.3.1.5.1 Graduations, which specify that the gradations of analog gauges “shall progress by 1, 2, or 5 units or decimal multiples thereof.” I mean, did some manufacturer deliver a jeep with a speedometer marked at 0, 7, 14, and 21 mph? Who would ever think of designing something like that? Well, presumably someone did, and the results in a time of war were ugly, so they made a standard to prevent it from happening again. Basic standards like these are fine for our purpose of dismissing stupid designs that aren’t worth a usability test.

MIL-STD 1472 and Web Sites

Of course, general standards like 1472 have their weaknesses too. But, along with other standards and guidelines, it’s another tool to have in your toolbox. MIL-STD 1472 comprises human factors standards for all kinds of products, from safety glasses to aircraft carriers. Standards scattered throughout the document can apply to your web site. For example, much of Section 5.5 Labeling applies as much to headings, fields, and link labels on a web site as they do to physical labels. However, Section 5.14 is dedicated specifically to computer UIs, so let’s focus there.

As might be expected for standards dating to the 1960’s, much of Section 5.14 were intended for antiquated computer systems featuring simple menus and forms. Contemporary GUI features, like direct manipulation, multiple windows, and scrollbars, are not addressed in the latest version, 1472-F. So that makes it just about perfect for your average modern web site. Strip away the browser, and you’ll recognize that a website is not all that different from early interactive character-cell user interfaces seen in the 1970s. Users may use multiple windows or tabs, but web sites don’t. Web sites divide their UI into pages, while character-cell UIs divide them into screens. The typical web site is almost entirely a menu interface. Whether arranged in a neat sidebar or distributed in-line with content, each link is by most definitions a menu item. Occasionally a web site has a modal form to complete, where the user keys in some simple alphanumeric strings into fields and selects an Execute command when done. That’s pretty much what the military was dealing with 30-odd years ago.

Nonetheless, general standards need to be subject to interpretation when applying them to a specific technology like web sites. The text of the standards may have a legal tone to them, but for the purpose of achieving the best usability, they should be interpreted according to the spirit of the law, not necessarily the letter. Users don’t care if you’re technically complying with standards they’ve never heard of. They only care if the web site gets them the content they need.

If you’re new to reading standards, there’s a big difference between a standard that uses “shall” versus “should.” “Should” indicates a recommendation, something you as a designer can choose not to comply with if you have good reason. In my book, a “good reason” is research-backed analysis or usability test results that show that following a standard will result in inferior usability. You shouldn’t violate a “should” because of a hunch on user performance or to avoid inconveniencing the developers. “Shall” indicates a requirement. The design must follow “shalls” to be in compliance with the standard.

Here, then are some 1472 standards that I think are most apt for web sites along with my interpretation for them.

Top 1472 Standards for Web Sites

IA and Layout

5.14.3.2.2.2 Related data on same page. When partitioning displays into multiple pages, functionally related data items shall be displayed together on one page.

This means that content shall be divided among pages by function, task, or similarity. Prose and forms shall not be arbitrarily divided into pages, such as done to articles at the web site of the Minneapolis Star-Tribune among other on-line newspapers and magazines. The readers get to the end of a page and have to mentally cache the context while they click Next Page and wait several seconds for all the ads to load before they can proceed. And sometimes the only thing on the subsequent page is the post date and contact information for the writer.

5.14.4.1.7 Hierarchical process. The number of hierarchical levels used to control a process or sequence should be minimized. Display and input formats shall be similar within levels. The system shall indicate the current positions within the sequence at all times.

The first part tells you that you should generally go for a relatively broad and shallow IA hierarchy to minimize the time-consuming page-loads a user must endure. It’s a “should” rather than a “shall” because at some point too much content or too many links on one page will interfere with usability, so the standards give you an out. However, it does mean you should avoid pages with sparse content, for example, any time the content takes less than 700 vertical pixels to fill. If two pieces of related content can be visible on the same page without scrolling, then they should be on the same page.

The above standard also covers the labeling of pages, which is elaborated by these standards:

5.14.3.2.2.3 Page labeling. In a multipage display, each page shall be labeled to show its relation to the others.

5.14.3.1.12 Page numbering. Each page of a multiple page display shall be labeled to identify the currently displayed page and the total number of pages, e.g., Page 2 of 5.

Collectively, these standards say that if the page is part of a linear or hierarchical navigation structure, then the pathway through the structure to the page shall be represented on the page (e.g., with breadcrumbs). They also say that you shall show progress through linear structures, like search results, wizards, and multi-page forms.

5.14.3.2.5 Context for displayed data. The user should not have to rely on memory to interpret new data; each data display should provide needed context, including recapitulating prior data from prior displays as necessary.

5.14.4.1.5 Availability of information. Information necessary to select or enter a specific control action shall be available to the user when selection of that control action is appropriate.

These standards mean that the information that is typically referenced to complete a task shall be available on a page supporting that task without the need to navigate to another page in the site. This is especially important for web forms where navigating away to try to get some key piece of information can mean wiping out the work the user had done so far.

5.14.3.1.4 Order and sequences. When data fields have a naturally occurring order (e.g., chronological or sequential), such order shall be reflected in the format organization of the fields.

Content shall not have an arbitrary order but rather shall be ordered and/or grouped by at least one of the following as determined by the users’ task:

• Frequency of use.
• Importance to task.
• Sequence of entry or review.
• Functional relations.
• Functional similarity.
• Name (i.e., alphabetical).
• Date or time stamp.

For dynamically created forms or tables, this means don’t forget the ORDER BY clause in your stored procedures. Note that some of the above criteria for ordering imply your database may need fields specifically for determining display order (e.g., task importance).

5.14.3.5.10 Justification of numeric entry. Users shall be allowed to make numeric entries in tables without concern for justification; the computer shall right-justify integers, or justify with respect to a decimal point if present.

This means that columns of numbers that use the same units shall have the decimal place of the numbers vertically aligned, so users can compare numbers easily. Columns should look like this:

5.0750

1.8000

46.5000

.5209

8.0000

Rather than this:

5.075

1.8

46.5

.5209

8

For user-entered numbers, a form shall pad the numbers as necessary to keep the decimal points aligned irrespective of what the users type.

5.14.4.2.6 Simple menus. If number of selections can fit on one page in no more than two columns, a simple menu shall be used. If the selection options exceed two columns, hierarchical menus may be used.

This means use simple (non-hierarchical) menus up to two columns wide rather than split the menu into two pages, assuming the menu items fit on a page with the other content intended for the page. Avoiding a click to navigate down a level in a menu hierarchy is worth the added scan difficulty that two columns imposes. However, once you get to needing three columns or more, you might be better off splitting the menu up onto separate pages. That’s up to you.

5.14.3.5.13 Column scanning cues. A column separation not less than three spaces shall be maintained.

Translating that to the web, columns in tables shall be horizontally separated by a distance equal to 3 spaces of Arial font of the same point size as used in the columns when the browser is set to display medium text size. This makes the columns appear as cohesive wholes, making it easier to scan down them without the eye “jumping” to an adjacent column. In some cases, such spacing obviates the need for cluttering vertical rules, further improving scanability.

Graphic Design

5.14.3.3.1 [Display Coding] Use. Coding shall be employed to differentiate between items of information and to call the user’s attention to changes in the state of the system. Coding should be used for critical information, unusual values, changed items, items to be changed, high priority messages, special areas of the display, errors in entry, criticality of command entry, and targets. Consistent, meaningful codes shall be used. Coding shall not reduce legibility or increase transmission time.

In other words, colors and other graphic elements should be selected to consistently mean something, not just make the web page look good. Specifically:

• All navigation menus shall use the same color and style for all pages.
• The navigation menu shall appear visually distinct from any other content that may appear in its place on a page.
• All text links shall have the same color unique to links, except that visited links may have a different color than visited links.

5.14.5.6 Highlighted option selection. Any displayed message or datum selected as an option or input to the system shall be highlighted to indicate acknowledgment by the system.

This means selected items need to be somehow graphically distinguished from non-selected items. For example, on a navigation menu sidebar, the selected menu item shall change appearance on selection, and that appearance shall be maintained as long as that menu selection is maintain. If the menu item corresponding to your current page looks like all the other menu items, then you’re doing it wrong.

5.14.4.8.3 Supplementary verbal labels. Where icons are used to represent control actions in menus, verbal labels shall be displayed, or made available for display, with each icon to help assure that its intended meaning will be understood.

So each icon needs at least a tooltip, but keep in mind these are minimum standards. For most actions, you get better usability if you include a static text label, or even use a text label instead of the icon.

Responsiveness

5.14.9 System response time. Maximum system response times for real-time systems shall not exceed the values of Table XXII.

Below I’ve reproduced portions of Table XXII with a separate column to give the equivalent application for web sites. For example, any user mouse click, including input to a custom AJAX control, shall result in some kind of a visual response within 0.2 seconds. A page shall begin to appear in a window within 2 seconds after the user selects its link.

Input	sec.	Web Equivalent
Key Print	0.2	Display of a keyed character after any per-character validation and correction.
XY Entry, Pointing	0.2	Response of some kind of visual verification to a mouse click.
Sketching	0.2	Update period for any drawing or any dragging.
Page Scan	0.5	Update period for carousels and other scrolling controls.
Page Turn	1.0	Response of tabs, lightboxes, and other loading of content within part of a web page.
Host Update., Simple Inquiry	2.0	Response from selecting a link until a page begins loading.
Error Feedback	2.0	Response for any server-side validation after data submission.
Complex Inquiry	10.0	Response for ad hoc queries or other operations involving submission of multiple fields.
File Update	10.0	Response for loading non-HTML content, such as pdfs.

Once again, these are minimum standards assuming worse-case conditions.

Too often discussions of response time for web sites take one of two extremes. One extreme is ”make it as short as possible.” This does little to help you specify the appropriate server and network performance for the real world. The other extreme is, “right before the point where users abandon the site.” I would hardly define “usable” to mean “the level of performance where users just barely stop assuming your site is broken.” Table XXII provides an alternative to the extremes that has held up remarkably well over the decades.

5.14.1.2 Computer response. Every input by a user shall consistently produce some perceptible response output from the computer.

5.14.5.2 Stand-by. When system functioning requires the user to stand-by, a WORKING, BUSY, or WAIT message or appropriate icon should be displayed until user interaction is again possible. Where the delay is likely to exceed 15 seconds, the user should be informed. For delays exceeding 60 seconds, a count-down display should show delay time remaining.

5.14.2.1.3 Processing delay. Where system overload or other system conditions will result in a processing delay, the system shall acknowledge the data entry and provide an indication of the delay to the user. If possible, the system shall advise the user of the time remaining for the process or of the fraction of the process completed.

For most web sites, the above standards are not much of an issue. Most input is asynchronous, so there’s no need for a BUSY indication. The browser’s throbber provides immediate response for the most common input, link-clicking, so you don’t have to worry about it. Start loading your pdfs and other bulky files within 10 seconds for worse case conditions, as discussed earlier, and you don’t have to worry about informing the user that they’ll need to wait over 15 seconds. However, if you start getting fancy, employing AJAX or Flash which can subvert the throbber and other browser feedback, then you may find you have to create your own feedback, including progress bars or equivalent for anything over 60 seconds.

5.14.2.1.8.4 Explicit actuation. A separate, explicit action, distinct from cursor position, shall be required for the actual entry (e.g., enabling, actuation) of a designated position.

5.14.3.6.9 Confirming cursor position. For most graphics data entry, pointing should be a dual action, with the first action positioning the cursor at a desired position and the second action confirming that position to the computer. An exception may be a design allowing “free-hand” drawing of continuous lines where the computer must store and display a series of cursor positions as they are entered by the user.

Here the main culprits on web sites are a breed of Javascript pulldown menus that display their contents on mouse-over rather than a click. Menus shall only appear when the user clicks the mouse. However, the above standards should not be interpreted to preclude the use of mouseover effects to provide pointer position feedback or supplemental information to the user, such as through tooltips.

Forms and Fields

5.14.3.1.6 Recurring data fields. Recurring data fields within a system shall have consistent names and should occupy consistent relative positions across displays.

This is just a matter avoiding oversights and double-checking that you’re being consistent. You don’t want people being unsure if the “Check Date” is necessarily the same the “Payment Date.”

5.14.3.1.1 Consistency. Display formats should be consistent within a system. When appropriate for users, the same format should be used for input and output. Data entry formats should match the source document formats. Essential data, text, and formats should be under computer, not user, control.

This standard was probably made with keypunching in mind, but in this era of copy and paste it’s ever more important. For example, your web site should never reject the input of a date, phone number, credit card number, or other datum when it has the same format your own web site uses.

5.14.3.7.10 Predefined formats. When text formats must follow predefined standards, the required format shall be provided automatically. Where text formats are a user option, a convenient means should be provided to allow the user to specify and store for future use the formats that have been generated for particular applications.

5.14.3.5.7 Numeric punctuation. Long numeric fields should be punctuated with spaces, commas, or slashes. Conventional punctuation schemes should be used if in common usage. Where none exist, a space should be used after every third or fourth digit. Leading zeros shall not be used in numerical data except where needed for clarity.

And while we’re on the topic of credit card numbers, we must stop this madness of rejecting user input of these numbers with spaces. For any formatted string input, if the user omits delimiters for formatted text, than the delimiters should be added automatically to user input without displaying an error message. Prohibited characters (like letters in a credit card number) should be automatically suppressed or removed from user input without displaying an error message.

5.14.4.3.6 Cursor. A displayed cursor shall be positioned by the system at the first data entry field when the form is displayed.

This means that when displaying a cleared form or a form with new content for a session, focus shall be placed on the editable control at the topmost leftmost position. Save the user from having to use the mouse to click into the field. This applies to pages for searching and querying.

5.14.7.1 Workload reduction. Default values shall be used to reduce user workload. Currently defined default values should be displayed automatically in their appropriate data fields with the initiation of a data entry transaction and the user shall indicate acceptance of the default.

5.14.7.4 Defaults for sequential entries. Where a series of default values have been defined for a data entry sequence, the experienced user shall be allowed to default all entries or to default until the next required entry.

That means that when a list box, dropdown list (combo box), checkbox, or radio button (option button) is used to acquire user input of an unknown value, it shall default firstly to a value that does not result in damage to the system or lost of data, and secondly to the most frequent value.

I’m not sure where the web got the idea to never use defaults, except to default to opt in for annoying email spam. Radio buttons are often left with none selected. Dropdown list default to nonsensical “Select an option.” values. Thick-client desktop apps worked fine with defaults for these controls for years before the web showed up. I suspect that many web designers think you get more accurate data if you force the user to explicitly choose an option. While there may be situations where this is the case, usually defaults make it more likely you get accurate data, especially when there’s one choice that is likely to be correct. By freeing the user from selecting the value you avoid the possible slips the users might make, as well as make input faster for the users.

5.14.8.1 Error correction. Where users are required to make entries into a system, an easy means shall be provided for correcting erroneous entries. The system shall permit correction of individual errors without requiring re-entry of correctly entered commands or data elements.

If the user makes an error on a form and submits, you can show an error message on the subsequent page. That’s not the best way of handling errors, but it meets a minimum standard of usability. However, when the user goes to the form to correct the error, all entries for all fields shall be just as the user left it. Do not present a cleared form. Do not clear any fields, not even the password field. It adds work and sets the user up for another error.

5.14.4.1.13 Feedback for correct input. Control feedback responses to correct user input shall consist of changes in state or value of those display elements which are being controlled and shall be presented in an expected and logically natural form. An acknowledgment message shall be provided only where the more conventional mechanism is not appropriate or where feedback response time must exceed one second.

5.14.5.4 Input confirmation. Confirmation shall not cause displayed data removal.

Web forms use way too many confirmation pages. Partly this is because of the unreliability of web connections and the long delay between the user selecting the Submit button and the server sending some kind of acknowledgment. As a minimum standard, a confirmation page is acceptable for such cases, but the confirmation page should display what data is being confirmed. A purchase confirmation, for example, should list the products, prices, and shipping.

Once you get into AJAX, with response times less than a second, there shall be no confirmation message. It is sufficient and less distracting to display the changes to the data as the confirmation.

Summary Checklist, Such that it is

Problem: Preventing bad designs without relying on usability testing.

Potential Solution: Use standards and guidelines such as MIL-STD 1472

For more of my interpretations of MIL-STD  1472 for the apps, specifically for tables, see Table usability/Readable font for a data table at UI StackExchange.