CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)

CHI-WEB@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Cameron Barrett <[log in to unmask]>
Reply To:
Cameron Barrett <[log in to unmask]>
Date:
Mon, 25 Jan 1999 20:13:46 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (65 lines)
Coming in late, I will outline our thinking behind the current searh
results pages for Borders.com.

Middle of last year (eons ago) we decided our current search results
sucked. We admitted it freely around the office and our customers weren't
fooled, so we worked on a better results interface. Much of our thinking
reflects the interface you see today.

Dealing with three wide categories (books, msuic, and video) with an equal
amount of databases for each, we realized that it'd be rather impossible to
do a search query across the three, as the nature of each database didn't
(and still doesn't) allow so. Not only would it returna n confusing array
of matches, it would be awfully slow and quite cumbersome in usability.

Instead, we broke the three down by category. Currently, you can only do a
search within each media category. However, we thoughtfully broke each
media type down by search type. For instance, within "Books" you can search
for Keyword, Title,  Author, Title & Author, ISBN and  UPC. Each of these
is a seperate search interface with it's own syntax. By breaking down each
category into search types, we solved the problem of presenting the end
user with too complex a search interface. You can only imagine how messy an
interface could be with all of these options, plus the options within the
other two media categories.

Ah, but what if a user wants to do a wide search? We solved this issue by
giving them a "quick" search form that is present on every page no matter
how deep or shallow you are in the site. This is even part of the global
navigation area.

Every search results page contains the previous search interface again,
with every option you'd ever need (sorted by media type) nicely listed to
the left in a neat column.

Each of the search interfaces queries one or more different search tables
within one or more databases. Each of these tables is optimzed for search
results. We purposely tried to design our search results pages to download
and render quickly, even though at times they can be slow.

Each search results page allows the user to "re-sort" their results either
by author or title. More options along this line are forthcoming.

We have many other options in the works that promise to enhance our end
users' searching capabilities. One of these is the potential to search
across media types. Another is the potential to sort by media type within
media category. (Example: CD, Cassette, Audio Tape, etc.; VHS, Laserdisc,
DVD, etc.). We're also working on a "bestsellers within search query"
sorting option/display.

A word of caution to those just starting out with obscenely large databases
and search engine technology. Be sure to choose a database technology that
is sufficiently expandable. Currently, I have very few good things to say
about db2 or ASP (for accessing databases). This of course, takes into
consideration the technologies used to access your databases. A weak macro
language can limnit your possibilities in ways that you could never imagine.

I hope that I explained our search results philosophy in an
easy-to-understand manner. If anyone has comments and/or questions about
what we're doing, don't hesitiate to ask. [log in to unmask]

Cameron Barrett
--------------------------
Interactive Designer - Borders Online
[log in to unmask] http://www.borders.com (Work)
[log in to unmask] http://www.camworld.com (Personal)

ATOM RSS1 RSS2