Ask Eric: Questions & Answers

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.

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 9, 2004 – submitted by Anonymous

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 Manjunath of India

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 19, 2004 – submitted by Anonymous

Question: I have 2 questions:

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

There are arguments against this design which include:

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

Do you have any experience on this matter?

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

Microsoft UI Guidelines say the following:

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

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

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

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

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

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

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!!!

March 16, 2004 – submitted by Emily Goodin of USA

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

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

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

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

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

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