Ask Eric: Archived Questions

Question: In a high use and heavy data entry screen, where data entry labels and fields are placed in a three-column grid, what alignment would you suggest for the data entry labels. Should they be left-aligned or right-aligned to the data entry field. Thanks in advance.

Eric's response: Left-aligned labels and fields are easier to scan and are generally recommended. It is not a bad thing if the entry fields have two or three left margins. This makes it easier to handle different length labels and also easier to quickly find an item as the different markers provide points of reference.

One exception to this is when you have to translate the labels to a different language (particularly if it is German which often results in a 300% increase in label space requirements). Then it is best to put the label ABOVE the field.

Top

Question: Hello Sir, I am Naveen Prasad from Bangalore, India, I have 2 questions for you,

1) As per studies, black color (foreground) increases readability on a white background but why do most people prefer writing in blue ink?

2) Usually, Urdu or Hebrew Web sites are designed to read from right from left but why does the horizontal scroll bar always default to the left corner of the browser? I feel it should be to the right side. Is Microsoft planning for any localization on this?

Eric's response: Yes, people read dark text on a white background 32% faster than light text on a dark background. DARK blue ink is dark enough that the difference from black is probably small. On the screen of course, blue text signifies a link..

A brighter and pure blue color is a bit dangerous to use. There is an effect called "small field tritanopia". The fovea centralis (the small area of the retina most sensitive to detail) has very few blue receptors so is not very sensitive to blue.

On the second question, we have some data that it might have been better to put the scroll bars on the LEFT for English sites! But in this case the standard is pretty much set and we will probably live with it, and do so internationally.

Note the following update from one of our readers, Avner Laufer of Israel:

Scrolling bar on the left hand side actually exists in Hebrew sites for years. Microsoft were doing a major job on this difficult localization. Well, not all browsers support it (only Internet Explorer; Firefox ignores that), not all Israeli webmasters know how to do that. See example from the Hebrew site of Google. As you can in IE, the scrolling bar exists on the left hand side (same page appears with a right scrolling bar on Firefox). Yes, it takes us an extra second to figure out where the scroll is, but hey, who's using that bar anyway? I usually use the mouse wheel, space bar or Page Down button to scroll (although I'm probably not the common user).

In any case, to provide a more comprehensive answer, building Web sites for Hebrew (and other right-to-left languages such as Arabic) is more complex. You actually need to convert the whole site – for example: the left navigation bar appears on the right hand side! The logo is positioned on the top right corner, etc.

Top

Question: I am an HFI-CUA and I would like to know if there any studies around marking required versus optional fields on the Web. For example, if the application has 95% required fields, would it make more sense to mark optional fields instead of the required ones? What are some best practices around marking the optional fields?

Eric's response: The marking of required fields is not a universal practice. But it is generally useful, particularly when you expect the user may want to skip optional fields for privacy or time reasons (such as in registration forms). IF you decide to mark fields then you have to mark the required fields as this has become a de facto international standard. When marking the required fields this is generally done with an asterisk or similar mark next to the field. It is better to put it before the field (as this is a bit more logical for eye scan and also has better alignment.

Top

Question: Has there been any research done to compare the preference or effectiveness of the vertical versus horizontal display for comparison purposes?

Most of the time I see vertical displays of the data to go down the list of attributes and scan across for differences between options selected or presented. I see this when comparing car models in the industry but even on the back of software boxes that offer different versions, like Turbo Tax for example.

I would appreciate your thoughts and you pointing me to any research you may have or have come across. Thank you in advance.

Eric's response: If the number of items is not an issue then the design should mimic the task, with the first dimension on the left (where people will start) and the secondary data horizontally.

If the user is looking for a car, and then checking for attributes, then the car is vertical. If the user is looking for an attribute, and then seeing what cars have it, then the attribute is on the vertical.

But more often the decision is a function of the NUMBER of items. The horizontal can really only fit 7-10 items at most, while the vertical can fit 20-30. So if there are 5 car models and 25 attributes, the attributes WILL go on the vertical.

Top

Question: I'm wondering if you have any opinions on labeling or language associated with "e-learning" or Web-based tutorials. Are there words or terms that people find particularly useful or intuitive? Do you think that words like "e-learning" intuitively encompass things like Webcasts, online seminars, Podcasts, and online tutorials? Your thoughts/opinions, "best practices" or research in the area that you can recommend would be greatly appreciated!

Eric's response: In general we want to use the most specific language that the user will understand. So it is better to say Webcast instead of e-learning. The term "e-learning" is unnecessarily broad. At the same time we need to watch to see if our target population will understand the terms. We can't assume that people will all understand jargon like Podcast. It is good to test such terms during data gathering and usability testing. That is the best way to be sure.

Top

Question: When a user clicks on the calendar icon next to a textbox in which he/she is being asked to enter a date value, I think the general consensus is that the user expects the calendar to highlight today's date in the calendar.

Questions: If the user has previously entered a date value in a textbox and now wants to edit the date, if the user clicks the calendar icon what date does the user expect to be highlighted in the calendar? Is it better to be consistent and highlight today's date or in the second scenario highlight the date previously selected? Should the coding choice depend on the circumstances of the application?

Eric's response: I'm struggling to think of a case where I would show the entered date... I don't see one. It is highly unlikely that someone would enter the date and THEN click the calendar to check which day it is (about 7 clicks with a keyboard/mouse switch equal to 3-6 more clicks depending on typing skill). They are far more likely to click on the calendar and then maybe click to switch months to find the date they want (about 3 clicks).

Top

Question: Hello Eric, I am to design 4 different look-and-feels for a Government portal. They want to choose one and implement the design using various tools, such as: Webspere, city Seal, sharepoint. We also want to incorporate new features. such as: My personal page, advanced search, a dynamic flash advertising area. I'm starting to gather requirements, etc. What should my time frame be for such an undertaking and what problems should I foresee? What is the best place to start. They are looking for something fresh. My goal is to achieve excellence...

Eric's response: Well I can't say I totally understand what you are trying to accomplish. It sounds like a combination of visual design and functional additions.

If you are addressing visual appearance (I have no idea why a government portal would want four skins) then the process requires:

