Question: In a desktop application, given a modal (sequential) window-based navigation, how many navigation levels are considered to be optimal?

Eric's response: If you have a single modal operation there should be no navigation. You should open into the screenflow and just go from one working page to the next. When done you should get feedback that the task is complete and then be ready to immediately start the next (or exit).

We do not automatically need navigation. It is far better to immediately be able to begin work. If you have more then one modal navigation screen then you will need a non-persistent menu. This type of menu is optimal at about 18-24 selections, grouped in groups of no more than 10.

Question: Hello Eric, I have a question: can you please tell me the reason for the SPIN buttons and the SLIDERS, instead of simple input box?

Would be thankful for your answer! Thanks for your time!

Eric's response: There are keyboard primary interfaces and mouse primary interfaces. People would rather key 3-8 keystrokes than move their hand from the keyboard to the mouse. Therefore, there are controls that work best with a keyboard (like a text field) and controls that work best with a mouse (e.g., radio buttons). We try to stay with one class or the other.

In addition, the spin button and slider accommodate VERY specific tasks well. The spin button is designed to INCREMENT or DECREMENT an entry. So if the date can be increased a day, then a spin button helps. The slider is specific to set an analog entry. It is for when there is a continuous variable (e.g., volume, or brightness). It is best when there is immediate feedback (so I can see if it is bright enough). Using the wrong control is a disaster. For example, setting the volume by entering a textual volume level is inefficient and frustrating.

Question: We are trying to determine the most user-friendly button labels to use in our GIS application (aside from the standard Save, OK, Cancel, etc.) Do you have a suggestion for the best "rule of thumb" to use when applying labels?

Eric's response: Unfortunately, the selection of button labels is not as simple as you seem to expect. Certainly the labels should use short and common words. The labels should use the language of the user. And the labels should be as specific as possible. However, this is a very superficial set of suggestions. Perhaps more importantly the labels should work together in a GROUP. For example "back forward left right" will be easier to remember then "Rear Forward Open Right". In addition, the labels should fit with the overall structure of the interface; which means they must support the user's mental model of the interface and task.

I would also emphasize that labels should not be simply guessed at. Once an initial design is developed, it is critical to do usability testing to ensure that they are working. MANY times I have seen one poor choice of button label make it impossible for users to FIND a function that has cost the company dearly to develop and maintain. In effect that entire investment is lost.

Question: When you have lots of left nav items which is the best usable method to represent?

Eric's response: It depends on how many you mean by "lots".

A grouped list is very nice if this requires perhaps two pages of scrolling at most.

If you have more items then you can fall back to a tree view type of control (like in Windows Explorer). However, this is not good for novice users. It has a number of detailed usability problems, so this should only be used when really forced by the number of choices.

Question: I'm designing a GUI. The user needs to key-in a search criteria and based on the search string, I need to retrieve the data. Should I allow the user NOT to enter a search criteria and fetch all the records from the database? Or, should I prompt the user to enter some search criteria ? What does the standard say on this?

Eric's response: The key to this question is the characteristic of the search task. Is it possible that the user will really WANT all the listings? In most databases this is quite ridiculous. In this case the user must clearly be required to enter search criteria to narrow the search.

Also, consider the nature of the task. Is a null search filter really appropriate and useful? Or will this be a poor use of time? Even if the database is of limited size consider giving the user at least a warning message with guidance on entering a search filter.

Question: For a Desktop Windows GUI application, how to decide when to use form level validation or field level validation? Are there any standards that address this decision from a usability perspective?

Eric's response: For most cases use field validation (initiated when the field loses focus). The exception to this is the required field edit which must always be done as the user tries to enter the whole screen. Also, of course cross check edits must occur at the end as well. It is best to use a popup box to handle these field level errors. The box should appear near, but not cover, the field in error.

Use form level edits only for high-volume, heads-down keying. When expert users are pounding in forms, then it is best not to disturb them. Let them just enter the data. When done with the form do error handling. Do NOT fall into the trap of displaying all error messages. Just show ONE message at a time. However, you CAN subtly highlight all fields that appear to be in error. Then the expert may be able to correct some of these at a glance.

Question: What do you think about using mouse double-click in Web applications? Not in a classical Web site, but in an application like, let' s say, call center agent's desktop (thin). From one hand, double click is not very "webby" thing, but from the other hand, this is a great piece of selection-function pair.

Thank you.

Eric's response: You are pretty much forced to use the mouse convention of your environment. The choice between single and double click was related to secondary and drag functions that are generally not available on the Web. Apple went with a single button and double click. MS went with a two button mouse. But these are BAD things to allow drag and drop and other functions. So the single click is better for your situation.

Question: I would like to know how disabling of fields on a form is considered in terms of usability. What would you recommend if on a form there are various fields and fields "b" and "c" should be entered only if "a" is entered. Currently we disable field "b" and "c" until "a" is entered. Is there any other way of handling this without refreshing the page.

Eric's response: First, try to arrange that the contingent fields appear on the next page. Then they can be shown or NOT shown as needed. Second, if you need to have contingencies use a "deferred create" area. That means have a choice made (say a radio button). When the user selects the radio button, have an area below change to show or not show the needed fields. This said, try to keep the second method to a minimum. You do not want an effect in which fields shift all over the screen as you make a selection (labeled "Aerobic Widgets" by Deborah Mayhew).

Question: Missed your training seminar in Chandigarh.

