Use of Search Tools on Home Pages
... Compiled by Anthony J. Masalonis, masalonis@cua.edu
An interesting discussion recently cropped up on CHI-Web regarding the use of search tools on home pages. Some of the participants in that discussion have expounded on their original views for Internetworking……….
This in from Lou Rosenfeld:
There doesn't seem to be a clear case to be made either for or against searching. This is probably because, like just about everything else in information systems design, the answer depends on the situation. If someone claims that one approach is universally better than another (and I'm not certain that either Nielsen or Spool, whose work has been quoted in this discussion, do so), they're missing the point. All situations are different, and designs should be accordingly different. The best we can do is try to identify major audiences, their most important information needs, the core content that will meet those needs, and select from the various ways to configure searching and browsing to best meet those needs.
The fact that users' information needs vary substantially is, unfortunately, not widely recognized. One example is known-item searching: users search for information they know how to describe and know exists in the site (maybe they've found it before). Other users are satisfied with just a few relevant results, while others want to perform comprehensive research and wish to leave no stone unturned. Sometimes users aren't quite sure what they're looking for at all; the process of actually searching exposes them to new information, and they learn more about what exactly they were looking for and how to describe it through that process. There are other variant forms of information needs. Search systems can be designed differently to address these needs. For example, a search system that supports research or exploration probably should closely integrate both browsing and searching capabilities (e.g., display a table of contents on a null results page). This approach allows users to jump back and forth from one mode to the other over multiple iterations, mirroring how research and exploration might typically proceed. The presentation of results similarly depends on what users really want out of the search process. Just as you might provide users with different search interfaces, you might provide them with the option of selecting different ways to present results, such as allowing them to change the way that results are ordered or which attributes are presented for each item. Like users, content also varies substantially. Differences in format, level of structure, level of metainformation, topicality, volume, currency, and quality all can have an impact on the design of a search system. And just as consensus would have it that we should interview users before plunging forward into design, so should we "interview" or inventory the content that will be searched.
Ultimately, the challenge is that there are so many options to consider when designing a search system that it can get really overwhelming really fast. The best answer lies in knowing your users' information needs and content characteristics well enough (and, ideally, in advance) to determine the most appropriate subset of possible options and develop a search system that is effective at mapping users' queries with content.
-- Louis Rosenfeld (lou@argus-inc.com)
Argus Associates, Inc. (http://argus-inc.com)
And from Michael Fry:
Ralph Brandi wrote:
I think it does, too. I certainly don't want users giving up and leaving my site in frustration because they can't find what they're looking for. But I also wonder how many users actually think of "search" as a last resort rather than the primary and preferred method of accessing a site's information. Even Lycos—which has a directory structure—is busy advertising quick and immediate success with their search tool. Of course, the notion that users can just push a button and have Lycos (or whoever) simply "go get it" is just fatuous, but the ad campaign is still bound to convince some people that there's no reason to rely on a site's navigation and information architecture when they can just use "search" instead."I asked Jakob [Nielsen], if search is so awful and doesn't work, why should I rush to place it on all of my pages when I get home? His answer was that yes, it was pretty bad, but it was less bad than the alternative, which was for users to surrender and leave the site. He claimed it acts as a "life preserver" when users are foundering and about to go under for the third time, and gives them one more chance to find what they're looking for. It may not produce success as often as you would like, but it succeeds more often than giving up does.
"I thought that made sense."
So I wonder—as long as the currently available "search" tools don't actually produce such stellar results—if users might be better off if designers encouraged them to rely on navigation and information architecture rather than on search tools that are not as quick, easy or unfailingly accurate as they've been advertised to be.
To wit: According to the research of User Interface Engineering (Jared Spool, et al.),
"Search engines didn't make finding information easier, they made it harder. When users found information without a search engine, they did 50% better than when they tried to use a search engine...On sites where no search option was provided, users complained, but did 50% better than the best site that had a search engine."My interpretation of Spool's findings is not that "search" shouldn't be available to users. Indeed, as Jakob Nielsen points out, many users "are search-dominant [and] will usually go straight for the search button when they enter a website: they are not interested in looking around the site; they are task-focused and want to find specific information as fast as possible." But even if Nielsen's right, as long as the power, efficiency and speed of searching is so much less than what many perceive it to be—thank you, Lycos—I don't think "search" should be ubiquitous or ever-present on a Web site. I'm not suggesting that site designers hide "search" or opt not to provide it at all; I'm saying that we should think about how to create an environment where users can succeed at finding what they came for, even if that means they complain a little about how they did it.
Michael Fry (mfry@MAIL.HIS.COM)
Finally, a word from John Rhodes:
THE FAILURE OF GENERAL USER FEEDBACK
Below is a slightly modified version of a message I posted to the CHI-WEB mailing list on February 10th, 1999. I received several private e-mail messages about this posting. To address some of these comments, and to drive home the importance of this data, I've written up a few of my thoughts. You can find these at the end.
[My CHI-WEB Posting]:
I recently created a generic (automotive information) Web site to test out a few ideas I'd had about affiliate programs and user feedback. I deliberately placed 3 blatant and very obvious broken images on the index page. Over the course of three weeks, with 175 unique users (229 total), not one person has e-mailed me to tell me that the site has problems. It gets worse. Of those 175 unique users, I sent 6 of them! That is, I told 6 people about the site, they visited it, and said that it looked fine. I pressed these users about the page, without giving anything away about my true intentions, and they persisted. They said the content was good, and that the site was useful. Not a word about the broken images. Yikes.
I have a link to the site from WebWord.com, my Web site dedicated to Internet usability [approximately 30 users have been referred from WebWord.com so far]. Thus, several users are probably interested in usability problems. Many have read my columns, and expert interviews. They know about usability, at least more than the average bear. Still, even from these informed users, I did not get any feedback (e.g., "You have 3 broken images on your site!"). In my opinion, this is both stunning and scary.
[End of Feb. 10th CHI-WEB Posting]
My Thoughts on This Data and The Posting
As of Feb. 21st , my hit count has risen to 288 unique users (371 total); Interestingly, I've still not received any feedback about the site.
What does this data tell us?
When I originally reported this, Beverly Parks parksb@emh1.hqisec.army.mil had some interesting comments to share with me and the CHI-WEB group about why people don't provide feedback. Here those points are, in edited form:
* [The lack of feedback] may just indicate the [low] level of Web design knowledge of the visitors. Some people may think the problem was their browser, their Internet connection, or their computer.Beverly certainly has some excellent points. There are *plenty* of great ways to explain why people don't report problems.The bottom line, though is that -- for whatever reasons -- people did not report the problems on my experimental Web site.* Users may not feel comfortable reporting perceived problems. They may see it as an insult to the designer or webmaster.
* Some users may assume that others will report the flaws or that you [i.e., the Webmaster] must already be aware of the problems.
* People are apathetic. It's too much trouble to report it, or not enough time.
Taking a step back, I think that the data tells an incredibly simple story: You cannot count on users to give you feedback. (I must pause to reflect, why should you expect users to give you feedback?) Many Web developers, including usability professionals, are lulled into thinking that a feedback link will catch problems. But "Contact the Webmaster" just doesn't cut it.
We can make excuses and we can develop theories as to why users don't give us feedback. But when you get down to it, you (or your development team) must be responsible for finding and fixing your own mistakes. You are mainly responsible for effective user testing. You are in charge of ferreting out the dirty little errors that plague your site. Don't rely on general user feedback for finding your problems. If you get feedback, fine. Respond like lightning to those users. Praise them, shower them with your blessings. These are not just users -- they are usability heroes! But do not, under any circumstances, build the expectation of this general feedback into your general Web development plans.
It is time for usability and rugged individualism to join together. This is yet another call for proactive usability testing. You need to rely on user testing. You need to fire off explicit feedback requests, and you must perform heuristic evaluations. You have to do it. Finally, don't think the minor details and little problems don't count. They do count. As Keith Instone recently said in an interview http://webword.com/interviews/instone.html, we must care about the details because the sum of all of the tiny details equals usability.
In short, remember this: You are in charge of the details, not your users.
John S. Rhodes (john@WebWord.com)
http://WebWord.com/
Your comments are encouraged on providing search on home pages, user feedback on sites, any underlying concerns these issues raise, or any other issue in Internet usage that is potentially controversial (or just plain interesting.) Submit opinion pieces, anything from a few sentences up to 750 words, to Tony Masalonis at either of the following addresses: masalonis@cua.edu or anthony.j.masalonis@bellatlantic.com
© Internet Technical Group
Last update: March 5, 1999
URL: http://www.sandia.gov/itg/newsletter/mar99/opinions_search.html
hosted by Sandia National Labs
Disclaimer: Neither Sandia Corporation, the United States Government, nor any agency thereof, nor any of their employees makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately-owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by Sandia Corporation, the United States Government, or any agency thereof. The views and opinions expressed herein do not necessarily state or reflect those of Sandia Corporation, the United States Government or any agency thereof.