Ask Eric: Questions & Answers

November 3, 2008 – submitted by Ravindra Papineni of Austin, TX

Question: On Windows XP search box (with that cute yellow puppy) after the search options of Pictures, Music and Video, the two buttons displayed are "Back" and "Search" respectively.

The primary goal for that little form is to search so "Search" button should be the first one rather than the "Back" button. Is that correct? Or does it matter at all? Thanks in advance.

Eric's response: Clearly, once the search options are set, the next button should be SEARCH.

Sometimes Microsoft developers seem to feel that they can disregard usability principles as they are so powerful in the market. Maybe that will catch up with them one day...

September 9, 2008 – submitted by Larissa Schwartz of Amherst, MA

Question: There have been studies in e-commerce environments on the need to give users the ability to "view all". Recently, the Usability Sciences Corporation dedicated their newsletter to the subject.

How do you think this transfers to other sites? Should we follow the lead of online shoppers when it comes to search results and other data sets and by defaulting to "view all" or should we just give them the option?

Eric's response: Larissa, thanks for bringing this up. Kath Straub (our chief scientist) and I had a lively interchange on the issue. And the bottom line is we don't think a mass move to View All is at ALL the right thing. See original

I suspect that "View All," like HELP, can be a desperate attempt to compensate for a poor design. If the information architecture was done right, there would not BE 300 dresses to be viewed. It would be a limited, targeted set. The View All strategy may well be trying to scan through a load of misses.

Now there may be times when the user wants to drift through lots of choices in an engaged shopping experience. Kath rightly felt that throwing all the choices into one LONG scrolling page would create a behavior of looking at the first page, scanning through the middle with maybe not even a glance, and then looking at the last few.

I think we also know that scrolling/paging has limits. Certainly almost all users know how to scroll. But a very long list is physically difficult to manage. Also, if you have to go back and find a previously scanned item it is truly a challenge.

So it is OK to provide a View All button. But we are not all that excited. Though Kath says she may run it through her handy dandy eyetracker to see more.

January 3, 2008 – submitted by Linnette Desch of Bloomington, IL

Question: Is there any research or articles about bound and unbound picklists?

We have an instance where we'd like to provide common values for a field but also allow users to key data. If the field appears as a picklist with data, I'm not sure our users would know they could also key into the field – we've seen this problem on other occasions.

An alternative is to offer "other" in the picklist and then provide a separate field for data entry but I was looking for other ideas or research on users in general knowing about unbound picklists.

Eric's response: Such "Combo boxes" were very common in GUI applications. Because of the limited (bi-synchronous) capability of the early Web, they become less frequently used. This will change as Web 2.0 capabilities make combo boxes again feasible.

In terms of design they are a slightly advanced control. So for novice users you might indeed use "other". They will also be unexpected in the Web environment. However, the combo box has a pretty good affordance for entry, as the cursor appears in the typing area. I am certain this control will stage a comeback as the technology allows easy coding.