1. Definition of brand objectives.
   There are specialists in this area that will generally take 1-2 months to define a set of brand characteristics. Other times executives just guess. But at the end you have a list of descriptive terms (ie. we are bold, fresh, keen, and responsive).
   
2. Creative design
   Based on the brand characteristics the visual design team creates a set of possible alternatives. There is good data to suggest that parallel design (having several graphic artists work independently) is a good practice. I would expect 1-2 weeks of work creating alternatives.
   
3. Selection and refinement
   Complete a brand perception test with actual target users. Here they select the version that is the most "bold," the most "fresh," etc. You will see the ones that best fit the target brand values. Then you can tweak them to reduce any problems (this is the most fresh, but a bit unresponsive... So we will add elements from the most responsive design). This whole process will take maybe 7-8 days.

In terms of functional additions I would need to know more about the planned enhancements. Some can be done in a couple of weeks. Others deserve significant research, design work, and iterative testing.

Top

Question: Have there been any studies on what numbering / lettering format is the most effective for multi-level procedural lists? Some say using numbers exclusively is easiest to follow, others say indented levels, etc. I have been unable to find any studies (preferably international) that show empirical evidence supporting a particular style. Different examples would include:

1. XXXXXXXX
1.1 XXXXXXXX
1.2 XXXXXXXX
1.2.1 XXXXXXXX
etc.

1. XXXXXXXX
A. XXXXXXXX
B. XXXXXXXX
1. XXXXXXXXX
a. XXXXXXXXX
etc.

Eric's response: Well the only thing I have seen on this was research that warns about very cluttered nested numbering. So the old "Section 2.9.21.4.7" is really bad. I would try to absolutely limit the nesting to three levels. If I can avoid numbering the secondary levels I would.

Top

Question: I'm part of a team redesigning the corporate Web site for a company that provides mortgages, and we're currently having a discussion about what should be included on the FAQ page.

