Displaying search results

25 Mar 2008 - 8:05pm
6 years ago
2 replies
697 reads
Dante Murphy
2006

I can only think of two situations where this interaction would be valuable, neither of which is demonstrated in the sample:

1. where the current content of the page was still visible and in some way helped contextualize the search results, or
2. where the original page was dynamic and took a really long time to load, such that navigating back to the point of origin would be problematic

And there are plenty of less fancy but well-proven methods for addressing both of those. So I'd pass on this implementation.

Dante Murphy

________________________________

From: discuss-bounces at lists.interactiondesigners.com on behalf of Eugene Kim
Sent: Wed 2/6/2008 8:10 PM
To: discuss at ixda.org
Subject: [IxDA Discuss] Displaying search results

Hi,

I'm Eugene and I'm an IA for IGN Entertainment. Prior to this, I spent
several years as an Interface Designer and IA at EarthLink. I've lurked
for quite some time and posted a couple job postings here and there, but
I figured now is a good time to get more involved.

I'd like to get your opinions on overlay methods for displaying search
results. For example, check out
http://www.google.com/cse/samples/overlay.html. I don't know if it
really has value for static pages, but with media such as audio and
video I envision this allowing the user to multitask effectively without
cutting off the media stream.

But is search so standardized that something like this could become a
distraction?

Please post any other examples you've come across.

Thanks,

Eugene

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

Comments

27 Mar 2008 - 10:53am
Jason Conness
2008

This may be somewhat to Dante's first point but I have designed a scenario
where a user is searching for favorite Celebreties, Programs, and Channels.
The use case is not intended to take the user to a separate page to learn
more information. It is intended as a selection tool. Search > Select >
Search > Select. For this case I found it a great way to allow users to
quickly search for an item, find it, select it and never have to leave the
page. Much quicker than loading a new page only to have to have the user
click "back".

27 Mar 2008 - 6:56pm
SemanticWill
2007

Again, time for Will's 2 Cents and a Tequila shot. This time about
Information Seeking/Information Retrieval behavior given that research has
shown essentially 4 modes of information seeking:

*Known-item information seeking.**
*

In a known-item search, the user**

- Knows what they want

- Knows what words/keywords to use to describe it

- May have a fairly good understanding of where to start

- In addition, users may be happy with the first object/article they
find (though not always) and the task may not change significantly during
the process of finding the article (or member, for that matter).

*Exploration*

- In an exploratory task, users have some general idea of what they
want to know. However, they may or may not know how to articulate it, and,
if they can, may not yet know the right words to use.

*Don't know what you need to know*

- The key concept behind this mode is that people often don't know
exactly what they need to know. They may think they need one thing but need
another; or, they may be looking at a website without a specific goal in
mind.

*Re-finding*

- This mode is relatively straightforward—people looking for things
they have already seen. They may remember exactly where it is, remember what
site it was on, or have little idea about where it was.

But before moving forward, don't get trapped in the "Solution searching for
a problem," trap by seeing a new interaction pattern– in this case
displaying the search results overlayed on top of the originating page. If
the user starts on Page A which has content and a search widget, what is the
goal they are trying to achieve? This page is close, but I want to see what
else is out there? Why not just navigate to a new page?

Okay – I have a use case – but before going there, let's review that the
basic steps in information seeking behavior according to Ben Schneiderman
are:

1 Formulation

2 Action

3 Review

4 Refine

5 Repeat

Now – if my Page A is not content, but actually a search results screen from
search formulation:action 1, but I want to reformulate my query terms
without losing the current results set – have that load somewhere else while
I perform the "Review-Refine" actions in Page A, then this might make sense.
Better implementation would allow the original query results to be viewable,
refinable, etc… but still have the Page B results viewable as they can come
in so that if the reformulated query is better, Page A results can be
disgarded. I think the implementation of something like Amazon's A9 might be
a better design pattern – with each pane as a vertical
expandable/collapsible view. This Google implementation doesn't allow the
multitasking of reviewing/refining/filtering on results set Page A while
simultaneously checking on the quality of the query in Page B.

But this goes down a bit of a rabbit hole because do people actually behave
this way – or not. Well – not according to Patricia Bates in the great
article about "berry-picking" where an information seeker's query is
constantly shifting – but within a confined context – the user begins with a
query, but continues down a path where they review results, refine query,
pick up tidbits of new info, refine query, reviewing results, hopping and
skipping down a crooked path but all within a narrow context.

"In real-life searches in manual sources, end users may begin with just one
feature of a broader topic, or just one relevant reference, and move through
a variety of sources. Each new piece of information they encounter gives
them new ideas and directions to follow and, consequently, a new conception
of the query. At each stage they are not just modifying the search terms
used in order to get a better match for a single query. Rather the query
itself (as well as the search terms used) is continually shifting, in part
or whole. This type of search is here called an *evolving search."*

So with that addressed (partially) – how does the Google implementation
increase user benefit in the information seeking process? I illustrated one
use case where it could theoretically be useful – but that's hypothetical.
Bates go on in the article to dig further into interface design
considerations for improving user experience given this research – but
nothing points to this solution actually maximizing utility of a user
following one of the four basic modes of information seeking.Perhaps the
best thing is if these examples were shown in a format like Jen Tidwell's
design patterns , or the Yahoo design pattern library where the problem
space is first defined, user expectations discussed, and then design pattern
is shown - as opposed to this case where all we have is the "you could do it
this way" :-)

See also this stuff:

*Ambiant Findability, *
By Peter Morville, O'Reilly

*THE DESIGN OF BROWSING AND BERRYPICKING TECHNIQUES
FOR THE ONLINE SEARCH INTERFACE*
by Marcia J. Bates

*Information scent as a driver of Web behavior graphs.
Proceedings of the Conference on Human factors in computing systems CHI '01
Association for Computing Machinery.*
By Card, Stuart K., Peter Pirolli

*Sorting out searching: a user-interface framework for text searches
Communications of the ACM*
Ben Shneiderman<http://portal.acm.org/results.cfm?query=author%3ABen%20Shneiderman&querydisp=author%3ABen%20Shneiderman&coll=GUIDE&dl=GUIDE&CFID=6785436&CFTOKEN=34245674>,
Donald Byrd<http://portal.acm.org/results.cfm?query=author%3ADonald%20Byrd&querydisp=author%3ADonald%20Byrd&coll=GUIDE&dl=GUIDE&CFID=6785436&CFTOKEN=34245674>,
W. Bruce Croft<http://portal.acm.org/results.cfm?query=author%3AW%2E%20Bruce%20Croft&querydisp=author%3AW%2E%20Bruce%20Croft&coll=GUIDE&dl=GUIDE&CFID=6785436&CFTOKEN=34245674>

*A User-interface framework for text searches
http://www.dlib.org/dlib/january97/retrieval/01shneiderman.html
D-Lib Magazine *
Ben Shneiderman, Donald Byrd, W. Bruce Croft

<trimmed>

On Thu, Mar 27, 2008 at 12:53 PM, Jason Conness <jconness at gmail.com> wrote:

> This may be somewhat to Dante's first point but I have designed a scenario
> where a user is searching for favorite Celebreties, Programs, and
> Channels.
> The use case is not intended to take the user to a separate page to learn
> more information. It is intended as a selection tool. Search > Select >
> Search > Select. For this case I found it a great way to allow users to
> quickly search for an item, find it, select it and never have to leave the
> page. Much quicker than loading a new page only to have to have the user
> click "back".
> ________________________________________________________________
>
>

Syndicate content Get the feed