I am currently writing standards and guidelines for installation and licensing across all products in my organization. Can you point me to any research in installer usability.

Eric's response: Sudhir, sorry you missed the class. It was good fun. I so rarely get to teach these days.

I have not seen specific research on installers. But clearly the installer is an infrequently used software module (in the extreme). Therefore you should design primarily for complete self evidency Hold the user's hand through the operations. Many installers use a Wizard approach. This makes good sense. Also, remember to automate as much as possible. A good installation package asks VERY little of the user.

Question: Currently working on a web based application. I have a problem with the architecture ( navigation ). Basically we have 3 levels of navigation:

In top level we have say A, B, C links and under "A" we have a, b ,c and under "a" we have 1, 2, 3, 4, 5, etc. Currently this is what I have done – when a user logs in he will get to a page where I display all the top level links like A, B, C, etc. Once he selects one of them (say A) he will get into a page where I show a, b, c menus and the 1, 2, 3, 4 as dropdown dhtml menus under each of the sub navigation menus (a, b, c, etc.). I would like to know if this is a good approach? Or can you suggest some other method ?

Note: There is space limitation because of the input forms.

Eric's response: The navigation structure depends on the taskflow and the user's mental model of the domain. Just for grins I'll assume that the user must navigate asynchronously between all these selections. I will assume that there is no compartmentalization so access must be to all areas.

In this case I would immediately send the user to a page with tabs across the top (for the primary division). I would have a left navigation for the secondary division. Then I would indeed use flyouts for the last. However, this is a bit of an extreme case. Usually you would find there are divisions in the domain that let you compartmentalize more and avoid the flyouts. However, we are seeing increasing evidence that people are adapting to these ergonomically poor controls.

Question: I'm developing version 2 of my Point Of Sales system (specifically targeted to billiard & bar establishments). I'm facing a problem because I can't decide about the GUI to control the table rental, drinks and food sales.

If I use a highly graphical GUI the interface becomes user proof (avoiding user errors) but to the most "experienced" users it may / will become slower than the actual approach (using mnemonic codes to find a product) and most of the time using the keyboard than the mouse.

What do you suggest to make the user interface friendlier to "novice" users and still remain fast to the "experienced" ones.

Some other programs I've checked use the buttons approach to add items to the sales, but I believe that having over 300 different drinks, foods and snacks will make it difficult / slower to find one (even using several levels or categories).

Thanks in advance for your suggestions

Eric's response: Start by designing a simple hierarchical menu system, preferably with touch screen given the environment. 300 items is not that many. A hierarchical menu is optimal at 18-24 items (assuming they are grouped in groups of no more then 10). So there need not be ANY items more than two button clicks.

Test this design (even with experts) against a (probably numeric) key entry solution. If the key entry is much better consider a dual system. It is good if a dual system can match the buttons and the keys. This means on the top level button 4 is snacks (label the button with the number). The menu this calls has a button for crunchy corn nibblets that is 8. So the keyboard shortcut is 48. Typing the number actually actuates the button. This makes a nice clear learning path and easy operation if you forget a code.

Question: I have 2 questions:

First Question: In order to try to prevent confusion and also to save screen real estate, we would like to toggle the text and functionality of a button depending on the state of the screen. For instance, if the user is already active, the button would say "Deactivate" (clicking it would deactivate the user). Logically, if the user was inactive, the button would say "Activate" (clicking it would activate the user).

There are arguments against this design which include:
a. The user will be confused that a button is changing text.
b. The user will try to find the Deactivate button and not be able to, but if it is right beside the Activate button it will be obvious. (My response to this was that the user that would wonder where that missing button is, would also wonder why they can't click on the disabled button if it was there).

Do you have any experience on this matter?

Second Question: In error or confirmation messages to the user, sometimes the message needs to be in the plural tense and sometimes in singular. How do we handle such things? The development/QA team does not want to maintain the potential errors that come with the mechanism of checking to see the number of items we're talking about and changing the message accordingly ("The templates have been saved" versus "The template has been saved"). The technical writers say that the (s) mechanism is written "noise".

Microsoft UI Guidelines say the following:

Use the plural form of a word rather than using "(s)" (or use both the singular and plural forms).

But my instinct tells me that "The template or templates have been saved" is way too wordy as is "One or more templates have been saved".

The best solution that we came up with for now is just to use "The templates have been saved" even if you are talking about just one template. But a lot of people still don't like that either.

Would love to hear your take on these issues. :) Thanks!

Eric's response: First Question: Right. In my experience this toggle button with switching meaning and serving as a state indicator confuses many users. I do NOT recommend it. Remember that people remember best by spatial location. It is important to have buttons with consistent placement on the screen. Here, the same place has two different meanings. If you want a small conventional control for this task try a check box. [ ] Active This allows a clear binary choice in this case.

Second Question. Obviously specific feedback is good. So "2 Templates Saved" is very nice. But if that is too much work, is it possible that the user is clicking "save" and knowing what is being saved? So consider a message that just says "Saved" (or maybe "Saved in C:/whereever"). The user might have little question of what was saved.

Question: I'm a UI Designer working on a system that provides functionality to a user based on his/her security rights. My question is whether or not to show the icons that are inaccessible to a user. Right now I'm leaning towards designing a separate icon that is grayed out and using that to display on the screen when that action is not available. Along with displaying the grayed out icon I would have a message within the alt tag explaining why this action is unavailable. Our developers are going to love me for this one!!

