Ask Eric: Questions & Answers

November 2, 2004 – submitted by Nancy Klein of USA

Question: Hi Eric,
I would appreciate any help on these two topics.
First: where should the required field indicator be placed, next to the label or the text field?
Second: can a drop down be used instead of a radio button? This may save the user from having to alternate between mouse and keyboard.
Thank you.

Eric's response: There are several ways of placing the required field indicator. The most critical issue is that you be consistent in placement. The second issue is that you need to label the indicator (e.g., *=required entry). In placement, I favor placing an indicator immediately before each required field.

On the second question; Don't kid yourself. Few users will know how to use the drop down from the keyboard. If you have expert users who are comfortable with this that is fine. But for most users the radio button is best (given space and non-dynamic data). The radio button makes all choices immediately visible and requires only a single mouse click.

September 21, 2004 – submitted by Fiona Hamilton of Australia

Question: I would like to know if there is a standard for display of page-loading status to a user. The application we are working on has some pages that are slow to download as they are either fairly graphically intense or call on data from other systems. Based on the research we have done the users are OK with the speed but would like an indication that the page is still loading etc. We have a couple of ideas involving the hourglass icon as well as page loading status bars, with both blank page in background and display of the page as it loads. Are there any standards on how we should be addressing this? Any suggestions?

Eric's response: If the response time will be under two seconds you do not need feedback. If the response time is consistent and at an expected slow level you do not need feedback. If there is variability in the response time or it is unexpectedly long then provide feedback.

The best feedback shows progress (not just an animated hourglass). It is also best if you can start slow and make the movement increase in speed. Never have a fast start and then have it slow down.

September 14, 2004 – submitted by Sudhir Nain of India

Question: Hi Eric,

What are the user expectations from a multi-platform deployment vis-a-vis its GUI. For example, would a linux user expect the installer GUI to to emulate RPM (Linux installation software) GUI.

Doesn't a one-GUI-fits-all-platform approach confuse users.

Eric's response: There are very different conventions between a browser-based application and a windowing application. You really need a different set of standards. Between the windowing applications the differences are smaller and a standard can be stretched to fit without too much trouble. There must certainly be modifications (for example the Apple mouse selection system is different). However, if you are only dealing with the installation package I would be far less concerned. The installation is a single use facility that needs to be completely self evident. I think you can safely target a single UI for the installation.

July 14, 2004 – submitted by Rose Capra of Overland Park, KS

Question: What are the usability guidelines when presenting information in a PDF format? Should we avoid it all together or are there certain instances where it would be OK?

Thanks,
Rose

Eric's response: The good news is that PDF will work for a large number of users. However, it takes time to load and is a completely different interface. I feel that the PDF format is a good response to the POOR practice of dumping paper documents online. It maintains a solid format and has controls appropriate to working with a document. However, it is far better to reorganize a document for easy online access instead of dropping it in PDF. But this does take time.

June 22, 2004 – submitted by Michael Bushe of Hopkinton, MA

Question: I am creating a Rich Client Application with a number of form dialogs. In a form dialog is it better to always enable the OK button, then show the user why the form can't be submitted via a popup message, or is it better to gray out the OK button until the form is complete?

In our gray-out example, each field requiring outside validation indicates that it's validating (Background yellow and "Searching for xxxyy"), and if it fails it indicates so (Background Red and "No results for xxxyy"). Required fields are indicated by a red asterisk (and a "*Required Field" label at the bottom of the form). As a further indicator, when disabled, the OK button's tooltip will indicate why it is disabled ("Can't submit order because there's no security specified")?

Thank you.

Eric's response: NEVER NEVER NEVER gray out an OK button. NEVER. Imagine the user THINKS the form is ready to submit, but finds The button inactive. It is FAR better to let the user click OK and then get guidance.

June 8, 2004 – submitted by a Sandy Stanton of Bloomington, MN

Question: When is help no longer helpful? I am designing a Web application where we have content-specific help as well as overall help available. For example, if a reader wants help on how to complete a task, but doesn't know where in the Web application to go, he or she can choose the overall help link located in the upper right corner of the Web application and navigate to the appropriate topic. If a reader is located on a specific page and wants help regarding the current page, he or she can choose the content-specific help located in the content area of the page.

Both the overall help and the content-specific help contain the same topics of information (the reader can navigate using an index or a search function). The overall help starts at a how to use the help system page, whereas the content-specific help starts at a page relating to the current content.

My challenge is to find a way to let the reader know what the similarities and differences of the two different help links are. I know that the links shouldn't both be named "Help", but I don't know what to label them – "Help" for the overall help and "Page Help" for the content-specific help? Or, should there not be two different help links? If so, which one should I keep and which one should I remove?

Eric's response: The answer is 'usually'. It is very rare to find a help system that is actually used much. This is particularly true in a Web environment. Users rightly expect an interface to be self-evident. You may want to provide VERY occasional links to descriptions of specific fields (providing popup descriptions) in cases where many users would be confused. An example is a popup describing where to find the security code on the back of a credit card.

May 24, 2004 – submitted by John Taylor of USA

