Number of search results to display

12 Mar 2007 - 2:26pm
7 years ago
9 replies
566 reads
vcagwin
2007

My team and I are currently designing a desktop application that
contains a search. I have been trying to find out what the magic number
is for displaying search results before the user finally gives up and
enters more criteria to narrow the results. More than likely, these
users know exactly what they are searching for and probably would not
return a list of 10,000 results, but we have decided that we wouldn't
prevent them from doing this.

Our current solution is to display "x" number of results, but inform
them that "x" was found. Does anyone know the magic #? Have other
suggestions that do not include pagination?

Virginia

P.S. I did a search in the discussion archives to see if this was
already talked about and didn't see anything. Please forgive me if this
has already been discussed.

Comments

14 Mar 2007 - 12:40pm
Robert Hoekman, Jr.
2005

> Our current solution is to display "x" number of results, but inform
> them that "x" was found. Does anyone know the magic #?

The magic number is not a number, it's *speed*. Speed is the most
important factor. Figure out how many results you can get onto a
screen as quickly as possible and still have meaningful information -
probably around 10 or so - and go with it.

-r-

14 Mar 2007 - 1:01pm
bhekking
2006

We ran into a similar issue with some document search software we were
redesigning.

Our field studies showed that, while speed mattered, seeing *actionable*
matches fast was more important. In our case, the saerch utility was
optimized for speed alone, and results were not sorted as the user wished
them to be, but by the search engine's notion of 'relevance'.
So, while results appeared very quickly, the first thing *every* user
did with them is sort them by date, author, or whatever would help make them
useful. Only when sorting was complete did users feel as though they could
declare victory.

The moral is that, while speed counts, useful speed plus useful results
count more, in my experience.

- Bret Hekking

On 3/14/07, Robert Hoekman, Jr. <rhoekmanjr at gmail.com> wrote:
>
> > Our current solution is to display "x" number of results, but inform
> > them that "x" was found. Does anyone know the magic #?
>
> The magic number is not a number, it's *speed*. Speed is the most
> important factor. Figure out how many results you can get onto a
> screen as quickly as possible and still have meaningful information -
> probably around 10 or so - and go with it.
>
> -r-
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

14 Mar 2007 - 3:00pm
Robert Hoekman, Jr.
2005

> Our field studies showed that, while speed mattered, seeing *actionable*
> matches fast was more important.

> The moral is that, while speed counts, useful speed plus useful results
> count more, in my experience.

Sorry for the lack of clarification - I just thought this part was a
given. Very obviously, all the search speed in the world won't make up
for weak search results.

-r-

14 Mar 2007 - 3:10pm
bhekking
2006

>
> Sorry for the lack of clarification - I just thought this part was a
> given. Very obviously, all the search speed in the world won't make up
> for weak search results.

Hey, no problem...it was not *your* lack of clarification I wanted to shed
light on, but that of the team that built the search tool...we found that it
never ocurred to anyone (on the team) that speed alone was insufficient. I
guess the take-away is that you can't assume that anything is a given with
software.

Apologies for dragging this topic off the rails...

- Bret

14 Mar 2007 - 3:50pm
vcagwin
2007

"So, while results appeared very quickly, the first thing *every* user
did with them is sort them by date, author, or whatever would help make
them useful. Only when sorting was complete did users feel as though
they could declare victory."

When does the list become unbearable to scroll through even if I can
sort?

14 Mar 2007 - 4:21pm
cfmdesigns
2004

>From: "Cagwin, Virginia" <Virginia.Cagwin at turner.com>
>
>"So, while results appeared very quickly, the first thing *every* user
>did with them is sort them by date, author, or whatever would help make
>them useful. Only when sorting was complete did users feel as though
>they could declare victory."
>
>When does the list become unbearable to scroll through even if I can
>sort?

Scrolling probably isn't even an issue here. If there are enough items displayed in no discernable, useful order such that the user has to *read* each item (as opposed to scan the list) to find what he wants, sorting is desirable and you've hit the "unbearable" point.

Experience/gut reaction tells me that number is 3. With 3 or less items, you read and scan about equally; with 4 or more items, scanning is faster than reading the entire list. (With 2 items, there is no such thing as random order, as some order can be inferred no matter what, and read and scan become the same thing. With 3 items, scan is probably marginally faster than read, but not much, and the odds of things being in an assumed order despite being truly random is still fairly high.)

(These numbers are not experimentally verified by me.)

-- Jim

14 Mar 2007 - 7:34pm
bhekking
2006

>
> (These numbers are not experimentally verified by me.)

...which is why this is a good example of a question that user testing can
help resolve. Find a few users (or close surrogates), prepare a
representative task, and let them show you what their threshold for the
number of search results is.

- Bret

14 Mar 2007 - 10:36pm
dcooney at umich.edu
2006

Hi Virginia,
You mentioned that these users are likely to already know what they are
looking for, so I presume this is (at least) a matter of finding the
best way of surfacing a known item - given that the item could be in
the midst of thousands of other items.

I wonder if it would be useful to ask: in what way do the users already
know what they are looking for?

If this is a photo, then the customer might need to see the photos.
Today I needed a photo, and using iPhoto, I looked through more than
700 tiny thumbnails and in seconds found the picture I knew was in
there. Things were ordered by time, and I was easily able to find it
because I knew it was "sometime around then" In that case, 700 would
have been no different than 5,000, as I know from other instances that
I would have very quickly scrolled through chunks of photo/time.

If what the user will know is "it was a PowerPoint presentation", then
somehow visually indicating file types in the search results would be a
great help (as would an easy UI for the search/filter function).

If the user knew they had used a certain word inside a document, then
it would be good to see in the search results some of the words or
context that surround the query term (in Google, see those first 2
lines after the result item title, and the bolded search term)

So, maybe consider what it is you would need to surface in the search
results that would correspond to the aspect of the searched for item
that you think is "known" by the user, and therefore enable more speedy
scanning of a list of results.

Best,
Dan

Quoting "Cagwin, Virginia" <Virginia.Cagwin at turner.com>:

> "So, while results appeared very quickly, the first thing *every* user
> did with them is sort them by date, author, or whatever would help make
> them useful. Only when sorting was complete did users feel as though
> they could declare victory."
>
> When does the list become unbearable to scroll through even if I can
> sort?
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>
>
>

15 Mar 2007 - 2:18pm
Peter Boersma
2003

Robert wrote:
> The magic number is not a number, it's *speed*.

Allow me to give an example where speed was not the magic bullet:
Two years ago I worked with a team that was designing the interface for a scientific search engine. At some point the developers came with the suggestion to put the time it took to search the massive database on the screen. The designers thought it might impress the users and agreed. The developers were so proud! A search on "rhematic +inflammable -bechterew" yielded over 1400 results and was produced in 0.91 seconds!

The users hated it. They could not believe that a computer could search ALL the references the company advertised it searched through in so little time (especially since they probably had been looking everywhere manually for weeks). They did not trust the results and abandoned the search engine.

As soon as the results from the next round of usability tests came in, the feature was gone.

This target group was willing to wait (I always said they'd wait a day or a week if they had to) and be sure that the search had yielded ALL relevant results. They would refine their search later on (for example by looking at the years in which the most references were made to a particular article and zoom in on those). They were not there for the first couple of hits, they wanted ALL hits.

Peter
--
Peter Boersma | Senior Interaction Designer | Info.nl
http://www.peterboersma.com/blog | http://www.info.nl

Syndicate content Get the feed