Thanks in advance.

Eric's response: Generally AVOID showing functions to the user that are not available. A permanently grayed out icon is of little value. Yes, it tells a user that some users can do this function, but they can't. But this seems to clutter the screen and be frustrating.

Let's take a concrete example. We have an image that is created by a production graphics person. Then a manager must approve it. It is better to give the graphics person a button that says "Send for Approval", rather then a grayed out approval button with a tool tip saying that the user can not access it.

Question: I am a usability professional in the insurance industry. I am working on a process to allow an adjuster to set a reserve, make a payment, and close the financials in one step. There are certain conditions that the claim must meet to be eligible for this process. If the claim does not meet the criteria the link for "First & Final" will not be available. The dilemma is that the processing required for this enhancement will not be available on weekends due to mainframe dependency. So if the user attempts to use the link on a weekend the process will not complete. As such my recommendation was that the link not be available, since it would always result in an incomplete transaction. The customer believes it will confuse users to not see the link for this condition and wants the link displayed. Which is the better usability approach?

Eric's response: It is important to have a stable interface. Avoid having buttons mysteriously appearing and disappearing. Instead, provide an error message that states that the 'First and Final' is not available on weekends. This is technically easy and avoids having the user searching for an important button that has mysteriously exited from the interface.

EVERYONE LISTEN!
Having the user wonder why a button is grayed out or missing is BAD. It is better to give a specific error message that explains the situation, instead of having users pitifully clicking on a grayed out button or an empty space where the button SHOULD be. DON'T DO THAT AGAIN!!!