One group wants generic "what do I need to know about mortgages" questions (which pretty much reproduce the content on other pages – without directing the reader to those pages – and do not include anything about the company's specific products). The other group wants questions specific to the company's products that are not answered elsewhere on the site.

Are there any guidelines about which is preferable? Any help you can give us would be appreciated.

Eric's response: First, it turns out that FAQs ARE actually read. So they are useful (more so than, for example, help facilities). They generally include questions that someone would ask AFTER they have read the site. They are NOT supposed to be a reiteration of the site. If you run usability tests or field questions for site users you may know what they would typically ask.

Top

Question: Are there any recommended (or commonly used) symbols to use for messages on a Web page? We use a green checkmark in front of our successful messages and a red circle containing a white exclamation point to indicate an error message. We now have a need to distinguish two different error message types. One is an error that the user can fix by changing the information entered on the input screen. The other is an error where the user cannot fix it himself, it must be fixed by another agency. It is being proposed that we use a red circle containing a white X. I feel that we should use something other than another red circle symbol. I searched the Web for a standard symbol set but could not find one. Do you know of any such standard? Thanks for your help.

Eric's response: Terry, there really is not a set of global icon standards. The closest one you can find would be the Microsoft Windows™ Environment Icons (just due to their near monopoly status). However, the icons you describe seem quite acceptable.

I am not sure I see a need for another type of error message icon. Your current icon flags the user that there is something wrong and they need to read the error message. I would simply suggest using a standardized text message format for this additional type of condition. For example....

[X] Error. This record is classified and cannot be deleted. Contact the intelligence service branch at 212-555-1214 for assistance.

Top

Question: Is there any specific font type, size and color should I consider depending upon the type of industry (IT, Automotive... etc.) I am designing for?

Eric's response: No. Not in terms of performance. The common fonts all test pretty much the same and do best with a white background. So there are no performance differences.

Now you mean styles that support a brand, and there is little proscriptive data (which means you have to try different styles and test the resulting brand perception).

Top

Question: I am designing our company home page. After trying many layouts & color combinations, finally it is over. Now, someone pointed out that Search should be preferably on top right. (Shaihk and Lenz (2006). My design does not fit search at top right. How do I justify my client's concern?

Eric's response: Well, Search in the top right IS right, unless Search is the primary task on the page, in which case the top of the center area (below logo or tabs) is best. I'm not sure why you would do something different.

Top

Question: I've recently encountered quite a few clients that are concerned with the "whitespace" being wasted on forms we've designed for them and asked that the forms be placed in multiple columns to fill that space. The only reason they ask is because they feel screen space is being wasted, there is no usability concern from them.

Looking at previous answers I find differing information and wonder if you could clear it up.

You've said both of the following: "reasonably dense forms are better than lots of scrolling" and "columns are suboptimal". When it comes to online forms what is ideal? I tend to think one column with the fields in a logical order.

And just to reiterate, in all cases the only reason the clients (unfortunately a few co-workers also feel this way) want to use two or more columns is they feel screen space is wasted.

Sometimes the one-column forces scrolling, which I don't feel is a problem, and is sometimes a secondary argument against a single-column form.

Eric's response: Obviously, if there is no need for content, we do not create additional fields to fill white space. But when you consider the tradeoff, it is FAR better to use multiple columns, than to have white space but have to scroll or move between pages. There are nuances based on user type. If people will use the form only once, then a bit more whitespace is worthwhile. If the user fills the form often, make it very dense. Multiple columns are needed for sure.

Top

Question: What would be the best way to convey to the user that they do not have access / authorization to perform a task or function initiated by a link or button.

There are three approaches that we are considering and your thoughts would be greatly appreciated.

Approach 1: The link/button is disabled

Approach 2: The link/button is not displayed

Approach 3: The link/button is displayed on the screen but when clicked would display a message stating that the user is not authorized to perform the task or function.

Eric's response: First forget the idea of a disabled or grayed out button. This is a rather nasty choice. The user sees a function that is desired, but can't select it. It also clutters the page.

If you MUST let the users know that a specific function is available to someone else, or to them if they upgrade, you can popup a MESSAGE. But this is VERY annoying and should be avoided unless you are truly forced to it. A reasonable example is when a bank clerk can select a function, but a popup asks for a supervisor to enter a confirmation code.

The best plan is to only show the user what they can do.

Top

Question: I have a question regarding placement of PRINT and CLOSE buttons on a read only mode of popup.
Explanation:
- On a page, we have a link to a report as: Report A.
- Based on user's login rights, one can view a read-only mode or editable mode of the report.
- User XYZ has read-only rights.
- He clicks on Report A and gets a popup.
- So on the bottom right corner of the popup should we have buttons as:
PRINT CLOSE
or
CLOSE PRINT
- Assuming print is the only action that users will perform on a read-only mode.

Eric's response: Well it is probably more important to be consistent than which sequence you choose. But I would suggest using "Print" then "Close." There is a convention that "Cancel" functions are rightmost in a window. So this would follow that principle.

Top

Question: What is your opinion on the fixed width vs. liquid layout issue? With monitors becoming larger and screen resolution standards increasing, this is a difficult factor when designing layout. Jakob Nielsen is very much opposed to fixed widths (although I've never seen his opinion on the issue for form/data application-based sites). Just because information-based sites stretch elegantly, should that dictate the same approach for an application-driven site?

Our current project involves a redesign of an application-based site. Knowing that users will be comparing rows of information within the same page, I feel the need to visually control the layout and the many tables of data and forms. Are we taking a wrong step? Is there a usable approach to honoring different screen resolutions while keeping control of the layout?

Many thanks!

Eric's response: Liquid page layouts can certainly work for typical information sites. But I have not seen a study showing a substantial advantage to this (see our October, 2002 newsletter).

For form filling applications you really need to target a single resolution and design for that. Field layout requires an assumed screen space. Having fields dynamically reposition will result in inconsistent entry sequence, odd grouping, and a failure to correspond to any paper source document.

So just pick a resolution and stick with that.

Top

Question: Is a Web page more readable if the paragraphs are indented? If so, why?

Eric's response: The issue is that there should be a clear paragraph separation so that the text is logically chunked. This can be done with an indent or a blank line. The indent may be a bit better as it saves a little space. This chunking makes it easier to scan and remember where text of interest was placed on the page.

Top

Question: In a Web application, should the buttons like save, done, continue, etc. come at the bottom of the browser window or is it better to place them just below the content that is above them?

In other words should a user expect buttons at a certain place in a browser window or is it okay that button locations vary screen to screen?

Eric's response: Vineet Ji, you have to think about this a little differently. The Web is not like a GUI with a fixed screen size. Would you have the buttons positioned for 640x480, then another button further down for 800x600, and other further down for 1024x768 resolution screens? Hmmmm. Does not work. Instead you must design for the taskflow and put the buttons where they make sense.

Once I had a client with a Vice President that wanted the buttons easily visible, so she put them in the upper right of the screen (as some GUIs do). In testing the users promptly scrolled down and then were perplexed when they saw no buttons at the bottom. The users rarely recovered in reasonable time.

For consistency you SHOULD have the buttons in the same LOGICAL place. You should design for your target resolution and TRY to have the content work well within the page size. But no, there is no practical way to lock down the Web.

Top

Question: What is your view on the use of tooltips as a replacement for field descriptions in an online help system for software? Alternatively, would you recommend the use of a "Description" field located in the GUI that contains the field descriptions. Do you know of any research to support your view?

Eric's response: Well the tooltip is just fine for simple, short, and usually useless help. But serious help requires far more space than can be provided in a tooltip. I am frankly not delighted with the "tool tip for each field" scheme. You have way too much waste help (e.g., Last Name –> "Type your full last name here"). Generally, I would rather see a link for help on just those fields that are likely to need help.

I have not seen any research, but it seems a bit simple to need a study. Just look through your help system, find the longest field description, and then put it in a tooltip format.

Top

Question: Are there standards or "best" color schemes to use when creating a GUI to an application or system?

Eric's response: No. There are a whole set of things to avoid based on legibility. For example people have trouble with highly saturated colors (particularly red and blue). You have to be concerned with sufficient contrast. You have to use color sparingly to guide the user's scan.

In addition, we use color to convey a brand or feeling to the application. Color (in conjunction with content, organization, textures, etc.) will make a site have a given flavor. We define the objectives based on the business goals (typically brand values targeted). We can then easily test them during usability trials to ensure that the design gives the right impression.

Top

Question: Are you aware of a Web site that displays "international" icons (i.e., those that are instantly recognizable to the user, regardless of country)?

Eric's response: While I have indeed seen listings on "international" and "standard" icons, I am afraid they represent a severe delusion. There is simply no such thing. I know of not a single icon which will be recognized by all users worldwide. There are, for example, some ISO standard icons. But this is more an attempt to present a standard set of icons to the world in a slightly optimistic hope people will learn them.

Top

Question: Can you provide any guidelines on the placement of "$ & %" symbols in an editable data entry box. Is there a standard for the placement of these symbols when displaying dollars or percentages? It was my understanding that in an application the dollar amounts should always be right justified and the $ sign should be immediately left of the left most digit in a numeral inside the box.

Development said that it impacts performance if it is inside the box.

Thanks in advance for any light you can shed on this issue.

Eric's response: There are really two ways to do this. Neither involves putting the character inside the field.

Salary ($): ____________

Tax rate (%) ___

Or

Salary: ____________ USD

Tax rate: ___ %

If you put the character inside the text field it appears as if it is editable. If this is a false message, then avoid it. In addition, the special characters near the numbers will tend to clutter the screen.

Top

Question: Hi Eric, I work for a company that designs interfaces for use in industrial environments, such as oil refineries. The monitors are set at very high resolutions and include a large number of complex diagrams and editable settings. We're grappling with the issue of font sizes – can you provide any recommendations? As the operators can crank their resolutions right up, the standard
recommendations of "n pixels" presents the problem of small fonts becoming smaller and more illegible. Especially with the complicating factor of many of our operators being older and suffering from diminished sight!

Eric's response: No problem. Design your font so that the x-height is 1/200th of the distance from the
screen to the user's eye. Visually impaired users can then perhaps adjust the size, or more likely lean closer to the screen. See more about font sizes in our February, 2002 newsletter.

Top

Question: On your submit form here, I don't see a "Cancel" button at the end of the "Ask Eric" form which is pretty normal and said to be a good practice on any form. Is that intentional? What was the reason behind it?
Thanks.

Eric's response: "Cancel" is used in GUI (Windows™) applications. It means do nothing, save nothing, and close the current window. In a browser we do not have CANCEL buttons. Instead we use CLEAR (if needed) which means do nothing, save nothing, and erase all inputs on the current screen. You also may need RESET which puts the screen back to where it was when you first called the data up.

CLEAR buttons make sense if the user is likely to suddenly decide they need to start over. This is not a universal situation. For example in a form where I simply put in my name and address it is quite unlikely I will need to clear it and start over.

Top

Question: We use video and audio icons to highlight multimedia content within some of our sub-sites. The site owners of one site in particular would now like to use these same icons in links to video or audio content on external sites. Do you think this is appropriate?

Eric's response: I think that it is fine in principle to use distinctive icons to indicate the type of file that is available. However, I would be cautious about the specific icons used. The fact that they were developed for an internal audience makes me wonder if they will work well with the public users. I therefore strongly advise a quick usability test.

Top

Question: With respect to designing a public Web portal, what is the current recommendation for minimum screen resolution? Last response I saw here, dated Feb., 2004, was that 800 x 600 is still the way to go. Thanks.

Eric's response: It's still 800 x 600, unless you have a special user group.

Top

Question: We are developing a corporate intranet portal. When should we require the audience to login? The challenge seems to be striking the balance between encouraging / forcing early login to personalize the experience without disaffecting the user.

Eric's response: It is best to authenticate the user just once, when they get access to the corporate online environment. The key is to avoid forcing repeated logins. It is particularly dangerous to force different logins. This will tend to encourage users to write down their passwords.

Top

Question: I am confused by the quiz – such all out rules as "do not use computer jargon when designing for the web" and "left align for speed of reading" and "sparsely use multimedia" all rely on the ignoring of function it seems to me.

As a fine artist before I tried to use this game for charity and many chastened hours later – I want to point out that the tricks like color or tonal patterns which lead the eye, and the use of multimedia maximally to explain points so that right brain can also record, are also valid modes of looking at Web design. Have you ever considered looking at it from this point of view that was not possible twenty years ago – of course I am the new kid off the block and WOEFULLY IGNORANT but I do feel that effective design should be centered on the user and that user is a being with eyes and emotions and prejudices and these are the bits that design should appeal to. Furthermore that across-the-board design rules maybe do not exist – it depends on the user what you shove in. Am I also WOEFULLY WRONG?

Eric's response: Penelope, you are correct and also wrong.

You are correct that there are few blanket statements that we can always apply to every site design. The objectives of the site vary. We have one client who actually WANTS to reduce the number of users on the site. Therefore, all the normal principles must be reversed. We use LOTS of jargon (etc.). In even the normal design program there are numerous tradeoffs. We may right justify our text to create a given brand perception (even though we know from the research that this will slow reading and increase perception of clutter).

You are very wrong in thinking that usability people have ignored emotion until recently. My doctoral work (in the early 80s) specifically looked at emotion and motivation for computer interfaces. We have a renewed focus on this area after Don Norman's book on emotional design. But subjective satisfaction has been a key objective of usability work at least since my first class in the field, over 30 years ago.

Top

Question: Labels on the left side of an edit field vs. labels above an edit field. Which is more user friendly? How about screen space utilization or similar considerations?

Eric's response: In general I would recommend labels to the left of the field. This is better in terms of visual scan and also tends to be better in terms of screen real-estate. With labels above the field the vertical space is used rather quickly, and having multiple columns is suboptimal.

The one exception to this recommendation is the need for dynamic translation. The label above the field will accommodate the often amazing changes in label length (especially when changing to German).

Top

Question: For intranet sites where users are filling out forms where information is required, if an error is made what is the best way (giving the best usability) to indicate this to the user?

Eric's response: For required field edits it is essential to do the error handling when the form is complete and entered at the end. If you edit each required field the user is forced to enter the fields in the order shown, which is remarkably frustrating and unexpected. The error message you provide when the user enters the form should in some way highlight all required fields.

Top

Question: Do you think it is required to use an asterisk to mark a mandatory field of a form on a Web page when the field / page is in the read-only mode?

Eric's response: No. Unless you have some special situation where the user needs to know which fields are required.

However, when the user is entering data it is generally important to indicate required fields.

Top

Question: What is the current convention for user input (bolding) in procedures for online documentation?

Do most still follow the conventions in Microsoft Manual of Style, written in 1998 and the online 3rd edition, bolding ALL window-based elements in procedures whether they are clicked or selected or not?

Is it acceptable to limit bold to actual user input (what the user clicks, selects, or types) and not to bold window-based elements the user is not actually selecting or clicking? For example in the following, I would not bold the name of the box:

In the Printer Name box, click Acrobat PDFWriter and click OK.

In the following, I would not bold the name of the window:

In the Microsoft Internet Explorer main window, click Tools >> Internet Options.

Too much bolding clutters the page, especially when online also uses hyperlinks.

Thanks for your help!

Eric's response: First, as with so many of these issues, the main thing is to have a standard decision and to follow that standard religiously. There is no consistent worldwide standard. So you must make a standard based on good design principles and user expectations.

My concern with your examples is that you have not provided a separator to make it clear that you are referring to a window name. So I would think about a convention to provide a stronger visual cue.

You show...
In the Printer Name box, click Acrobat PDFWriter and click OK.

Consider a design like this...
In the 'Printer Name' box, click Acrobat PDFWriter and click OK.

However, I also agree with your comment on bolding. The problem with bolding is that it is too powerful a highlighting method. That is what creates clutter. If you use less powerful methods like semi quotes or italics you can make the distinctions without undue distraction.

Top

Question: There has arisen a difference of opinion between me
and the other members of my group concerning a GUI design issue. We are all developers, not human factors experts, so I thought I'd get an outside opinion. We are using a COTS tool to create an application, so our GUI options are limited, but we do have access to some basic properties. The question is pretty straightforward: Should an alarm indication field have a border around it? The field could be colored green, red, orange or yellow. The field contains black text that changes based on the alarm state (OK, Alarm, Warning, etc.) The text is center-justified. The window background is white and the window could contain a large number of these alarm fields. The default size of the border when the field is initially created via the COTS tool is 0 point. Also, the field has only width and length (i.e., it is a 2-D field, not 3-D). I'll withhold my opinion on this issue, so I won't be accused of asking a loaded question. But any guidance you can offer concerning whether or not such a field should have a border would be appreciated.

Eric's response: There are three issues with the alarm field. First we must be sure that the user's attention is drawn to it. That means we want a very neutral 'ok' state and a visually noisy alarm. The border, if always there, will not help this problem. The color and text will have to do the work of alerting the user. If the border can appear ONLY if there is an alarm, then I would recommend it to help alert the user (so this means 'ok' has a white background and no border, while alarm conditions are colored WITH boarder). Adding the border to the color would be moderately useful (i.e., it will help only a little).

Second, the user must interpret the alarm. For this the text must be legible. Be particularly careful about red background and black text. You may get too little contrast. The selection of color is also semantically important. Make alarms red and warnings yellow. Do NOT NOT NOT use green for 'OK'. Use black text with white background. The green will just add to page clutter.

Finally, the user must be able to figure out what to do with the alarm. A border suggests that the field is editable. If you have novice users this may be a problem. With more experienced users I would not worry.

So... For experienced users have a border for alarm conditions only. For applications with mostly novice users have no border and just use color to flag the alarm.

Top

Question: I am in the process of designing a system that requires the user to define a series of questions that will eventually be presented to a patient. The series of questions will contain branching logic which will determine the order in which the questions will be displayed. Branches can occur based on a response to a single question or based on responses to multiple questions. We are using a tree view to represent the questions and the branching logic. I am having a difficult time coming up with a user friendly method for defining branching based on multiple responses. Any suggestions would be greatly appreciated!

Eric's response: Tree view may sound good from a logical perspective, but it is likely to be difficult unless you have very technically savvy users. I have seen tree views confuse people in their operation and in the very dense way they show choices.

In this case you may be better off unpacking the task. Let the user enter one question and possible answers at a time. Let them then build out the network of questions.

You may then provide a full screen view so that they can navigate through the items and make changes.

Top

Question: I was just wondering if there is any guideline or specific standards made for writing error messages. What points apart from the type of error must be kept in mind while writing errors?

Also, can you draft me the error message, if the case is like; "User entered alphabets in the field of numbers, like 'l' in place of '1'".

Eric's response: First the error handling needs to catch messages effectively and indicate the specific type of error.

Then the error message should have...
1. The entry in error (it is fine to highlight the field in error)
2. What the problem is (as specifically as possible)
2. What must be done to correct the problem

Good example:

Salary: y2,000

The entry contains the letter "y".
Enter numbers only.

Top

Question: We have a junior designer who wants to put icons in all buttons in the Web application... even putting a checkmark in the "submit" buttons and a cancel sign in "cancel" buttons. I have typically only used button icons in sort of a toolbar approach, following the Apple and Microsoft lead on this. I find the iconified form buttons from this designer to be noisy and hard-to-parse, but don't know what to tell him that is not just my opinion. Dr. Schaffer, do you have any guidance on this topic?

Eric's response: Placing icons on buttons is generally gratuitous. It adds visual noise and not much else. In controlled and isolated studies adding icons will save between 10 and 300ms (not much time), but the download time can easily eclipse this.

I would like to see icons used in cases where they are actually useful. An example is a check mark that flags that the function has been completed. Then it is meaningful and useful.

In general, please aim for graphic work that is helpful. That conveys some information. There is also a clear value in terms of branding. But I suspect your icon/buttons may backfire even in brand positioning.

Top

Question: What should be the best way to design any code for identification process of huge amount of products or materials, or anything?

What key points and care should be addressed while designing such a coding system.

Thank you Dr Eric!

Eric's response: There is SO much more to code design than most people realize. Here are some principles that pop to mind...

1. Keep the code as short as possible
2. Make Alpha, Numeric, or a mix depending on typing style (standing bank clerks use all numbers, as their hand is on the numeric keypad for example)
3. Leave out frequent confusions (like V and B for a code read over the phone)
4. If the code list is longer then five digits chunk it (123-121-9991)
5. For expert typists avoid using the same key twice in a row (it breaks up the keying pattern)
6. Consider a check digit to validate the entry

Top

Question: I am in a technical writing group that is researching usable help access. Our current help icon on the banner of the page does not work. We are struggling with the decision to use context-sensitive help, field help, or just rely on good error messages. Do you have any recommendations?

Eric's response: First get the screen design right.
THEN, error messages.
THEN, if you need it, think about help, documentation, and training.

The problem is probably not in the button placement as much as the issue of whether help is actually helpful and useful. In most applications we find that even the best help is not often used.

Top

Question: What is the best way to format a form – with the field label directly above the entry field or with the field label and the entry field all on one line (with all the entry fields starting at the same horizontal location)? If the best format is all on one line, then where should the form entry buttons (Save, Submit, etc.) be aligned - with the field labels or with the entry fields?

Eric's response: Ok, the best way is like this...

Now if easy translation is critical you can run the text above the field. And, the button placement I show is for Windows™ applications. Other environments are different, just follow their standards.

Top

Question: We have a Web site that has 1000's of parts that a customer can order. 70% of our customers search for parts using a part number. Users can input a partial part number. The question has been raised in how we display the search results.

The current state is that the site displays all results containing the input criteria of Manufacturer's part number in no particular order.

One group wants to display the results using the input criteria in numerical order. This group's rational is that the customer has searched by part number as criteria and would expect to see the results sorted on that number in ascending order. Users could scroll down to find the exact part they are for which they need.

Another group wants to display the results with the newest items first that contain the input criteria. This group's rational is that this enables users to see newer items first.

We tried to find some empirical data on this question, but didn't have much luck. What is your opinion?

Eric's response: Actually, to give you a concrete answer would be just guessing. The correct answer depends on the user's task, the business objectives, and the design of the code structure.

Clearly, if the user has a complete and unique match then take them directly to the detailed page for that part. Don't give a list at all.

The issue is with a partial code. Why would the user enter a partial code? Is it a shortcut to save keystrokes? Do they only know the first part of the code (which is a category of products)? Do they have a code which is only partially legible or partially remembered?

Are there particular products that you want to put first? They might have higher margins. They might have companies that pay to be listed first...

So, for example, if the code is entered because the user knows only the category, then you would show products in that category. The user is unlikely to know the rest of the code, so listing by code is not advisable. Instead, provide a logical listing. The logic depends on the domain. It might be in order of cost. It might be by sub-category. Consider how the user is thinking about the product they want.

Top

Question: On March 23, 2004, in a response to Barbara Davis concerning error messages, you ended with the statement: "Incidentally, required field edits must always be page level." My question may be related to this, but I would like some clarification.

My question deals with the placement of field level errors at the top of the form page (after submission) versus embedded within the page beside the actual form element. For instance, if form element "userid" was required, is it better to have a page-level error message that states that field-level error messages can be found below & then have the exact "please enter a userid" message beside the user id text box, or to just display this message at the page level with any other field-level error messages.

It would seem that field-level error handling would be offering a more usable system, but how much more usable? Things to consider in my case are that some of our forms are complex (perhaps another issue) & would receive more benefit from field-level error handling, but we would also like to handle errors consistently across the site, meaning even simple forms should follow this model, should we adopt it. I am unable to find supporting literature & would appreciate your input.

Eric's response: Field-level error handling is particularly important when the user is gathering data from separate sources for each field. So if the user must retrieve a document to enter the field, and then is likely to return to the document before going on: then field-level error handling is important. The user must re-retrieve the document if there is an error found at the end of the form.

There are many situations that are similar. For example the user may be going through a complex mental process to complete the field. Then the user would have to reconstruct the process when told at the end of the form that there is an error.

Screen-level messages are best put at the top of the page (below the title and any top navigation elements), and highlighted. In this way the message is the first thing the user will see when the page is returned with the error. It is true that mainframes had the exact same situation, but put the messages at the bottom. This was bad (and I complained about it for a decade until GUIs made the point mute). But mainframes used the bottom because they retained the error placement from paper printers that printed the error message on the next line (sigh).

Top

Question: Has there ever been a study done on user completion of forms vs. number of fields to fill in?

Eric's response: If you are talking about the decision to complete a form: yes. There is a very interesting study that showed the addition of just one open comment field to an online survey dropped the response rate by 9 times. As the form gets longer and more complex the completion rate will drop. Conversely we find simplification of designs reduces drop off, sometimes resulting in a huge impact on conversion rate.

If you mean is there a relationship between the number of fields and the time to complete the form, the answer is certainly yes. For novice users the form completion time is very much a function of confusion and complexity. But for experts, the main issue is the amount of physical work involved. This is directly related to the number of fields. We often estimate time to complete a form for expert users by looking at the number of fields (and other controls) and mouse movement requirements.

If your question is form density, in general studies show reasonably dense forms are better than lots of scrolling or navigation between pages.

Top

Question: Do you have standards or suggestions for dollar sign display and input? I work for a financial institution and dollar amounts are part of many screens. We also have dollar amounts in various currencies. We cannot reach an agreement on:
1. Whether the currency indicator should be before or after the amount
2. Whether there should be a space between the $ and the amount
3. If the $ should stick out from the left aligned input or display
fields
4. If negative amounts should be displayed in brackets or simply
with a "-"
We would like to implement consistent rules that work for both simple input and display areas as well as when tables are used. Any suggestions?

Eric's response: First let me say that the most important thing is to have a solid standard in place. This is maybe MORE important then getting every rule perfect.

Let me help...
1. Whether the currency indicator should be before or after the amount

If you are showing currency type as a three letter code (e.g., INR, USD, etc) then it will come AFTER the number. If you are using the single character ($, etc) then it will come before.

If you are just using USD, then ask yourself if you NEED the "$" at all. It may be obvious from the context and the format of the numeric field (e.g., Overall Transaction: 23,212.01)

2. Whether there should be a space between the $ and the amount

If you are using a "$" it should be at the left of the field. The number should be RIGHT justified at the decimal space (making it easy to compare numbers).

Overall Transaction:	$	23,212.11
Taxable Amount:	$	872.13

You can also embed the indicator with the field, this is fine too.

Overall Transaction ($):	23,212.11
Taxable Amount ($):	872.13

Note that you can also show the three letter indicator embedded.

Overall Transaction (GBP):	23,212.11
Taxable Amount (GBP):	872.13

But to the left is NOT conventional. Don't do this.

Overall Transaction:	GBP	23,212.11
Taxable Amount:	GBP	872.13

3. If the $ should stick out from the left aligned input or display fields

This is ok...

Overall Transaction:	$	23,212.11
Taxable Amount:	$	872.13

Here the $ clutters the dollar amount.

Overall Transaction:	$23,212.11
Taxable Amount:	$872.13

4. If negative amounts should be displayed in brackets or simply with a "-"

This depends on your user base. For lay users the "-" is conventional. For business, especially accounting users, you may find that parentheses are expected. If you have even a small number of lay users you are really forced to use the hyphen, as they won't understand the parentheses. If it is critical, consider using a color highlighting (red) in addition; to emphasize the negative number.

Top

Question: Hi. I am an instructional designer tasked outside my usual comfort zone. I want to design context-sensitive help for a Web-enabled product and I argue that "context sensitive" means putting help in the same context as the subject. To me, at least at the field help level, that means help content, and content that is the subject of the help, should share focus (e.g., mouse-over activated help content). My boss and others believe that a separate browser window is adequate. I argue that when a neophyte loses context, an added element of confusion is introduced. This seems like a no-brainer, but short of meaningful testing (we don't have that luxury), I need corroborating support for my opinions. I am looking for an academic or professional discussion debating this issue. Or, failing that, best practices relative to this subject. Do you have any suggestions/ideas on where I can find that?

Eric's response: First let me say that I am not very enthusiastic about Help facilities. In most Web sites people don't often use help (they will more often access a FAQ). For expert users in corporate applications help is rarely useful, they would rather ask a friend. So please be sure that help is really the right solution. I would generally invest your effort in making the screens self-evident and the error messages clear.

Assuming you want to provide help, let's look at types and delivery. Rollover help is usually used for clarifying labels. (Right. It would be nice to just make the labels clear and label your icons. But there are cases where this is useful.) I have seen applications with extensive rollover help where the user was constantly distracted by unwanted messages, as there was almost no inactive place to rest a mouse. This is a serious problem (particularly as it was for emergency services personnel).

Probably the most useful type of help is very selective help that appears embedded as links in the screen at a FEW selected points where people have trouble. This is usually a more extensive explanation and should NOT be in a rollover. A popup that appears over the current screen is clearly best. This maintains context and provides space for the material. I would indeed avoid going to a separate browser as this impedes the flow.

Finally, extensive and involved help is sometimes available in a separate help facility. While a popup is still best, there are cases where the material and interactivity required is so extensive that a full separate browser or separate application I justified. In some cases these even become training facilities in their own right. In such cases the flow is fully broken as the user goes off to learn neurobiology (or something) in depth.

Top

Question: I looked at previous questions and found one that was similar, but not identical to mine ... so here goes.

I have developed a simple tabbed UI that is appealing to users. Each tab has a variety of fields where users can enter text. I plan to put two buttons at the bottom of each tab:
1) One that saves all the user's input for that tab (but the tab remains in the foreground)
2) One that ignores all the user's input for the tab (but the tab remains in the foreground)

If this were a dialog, rather than a tab, I would use "OK" and "Cancel." However, because the tab never closes, I plan to use "Save" and "Reset." You mentioned in an earlier response that "Cancel" is better understood than "Reset" ... so, should I still use "Cancel," even through the tab
never closes?

Eric's response: You are raising an interesting question. The "explicit save" requirement of many applications is just an old artifact of the technology. Why would I enter a form and then need to do something else to save it? It is like using a blotter on a form filled out with a quill pen! "SAVE" means transfer from RAM to Disk. WHY SHOULD THE USER HAVE TO WORRY ABOUT THIS????

So what does this mean for your question? You can use "Implicit Save". That is you can simply make the saving automatic. Just save when the user goes to anther tab. You can then have a [Done] button for when the whole set of forms is complete (it is good to capture any other exit and save on that too). You can also have a [Clear] button (to erase new text), or a [Reset] (to restore to the version before the previous session.

I think the ancient artifact of explicit save will soon fade into the past, like ink blotters have. And to both; good riddance!

Top

Question: 1. How many words should a single content page support?
2. How many words should be put in one single line so that the user can scan it properly?
3. If I were to break the content into two columns how many words should
be adjusted into each column?
4. Does point size have any relevance to the number of words in each column/single column layout?

Eric's response: People read fastest at 100 character column width. People prefer 55 character column width.

The font size is an issue of legibility. The x-height of the characters should be 1/200th of the distance from the display to the user's eye. Certainly a small font will force more text onto the screen, but it will be slow to read and may encourage the user to not read at all.

Finally, remember that online users generally do not actually read the screen, they scan it. So unless your user is reading a novel online, you need to design for effective scanning. This means not dumping a bunch of paragraphs onto the screen. Organize the content and present it with better techniques like bullet lists and step charts.

Top

Question: BEST PRACTICE: When presenting transactional history data in a financial services application, should the data appear with the newest transaction on the top descending to oldest? Or, should it appear with the oldest transaction descending to newest? Please advise.

Eric's response: You have to look at the user's task. If the user is trying to reconcile a series of operations over a set amount of time then it is best to put them in chronological order (oldest at the top). An example of this is trying to understand the flow of money in a brokerage account. However, if the user is primarily concerned with finding a given transaction, without reviewing the logic of transactions during a time period, it is best to just list the items with the most current first.

Top

Question: I can't seem to find a standard or best practice (with some clout that is) on how "required fields" should be annotated as such on a Web page. Most forms I see seem to indicate such via a "*" by each required field along with a byline indicating to the effect "* indicates a required field" at the start of the form.

I have various business user opinions... some asking/requiring me to bold the labels for such... or highlight the input fields background... or if not complete, render in red after submit... etc.

I'd like somewhat of a more definitive source, if one exists (W3C?), that might settle this and any other GUI/UI best practices or at least provides me a direction to point such opinionated UI newbies to.

Any help on this matter is appreciated.

Eric's response: Well let me definitively say there is no established standard. The "*" is commonly used. Sometimes it is black and sometimes red. Sometimes in front and sometimes after the field. There are lots of other schemes used too (like "(required)" shown following the field).

In any case AVOID cluttering the page with lots of extra visual noise. Bold and color will unnecessarily clutter the page.

Top

Question: I know you are a great advocate of liquid page design so that Web pages adjust to users screen resolution and users with different monitor sizes and resolutions can all see the contents of those Web pages without horizontally scrolling.

So, my question is this -- how do we ensure that users will be able to print a liquid page without truncation? (I notice that many Web pages look just fine, but when I print them, their contents are truncated).

Eric's response: Actually the only research I am aware of indicates that it does not matter if you have liquid pages, a left-aligned fixed page, or a centered fixed page. This was a bit of a surprise and therefore I hope to see some more research to confirm the finding.

If you want to create a liquid page that will not be truncated you can simply limit the width allow for the page to expand. As I recall you do this by setting a table of fixed size and then have the contents liquid within the table. Here is an example in case you want to make printer-friendly liquid pages.

Top

Question: I am building a Web application that has just two types of users: Administrator and User.

The tasks involved are different and not everyone is an Administrator.

I would expect that the widget would be at the top of the screen, but what UI widget would you use and why?

It would be great to hear from you.

Eric's response: If I understand your email, you have a very common situation. You have Users and Administrators. Normally you have many more Users than Administrators.

I am assuming that the people who do administrative work ALSO may want to use the "User" facilities. This is common when administrators are supervisors. If this is true, you design primarily for the users. They are most numerous and often least skilled. Then have a link available that is only seen by administrators. If the administration work is done infrequently (as is usually the case) just put a single link off of the main page that is only displayed to users who have administrator permissions.

It is very rare to have a situation where the administrator must frequently switch between the user and administrator facilities. If that was true then you might need a switch on every page. This can again be a link that is only shown to users with administrative permissions. Then there can be a similar link on each administrative page to return to the user mode. The one trick would be to keep track of the user page and state of the page that the administrator came from. Then return the user to the source page so they can continue their work.

The choice of control is not terribly important. It is a direct navigation to another page. This can also be done with a button. But a link is small, simple, and cheap. You could theoretically also use tabs, dropdowns, etc. But these are unnecessarily complex and physically large.

Top

Question: We are currently developing online forms (both html and pdf) their submission cycle for a government Web site. Please comment on form designing and suggest some URLs to well designed forms according to you?

Eric's response: Samir, form design is a rather involved affair. There is a ton of research on how to do it well, both from the point of view of process and design specifics. There are many principles. We know to left justify labels and fields. You might see this in an example. But would you realize to consider mouse-keyboard switching? People would rather key 3 to 8 keystrokes than move their hand from the keyboard to mouse. So if you have text fields alternating with radio buttons you will have a terrible design. I really suggest getting some training. Form design can not be learned by looking at good examples.

Later, when you have the underlying skills, then you SHOULD have best practice examples, in the form of standards. These standards must be custom tailored to fit your domain and context.

So Samir, please don't look at a few examples and then think you can just copy them with success. "Chalta Hey" NAHIN

Top

Question: Hi - in a current project (online bookstore) I am wondering whether to provide an advanced search at all? Do you know about any research whether an advanced search is used at all? I always have the impression it's just there because (almost) every site has an advanced search... Maybe it's better to provide a good simple search (text input field and a SEARCH button) and spend time on defining a concept that supports the user in a more guided way to get to a list of books he might be interested in? Or would you recommend to follow the crowd and play safe?

Eric's response: In many cases search is provided by sites as a design reflex, or even as a patch for poor navigation. However, an online bookstore is a classic example of a site that is primarily about search. At least for general online bookstores customers usually come knowing the title and/or author. Given this search is a very good way to find the desired book.

Since you are building a search-primary site you should indeed focus on search design. A good primary search is essential. But I would also suggest the advanced search. This will allow customers to employ otherwise difficult search logic. Remember that advanced search is not really well named. It often provides the LESS experienced user with help in defining a complex search. The true advanced user will use commands in the search field.

Top

Question: Is it really necessary to have printer friendly pages?

Eric's response: It depends on the application of course. In many cases users want to print material off the Net. We have even seen people printing news items and reading them in paper form (when their employers will pay for the paper). But many Web page formats are very difficult to print.

A concrete example: There is a site with instructions for playing a game. These instructions are presented in a series of 8 separate pages with a wizard navigation. Luckily they have a printer friendly version that concatenates all this material. Otherwise the user would have to navigate to each page and print it separately. In addition there are some very short pages, and some are longer. The resulting printing would waste quite a lot of paper and be awkward to read.

Top

Question: How I should control the view path of visitor's eyes for redirecting their attention to a specific place on a page without confusing them between lot of visual components of a page?

Eric's response: Normally Web page users tend to start reading below the logo area at the beginning of the SECOND column. This happens because they have adjusted to the fact that this is where primary information is usually placed (with navigation or nonsense in the first column). This is just the same as mainframe users who adjusted and started each page by glancing at the bottom of the screen to see if an error message was present.

Generally people will scan the material from left to right and then down. However you can change this. People's eyes are attracted to movement, dark areas, visually complex areas, and highly saturated colors. People's eye track will also be affected by the grouping and apparent logical flow of material on the page. There is research showing very different scanning patterns between types of sites (news, eCommerce, etc).

People do an amazing job of visually scanning to obtain the information of interest. We foul this up with flashing banners and illogical layout.

These are a few of the basics, but it is truly an art form to consider and optimize the user's visual scan.

Question: We are in the process of using CSS on our site. Because of standards (imposed on us by someone else), we have to use a fixed width of 700px for our Web page. If someone printed the page as is, some of the text would be cut off. Our thought is to use a CSS print style which would make a "printer friendly" page without the left navigation bar (165px). Is this the best way to proceed? What about the people who want to print the page as is? We're assuming that these people are few.

Eric's response: If the content is likely to be printed, then a printer-friendly version can make a lot of sense. It is a mechanism that is widely used, so the link is unlikely to confuse users.

Question: Hi Eric,
I would appreciate any help on these two topics.
First: where should the required field indicator be placed, next to the label or the text field?
Second: can a drop down be used instead of a radio button? This may save the user from having to alternate between mouse and keyboard.
Thank you.

Eric's response: There are several ways of placing the required field indicator. The most critical issue is that you be consistent in placement. The second issue is that you need to label the indicator (e.g., *=required entry). In placement, I favor placing an indicator immediately before each required field.

On the second question; Don't kid yourself. Few users will know how to use the drop down from the keyboard. If you have expert users who are comfortable with this that is fine. But for most users the radio button is best (given space and non-dynamic data). The radio button makes all choices immediately visible and requires only a single mouse click.

Question: Does aesthetic consistency always improve usability?

This may seem trivial but it has generated a lot of noise and may raise some important usability issues. We have a debate going on in our portal community concerning placement of a blue hairline. On our site, we have major content labels, which are accompanied by optional, brief descriptions of varying length. These major headings/ descriptions are followed by indented, bulleted lists of links. A blue hairline divides the heading/ description from the rest of the content on the page. For aesthetic reasons, some don't like this because due to the varying length/ presence of descriptions, the line is in a different position on every page. They also argue that the inconsistency from page to page hinders scanning. They advocate moving the hairline below the heading but above the heading's description. Others argue that having the hairline below the optional, varying-length description helps the user make the a subtle, visual connection between the heading and description, and as well to see where the "uber" heading/ description ends and its associated content choices begin. Here are some sample pages with the hairline:
Sample 1, Sample 2

Here's an example with the line above the heading description:

Thanks in advance for any insight you can offer.

Eric's response: In general, aesthetic consistency makes the site easier to understand (as the visual affordances are more consistent) and it will make the site less visually cluttered. However, this can mean a visually boring site and I suppose it could make a lack of visual cues to distinguish between pages. But this does not seem to have much to do with your specific question.

The hairline question is really addressed well by the Gestalt principles. The hairline is a way of grouping material (to make it a FORM). It is useful to think about the page design as if it were a set of physical objects at various heights. The hairline is used to help create the boundaries of the object.

Hairlines can be VERY useful in providing this cue. This can successfully group material.

If you are using the hairline as a part of a header you can place it above or below. If you put it above you are making the title a part of the object defined. If you put it below you are making the object with a header above it and then you need to take care that the header is sufficiently separated from material above so it does not appear as a part of the object just above.

It is a good idea to be consistent with your use of the hairline to avoid confusion. Probably the hairline below the title is a more common design.

Having line shift down to allow a longer title is not a problem. Users will not even see it. What matters is when you, for example, rearrange the sequence of buttons.