Site MapUser Experience for a Better World Site MapUser Experience for a Better World 
| Each month Dr. Eric Schaffer answers selected questions on usable interface design. | Recent Questions |
| Archived questions and answers about ... |
|---|
|
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. |
| Top | |
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:
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... |
| Top | |
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:
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. |
| Top | |
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...
Consider a menu more like this...
Notice that frequently used functions are moved to the top. |
| 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. |
| Top | |
October 18, 2005 – submitted by Scott Lary of Austin, TX |
|
Question: Which gives better results on a simple "more info" / contact page? 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 Mediatio™ 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. |
| Top | |
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]. Always good to hear from a CUA! |
| Top | |
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). |
| Top | |
July 30, 2005 – submitted by Anonymous |
|
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. 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: 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. |
| Top | |
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. |
| Top | |
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: Similarly, suppose the field contains X-1 characters, and the user pastes 2 characters in the middle of the input field. Options include: |
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. |
| Top | |
June 13, 2005 – submitted by Scott Dawson of USA |
|
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. |
| Top | |
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. |
| Top | |
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. |
| Top | |
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. |
| Top | |
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. |
| Top | |
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. |
| Top | |
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. |
| Top | |
| © 1996-2012 Human Factors International, Inc. All rights reserved | Privacy Policy | | 
biber hapıbiber hapı
|
