Software Navigation and Interaction Design Challenges
May 26, 2009 – submitted by Yirat Hendler of Israel
Question: What is your view on trouble-shooting online? I refer to a decision-tree pattern (I think that's how it's called) when a user tries to resolve a problem via answering a set of questions, each question is dependant on answers on previous questions, leading to a proposed solution for the problem. Do you think it is a convenient pattern to use? Is it for novice or expert users? If you can refer me to any research/articles on this topic it would be great! Thanks.
Eric's response: Yep. Trouble shooting is generally in a decision tree mode. If you have expert users just go for a tree view where they can quickly see large parts of the tree and scan through it as needed. For novices step them through one point at a time and let the system branch.
February 13, 2009 – submitted by Ed Sykes of London, UK
Question: The delete phase of a CRUD system is destructive in nature. I can see 2 different ways of dealing with this.
Ask the user to confirm the delete.
Allow the user to undelete.
The first option has the advantage of being more consistent with what the user expects to see (at least on windows systems). On the negative side it interrupts the user and is prone to habituation (i.e. automatic clicking of yes).
The second option has the advantage of being non-intrusive but may mean that the user does not know where to look for the undelete. Also, it is less common to see.
Do you prefer one approach over the other, or is there a third way (perhaps a dialog that can be dismissed forever followed by sending to an undelete folder).
Eric's response: Best practice is to delete without confirmation, and then offer an obvious place to undelete.
The "Are you Sure?" message is only useful for infrequent tasks (as you point out, the user will habituate). For frequent tasks, the question really only helps for accidental actuation.
November 3, 2008 – submitted by Ravindra Papineni of Austin, TX
Question: On Windows XP search box (with that cute yellow puppy) after the search options of Pictures, Music and Video, the two buttons displayed are "Back" and "Search" respectively.
The primary goal for that little form is to search so "Search" button should be the first one rather than the "Back" button. Is that correct? Or does it matter at all? Thanks in advance.
Eric's response: Clearly, once the search options are set, the next button should be SEARCH.
Sometimes Microsoft developers seem to feel that they can disregard usability principles as they are so powerful in the market. Maybe that will catch up with them one day...
November 1, 2008 – submitted by Paul Hardy of Paramatta, Australia
Question: Is there a best practice for what (if anything) the computer should say to the user if they have changed no data and then pressed "save"? Some applications (e.g. Microsoft Word) say nothing and some say something along the lines of "no data needed updating". When leaving SAP you get a generic warning about losing unsaved data regardless of what you have done. Which is deemed to be best?
Eric's response: All things being equal "implicit save" is the best strategy. Implicit save means that you make changes to the display and they are saved when you leave. There is no need for an explicit SAVE action (which means "move data from RAM to Hard Drive" and that should not be a concern of the user). In this case there should be an undo capability (RESET or CANCEL). The technical limitations of the Web sometimes force you to use an explicit save method. But this will probably disappear as the technology matures.
September 9, 2008 – submitted by Larissa Schwartz of Amherst, MA
Question: There have been studies in e-commerce environments on the need to give users the ability to "view all". Recently, the Usability Sciences Corporation dedicated their newsletter to the subject.
How do you think this transfers to other sites? Should we follow the lead of online shoppers when it comes to search results and other data sets and by defaulting to "view all" or should we just give them the option?
Eric's response: Larissa, thanks for bringing this up. Kath Straub (our chief scientist) and I had a lively interchange on the issue. And the bottom line is we don't think a mass move to View All is at ALL the right thing. See original
I suspect that "View All," like HELP, can be a desperate attempt to compensate for a poor design. If the information architecture was done right, there would not BE 300 dresses to be viewed. It would be a limited, targeted set. The View All strategy may well be trying to scan through a load of misses.
Now there may be times when the user wants to drift through lots of choices in an engaged shopping experience. Kath rightly felt that throwing all the choices into one LONG scrolling page would create a behavior of looking at the first page, scanning through the middle with maybe not even a glance, and then looking at the last few.
I think we also know that scrolling/paging has limits. Certainly almost all users know how to scroll. But a very long list is physically difficult to manage. Also, if you have to go back and find a previously scanned item it is truly a challenge.
So it is OK to provide a View All button. But we are not all that excited. Though Kath says she may run it through her handy dandy eyetracker to see more.
August 12, 2008 – submitted by Paul Tarquinio of Massachusetts, USA
Question: Wondering if there's any research regarding best practice for navigation menu display. Currently, in our web-based training, we're displaying a narrow left hand menu at all times, which automatically updates/opens new lesson/topic menus as the learner moves through the course. In order to save on screen real estate, one option would be to have the menu displayed from a drop-down button that would only display when the student wishes to see the menu.
Question: is it preferable to have menu displayed at all times, even if it takes up screen real estate, or should it be only available as an option.
Eric's response: Hi Paul. There is indeed a load of research on menu design. Maybe enough to keep you reading for a year, if you have some spare time.
In terms of the TYPE of menu, an INDEX or classic hierarchical menu is best (this has all the choices presented in groups, and takes up most of the page). The next best is the left navigation. The worst is the top navigation (e.g., tabs). In this case the user preference and performance align. That ranking is true for both.
The next issue is persistence of the menu on the screen. If your users are online novices or infrequent users then there is no option for hiding the menu. Keep it in place. Otherwise, persistence is a function of the frequency of menu access as compared with the need for screen real-estate.
In an online training environment, I would suggest having the basic navigational controls (next question, backup, etc) embedded in the page, and a separate MENU button with infrequently used choices shown in a consistent place.
January 3, 2008 – submitted by Linnette Desch of Bloomington, IL
Question: Is there any research or articles about bound and unbound picklists?
We have an instance where we'd like to provide common values for a field but also allow users to key data. If the field appears as a picklist with data, I'm not sure our users would know they could also key into the field – we've seen this problem on other occasions.
An alternative is to offer "other" in the picklist and then provide a separate field for data entry but I was looking for other ideas or research on users in general knowing about unbound picklists.
Eric's response: Such "Combo boxes" were very common in GUI applications. Because of the limited (bi-synchronous) capability of the early Web, they become less frequently used. This will change as Web 2.0 capabilities make combo boxes again feasible.
In terms of design they are a slightly advanced control. So for novice users you might indeed use "other". They will also be unexpected in the Web environment. However, the combo box has a pretty good affordance for entry, as the cursor appears in the typing area. I am certain this control will stage a comeback as the technology allows easy coding.
October 19, 2007 – submitted by Tony Gullaci of Vancouver, Canada
Question: What would be the best method to show users that a table column is sortable.
Eric's response: This is one area that has become rather standardized. Make the header look like a raised button. Put a triangle (arrow) to the right of each button that indicates the sort order (ascending or descending). Clicking the header switches the sort order.
September 19, 2007 – submitted by Shweta Shah of India
Question: Hi Eric, I am Shweta from India. Right now I am working on an existing Web interface for usability issues. In one page there is a table which uses 4 columns and multiple rows to select one option. They have used radio buttons on the right side of the page. Is there any other option other than radio buttons to select? Number of rows can be many in this case. Please suggest something to me.
Eric's response: If you are in a keyboard-primary interface, then consider a classic menu. Number the items and let the user type in the selected item's number. If you are in a mouse-primary interface, then consider an array of toggle buttons, where one item can be selected and shows as highlighted. Selecting a different items leaves only THAT selected item highlighted.
Radio buttons are OK for a mouse primary environment, but should be only a single column. They are also a bit slow as the target size is small.
September 5, 2007 – submitted by Eric Gauvin of CT, USA
Question: I have a question about input field error messages. Has there been any research about the best way to present error messages based on multiple criteria. Let's say you have an input field that the system validates on 3 different criteria. I've seen examples of stacking up a separate message for each validation criteria, but my instinct is to compose one all-purpose message so it looks like fewer errors. However, that requires the user to figure out the part that specifically applies to them. What's the recommendation for that?
Eric's response: I have always found many problems with multiple error messages on a single entry. A single incorrect character can trigger dozens of error messages. It does not help to dump all these messages on the user. Just give the first one out. BUT, it is important to think carefully about the sequence of error checks. If you make the sequence logical the user is lead, step-by-step, to enter the right information.
August 8, 2007 – submitted by Niraj Gorde of India
Question: I could not find the details on "factors affecting the usability of an online help or a context-sensitive help" anywhere on the Net.
Is it not important to make the online help more usable? I have found few factors as navigation, structure of help, TOC, links, search on help, screen shots and so on. Could you please let me know, where should I find more information and if possible could you please send me details for the same.
Thanks and regards.
Eric's response: The first insight is that HELP should be made unnecessary. A good user interface design minimizes and often eliminates the need for help.
Second, we need to understand what TYPES of information people need. This "gap analysis" is completed by comparing the skills and knowledge that the users have with the skills and knowledge of your application. So they may need to know typing, but if they already know how to type it is no issue. But if they don't understand a SKU code, then they will need SOME TYPE OF SUPPORT.
Now the question is WHAT type of support do they need. You can use paper documentation, online documentation, physical job aids, online job aids (help), or training. You must work out the best strategy.
This reminds me of the time an executive told me he was going to a paperless office and all instructions would be online. I asked him where he would put his system failure instructions. And he said ONLINE!
Once you determine IF you need help, and what type of content is needed you will find that there are different types of help possible. You have overall orientation help, page level help, field (or object) help. In some cases you will need help on every object, while in other cases you will only provide help where you know a good percentage of users will be struck (the latter is generally my preference).
With this in place you have rather typical issues of navigation (how you GET help of various kinds) and content development (good writing).
My best advice is to keep help to a minimum and make sure that what you DO provide is really helpful. I've seen examples like "SKU Help: Field where you enter the SKU code." This doesn't provide any help to the person who needs to know what SKU means. Rather than have tons of useless help, provide help on what people are really likely to need help on, and think through what they really are likely to need. Then you can test the application and see if more help is needed.
August 6, 2007 – submitted by Naveen Prasad of India
Question: We are developing a user management module for a Web application. In the user search results page:
1) I am planning to provide a check box in all the rows of user 'Search Results' to select and delete the user. Is it correct?
2. If point no.1 is correct, after deleting the user, do I need to reload the 'Search Results' again?
3. If point no.1 is wrong, then, is it good to provide a delete button inside the user details page?
4. If point no.3 is correct, then if I click 'Delete User' button do I need to provide a confirmation message in the same page? And a back button to take me back to the 'Search Results' page or a alert message on click of 'OK' taking me back to the search result page?
Please advise me?
Eric's response: First of all you need to refer to your interface standards documentation. I think HFI should have created one for you guys by now. Would let you just look it up instead of keeping me up answering Ask Eric questions half the night.
The check box for multiple deletions is useful only if the user will need to often do multiple deletions. Otherwise you can just put a delete button on each line (a bit cluttered but easier), or allow deletion of the highlighted items. Once the deletion is complete you should show the list minus the items deleted, you can show a shortened list (not re-running the search) as a form of feedback.
However you handle your list, you should probably provide a delete button on the details page. When the user views it he/she might like to delete the item.
If the user will use the delete frequently, a confirmation will not help (except for accidental actuation) because the user will learn to reflexively confirm the deletion. So I would only provide a confirmation if deletion is unusual. Then you can return to the list screen with a feedback message shown in your standard feedback message area that confirms the deletion.
June 21, 2007 – submitted by Christina Chang of St. Louis, MO
Question: I am often asked by engineers when to use buttons and when to use links. We have a screen where there is a table to do ePrescriptions. On each drug row, the drug name (2nd column from the left) is a link to the drug info. The 2nd last column on the right has an "Add Rx" link to add this Rx to process.
However, in our usability test, almost all users miss the "Add Rx" link, instead, they clicked on the drug name to try to add to process. To solve this problem, we propose to make the "Add Rx" a link button (with some 3D button effect to catch attention), but some folks disagree that having a button on each row make it look crowded. We haven't had a chance to test this design up to now. I guess this is the question I should have asked: When to use Button (html button), Link Button (CSS button) and Link?
Eric's response: Well no surprise a Certified Usability Analyst would be on the right track. But here is the solid rule.
If you are going to process something on the current page (e.g., calculate) then you MUST use a button. Never a link.
Otherwise GENERALLY you use a link to go to someplace (such as making the name of the drug a link and selecting it to see that record in detail). But if you are acting on the table (such as going to an "ADD" dialog) then the button is better. But certainly buttons are used to go places often and it is not a problem (e.g., a HOME button).
June 21, 2007 – submitted by Melanie Weber of Ontario, Canada
Question: Our team is constantly debating the use the word "please" in error messages. For example "More than one Applicant exists for this application. Please edit the applicant type or remove the additional applicant(s)" vs. "More than one Applicant exists for this application. You can either edit the applicant type or remove the additional applicant(s)". What is your opinion on the use of "Please" within error messages?
Eric's response: Funny, I immediately looked at your country when I read the question. It matters. :)
In general I would avoid "Please". It contains no information, so it only clutters the instruction. It is also anthropomorphic, which means you are pretending that the computer is a person. But it will be pretty obvious to the user that the computer does not care and is not concerned.
HOWEVER, we have found in the UK that omitting "please" makes people feel like the application is rude. You might do a bit of testing to check if this is true in Canada. It could be. (Please let me know your findings!) At the same time in other cultures, like India, "please" is not normally used. Using "please" makes the interface seem oddly formal and stand-offish.
April 2, 2007 – submitted by Mark Pawson of Calgary, Canada
Question: Is there a UI forum that you recommend where UI questions can be posted, such as this question and answer page, but with the ability to provide input from a variety of participants.
For example, I am presently redesigning a GUI interface where I am debating whether a feature (icon, button, menu item etc) should be greyed out when it does not apply, or should not even appear when it does not apply. What does the research show? Thanks.
Eric's response: I want to caution about discussion groups. Usability engineering is not a function of opinion. It is a research-based discipline with a foundation in at least 60 years of data. Arguing in a discussion group is not necessarily the best way to get questions resolved. Consider usability.gov, useit.com, or humanfactors.com (ah, well I guess you did find that). In fact the gray button question was just answered here recently.
March 20, 2007 – submitted by Andy Rotering of MN, USA
Question: My question is in regards to enabling and disabling controls based on user selections. For example, if a feature can be enabled and disabled, how should the controls that configure this feature behave when the feature is disabled? Should we:
a) Disable the controls that control this feature and only enable them if they enable the feature (presumably the control to do this is on the same dialog)
b) Always keep all the controls enabled and if the user tries to interact with a control that only applies to this disabled feature, pop up a window that says something like "You're trying to configure feature XXXXX, would you like to enable this feature?"
As I write this, I am amazed at how much option (b) sounds like Clippy (of "It looks like you're writing a letter" fame).
Eric's response: First, I assume when you mean "disable" a control you mean that it is "greyed out." The advantage to greying out controls is that the user is presented with the controls that are available at any given time. This might seem nice. But the severe problem comes when the user thinks that a control SHOULD be available when it is greyed out. THEN there is a problem because there is no indication of what the user should do to activate the control. Unfortunately, there is no convention that tool tips appear for greyed out controls indicating what is needed to activate the control (would be good, I think). So the user is stuck. I would therefore generally like to see all controls enabled and an error message that describes why the control can not be activated. No need to make the message smarmy however.
March 15, 2007 – submitted by Diane Albert of PA, USA
Question: I have a debate going with some programming colleagues – when you have action buttons such as "OK" and "Cancel" in a dialog box, what is the intended order? I had been placing the default button to the far right, figuring if I'm mousing through quickly, Fitt's law would give me a better target if it's along a barrier or in a corner. The programmers say because we read left to right, the default button should be on the left most of the row of buttons.
In addition, what happens if the default button changes from one screen to the next – the first one might be "OK", but the logical button for the second screen is "Cancel." Do you swap the buttons making the logical always in the same place, or do you keep them so that "OK" is always in the same place?
Eric's response: So the first thing is about Fitt's Law. Having the button on a border does NOTHING to change the calculation. You are probably thinking of the effect of a hard stop. So if you have a button and the cursor is stopped from leaving the target on some axis, then the size of the button becomes effectively infinite on that axis. But since the cursor will just move through the button, this is not true in the case you stated.
The first answer to that question is to follow standards. Microsoft created a rather strong standard of having the cancel button far right, and then other buttons to the left of that, with the default last. This is not a particularly good design. But Microsoft has a big footprint and some user populations have come to expect it.
If I was doing the design without a standard to worry about, I would probably put the default hard left. In this way the default is always leftmost and flows logically as the first item as the user goes down the screen. I would also put the CANCEL button far right, to get it out of the way, but give it a consistent position.
November 27, 2006 – submitted by Tony Gullaci of Vancouver, Canada
Question: Hi Dr Schaffer. We are currently designing a Web form that asks a series of questions with yes/no answers. This form would be used infrequently by our external customers.
In your opinion what would be the best control to capture the user's choice? Our team can't agree on a particular control, half would like to use two radio buttons with Yes and No with no default set. The other half would like to use a Y/N drop-down list with a blank option.
Eric's response: Generally with a Yes/No item I would like to see it converted into a CHECK BOX.
So...
Do you want Premium Service?
Yes
No
becomes:
Premium Service
Other than that, the radio button is clearly better then the drop down. It makes the choices obvious without having to click to see them. It also take one less click.
I generally try to fight the idea that forcing the user to make a click to choose is useful. It seems that some court cases have forced the issue, so you can't make "accept the agreement" a default selection. But I don't think that actually gets anyone extra to read the agreement.
November 13, 2006 – submitted by Aditya Dwivedi of Mumbai, India
Question: I find it very amusing that although having a side menu on the right makes browsing a site faster, most sites still have a left sub menu. I understand that users have been accustomed to this tradition for too long to drastically change it, but shouldn't we be moving to a right-sided navigational panel?
Eric's response: Right. We do not easily go against established population stereotypes. Even the horrible QWERTY keyboard remains despite a load of studies proving the superiority of the Dvorak design. Just forget it and live with the left navigation please.
October 4, 2006 – submitted by Patricia Burns of NY, USA
Question: Are there any user interface standards for when to "auto-tab"? That is, in fields where data entered does not exceed the maximum length, the user would naturally have to tab to the next field. But when the max has been entered (e.g., in a date field), is it considered easier on the user to keep the focus in that field or move it to the next data entry field? Is there a standard for radio buttons, Y/N, check boxes, etc? Thanks.
Eric's response: Yep.
Generally do NOT use auto-tab. It forces the user to check to see if he/she needs to press tab after every field. Because the user does not know which fields will fill completely and therefore not require a tab. It is far better to always require pressing tab, rather then having to SOMETIMES press tab.
The only exception to this is when you are moving between segments of an entry WITHIN a masked field. For example sometimes what is seen as a single field may be actually several fields (like a phone number in segments). Then moving between segments should skip. It is also much better if backspace moves backwards through all segments.
August 9, 2006 – submitted by Mary Ann Eiler of Chicago, IL
Question: I love your newsletter and in the past took several courses with Human Factors. Now I have a question. Here at work I am told that a main menu on the home page should ideally not have more than seven major links – the old George Miller principle of, I think, 5 plus or minus 2. But I always thought this applied mostly to chuncking, phone numbers, etc.
What is your read on number of links on a home page?
Eric's response: Well, that thinking that a menu should hold just 7 plus or minus 2 was discredited about 12 years ago. (See our newsletters on breadth vs. depth).
Currently I would think the optimal number of items is more like 18-24 in groups of no more than 10 items.
July 27, 2006 – submitted by Ravindra Papineni of San Antonio, TX
Question: As a user, I like the drop down lists that go to the selected page, after merely selecting it. My mind just expects to go the selected page without doing another click. On some sites (including Amazon.com!), I have to click on "go" button AFTER I selected my list. I feel this later method is not quite intuitive. Do you agree?
Eric's response: I disagree twice.
First and most importantly, if you are a professional usability engineer you will NOT design referencing YOUR personal preferences. You will design based on the literature and models in the field. When you design based on your personal preferences you are designing based on a sample of ONE and designing based on a highly atypical sample (you are not an average target user).
Second, the normal expected behavior of a dropdown list is to make a selection, but NOT take an action.
June 24, 2006 – submitted by T.J. Wolfe of FL, USA
Question: What percentage of users have adopted the convention of using a company logo to return to the home page?
Eric's response: About 30% of users expect the "back to homepage" link to be at the top left where the logo normally appears. I also suspect that many more users would eventually try the logo if they do not find an explicit home page link. However, I do not think it is good practice to rely on the logo as a home page link. I would provide it as a secondary method only.
May 17, 2006 – submitted by Tony Gullaci of BC, Canada
Question: Hi Dr. Schaffer,
Your advice would be greatly appreciated. I'm currently involved with a project that will display information based on the criteria selected by the user. The user however will need to select from a list of fifty options.
My approach would be to ask the user a series of questions (wizard) to narrow the number of choices available to them.
Is this a good approach?
Eric's response: It depends a lot on the response time of the query. In general we want to make it quick and easy to try another selection. So we build search criteria fields right above the results. You can modify the fields and just pull up the results. Picking from 50 choices is hardly earth shattering and I would try to make it possible to select and look... without stepping through a wizard.
March 16, 2006 – submitted by Deb Holmes of Tennesee, USA
Question: Can you recommend a site, article or book that demonstrates good solutions for complex navigation needs? Our portal offers the ability to perform a number of quite distinct actions and therefore needs a large number (at least 10) top level navigation nodes. We prefer these be persistently displayed because users have a strong need to switch easily between these top level options. Many of the top level functions are very complex and have 2-3 levels of additional navigation. We are looking for a compact and intuitive way to guide users through this maze.
Eric's response: The best method I know for a single page is a hierarchical menu. This puts links grouped in logical categories (generally of 10 or less links). It is easy to get 30 descriptive links on a page, or even 50 if you crunch things a bit. This is the most items you can get at a single click.
You can then offer these hierarchical menus using a navigation method like tabs. So you can tab across a set of these menus. So, say 10 tabs, gives access to about 300 links. THEN, you can also have each tab give a left navigation panel (like this site). This will give about 20 hierarchical menus per tab. So then you get to 6,000 links.
The other point to make is that you should follow the cockpit design strategy of having the frequently used and critical links immediately available. Then have the less important links a click or two away.
February 16, 2006 – submitted by Emilya Naymark of Garden City, NY
Question: I am part of a creative / usability team working on re-designing a number of member-oriented e-commerce Web sites. We just found out that the most frequently used page on all our sites is the log-in error page (forgot user name, forgot password, etc.) Is there a way we can make this a smoother experience for our members?
Eric's response: Yes. The login is a very critical issue, and there is a lot that can be done. Of course, all usability recommendations must be considered in the light of security issues.
Consider using an email ID instead of a user name. The email ID is always unique, but also hard to forget.
Avoid making the password sensitive to case. Many users have their caps/lock on by accident. If your security staff push you on this I have an algorithm (patent applied for) that is a compromise, solving the caps/lock problem but keeping almost all of the extra security afforded by a case-sensitive password.
Avoid putting restrictions on the password. Many people have just one, or a few passwords that they commonly use. If you put a restriction (like must contain a number) that forces them to create a new password, it is a burden and is likely to be forgotten.
It is good to use cookies to allow the user to keep the login on a machine so the login need not be repeated.
Finally, try to have a "forgot password" option, with an easy way to get the password reissued and sent to the user.
January 13, 2006 – submitted by Vineet Chandra of Roseland, NJ
Question: At our company, we develop many Web applications. In most cases, the user needs to log in, as they are dealing with financial and other personal data.
The issue is we have is an "X" on an icon and under that we sometimes write exit and sometimes logout. We would like to be consistent on this.
The debate is does exit mean close the browser window with or without a warning message, and logout mean bring the user back to the home page of the application and not close the browser window.
Are these terms interchangeable? Should we have two different icons: one for exit and one for logout? Or should we just write logout without an icon and leave the "X" only for exit.
Is there any standard for this that is generally accepted internationally.
Thank you for your insight on this issue.
Eric's response: Yes, there is indeed a difference.
Logout explicitly reminds the user that they are ending the authenticated connection. After selecting logout they would go to a login page or non-authenticated home page (as appropriate).
Exit refers to leaving the application. This should indeed close the application.
Logout would be important to use when there are two states of interaction; authenticated and not authenticated. It is also correct to use when the user will be returned to a point where login is possible. Commonly, this is the case where the user may want to control access to the facility, and wants to be able to temporarily logout, but then may return to the application shortly.
Use Exit if you are dumping the user out of the application completely.
December 13, 2005 – submitted by S. C. of Los Angeles, CA
Question: Are there any studies or best practices that determine the best place for "Welcome Username" verbiage and "Sign In/Sign Out" links on a non-transactional Web site? I'm being asked by upper management to remove our existing login information and links from the upper right corner of our site, and move them further down on the page. I believe this info should always be located at the top of the page where it is easy for the user to find and see whether or not they're logged in. What do you think?
Eric's response: You say the site is not transactional, but it needs a login. I am then left wondering what the login is for. I have certainly seen sites with useless logins. If this is the case I strongly agree with your management, move the login down the page. Or even better – OFF the page. Sometimes marketing departments fantasize that users would love to register at their site, fill in a long form with personal details, and then receive no benefit.
If the login is important, then it needs to be prominent. I think the more common placement is in the upper left of the page, just under the logo. The other strategy is to let the user proceed as far as possible without login, and then provide a login request when they request a function that requires login. This strategy might be a bit messy. But the advantage is that it draws the users in and then confronts them with a registration requirement only when they are involved with the site. You will get more registrations that way.
December 8, 2005 – submitted by Laura Christopherson of Chapel Hill, NC
Question: I can't seem to find any research on using Web site link titles/labels such as "General Information." To me it is bad to title a Web site section as such because:
it is non-specific
it is not indicative of what a user can find there
it's ambiguous
and everything on a Web site is "information."
Do you know of any research that specifically says the use of a label like "General Information" is a no-no?
Eric's response: Well it does violate one of the most key principles of writing ("be specific"). It also violates the key Web design principle of having a strong "scent.".
Finally, it really totally ticks me off. The word "INFORMATION" is my pet peeve. It is a long word that does not mean anything! If you label the form "Customer Information" you can change it to "Customer" and it works FINE. THEN, we add "General"!!!! Sigh...
November 28, 2005 – submitted by Pat Malecek of St. Louis, MO
Question: We are revisiting standards for our custom workstation and the following notion came up: Should developers / vendors be required to lock navigation (or controls) in view?
Our users have multiple applications open across two monitors. Applications are often delivering table-style data about a particular customer, product etc. A few apps are keeping controls persistently in view by locking them in a top pane (frame, etc.).
Can you speak to:
True benefits for the users?
Difficulties for developers/ vendors?
Published research?
Note: as we move forward, we will likely be doing more and more Web-based apps.
Eric's response: This question is very much an issue of the user model of the application. In your situation I assume you are creating displays to be used my brokers, dealers, and quants in monitoring the market. It is common for an individual to set up their display space with a blinding array of content, and then leave them untouched for many days. If this is the case, the LAST thing you would want is to have the controls taking valuable display space. You would want a small "setup" button that would then display a set of controls.
There are other situations where control access MUST be constant and locked down. For example in avionics, we want to keep control position as constant as possible. In bad weather it can be hard to even read the button labels. So the pilot relies on position. It is also undesirable to have to dig for essential controls. In this case locking controls can make good sense.
In more "common" types of applications the question of navigation control persistence is driven by taskflow. If the taskflow is modal (where the user decides on a task, selects it, and does the whole task) then a classic menu is better. The menu does not persist. If the taskflow is non-modal (with the user exploring or moving randomly through the interface, then persistent navigation makes sense (like tabs).
Beyond the primary navigation controls the operating control presentation should be based on standards for the particular page types. Having done over 200 customized standards we have seen every possible configuration. But it is generally good practice to make the controls visible. If there are many controls use the strategy of putting the key controls in front. This is like an aircraft cockpit, where the controls that are used to stay upright are right in front of the pilot. Controls used infrequently like fuel tank switches and circuit breakers, are placed off to the side.
November 17, 2005 – submitted by Nupur Khanna Vij of New Delhi, India
Question: How do we give the user control over the five levels of navigation in a portal application (using IBM Sphere) being developed in a PDA, where the use of breadcrumbs is a bad design because of space constraints on a small screen.
Do you think providing a drill down via hypertext links be intuitive?
Eric's response: There are two types of navigation to consider. For non-modal tasks, where the user must bounce around an interface, a persistent menu scheme is needed. Tabs are an example of this. If the navigation is modal, where the user just needs to get to one task, do the task, and then possibly consider other tasks, then a hierarchical menu is best.
Five levels of navigation does seem a bit deep. In a hierarchical menu you may be able to reduce the number of levels (particularly for the frequently used functions). Instead of this...
Business News
HR
Local Activities
Technical Resources
Consider a menu more like this...
Business News (Stock Price 49)
HR
Salary Insurance Other Benefits
Emergency
Local Activities
Lunch Clubs Other
Technical Activities
Notice that frequently used functions are moved to the top.
November 15, 2005 – submitted by Steve Chalastra of Toronto, Canada
Question: There are conflicting opinions here about whether navigation bars (<< < 1,2, n > >>) for paging tables belong at the top or the bottom of the table. My feeling is that the bottom is best because the decision as to whether paging is required is made after, not before, the user has visually scanned down the page.
At the optimal resolution, the point of table pages is to eliminate vertical scrolling so the navigation bar should always be visible. Where scrolling is present (for example, if the user selects a greater number of rows per page), the argument is even stronger. When they have scrolled down to determine that the sought-after data is not there, they have the opportunity to navigate to the next page. They should not have to scroll back up to the top (or click an additional "Top" link) to return to the navigation controls.
Could you please weigh in on this?
Eric's response: The display has two roles. First the display indicates how many pages the search has found. This is often the FIRST thing the user needs to see and serves a labeling function. Then when the scan of the results is done, the user needs this bar to proceed to the next set of records. So logically the bar belongs at both the top and the bottom. This is perhaps not a bad decision. But there may not be room for the bar at top and bottom. This will not happen in a scrolling page, as the addition of the one line for the navigation bar is trivial. So for a scrolling page putting the bar at the top and bottom is fine. For a FIXED display then I would just have the bar at the top if I felt the duplication was too space intensive. The user will see the bar at the top and hopefully remember it is there. Also this does minimize mouse movement distance.
October 18, 2005 – submitted by Scott Lary of Austin, TX
Question: Which gives better results on a
simple"'more info" / contact page?
(1) the client clicks and sends a "Mailto:"
- or-
(2) the client fills in a form.
I.E., what does your research show? Note: this is for a Transcendental Meditation related site.
Eric's response: People (and other sentient organisms) are pretty efficient in their economic
analysis. When the rewards are very high, they tend to be willing to do a
lot of work to reach the goal. When the rewards are meager, they are willing
to do little or no work. If you hold the value of the goal constant (in
your case of Transcendental Mediation™ I guess stress release and eventual enlightenment) then you will generally find that people will request information more often if the work to make the request is less. So get the minimum information you really need to follow up. Application of these "approach-avoidance models" gives a hearty vote for "Mailto:". Unfortunately for many or our colleagues, marketing departments want more data. So they have a challenge. But I can't forget one study which showed just adding an OPTIONAL comment field on a survey cut response by 90%. People are sensitive.
September 30, 2005 – submitted by Melanie Weber of Waterloo, Canada
Question: We are in the process of building an application where we collect and display data but are running into some space issues. The space issue is in the data view area where there is more data to display than room. Our approach has been to display the most frequently used data and put the remainder in a hover/mouse over. This approach seems to work well for our users as they can choose to see the extra data when required. My question is how do we inform the user that there is data in a hover/mouse over? We have been debating what type of icon/image would be the most obvious to the user. Is there any preferences/studies that would outline what people look for that would indicate more data is available.
I appreciate your help.
Melanie Weber, CUA
Eric's response: Well in my experience is is pretty hard to find an icon that more then 50% of users understand without training. In addition, this is not really "more information" (that is typically show with an "I" icon). So, consider a word. For example you could have a button that says [more].
August 4, 2005 – submitted by Cheryl Sella of Herndon, VA
Question: Not really sure if this is the right forum but... could you point me towards research or metrics on Help system design. How can I encourage people to actually use Help (other than making the content useful!) I've looked at a lot of Web design stuff but don't see too much specifically on Help. Maybe I'm just not looking in the right places? I'd appreciate any guidance you could offer. Thanks.
Eric's response: I think your objective is wrong. If you want people to use Help simply build a bad user interface and make sure to very highly motivate the users. Obvious a silly idea, but it meets your objective.
The real objective, of course, is to ensure good performance and satisfaction. This is unlikely to occur from a good Help system. Instead design the interface so it is self-evident and needs no Help. Unless you really force people, they will not normally use Help. You can write WONDERFUL Help. But people just don't use it often. In fact, a good place to hide things is under the Help button. For example I have seen companies that do not want to hear from customers put their 800 number under Help.
Generally I find that the only really appropriate Help facility is for answering very specific questions about a single field.
If you want metrics for Help there are several ways to look at it. You can measure the number of times Help is accessed (this is mostly a measure of how bad the interface design is). You can have an exit survey asking if the Help answered the user's question (not bad). Beyond this, you can more specifically set users tasks, have the users try to complete them in a usability testing environment and see what happens when they access Help (very useful).
Question: An executive in my company wants to convert our current URL (www.xxxxxxxxx.com) to a URL that includes a hyphen
(www.xx-xxx.com). His reasoning is that the hyphenated URL is much shorter. I work for a large television network and the URL will be used on television and on the radio a lot. To make matters worse, he also wants to convert to .tv instead of .com. I've described all of the reasons this is a bad idea, but yet I'm still asked to make the change. Is there any specific research that I can point to to prove my point?
Eric's response: The rational that a shorter URL is good holds to some extent. But the real key issue in correct copying and recall is the number of "chunks" of information. In an information processing sense, the SECOND of these URLs is actually much shorter then the first.
www.my-documents-online.com
www.Y8SKI2.com
But you raise other issues. First, we know that people tend to see and remember what they expect. Even if you change the domain to ".tv" you can be assured that a big chunk of people will type ".com". Unless you want to really work at helping people to remember ".tv" (maybe as a part of some branding ploy) I would stick with ".com" for sure. Think of it like people have a default ".com" in their head. You get it remembered for free.
Second, the hyphen is a real issue also. People do not pay the same type of attention to punctuation as letters and numbers. In non-online environments the punctuation does not really matter, so people learn to ignore it. Therefore, if you include the hyphen only a fraction of people will remember it.
The value of the hyphen may be in making the grouping of letters clear. For example for a personal page:
www.erickleeny.com
www.erick-leeny.com
www.eric-kleeny.com
Clearly the hyphen helps. But if you flash the URL on screen and then expect people to type it later, many will leave out the useful hyphen. The trick then is to own both the hyphenated and the non-hyphenated domains.
July 21, 2005 – submitted by Brian of Illinois, USA
Question: I'd like my users to be able to toggle between two hyperlinks on my weather Web site. There is an 'English' or 'Metric' hyperlink.
I'm trying to determine if the user is on the 'English' section if it should be presented the following way: Verify the hyperlink 'English' as the default (bold, underlined and clickable). The 'Metric' hyperlink is clickable and normal, underlined text. Verify temperatures will be displayed in Fahrenheit with degree symbol and precipitation in inches.
Eric's response: If you want to use a link show only the link for the state they are NOT in. So on the English site, have a link "Celsius/Centimeter Version". On the Metric site have "Fahrenheit/Inches Version".
Another way to handle it is with two radio buttons. These may not really BE radio buttons, just images that LOOK like them. But this may be better as it will make the choice more obvious.
July 13, 2005 – submitted by Jeff Langr Colorado Springs, CO
Question: I'm working on an application that provides chat functionality. The
customer wants the chat input field to be restricted to X characters
(and
have that amount to be
configurable).
Questions arise when dealing with text pasted into the input field. How should things work when the user pastes X+1 characters? There are a
number of options:
- disallow completely and provide immediate feedback to the user (status message, beep, whatever)
- paste X characters, truncating the X+1 character; provide feedback to the user
- paste all X+1 characters, but provide feedback to the user and
disallow entry until the field contains X characters
Similarly, suppose the field contains X-1 characters, and the user pastes 2 characters in the middle of the input field. Options include:
- disallow completely
- paste both characters and truncate at the right end of the field
- paste only one character (i.e. only the number of characters that will fit)
- paste all characters, but provide feedback to the user and disallow entry until the field contains X characters
Eric's response: On a restricted chat field I would truncate the long pasted entry. This
is just like the past operation entered until the end of the field size
and then stopped (just like entering text by hand). No message is
needed. Just leave the user with the final material showing (as if they
had typed those characters.
The entry of characters into the full field is a bit unlikely. But I would simply not allow the entry (as if they were at the end of the field and trying to enter additional characters).
However, it would be good practice to show the size of the entry allowed and then count down the remaining characters.
Question: I have a form with two buttons at the bottom: Save
and Cancel. Is there research to support separating the buttons visually
(one on the left, one on the right) to reduce the chance that a user
selects the Cancel button instead of the Save button? Cancel will simply
close the form without making changes (which we would probably want to
warn on if the user had made changes), while Save would save the form
changes. Our business user would like to keep the buttons as close as
possible together.
Eric's response: I think the actual research on this question is spotty. But clearly the
key thing is to follow the conventions of your environment. That means
if you are in a windows GUI you will put them together. This is because
it is a standard that people have come to expect. In the browser, put
the "enter" button on the left and the "clear" button on the right.
There are several models we can use to evaluate these. For example, you can look at mouse movement, error likelihood, and eye tracking. But in reality following the standards, now that they are long set, is required anyway.
De facto standards are so powerful that I would recommend using blue underlined text for hypertext links. It is one of the WORST possible choices (with problems due to both chromatic aberration AND small field tritanopia). But you simply have to follow that standard or risk confusing users.
April 28, 2005 – submitted by Pat Malecek of St. Louis, MO
Question: This question pertains to internal applications. All users have a standard platform (OS, browser, etc.) All browser controls/options are locked down.
For apps and/or forms that have multiple fields, is there a standard or guideline for client-side vs. server-side validation? Is one method proven to benefit the user more than the other?
Eric's response: Client-side validation allows error feedback as soon as the user presses TAB or otherwise leaves the field. This is almost always best. Otherwise the user does not get feedback until the whole screen is complete and the context of the field in error must be recalled, which takes time at least.
The only exception is heads-down data entry. Here it is best to not interrupt the user's flow of work. So errors are handled when the whole screen is done. In this case it does not really matter which side the error handling is done on.
May 12, 2005 – submitted by Shari Thurow of Carpentersville, IL
Question: With all due respect, I do not feel you answered my April 8, 2005 site map question. Perhaps I should rephrase it.
I am referring to a Web page named sitemap.html (for example). I do not believe that a site map should contain links for every single page on a site. On a small site, it is reasonable to have all links with short descriptions about the information available on that section of a site.
On a larger site, however, I think a one-page site map is not a good idea. I tend to use a different site map format and use category pages to serve an additional site map function.
Have you found that small, medium, and large sites should have different site maps from a usability perspective? I hope I have made my question more clear.
Thank you! And great answer about the dollar sign format in forms.
Eric's response: Like help and documentation; I see a site map as a band aid to compensate for poor design. The user should understand the structure of the site from the main navigation. That navigation itself should show the categorization scheme.
I am thinking hard. Trying to think of an example where I would use a site map. I can think of examples where I would use help and documentation. Those involve very complex systems. But, I can think of just ONE situation where I would recommend a site map. IF I have a site with a bad structure that people could not understand... AND I had to make a very quick fix to help the situation because the structure could not be changed immediately. THEN, a site map would be a reasonable (if sad) stop-gap measure.
April 26, 2005 – submitted by Vicki Splaine of USA
Question: Can you direct me to research/best practices for a Web site/newsletter registration interface?
My company has many Web sites (over 100), and we are looking to put a somewhat standard registration UI in place that will work with many audiences. Any suggestions would be greatly appreciated. Thanks in advance.
Eric's response: Design of a registration interface follows the same principles as the design of any form-based interface. Use common practices of good labeling, grouping, sequencing, left justification, etc.
The content requirements of the registration are likely to differ depending on the site's focus, users, and marketing intent. It is important to control the impulse of marketing staff to want complete autobiographical data on every registrant. But this said; you are unlikely to be able to just identify a single set of registration details.
If it is possible to register once, and use that registration again, this would be quite valuable if users would use multiple sites.
Lastly, it is very important to properly set WHERE in the interface registration occurs. Do NOT try to get people to register early in the site. It is far better to have the user far into the interface before registration is required. In this way they will be more likely to see value in completing the registration procedure.
April 8, 2005 – submitted by Shari Thurow of Carpentersville, IL
Question: I am doing research on site maps. I think that the format of a site map depends on the number of pages on a Web site. Have you found that small, medium, and large sites should have different site maps from a usability perspective?
By the way, if you write a white paper on this, I can easily promote it at my conference engagements and columns.
Thank you!
Eric's response: I assume by site map you mean the navigational structure, rather than how to design the deliverable document that shows the site map.
Indeed, the size of the site does affect the structural design. Ideally, all sites would be a single non-scrolling page with all the useful information immediately visible. But almost all sites have more than one screen of information (sometimes not more than one screen of USEFUL information, but we will set that aside). With more information comes the need to navigate.
We have days of material on selecting navigational structures in our courses. The process and principles are pretty well understood. You must look at the user's taskflow. If the user must move around the site in a somewhat random way (exploration) then a persistent method is needed like tabs or a left navigation bar. If the user goes through in a linear fashion we use menus. We also know that it is best to provide more menu choices at the top of the site (perhaps 18-24) rather than make a site with many layers of menu.
What makes site structures an art, is the need to have them reflect the user's deep mental model of the domain. This can often be complicated by the fact that the target users may have a number of possibly conflicting mental models. One may see the travel site as an itinerary builder. Another may see the site as an interaction with a travel agent. This challenge is what makes navigation something anyone can do (just add tabs) but it takes a lifetime to learn to do well.
March 7, 2005 – submitted by M of Bangalore,
India
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.
January 18, 2005– submitted by Prashant
Dubey of India
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.
October 28, 2004 – submitted by Paulette
Chestnut of USA
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.
October 14, 2004 – submitted by Vinjamuri
Guru Prasad of Hyderabad, India
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.
September 15, 2004 – submitted by Subbu
Nistala of USA
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.
August 23, 2004 – submitted by Rajiv
Bongirwar of Mumbai, India
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.
August 18, 2004 – submitted
by Konstantin Verbov of San Francisco, CA
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).
August 9, 2004 – submitted
by Sudhir Nain of India
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.
July 31, 2004 – submitted
by Jesús Morones of Chihuahua, Mexico
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.
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:
The user will be confused that a button is changing text.
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.
July 14, 2004 – submitted
by Melissa Vincifora of Warren, NJ
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!!!
July 8, 2004 – submitted
by Rigmor Wennevold of Oslo, Norway
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...
hire employee
transfer employee
fire employee
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.
February 5, 2004 – submitted
by Gretchen Enger of St. Paul, MN
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.
November 17, 2003 – submitted
by Tony Gullaci of Canada
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.
September 22, 2003 – submitted
by Jeff Shege of Nairobi, Kenya
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.
September 11, 2003 – submitted
by Susan Parker of Massachussetts
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. :)
September 3, 2003 – submitted
by Jennifer Sherer of Las Vegas, NV
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.
September 2, 2003 – submitted
by Sharon Merritt of United States
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.
August 14, 2003 – submitted
by Dan Mabini of Pewaukee, WI
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.
August 6, 2003 – submitted
by Jeff White of Charlotte, NC
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.
July 28, 2003 – submitted
by Janette Cullinan of USA
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.
July 2, 2003 – submitted
by Deborah Munson of Manchester, NH
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.
June 19, 2003 – submitted
by Jeff White of Charlotte, NC
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.
Followup Question: Thanks for the prompt answer to my
first question! Could you point me to some sources that specifically address
the breakdown of technical reports for display on the Web? Also, could
you elaborate on your statement "It requires a dedicated researcher
to overcome the obstacles"
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.
Eric's response: Jeff, let me be clear. I am NOT talking
about simply writing the technical reports in a better way. The reason
I say that "It requires a dedicated researcher to overcome the obstacles"
is that research reports embed useful insights into a mass of research
report formats. The classical "abstract, method, analysis, results,
discussion" structures are horribly inefficient for conveying the
core value of research. Often 10 pages is spent to convey an insight that
could easily be put in a single sentence for a practitioner. Beyond this,
the actual results are often complicated by problematic research designs
and flawed statistical treatments. So it takes a very dedicated and knowledgeable
individual to get anything useful from the research.
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.
June 13, 2003 – submitted
by Adam Winkler of Boston, MA
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.
May 31, 2003 – submitted
by Jose Pariente of New York, NY
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.
May 29, 2003 – submitted
by Matt Brannon of Columbus, OH
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)
May 15, 2003 – submitted
by Rose Johnson of Colorado Springs, CO
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:
Creating printer-friendly Web pages, where an
entire document is collated for printing purposes, complete with a TOC.
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.
March 27, 2003 – submitted
by Christina Formentini of United States
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
March 10, 2003 – submitted
by Sandy Kruczkowski of Boston, MA
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.
February 13, 2003 – submitted
by K. Olson of Boston, MA
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.
November 11, 2002 – submitted
by Malc Wilson of USA
Question: In a functional Web page, when should I use
"Reset" & "Apply" and when should I use "Cancel"
& "Save"?
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.
Question: I am in the process of designing a password
reset scenario for a user using secret questions. How many questions do
you think are permissible from a user experience perspective? (The less
the questions, the less the security too!!)
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.
August 26, 2002 – submitted
by S. Udovic of Holmdel, NJ
Question: We need to collect information from users
that will automate a sequence of numbers they have to type frequently.
The sequence contains numbers with an embedded password. We could collect
this all in one string, but the password must appear in a password field
so that it is not visible on the screen but appears as *** characters.
So, we can break this into three text input fields OR we can have them
enter the password in a password field and enter the other characters
in a field that allows you to enter the entire string and "code"
where the password should appear, for example, the field would contain
530126Password555 with the "code" character entered here as
the word "Password." Clearly, this is not simple to represent
in either case, but I'd like to know whether there is any data showing
that the latter technique would be too confusing.
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.
June 24, 2002 – submitted
by Andrea Clement of Seattle, WA
Question: I just discovered your Web site today and
am looking for some benchmarking data on desirable and acceptable user
response times for screen loading and field tabbing for a client/server
Windows based business application. Do such metrics exist? If so, where
can I find them?
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.
April 24, 2002 – submitted
by Erwin Van Trier of Plano, TX
Question: We are currently having a discussion on the
implementation of different functions manipulating the same feature (within
1 GUI). The functions are Display, Create, Modify and Remove
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.
February 4, 2002 – submitted
by John Hooper of United States
Question: I have a list of data with some rows contain
sub data. I would like to be able to drill down from the header data to
the sub data below and considered using an expand and collapse hierarchy
structure. What are your views on using a two tier hierarchy?
Eric's response: Two tier hierarchies are fine for experienced
users.
Question: I have a usability question regarding pre-populating
fields in Web applications. If a form is being prepopulated by a web application
and a particular field has no associated data for a particular record,
is it better to leave the field blank or to populate the field with some
verbiage such as "N/A"? Thank you for your time with answering
this question.
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?
January 10, 2002 – submitted
by Markus Mayer of Vienna, Austria
Question: Hi Eric – When designing Intranet applications
that are only used on windows machines is it advisable to follow platform
or Internet naming conventions (i.e. "ok" and "cancel"
vs. "submit" and "back"), especially when users aren't
particularly Internet educated and experienced.
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.
January 8, 2002 – submitted
by Donna Way of Hartford, CT
Question: Do you have any data or studies that reflect
how users react to a top/bottom versus left hand navigation bar? We are
attempting to design a company-wide template that will effect thousands
of users and I haven't been able to locate any specific data.
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.
December 28, 2001 – submitted
by Sara Douglas of Novato, CA
Question: Eric, what does the term "glosses"
mean? You refer to it in your recent newsletter under the Web Site Design Issues Do's and Don'ts item #27.
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.
December 26, 2001 – submitted
by Daphna Mendes of Israel
Question: Is changing toolbars (like in Microsoft Outlook)
user friendly?
By changing toolbars I mean that the icons on the toolbar are changed
while moving between the views.
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.
November 19, 2001 – submitted
by Chris Uttley of Toronto, ON
Question: We build Gui software for advertising order
taking. Many of our users are keyboard power-users, with no interest in
using a mouse. On some of our windows, we want to provide the user with
the ability to jump right into a field using a keyboard combination, rather
than tabbing through a large number of fields.
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.
October 3 , 2001 – submitted
by Susan Saeger of Rochester, NY
Question: Are there standards for developing an application
wizard? We are working on creating a wizard that will allow a user to
setup security for an application.
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.
August 16, 2001 – submitted
by Cindy Huntley of El Dorado Hills, California
Question: What is the "norm" for the number
of days a user should be required to change their password? Our web app
currently requires our users to change theirs every 30 days, but we're
hearing that's "too often." They would prefer 6 months. Is that
acceptable?
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?
August 13, 2001 – submitted
by Jill McDaniel of Rochester, New York
Question: We are planning to use a "floating toolbar"
on our Intranet in an upcoming redesign.
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?
August 8, 2001 – submitted
by Chris Fortuin of the Netherlands
Question: Thanks for the useful newsletter. Concerning
user interface design I have a practical problem which comes around each
time in design teams when developing so-called workflow/document managed
information systems. The situation is that end-users need to view a (scanned)
document and use structured data the same time. How could a user interface
design effectively and efficiently support this situation? Do you have
a suggestion how to further analyze and solve this problem!?
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.
May 4, 2001 – submitted
by Chris Lee of North Caronlina
Question: I'm in the process of developing a usability
test plan for a prototype I've been working on. In my prototype, I have
users register into the system before searching for items as opposed to
registering before viewing search results. In Nielsen's work, he has suggested
prolonging registration as far as possible to reduce early exiting by
users but does not provide any references to support his claim. Do you
know of any published research that has compared the usability levels
of these different approaches?
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.
April 9, 2001 – submitted
by Christine Hubble of Toronto, Canada
Question: Cascading Menus (menus that expand when you
mouse over them, e.g. bedbathandbeyond.com)
seem to be a good idea from a usability standpoint (to reduce # of clicks),
and yet are not commonly used (at least on e-commerce sites). Why are
they not commonly used? I've heard that there are some technical drawbacks
to their use. What are those drawbacks?
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 "pulldown 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 pulldown 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.
March 28, 2001 – submitted
by Stephen Metcalf of Longbenton, UK
Question: Do you know of any sources of information
about designing browser-based transactional applications (rather than
the delivery of information)?
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.
March 22, 2001 – submitted
by Eileen Chong of Canada
Question: What do you think of pop-up information boxes?
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.