Question: I`m working on a GUI for a system that will allow asynchronous process. This will probably not apply to many processes, but in what way can I best give the user status updates? Do I build a progress bar into the design, or is a popup window the way to go?

Eric's response: I gather that you will be having processes that are running for an extended period in the background while the user proceeds with the application. In this case the best behavior is to launch a popup with an in-progress display. The popup should be brought to the front with a completion message.

Question: Is there a standard for the use of verbs within menu bar items as opposed to using nouns? I'm currently documenting a GUI that uses the verbs "Design" and "Manage" in its menu bar, and this seems confusing to me; I would rather see menu bar items that reflect the objects I'll be working on.

Eric's response: The first rule is use verbs OR nouns, but never mix the two. This is called "parallel construction". If you go...

1. hire employee
2. transfer employee
3. fire employee
4. spreadsheet

then number 4 sounds like you asking the maid to spread sheets on a bed.

Action verbs are generally more specific and clear ("hire", "transfer", "fire"). BUT, they are NOT useful if they are "null verbs" ("Use Paint", "Use Calculator", "Operate Database"). Nouns are also acceptable.

While I generally prefer action verbs, the noun construction is particularly appropriate in an object-oriented interface, or one that is focused on operation of tools.

Question: I'm updating a form on my company's Web site. One change I'm making is changing the Country field from a text entry field to a drop-down list box. Here's my issue: how do I know what countries to list?

Eric's response: The main issue is how this field is used. How many countries do you serve? If the answer is ALL, you will have a rather long list. But you need to allow all users to find their country. Also, be aware that your address fields must accommodate different countries. There are countries where the postal code comes first. There are countries where addresses are essentially driving directions. One approach is to just provide a multi-line text edit field to allow any address format. If the address must be parsed, you really need a different format for each country.

Question: We are currently designing a Web-based system that will display information in a spreadsheet format. We would like to give the users the ability to either sort or "drill down" on each column in the table. One approach that has been suggested is to have the column headings appear as hyperlinks that when clicked would display a pop-up menu. The menu would contain links to either sort or "drill-down" the column.

Is this a good approach?

Eric's response: I would try to make the design allow the user one-click access to the sort and drill down functions. If you have frequent or trained users you can certainly do this with two icons on each column title. If they are less frequent users you will need to take a bit more space on the column title. For example, you might have two links (sort view) on each column. While this may force the expansion of a couple of column titles, it is probably still worthwhile.

Question: For software engineers, the need to provide software security works against the end user's need for software usability. Please discuss this area of conflict and suggest how it may be diminished.

Eric's response: There is indeed some balance between usability and security. I have seen may sites where the security was so annoying that a large percentage of users simply decided to use other channels. I have a few recommendations....

Do NOT make security measures extend beyond login. I have seen interfaces where the selection of mode of operation was intended to make it harder for hackers. For example I have seen command interfaces used to increase security. Of course this is silly. Hackers are exactly the type of people who enjoy figuring out your obscure commands; while the actual users are confused and delayed.

When creating a password system NEVER make it case sensitive. This creates lots of logon errors and does not increase security much. It is better to force a longer password if you have to.

Be aware of the user's family of passwords. Few users have a separate password for each site or application. They will perhaps have a few. If you put demands on the password structure you may force the user to create a new password just for you (which will of course be either written or forgotten). If you demand that the user change the password he or she will run out of alternatives and have to created a new one for you (which will be written down or forgotten).

Login takes time. It is annoying. Always use "single login" strategies when you can. Make login in one area provide access to all facilities possible without additional login procedures (pass the permissioning from one system to the next).

Be aware that almost all computer crime is committed by people who are authorized to complete the criminal transaction and just do it when they should not. So your hot login system won't really do much anyway. Instead, concentrate on good monitoring systems.

Question: Do you have any opinions or research on the usability of (1) flyout / rollover / mouseover menus vs. (2) accordion style menus vs. (3) "click-click-click" drill down? We are a state portal, in the process of a complete overhaul. As an enterprise portal, we have enormous amounts / types of content to aggregate. Our primary navigation will be "Yahoo" style. But for certain content modules, we're experimenting with all three of the above types of navigation. Opinions are split on their usability. I was hoping to find out if you think flyouts and / or accordions are inherently bad in terms of usability, or are they to be preferred to click-click-click when properly executed? (Let's assume for the sake of argument that the content is optimally grouped into topics / subtopics and we've achieved the right depth and breadth.)

Eric's response: Take a look at this article. It supports your "Yahoo" approach for both performance and preference. :)

Cascading Versus Indexed Menu Design
Michael Bernard and Chris Hamblin
Usability News 5.1, 2003

Question: Tab versus Enter - Our users want to use the Enter key to move from field to field in our Windows-based software but our developers insist that Tab is the proper standard for field to field movement. Are there some standards out there that say that using the Enter key for numerical input by accounting-oriented users where speed is of the essence is OK and not bucking some incorrectly applied UI standard. We want to put our users' needs first but are having a hard getting everyone to buy into this uncommon keystroke as our user-centered standard! Help?

Eric's response: I wish I had better news on this one for you. When we moved from Mainframe to GUI applications we switched from using the ENTER key to navigate fields to the ENTER key pressing the default button. Tab became the method for moving to the next field. This confused everyone in the transition. But even worse, there has yet to be an adjustment in the hardware design to make TAB easily accessible.

This all said, you still have to follow the current conventions and the TAB key goes to the next field. Your users will inevitably be using other applications and this type of overlearned motor behavior is EXACTLY the type of thing that will trip people up. There is an effect called "proactive inhibition" in which users will revert to a previous overlearned behavior periodically: even if they intellectually KNOW it is not right. So you can explain that you have violated the standard only for this particular interface, but you will have tripped up your users... Even years hence.

Question: I am currently doing research on flyout menus on Web sites and was wondering what usability thoughts are in general regarding flyout menus? What are the pros and cons of using flyout menus on a Web site?

Thank you.

Eric's response: If you are doing original research on this we are very interested in your results! When the flyouts first came out people were quite confused by them. The key problem is that there is no consistent indicator (affordance) for a flyout. So the user does not know to select them.

The flyout hides the functionality and forces two clicks to get anywhere. The design of the flyouts in current technology often has many problems. For example the user may inadvertently change the flyout selected when moving their mouse to a selection. For all these reasons usability practitioners are very wary of flyouts.

This said, we have some more recent anecdotal evidence that users are getting used to the flyouts and they are preferred (especially in comparison with multiple pages of menus). Therefore we are actively revisiting the topic here at HFI.

Question: Hi Eric. Has there ever been a thorough study to address user expectations on how fast they expect a page to load in its entirety? I'm not so much interested in the actual number (I know the "industry standard" is 7 seconds) so much as how to go about doing a study that would get solid data and whether an actual study would really yield results that mean anything. Can you comment on this please???

Eric's response: Dan, there have been a long series of studies on response time delay. They generally show degradation of performance and increased frustration starting at 2 seconds. Therefore, we want to have the page load TO THE POINT WHERE THE USER CAN START WORKING within that time. Some studies show that there are performance improvements associated with sub-second response time. The idea is that if the user comes back quicker, the user tends to work faster. There was also a bit of an increase in error rate along with the increased speed.

Beyond this, there was an interesting study published in the newsletter from User Interface Engineering, January, 2001. It basically showed that the speed of page loading was not nearly as important as the ability of the page to provide useful content. If the page was useful it was perceived as fast, even when it was slow.

Question: What are your suggestions and thoughts for Search on Web sites? I am looking at all available options, including answer engines, FAQ matching systems, bots and search engines, they all seem to have their drawbacks. Is there one software firm out there that currently offers a solution that is above and beyond competing products? The Primus Answer Engine is the best one I have come across so far...... thanks very much in advance!

Eric's response: First of all let me emphasize the weakness of Search. In a few situations Search is the primary natural taskflow on a site. For example, book purchasers almost always know the title or author they are looking for. In this case Search is very useful. But in most cases you will find that a browsing strategy (selecting items in a well designed structure of links) will get you the desired answer 3-4 times more often. I will say in the search world the Google engine is being used by both commercial and government organizations with good success. But no matter how good the search engine, the user is likely to be stuck with 54,231 matching items and poor prospects for finding their target item.

Question: Is there research that provides guidance for rollover use? I'm looking for: (1) good visual cues to prompt users to rollover a text target, (2) how big a rollover target should be and (3) how much text is readable in a pop-up box. I'm not generally a fan of rollovers as anything but brief tags/titles, but don't have any research to back up my bias ...

Eric's response: Lets try to dissect this a bit. There are rollovers that confirm that the user has their mouse over a given target. This is done by highlighting the target in some way. The method of highlighting has not been standardized. For text, you will often find highlighting by showing an underline, changing color, or switching to inverse video (black background and white characters). If the link is not underlined, adding the underline is a good confirmation that the text is selectable. The size of the highlight area should be equivalent to, or slightly larger then the target.

Rollovers are also used to display "tool tips" (alternative text). This helps in very specific circumstances. For one-time users I would like to avoid making them wait for a tool tip. Make the interface self evident. For expert users I have seen tool tips pop up in a distracting way as they try to use the interface that they know completely. But, in between are users that know MOST of the interface, but occasionally need a reminder. Then tool tips help.

As you make a popup box larger there will come a point where it is not seen as a popup. There will come a point where it obscures the underlying interface. Otherwise there is no limit to the amount of text in a popup. But the overall principle is to provide just what the user really needs. Every character needs to be justified in terms of the user's needs. Usually this means no popup, or very limited text. If you do provide text, make sure it is meaningful. I've seen a button "Auto Code" with a tip that says "CODE FOR THE AUTO". Don't do that again.

Question: We have designed our site including breadcrumbs, and eliminating dynamic drop-downs This did a lot of wonderful things including removing redundant navigation, increasing download speed, eliminated technology conflicts, etc. And we tested our proposal in North America with great results. The problem is since we have a very democratic political arena, we have to convince everyone to vote for instead of against it. Well some of our European counterparts are claiming that they feel their users "aren't sophisticated" enough to use breadcrumbs. Do you have any information on the effective usage of breadcrumbs internationally, so we don't have to go through the additional time and expense of European usability testing?

Eric's response: That seems like an amazing idea. Users who are sophisticated enough for dynamic dropdowns, but are NOT sophisticated enough to use breadcrumbs. Seems like a long stretch to me.

Question: We are contemplating changing all customer references on our Web site from "Your" to "My", as in "Manage My Account" instead of "Manage Your Account", or "Pay My Bill" instead of "Pay Your Bill".

Do you have any arguments about making it one way or the other? It seems like there are sites that do it each way.

Eric's response: There was a fad in the Web industry to call everything "My". I think it started about 2000. Like most fads it went to ridiculous extremes. I recall reviewing menus with 15 items all starting with "My". Now I would say the tendency is passé.

To some extent using either MY or YOUR is unnecessary. If you say "Pay Bills" there is little likelihood that users will mistake this for paying someone else's bills.

Question: I am currently responsible for an Intranet/Extranet in the healthcare industry, and more specifically Technology Assessment for both current and future healthcare products. The site I am responsible for houses many technical reports currently organized by category (oncology, cardiology). These reports are all .PDF's, and sometimes are quite lengthy.

Are there resources, research, or anything out there that deals with usability issues regarding the display and distribution of technical reports? I am exploring the possibility of breaking down these reports into a scannable, hypertext format to reduce time necessary to read the reports, increase retention, and ultimately have a positive impact on patient outcomes.

Eric's response: There is of course a lot of research about writing methods and presentation of the type of material you describe. As you intuit, the "huge set of categorized reports" method is extremely unusable. It requires a dedicated researcher to overcome the obstacles. It is far better to develop a summary analysis of the practical applications and put it into a form where the useful content is summarized and categorized in a way that fits the user needs. For example, you might pick arthritis, then rheumatoid, then have a list of treatment programs under that. The source papers can then be referenced from there for the truly masochistic user.

I have searched through many sources that deal with writing for the Web in general, but have yet to uncover something as specific as I was hoping to find.

So, look at the vast work that has been done on corporate "decision support systems". They face the exact same problem. Lots of very complex technical stuff that must be quickly interpreted and acted upon by fairly non-technical executives. They put research findings into graphic form. They organize the graphs in a way that is simple and makes sense to the executives. Their situation is identical to yours.

Question: Site maps. Are they passé? If a Web site has clearly marked and navigable paths, is there any reason to maintain a site map any more?

Eric's response: If you can make a useful site map: MAKE IT YOUR HOME PAGE. Site maps are indeed passé, and were always a Band-Aid indicating poor navigational design.

Question: For some time we have suspected that human factors and information design contributes significantly to how our customers respond to our paper invoices. However, we have used “Marketing Tests” as a tool to try new designs. These tests would modify some aspect of the invoice and compare the response or lift in payment % to a control group. If the test caused a better response or better payment % we would adopt this change. We never really know “why” these responses occur; we just know that they are better or worst.

Is there research that links human factors and or information design to higher payment of invoices?

Eric's response: I do not know of any published data, but we have certainly seen invoice payment rates increase. This seems to be related to two factors. One is the ability to know what to do. When you look at the way that many people pay invoices, they do not actually read the whole document. They quickly scan for the amount they are supposed to send. If the amount looks reasonable then they send it. Therefore, making the amount to pay stand out is important.

It is also important to make it easy to physically make the payment. Complex return envelope schemes can be detrimental. At least make sure it is clear where to send the payment. Increasing work and confusion makes it more likely that people will defer and forget payments.

Finally, I think there is a value to providing invoice details that appear organized and make sense. Many years ago I redesigned an invoice for the phone company. The managers didn't like the new design. I was crushed. They said that my design was bad because people would understand it, and then be more likely to call. Well that might have worked in the regulated days where the phone company was a monopoly. I think unintelligible details would be a bad approach in most cases today.

Question: A while ago (maybe 2-3 years?) one of the newsletters had an article which talked in detail about user's preferences to select a keyword search engine versus using a sorted index when searching for data on-line. The results were split nearly 50-50 as I recall for using one vs. the other. Can you point me to that article, and do you have plans to revisit the topic, as my organization is revisiting the debate about whether to include one or both in our on-line help and on-line documentation libraries. We currently include both, based in part by decisions I made based on that article but must now validate the decision.

Eric's response: Research shows that people are THREE TIMES more likely to find useful information if they are using links instead of a Search (UIE report Dec, 2001)

Question: I just read your April 2003 article, updating findings about depth and breadth in on-line menus.

Is there a danger in extrapolating those findings to paper? For example, consider these situations:

1. Creating printer-friendly Web pages, where an entire document is collated for printing purposes, complete with a TOC.

2. Creating paper in the short-term with a specific long-term plan to put the content on Web.

I know that in many cases you do not want to use the same hierarchies on the Web that you use on paper, and vice-versa. However, I'm not convinced it is always a bad thing to do. And when the original is done well (discrete labels, evident hierarchies), would not the dangers of using the same hierarchy in both mediums be greatly reduced?

Eric's response: The data on menu construction seems rather specific to the dynamics of online environments. Just as we get in trouble when we directly apply the principles of magazine design to the Web, I believe we get in trouble extrapolating data the other way. Paper is different from screen displays. The dynamics of page turning is different than site navigation.

There has been a long history of refinement and vast amounts of experience in book design. People have very strong expectations. Just consider the idea of a book that had a menu (TOC) that then lead you to a second TOC, and then a third. This would be a very odd situation indeed! It would be a surprise and source of confusion. So use the methods that people expect when designing for the print media and be very careful about extrapolating research from online environments.

Question: What is the industry standard to denote hierarchy nesting for breadcrumb navigation? Is it a caret, or simply any character that denotes movement?

Eric's response: There are several different characters that can work. The caret is most common. But a slash is also fine.

Products> Books> History> France
Products/ Books/ History/ France

Note that breadcrumbs seem to have mixed results. I have seen some cases where they really helped users and were used to navigate. In other studies no one saw them, or even if they did, they used the "back" button to navigate.

Question: Have you done any usability studies on flyout menus? If so can you point me to your findings? I have taken two of your courses and respect your opinions. Thank you.

Eric's response: In the words of Dr. Kath Straub, our Chief Scientist... I would like the temporary official answer to the flyout menu question to be: Early experimental work showed that they were a usability challenge. More recent anecdotal reports suggest that users are accommodating to this type of interaction. We (HFI Global) are currently planning controlled experiments to test this both here and abroad so that we can provide a definitive answer.

Question: Are there any good references that detail how to
best design user interfaces for intensive Web-based data entry systems?

Eric's response: There are literally thousands of references on the subject. Our Web class provides an extensive summary of this research. There are studies for optimization of visual access (like left justify the labels and fields having a limited number of margins). There are studies of human information processing and memory (like chunking codes into 3 or 4 character groups makes them easier to work with). There are studies of the biomechanics in data entry (like people would rather key 3-8 keystrokes then move their hand from the keyboard to a mouse).

With high volume data entry the biggest key is to concentrate on the efficiency of the motor task. Users will do it enough that the cognitive load will not be the choke point. It will be an issue of motor behavior. As an example, it is better to have the clerks memorize all the state codes rather then switch to the mouse to drop down a list of choices. Just let them key the two digit state code.

Eric's response: Use "Reset" and "Apply" for technically savvy users and for users you want to confuse. I find that many DEVELOPERS don't know what "reset" is supposed to mean. We have also seen many users have trouble with the concept of "Apply". "Cancel" and "Save" are more commonly understood.

Eric's response: There is one key question. Does the user have to learn something to answer the question? If you ask my mother's maiden name, you get that free because I certainly know it. If you ask my current home phone number, you get that free too. If you make me use a password, that is harder because I may have to generate one or at least keep track of what I gave you. So if the customer already knows the information you can ask as many different items as needed.

In a single confirmation session there is a limit on the number of questions I would ask. It would depend on the level of security for that access. I had a Visa card fraud check resolved when I just gave my mother's maiden name. In the end I wondered if that was really enough to tell that the call from India was really me. In general though, no more then three questions.

Thanks in advance.

Eric's response: First I would suggest you consider a general macro facility. It is often useful to let the USERS setup and administer a set of macros as you describe. They will use them in ways you don't expect.

Be sure you really NEED the protection of non-display of the password in the setup procedure. It seems like overkill. I would like the user to be able to enter a string of characters, and just enter a tab for when the system should enter a tab.

If you must have a non-visible field you will have trouble with a generic facility. In this case it would be best to have the separate fields shown, with a protected password field. Do NOT introduce a coding sequence. This is more complex and less conventional. Use separate fields.

Eric's response: The Web has changed expectations quite a bit. People often tolerate long Web page downloads of 15 seconds. However the screen-to-screen transition in a client-server application is typically recommended to be less then 2 seconds. There were some studies that suggested that people work faster with a sub-second response time. But at least get the window-to-window interval down to 2 seconds.

There is another response time interval to be aware of. The time between an action (e.g., clicking a button) and the control registering the action (the button moving in). This needs to be more on the order of 200-250ms.

For more information on Web response times, see our April 2001 newsletter.

The question is if we need to represent these functions via a radio button or do we represent them via TABS.

For me the TAB option is the better one because each pane would only show the parameters that are applicable for that function.

With the radio button option we need to gray out non-applicable parameters.

Whenever we decide about this implementation do we need to have all other GUIs to follow the same rule, or could there be a good reason not to be consistent over all GUIs?

Eric's response: Several things. First it is generally a BAD thing to have multiple ways of doing one function. It increases complexity and clutter. So only do this if there is a clear user need that forces such flexibility.

Second, tabs and radio buttons can be used in an identical way. In these cases tabs are more obvious and present larger (and therefore quicker to hit) targets. Radio buttons reduce space.

Third, the functions Display, Create, Modify and Remove are almost never organized like that in a taskflow. This is the way the database designer sees it. The users usually look at the items (display) and then maybe delete or modify. Creating is often a separate task. Therefore, the appropriate design is almost never just a set of buttons to Display, Create, Modify and Remove. So I want ONE display from which I can see the item, change it, and delete it.

Lastly, all the GUIs need the same design for this... unless there is a really amazing compelling reason to do it differently.

Eric's response: Two tier hierarchies are fine for experienced users.

Eric's response: It is good to provide default (prepopulated) data if you know what the user will enter with about 80% probability. But with prepopulation, any field you are not sure of is simply left blank. Putting N/A is misleading, as the user is likely to think it is not a required field. If you are prepopulating as defaults, then it IS applicable. You just do not know what to put in it. In addition, the user has the work of highlighting the indicator to erase it before putting in the required data. It is very normal for users to see default data in Web applications, prefilled by logic or based on previous entries. Just add the data you have and leave the rest of the form as it is.

If you do NOT mean 'defaults' and you really know exactly what the user must enter, WHY are you asking the user to view it? And if the field is really not required, WHY are you showing it at all?

Eric's response: Thanks Markus – Some Web standards are bad. But those that have become population stereotypes should rarely be trifled with (even if they are bad). If you are designing for a browser, USE BROWSER CONVENTIONS. In the long run users will be faced with lots of other page designs and you will create a conflict for them.

Eric's response: Donna, we have data that indicates that users expect that a left-hand set of navigation controls are expected to have "internal links." This means selection results in changing the display area without leaving the navigation structure (try picking links on the left side of www.humanfactors.com). We know that links on the right and also sometimes on the lower part of the left are expected to be external. This means they go to another place. I have not seen a comparison of top vs. bottom. But I would expect a very similar distinction. Top should be internal. Bottom is less often used, but should probably be external links.

Eric's response: "Glosses" refers to a mechanism like tool tips for hypertext links. You hold your mouse over the link and text appears that further defines the link. In some instances actual text from the linked page appear. This helps users decide if they should chose the link. This is good. The main problem as I see it is that users do not currently expect this behavior. So until it is established as a convention I don't think it will be terribly effective.

Eric's response: First, I believe the icon representations do NOT change between views. That is to say that the "X" indicates "delete" no matter which view you are in. The icons do not change. If they DID, it would be a very bad design. I have seen this. At one auto manufacturer I found seven different icons that all meant HELP.

When moving between functional windows, the functions that are available change. This is fine – it is just the nature of the taskflow.

I've been looking around but I have been unable to find what this type of function is called and I can't find what standards should be followed. Do we use Alt or Ctrl as the base key? Is it OK for Alt-S to mean Save and Ctrl-S to mean "jump to price"? etc.

All help appreciated!

Eric's response: First a caution. I have often seen the addition of these shortcuts as compensation for lack of work on screen layout. Your FIRST attack on this issue is layout of fields in the order in which they will actually be used.

These types of combination keys are called accelerators, shortcut, or access keys. Unfortunately, there is a remarkable lack of standardization in the way they are actually used. For your purpose you can use accelerators that either go to the first object in a group box, or to specific fields. This is done by underlining the target character on the label, or if you run out of letters you can append the character (e.g., Finance(Q) with the "Q" underlined ). It is really good if you can keep consistency with accelerator selection rules and with the decision whether to use Alt or Control keys. However, with your expert user population this may be secondary to ensuring efficiency.

Eric's response: In the late 70s I worked on a standards project for the Bell System. We made many small rules, but they did not really hang together well. In reaction to this I developed the idea of a template-based standard. We found that there were a dozen or so page types that accounted for 85% of screen design in a given environment. So we began making standards with standard page types. We have made over 140 customized UI standards so far. The core idea is to make ergonomically correct example screens and document the standards for them. The closest we have to a universal standard is the Usability Central product from HFI. It has a set of over 20 standard page types for the Web, and about 15 for GUI applications. It contains a wizard page type with full standards rules.

Eric's response: The practice of forced password changes is NOT commonly required at all on net sites. Even financial and banking sites generally do not require regular changes. The more often the changes are required the more load you put on the user. The more load put on the user, the more users will go somewhere else. In fact my local bank requires a changed password every 6 weeks and as a result I do not use it at all.

When thinking of security ask yourself what would be reasonable if it was NOT online. I have seen onerous double login procedures protecting data that could be obtained by walking in and asking (if wearing a nice suit). Security is critical, but needs to be reasonable. Why not let your customers change their passwords when THEY want?

Let me take a moment to describe what I mean by a "floating toolbar" On the right side of the browser window, there will be a set of tools the user may need while browsing the page (which we are also testing to determine their self-evidency). The tools are positioned in the top right corner of the browser window. As the user scrolls down the page, they remain in the same position relative to the browser window. This makes the tools appear to "float" down the page as the user scrolls. Some of the tools that will be available are a link back to the top of the page, capability to print the page and the collection of pages, and a "find in page" tool. By making the tools follow the user as they scroll down a page, they are always right at the user's finger tips.

These tools do not obstruct any text, and only the appropriate tools will be available for each type of information. For example, on a glossary page, the user will see a "find in page" tool so they can quickly get to the word they want a definition for, a tool allowing them to navigate alphabetically to other pages in the glossary, and a word submission tool (which opens a word submission form in a pop-up window). We would not provide tools for printing, since users do not print pages from a glossary; they reference the pages when they need to know what a word means, but they do not save and post the page in their cubicle for later reference.

While everyone on our design team feels that this is very helpful, I wanted to ask an expert. Have there been any tests (or heuristics) with regard to objects that stay with the user for easy access to tools they will likely need when using a web page? If so, are there any findings we should be aware of?

Eric's response: I have some concerns with the floating toolbar concept. One issue I have is that some of the functions appear to be duplicating browser features. I have seen a number of companies create their own "back buttons" etc. This means that we present the user with two similar but different functions. This increases complexity and has a negative effect on learning time, speed (read up on the Hick-Hyman law in psychophysics), and screen real estate. I am sure there are additional functions, but the browser is already designed and working. Is it really worth this additional complexity?

I am also concerned about the mutating toolbar. The fact that the functions change from page to page "as appropriate" means that the user must manage those changes. However you design it (gray out buttons, or button replacement), the tool bar changes. Either the user is unable to learn by spacial location, or the design takes a lot of space.

Consider adding standard functions to the header or footer of all pages. Consider adding special functions (like word submission on a glossary page) where needed for special types of pages.

I suppose I can think of some applications where this type of floating toolbar would add substantial value, but not many. And I would not recommend creating this for general use throughout an Intranet. It is interesting that Windows™ has a floating toolbar capability built in where you can detach icons from the window. How often do you see that used?

Eric's response: It depends upon the task. In transcription, we have been able to present snippets of the scanned document next to the corresponding entry fields. So the scanned name appears above the field where the name is typed.

If you are working with full documents there are only two solutions. You can use the windowing operating system to allow positioning of windows (of course this costs time in window thrashing). Alternatively, you can provide a structured switch so the user can hit one key and switch between the documents.

Remember that the idea of "concurrently" viewing documents is a fiction. The human eye does NOT see both documents at once (we actually only see detail in about a 2 degree arc). So the question is how easy is it to switch between documents. Just moving your eyes is fastest. But a quick display change is not too bad.

Eric's response: Chris, I have not seen public studies that test this issue. I have seen private data to that effect. However, from the basic psychological literature we have good research that supports Jacob's assertion. The Zigarnick Effect shows how people have a drive to complete tasks. The model of Cognitive Dissonance indicates that users will be less likely to stop, as this would imply that they have been foolish and wasted their time. My only concern is where you may create some very negative feelings in users who feel they have been "lead down a garden path." So your numbers will almost certainly show fewer exits if you do not have registration until the user has invested substantially in the task. But the exits you do get may be pretty unhappy campers.

In e-commerce sites, however, I would recommend that the user not be required to enter personal registration data until he is ready to buy. Users should be free to learn about the product and pricing without having to cough up private information. If they have to give the information up front, not many will stick around to hear the pitch.

Eric's response: Cascading menus are poor from a usability viewpoint, because they hide too much. Less-experienced users may not even find these menus, since there is not a single strong cue that a dropdown menu exists. Even when users find cascading menus, we often see them losing time having to "pull-down surf" through the menus. Users have to drop down each menu searching for a link they want. Even for expert users it takes two (or more) clicks to get anywhere.

A hierarchical (Yahoo-Style) menu is far more efficient ergonomically.

As for pull-down menus, their advantage is precisely that they hide things, so that they let you fit a lot of functions into a small space. So use them for sites that will be used regularly (so users know they are there and know which item to look in) and that have too many functions to fit on the page.

Eric's response: It is pretty rare that human factors people are used for simple delivery of information. If it is very large and complicated it does make sense (we are currently working on the Library of Congress public site for example). But most sites we work on have complex interactivity (like brokerage, banking, telecommunications, etc.). There is a ton of material on this on our site. Our courses are mostly about that type of complexity and interactivity. There are THOUSANDS of articles and books (see our bibliography.) You can also ask me something more specific.

Eric's response: It depends on whether you're working in a GUI environment, where pop-ups can be valuable, or in a Web environment, where they rarely make sense.

In a GUI environment (Windows™, not in a browser) designers can keep good control of pop-ups. For example, they can make the pop-up support a modal taskflow, so that the user cannot do anything else until the task is completed. Or they can make the pop-up a reference tool by setting it to stay on top. But beware. Many times I see designs where the user ends up with a whole series of pop-ups on a page. It would have been better to let the user navigate to a second page full of material. I understand the advantages of keeping the user in the context of the primary page, but it isn't good to give the user the extra work of opening and closing all those pop ups.

In the browser environment, on the other hand, pop-ups are usually a bad idea. You have very little control over them, and there is a real danger that the popup will drop behind the browser and be lost. Also, many users have built up a reflex to cancel any small window opening, under the assumption that it is one of those pesky interstitial ads. Therefore you need to have a really good reason to use a pop-up.

An example of where it is probably justified is with financial sites, where normally people key a ticker. If they do not know about keying tickers, you can select a link that provides a pop-up that finds the ticker symbol. They will not have to leave the research page for this minor lookup.