Software Navigation and Interaction Design Challenges
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 th