Question: How helpful can Formal Task Analysis be with regards the problem of application-specific, "component visualization"?

Eric's response: It is important to know THAT a component must be visualized, and WHAT a user will be trying to understand. But beyond that, task analysis is not the primary tool for visualization design. Visualization is a specific field with specific research. For example, you must decide between a realistic photo view of the component, or a simplified cartoon view. If you are teaching the CONCEPT, the cartoon is likely to be better. If you want to optimize transference into the real-world environment, you may want to include the detail (and visual noise) of a real world photo view.

April 16 , 2004 – submitted by Jennifer Rose of Martinez, GA

Question: I'm looking for information about designing lists for optimal usability. I work for a manufacturing company, and we (the Tech Pubs dept. of which I'm a part) produce Illustrated Parts Lists (IPL's), which are actually books, to help the dealers and distributors identify and order parts from the company. (We plan to offer this information online via a software tool like Enigma, but not in the immediate future.)

These IPL books consist of spreads that have an illustration labeled with number balloons on the left-hand page and a hierarchical numbered list on the right-hand page. The items in the numbered list on the right-hand page correspond with the numbered balloons in the illustrations on the left-hand page.

Some of the illustrated components are very complex and consist of many, many subcomponents. The left-page illustration(s) show how all of the subcomponents relate and fit together to form the main component. Usually, all of the subcomponents in the illustration are tagged with number balloons, so the corresponding numbered list on the right-hand page becomes quite lengthy (kind of like my rather verbose message). To ensure optimal usability in our IPL's and the future Web versions, we are looking for information about the ideal number of items to include in a list. How many are too many, and how many are too few?

We need information that we'll be able to apply to our unique situation, and any assistance you could provide would be most helpful. Thanks for your time, and my apologies for the lengthy message.

Eric's response: In general, when developing a paper deliverable as you describe I have two concerns. The first is the ability of people to FIND the part they need. This can be very complex. The customer may not know the part number or name. They may need to find the part by function, but there is rarely a simple taxonomy that works for everyone. Pay attention to the structure!

The second issue is the detailed design and operation of the pages. The problem you described is typical of a design that is stretched to (and beyond) its limits.

First I would like to AVOID the numbered balloons if it is possible. It is far better to just have the text attached to the item, rather then forcing the user to convert to a number. So a line connecting the image and text can work better. But it becomes untenable as you get too many items.

Your numbering system may help the problem of a spaghetti of lines. So that is good as the number of references gets longer. But as you observe, even that design will run into problem as the list gets long.

With your nightmare assemblies, try using grouping. So instead of a flat list of numbered items, try to address logical segments. Break down the part descriptions so there are perhaps 7-10 items in each area. So as an example, put a small image of the overall part at the top. Then below that have several boxes showing parts of the unit.

So if the 'Part' was an aircraft, show the aircraft (Cessna 310R) with a small overall image. Then have a box for the fuel system, box for the electrical system, box for the avionics, and so on.

Sorry for the long response, but was interesting question. ;)
Eric

March 23, 2004 – submitted by Barbara Davis of Denver, CO

Question: Error popups versus error pages – are there any standards around this? Can you direct me to them?

Eric's response: From the usability viewpoint...
For high-volume data entry don't interrupt the user. Provide error messages when they submit the page. For all other situations use popup error messages to flag errors right AFTER the user has left the field.

For a technology viewpoint....
The Web does not generally allow all error handling to happen on the page. It requires processing at the server. So we popup those messages that we CAN, and then we give page-level error messages when the server has gotten the page.

Incidentally, required field edits must always be page level.

March 1, 2004 – submitted by Susan Parker of United States

Question: We have been debating this editorial style question about capitalization rules for headings:

Which is more readable on Web pages?
A) "Book title" style? (Capitalize in the manner you would for a book title or title of literary/artistic work.) or
B) "Journalistic" style? (Capitalize first letter and proper nouns only – similar to how most newspapers do their headlines and subheads.)

We actually decided it depended on the placement, use, length, etc. of the heading. We thought the shorter, and more "major" the heading, the more likely it was that book title facilitated readability; the longer, and less "major" the title, journalistic is probably better. We settled on a standard of book title style for most major navigational elements, which tend to involve 1-3 often include more than 3 words, and appear more frequently as you drill down into more granular content. We based our decision on usage of journalistic style in part on the advice of the WebStyleGuide site. (We settled on this standard for some other reasons too – including varying abilities of content authors to follow a standard consistently, visual design, and certain aspects of how our content management system works.) Looking to bolster our decision (or to undo it if it is a bad decision), I was wondering if you had advice, and or thoughts counter to what webstyleguide.com advises.

Eric's response: Frankly, I would be very surprised to find an important effect based on your capitalization scheme. If the headings are long, do avoid all capital letters. But I would be surprised to find a big performance difference based upon "Book title" vs. "Journalistic standards". More importantly, I would want to have and follow a standard.

In picking the standard you will probably find that the decision is mostly an issue of aesthetics. Pick the approach that fits your brand. I think the book title approach is perhaps a bit more formal.