Ask Eric: Questions & Answers

September 19, 2007 – submitted by Shweta Shah of India

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.

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.

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).

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