|
|
|
|
|
|
Lesson#43
|
INFORMATION RETRIEVAL
|
|
|
|
As the aim of this lecture is to introduce you the study of
Human Computer
Interaction, so that after studying this you will be able to:
. Discuss how to
communicate
. Learn how to
retrieve the information
43.1 Audible feedback
In data-entry environments, clerks sit for hours in front of
computer screens entering
data. These users may well he examining source documents and
typing by touch
instead of looking at the screen. If a clerk enters something
erroneous, he needs to be
informed of it via both auditory and visual feedback. The clerk
can then use his sense
of hearing to monitor the success of his inputs while he keeps
his eyes on the
document.
The kind of auditory feedback we're proposing is not the same as
the beep that
accompanies an error message box. In fact, it isn't beep at all.
The auditory indicator we
propose as feedback for a problem is silence. The problem with
much current audible
feedback is the still-prevalent idea that, rather than positive
audible feedback, negative
feedback is desirable.
NEGATIVE AUDIBLE FEEDBACK: ANNOUNCING USER FAILURE
People frequently counter the idea of audible feedback with
arguments that users don't
like it. Users are offended by the sounds that computers make,
and they don't like to
have their computer beeping at them. This is likely true based
on how computer
sounds are widely used today — people have been conditioned by
these unfortunate
facts:
. Computers have
always accompanied error messages with alarming noises.
. Computer noises
have always been loud, monotonous and unpleasant.
Emitting noise when something bad happens is called negative
audible feedback. On
most systems, error message boxes are normally accompanied by
loud, shrill, tinny
"beeps," and audible feedback has thus become strongly
associated them. That beep is a
public announcement of the user's failure. It explains to all
within earshot that you have
done something execrably stupid. It is such a hateful idiom that
most software
developers now have an unquestioned belief that audible feedback
is bad and should
never again be considered as a part of interface design. Nothing
could be further from
the truth. It is the negative aspect of the feedback that
presents problems, not the audible
aspect.
Negative audible feedback has several things working against it.
Because the negative
feedback is issued at a time when a problem is discovered, it
naturally takes on the
characteristics of an alarm. Alarms are designed to be
purposefully loud, discordant, and
416
disturbing. They are supposed to wake sound sleepers from their
slumbers when their
house is on fire and their lives are at stake. They are like
insurance because we all hope
that they will never be heard. Unfortunately, users are
constantly doing things that
programs can't handle, so these actions have become part of the
nor mal course of
interaction. Alarms have no place in this normal relationship,
the same way wt don't
expect our car alarms to go off whenever we accidentally change
lanes without using our
turn indicators. Perhaps the most damning aspect of negative
audible feedback is the
implication that success must be greeted with silence. Humans
like to know when they are
doing well. They need to know when they are doing poorly, but
that doesn't mean that they
like to hear about it. Negative feedback systems are simply
appreciated less than positive
feedback systems.
Given the choice of no noise versus noise for negative feedback,
people will choose the former.
Given the choice of no noise versus unpleasant noises for
positive feedback, people
will choose based on their personal situation and taste. Given
the choice of no noise
versus soft and pleasant noises for positive feedback, however,
people will choose the
feedback. We have never given our users a chance by putting
high-quality, positive audible
feedback in our programs, so it's no wonder that people
associate sound with bad interfaces.
POSITIVE AUDIBLE FEEDBACK
Almost every object and system outside the world of software
offers sound to indicate
success rather than failure. When we close the door, we know
that it is latched when we hear
the click, but silence tells us that it is not yet secure. When
we converse with someone and they
say, "Yes" or "Uh-huh," we know that they have, at least
minimally, registered what was said.
When they are silent, however, we have reason to believe that
something is amiss. When we
turn the key in the ignition and get silence, we know we've got
a problem. When we flip the
switch on the copier and it stays coldly silent instead of
humming, we know that we've got
trouble. Even most equipment that we consider silent makes some
noise: Turning on the
stovetop returns a hiss of gas and a gratifying "whoomp" as the
pilot ignites the burner.
Electric ranges are inherently less friendly and harder to use
because they lack that sound —
they require indicator lights to tell us of their status.
When success with our tools yields a sound, it is called
positive audible feedback. Our
software tools are mostly silent; all we hear is the quiet click
of the keyboard. Hey! That's
positive audible feedback. Every time you press a key, you hear
a faint but positive sound.
Keyboard manufacturers could make perfectly silent keyboards,
but they don't because we
depend on audible feedback to tell us how we are doing. The
feedback doesn't have to be
sophisticated — those clicks don't tell us much — but they must
be consistent. If we ever
detect silence, we know that we have failed to press the key.
The true value of positive
audible feedback is that its absence is an extremely effective
problem indicator.
The effectiveness of positive audible feedback originates in
human sensitivity. Nobody likes to
be told that they have failed. Error message boxes are negative
feedback, telling the user that
he has done something wrong. Silence can ensure that the user
knows this without
actually being told of the failure. It is remarkably effective,
because the software doesn't
have to insult the user to accomplish its ends.
Our software should give us constant, small, audible cues just
like our keyboards. Our
programs would be much friendlier and easier to use if they
issued barely audible but easily
identifiable sounds when user actions are correct. The program
could issue an upbeat tone
417
every time the user enters valid input to a field. If the
program doesn't understand the
input, it would remain silent and the user would be immediately
informed of the problem
and be able to correct his input without embarrassment or
ego-bruising. Whenever the
user starts to drag an icon, the computer could issue a
low-volume sound reminiscent of
sliding as the object is dragged. When it is dragged over pliant
areas, an additional
percussive tap could indicate this collision. When the user
finally releases the mouse
button, he is rewarded with a soft, cheerful "plonk" from the
speakers for a success or with
silence if the drop was not meaningful.
As with visual feedback, computer games tend to excel at
positive audio feedback.
Mac OS 9 also does a good job with subtle positive audio
feedback for activities like
documents saves and drag and drop. Of course, the audible
feedback must be at the right
volume for the situation. Windows and the Mac offer a standard
volume control, so one
obstacle to beneficial audible feedback has been overcome.
Rich modeless feedback is one of the greatest tools at the
disposal of interaction
designers. Replacing annoying, useless dialogs with subtle and
powerful modeless
communication can make the difference between a program users
will despise and one they will
love. Think of all the ways you might improve your own
applications with RVMF and other
mechanisms of modeless feedback!
43.2 Other Communication with
Users
This Part of the lecture is about communicating with your users,
and we would be
remiss if we did not discuss ways of communicating to the user
that are not only helpful
to them, but which are also helpful to you, as creator or
publisher of software, in
asserting your brand and identity. In the best circumstances,
these communications are
not at odds, and this chapter presents recommendations that will
enable you to make the
most out of both aspects of user communication.
Your Identity on the Desktop
The modern desktop screen is getting quite crowded. A typical
user has a half-dozen
programs running concurrently, and each program must assert its
identity. The user
needs to recognize your application when he has relevant work to
be done, and you should
get the credit you deserve for the program you have created.
There are several conventions
for asserting identity in software.
Your program's name
By convention, your program's name is spelled out in the title
bar of the program's
main window. This text value is the program's title string, a
single text value within the
program that is usually owned by the program's main window.
Microsoft Windows
introduces some complications. Since Windows 95, the title
string has played a greater
role in the Windows interface. Particularly, the title string is
displayed on the program's
launch button on the taskbar.
The launch buttons on the taskbar automatically reduce their
size as more buttons are
added, which happens as the number of open programs increases.
As the buttons get
shorter, their title strings are truncated to fit.
Originally, the title string contained only the name of the
application and the company
brand name. Here's the rub: If you add your company's name to
your program's name,
like, say "Microsoft Word," you will find that it only takes
seven or eight running programs
or open folders to truncate your program's launch-button string
to "Microsoft." If you
418
are also running "Microsoft Excel," you will find two adjacent
buttons with identical,
useless title strings. The differentiating portions of their
names — "Word" and "Excel" —
are hidden.
The title string has, over the years, acquired another purpose.
Many programs use it
to display the name of the currently active document.
Microsoft's Office Suite
programs do this. In Windows 95, Microsoft appended the name of
the active document
to the right end of the title string, using a hyphen to separate
it from the program name. In
subsequent releases, Microsoft has reversed that order: The name
of the document
comes first, which is certainly a more goal-directed choice 41
as far as the user is
concerned. The technique isn't a standard: but because Microsoft
does it, it is often copied.
It makes the title string extremely long, far too long to fit
onto a launch button-but
ToolTips come to the rescue!
What Microsoft could have done instead was add a new title
string to the program's
internal data structure. This string would be used only on the
launch button (on the
Taskbar), leaving the original title string for the window's
title bar. This enables the
designer and programmer to tailor the launch-button string for
its restricted space, while
letting the title string languish full-length on the
always-roomier title bar.
Your program's icon
The second biggest component of your program's identity is its
icon. There are two
icons to worry about in Windows: the standard one at 32 pixels
square and a miniature
one that is 16 pixels square. Mac OS 9 and earlier had a similar
arrangement; icons in OS X
can theoretically be huge — up to 128x128 pixels. Windows XP
also seems to make use of
a 64x64 pixel, which makes sense given that screen resolutions
today can exceed
1600x1200 pixels.
The 32x32 pixel size is used on the desktop, and the 16x16 pixel
icon is used on the title bar,
the taskbar, the Explorer, and at other locations in the Windows
interface. Because of the
increased importance of visual aesthetics in contemporary GUIs,
you must pay greater
attention to the quality of your program icon. In particular,
you want your program's
icon to be readily identifiable from a distance — especially the
miniature version. The
user doesn't necessarily have to be able to recognize it
outright — although that would
be nice — but he should be able to readily see that it is
different from other icons.
Icon design is a craft unto itself, and is more difficult to do
well than it may appear.
Arguably, Susan Kare's design of the original Macintosh icons
set the standard in the
industry. Today, many visual interface designers specialize in
the design of icons, and any
applications will benefit from talent and experience applied to
the effort of icon design.
Ancillary Application Windows
Ancillary application windows are windows that are not really
part of the application's
functionality, but are provided as a matter of convention. These
windows are either
available only on request or are offered up by the program only
once, such as the
programs credit screen. Those that are offered unilaterally by
the program are erected
when the program is used for the very first time or each time
the program is initiated.
All these windows, however, form channels of communication that
can both help the
user and better communicate your brand.
About boxes
The About box is a single dialog box that — by convention —
identifies the program
to the user. The About box is also used as the program's credit
screen, identifying the
419
people who created it. Ironically, the About box rarely tells
the user much about the
program. On the Macintosh, the About box can be summoned from
the top of the Apple
pop-up menu. In Windows, it is almost always found at the bottom
of the Help menu.
Microsoft has been consistent with About boxes in its programs,
and it has taken a
simple approach to its design, as you can see in Figure below.
Microsoft uses the
About box almost exclusively as a place for identification, a
sort of driver's license for
software. This is unfortunate, as it is a good place to give the
curious user an overview
of the program in a way that doesn't intrude on those users who
don't need it. It is
often, but not always, a good thing to follow in Microsoft's
design footsteps. This is one
place where diverging from Microsoft can offer a big advantage.
The main problem with Microsoft's approach is that the About box
doesn't tell the
user about' the program. In reality, it is an identification
box. It identifies the program
by name and version number. It identifies various copyrights in
the program. It
identifies the user and the user's company. These are certainly
useful functions, but
are more useful for Microsoft customer support than for the
user.
The desire to make About boxes more useful is clearly strong —
otherwise, we
wouldn't see, memory usage and system-information buttons on
them. This is
admirable, but, by taking a more ... goal-directed approach, we
can add information to
the About box that really can help the user. The single most
important thing that the
About box can convey to the user is the scope of the program. It
should tell, in the
broadest terms, what the program can and can't do. It should
also state succinctly what
the program does. Most program authors forget that many users
don't have any idea
what the InfoMeister 3000 Version 4.0 program actually does.
This is the place to
gently clue ,; them in.
420
The About box is also a great place to give the one lesson that
might start a new user
success fully. For example, if there is one new idiom — like a
direct-manipulation
method — that is critical to the user interaction, this is a
good place to briefly tell
him about it. Additionally, the About box can direct the new
user to other sources of
information that will help him get his bearings in the program.
Because the current design of this facility just presents the
program's fine print instead
of telling the user about the program, it should be called an
Identity box instead of an About
box, and that's how well refer to it from this point on. The
Identity box identifies the
program to the user, " and the dialog in Figure above fulfills
this definition admirably. It
tells us all the stuff the lawyers require and the tech support
people need to know. Clearly,
Microsoft has made the decision that an Identity box is
important, whereas a true About
box is expendable.
As we've seen, the Identity box must offer the basics of
identification, including the
publisher's name, the program's icons, the program's version
number, and the names of
its authors. Another item that could profitably be placed here
is the publisher's technical
support telephone number.
Many software publishers don't identify their programs with
sufficient discrimination
to tie , them to a specific software build. Some vendors even go
so far as to issue the same
version number to significantly different programs for marketing
reasons. But the
version number in the Identity — or About — box is mainly used
by customer support. A
misleading version number will cost the publisher a significant
amount of phone-support
time just figuring out precisely which version of the program
the user has. It doesn't
matter what scheme you use, as long as this number is very
specific.
The About box (not the Identity box) is absolutely the right
place to state the product
team's names. The authors firmly believe that credit should be
given where credit is due
in the design, development, and testing of software.
Programmers, designers, managers,
and testers all deserve to see their names in lights.
Documentation writers sometimes
get to put their names in the manual, but the others only have
the program itself. The
About box is one of the few dialogs that has no functional
overlap with the main program,
so there is no reason why it can't be oversized. Take the space
to mention everyone who
contributed. Although some programmers are indifferent to seeing
their names on the
screen, many programmers are powerfully motivated by it and
really appreciate managers
who make it happen. What possible reason could there be for not
naming the smart, hardworking
people who built the program?
This last question is directed at Bill Gates (as it was in the
first edition in 1995), who
has a corporate-wide policy that individual programmers never
get to put their names
in the About boxes of programs. He feels that it would be
difficult to know where to draw
the line with individuals. But the credits for modern movies are
indicative that the
entertainment industry, for one, has no such worries. In fact,
it is in game software that
development credits are most often featured. Perhaps now that
Microsoft is heavy into
the game business things will change — but don't count on it.
Microsoft's policy is disturbing because its conventions are so
widely copied. As a
result, Its no-programmer-names policy is also widely copied by
companies who have
no real reason for it other than blindly following Microsoft.
421
Splash screens
A splash screen is a dialog box displayed when a program first
loads into memory.
Sometimes it may just be the About box or Identity box,
displayed automatically, but
more often publishers create a separate splash screen that is
more engaging and visually
exciting.
The splash screen should be placed on the screen as soon as user
launches the
program, so that he can view it while the bulk of the program
loads and prepares itself for
running. After a few seconds have passed, it should disappear
and the program should
go about its business. If, during the splash screen's tenure,
the user presses any key or
clicks any mouse button, the splash screen should disappear
immediately. The program
must show the utmost respect for the user's time, even if it is
measured in milliseconds.
The splash screen is an excellent opportunity to create a good
impression. It can be used
to reinforce the idea that your users made a good choice by
purchasing your product.
It also helps to establish a visual brand by displaying the
company logo, the product logo,
the product icon, and other appropriate visual symbols.
Splash screens are also excellent tools for directing first-time
users to training resources
that are not regularly used. If the program has built-in
tutorials or configuration options,
the splash screen can provide buttons that take the user
directly to these facilities (in this
case, the splash screen should remain open until manually
dismissed).
Because splash screens are going to be seen by first-timers, if
you have something to say
to them, this is a good place to do it. On the other hand, the
message you offer to those
first-timers will be annoying to experienced users, so
subsequent instances of the splash
screen should be more generic. Whatever you say, be clear and
terse, not long-winded or
cute. An irritating message on the splash screen is like a
pebble in your shoe, rapidly
creating a sore spot if it isn't removed promptly.
Shareware splash screens
If your program is shareware, the splash screen can be your most
important dialog
(though not your users'). It is the mechanism whereby you inform
users of the terms of
use and the appropriate way to pay for your product. Some people
refer to shareware splash
screens as the guilt screen. Of course, this information should
also be embedded in the
program where the user can request it, but by presenting to
users each time the program
loads, you can reinforce the concept that the program should be
paid for. On the other
hand, there's a fine line you need to tread lest your sales
pitch alienate users. The best
approach is to create an excellent product, not to guilt-trip
potential customers.
Online help
Online help is just like printed documentation, a reference tool
for perpetual
intermediates. Ultimately, online help is not important, the way
that the user manual of
your car is not important. If you find yourself needing the
manual, it means that your car is
badly designed. The design is what is important.
A complex program with many features and functions should come
with a reference
document: a place where users who wish to expand their horizons
with a product can find
definitive answers. This document can be a printed manual or it
can be online help. The
printed manual is comfortable, browsable, friendly, and can be
carried around. The online
help is searchable, semi-comfortable, very lightweight, and
cheap.
422
The index
Because you don't read a manual like a novel, the key to a
successful and effective
reference document is the quality of the tools for finding what
you want in it. Essentially,
this means the index. A printed manual has an index in the back
that you use manually.
Online help has an automatic index search facility.
The experts suspect that few online help facilities they've seen
were indexed by a
professional indexer. However many entries are in your program's
index, you could
probably double the number. What's more, the index needs to be
generated by examining
the program and all its features, not by examining the help text
This is not easy, because it
demands that a highly skilled indexer be intimately familiar
with all the features of the
program. It may be easier to rework the interface to improve it
than to create a really good
index.
The list of index entries is arguably more important than the
text of the entries
themselves. The user will forgive a poorly written entry with
more alacrity than he will
forgive a missing entry. The index must have as many synonyms as
possible for topics.
Prepare for it to be huge. The user who needs to solve a problem
will be thinking "How
do I turn this cell black?" not "How can I set the shading of
this cell to 100%?" If the
entry is listed under shading, the index fails the user. The
more goal-directed your
thinking is, the better the index will map to what might
possibly pop into the user's
head when he is looking for something. One index model that
works is the one in The Joy
of Cooking, Irma S. Rombaur & Marion Rombaur Becker
(Bobbs-Merrill, 1962). That index
is one of the most complete and robust of any the authors have
used,
Shortcuts and overview
One of the features missing from almost every help system is a
shortcuts option. It is
an item in the Help menu which when selected, shows in digest
form all the tools and
keyboard commands for the program's various features. It is a
very necessary component
on any online help system because it provides what perpetual
intermediates need the
most: access to features. They need the tools and commands more
than they need detailed
instructions.
The other missing ingredient from online help systems is
overview. Users want to know
how the Enter Macro command works, and the help system explains
uselessly that it is the
facility that lets you enter macros into the system. What we
need to know is scope, effect,
power, upside, downside, and why we might want to use this
facility both in absolute
terms and in comparison to similar products from other vendors.
@Last Software
provides online streaming video tutorials for its architectural
sketching application,
SketchUp. This is a fantastic approach to overviews,
particularly if they are also available
on CD-ROM.
Not for beginners
Many help systems assume that their role is to provide
assistance to beginners. This is
not true. Beginners stay away from the help system because it is
generally just as complex
as the program. Besides, any program whose basic functioning is
too hard to figure out just
by experimentation is unacceptable, and no amount of help text
will resurrect it. Online
help should ignore first-time users and concentrate on those
people who are already
successfully using the product, but who want to expand their
horizons: the perpetual
intermediates.
423
Modeless and interactive help
ToolTips are modeless online help, and they are incredibly
effective. Standard help
systems, on the other hand, are implemented in a separate
program that covers up most of
the program for which it is offering help. If you were to ask a
human how to perform a
task, he would use his finger to point to objects on the screen
to augment his explanation.
A separate help program that obscures the main program cannot do
this. Apple has used an
innovative help system that directs the user through a task step
by step by highlighting
menus and buttons that the user needs to activate in sequence.
Though this is not totally
modeless, it is interactive and closely integrated with the task
the user wants to perform, and
not a separate room, like reference help systems,
Wizards
Wizards are an idiom unleashed on the world by Microsoft, and
they have rapidly
gained popularity among programmers and user interface
designers. A wizard attempts to
guarantee success in using a feature by stepping the user
through a series of dialog
boxes. These dialogs parallel a complex procedure that is
"normally" used to manage a
feature of the program. For example, a wizard helps the user
create a presentation in
PowerPoint.
Programmers like wizards because they get to treat the user like
a peripheral device. Each
of the wizard's dialogs asks the user a question or two, and in
the end the program
performs whatever task was requested. They are a fine example of
interrogation tactics on
the program's part, and violate the axiom: Asking questions
isn't the same as providing
choices.
Wizards are written as step-by-step procedures, rather than as
informed conversations
between user and program. The user is like the conductor of a
robot orchestra, swinging
the baton to set the tempo, but otherwise having no influence on
the proceedings. In this
way, wizards rapidly devolve into exercises in confirmation
messaging. The user learns
that he merely clicks the Next button on each screen without
critically analyzing why.
There is a place for wizards in actions that are very rarely
used, such as installation
and initial configuration. In the weakly interactive world of
HTML, they have also
become the standard idiom for almost all transactions on the Web
— something that
better browser technology will eventually change.
A better way to create a wizard is to make a simple, automatic
function that asks no
questions of the user but that just goes off and does the job.
If it creates a presentation,
for example, it should create it, and then let the user have the
option, later, using standard
tools, to change the presentation. The interrogation tactics of
the typical wizard are not
friendly, reassuring, or particularly helpful. The wizard often
doesn't explain to the user
what is going on.
Wizards were purportedly designed to improve user interfaces,
but they are, in many cases,
having the opposite effect. They are giving programmers license
to put raw
implementation model interfaces on complex features with the
bland assurance that: "We'll
make it easy with a wizard.” This is all too reminiscent of the
standard abdication of
responsibility to users: "We'll be sure to document it in the
manual."
"Intelligent" agents
Perhaps not much needs to be said about Clippy and his cousins,
since even Microsoft
has turned against their creation in its marketing of Windows XP
(not that it has actually
removed Clippy from XP, mind you). Clippy is a remnant of
research Microsoft did in the
424
creation of BOB, an "intuitive" real-world, metaphor-laden
interface remarkably similar to
General Magic's Magic Cap interface. BOB was populated with
anthropomorphic, animated
characters that conversed with users to help them accomplish
things. It was one of
Microsoft's most spectacular interface failures. Clippy is a
descendant of these help
agents and is every bit as annoying as they were.
A significant issue with "intelligent" animated agents is that
by employing animated
anthropomorphism, the software is upping the ante on user
expectations of the agent's
intelligence. If it can't deliver on these expectations, users
will quickly become furious, just
as they would with a sales clerk in a department store who
claims to be an expert on his
products, but who, after a few simple questions, proves himself
to be clueless.
These constructs soon become cloying and distracting. Users of
Microsoft Office are
trying to accomplish something, not be entertained by the antics
and pratfalls of the help
system. Most applications demand more direct, less distracting,
and trustworthier means of
getting assistance.
43.3 Improving Data Retrieval
In the physical world, storing and retrieving are inextricably
linked; putting an item
on a shelf (storing it) also gives us the means to find it later
(retrieving it}. In the digital
world, the only thing linking these two concepts is our faulty
thinking. Computers will enable
remarkably sophisticated retrieval techniques if only we are
able to break our thinking out of its
traditional box. This part of lecture discusses methods of data
retrieval from an interaction
standpoint and presents some more human-centered approaches to
the problem of finding useful
information.
Storage and Retrieval Systems
A storage system is a method for safekeeping goods in a
repository. It is a physical
system composed of a container and the tools necessary to put
objects in and take them
back out again. A retrieval system is a method for finding goods
in a repository. It is a logical
system that allows the; goods to be located according to some
abstract value, like name,
position or some aspect of the; contents.
Disks and files are usually rendered in implementation terms
rather than in accord with the
user's mental model of how information is stored. This is also
true in the methods we use for
finding information after it has been stored. This is extremely
unfortunate because the
computer is the one tool capable of providing us with
significantly better methods of
finding information than those physically possible using
mechanical systems. But before we talk
about how to improve retrieval, let's briefly discuss how it
works.
Storage and Retrieval in the Physical World
We can own a book or a hammer without giving it a name or a
permanent place of residence
in our houses. A book can be identified by characteristics other
than a name — a color
or a shape, for example. However, after we accumulate a large
number of items that we need
to find and use, it helps to be a bit more organized.
Everything in its place: Storage and retrieval by location
It is important that there be a proper place for our books and
hammers, because that is
how we find them when we need them. We can't just whistle and
expect them to find us; we
must know where they are and then go there and fetch them. In
the physical world, the
actual location of a thing is the means to finding it.
Remembering where we put something-
-its address — is vital both to finding it, and putting it away
so it can be found again. When we
425
want to find a spoon, for example, we go to the place where we
keep our spoons. We don't find the
spoon by referring to any inherent characteristic of the spoon
itself. Similarly, when we
look for a book, we either go to where we lef t the book, or we
guess that it is stored
with other books. We don't find the book by association. That
is, we don't find the book
by referring to its contents.
In this model, which works just fine in your home, the storage
system is the same as
the retrieval system: Both are based on remembering locations.
They are coupled
storage and retrieval systems.
Indexed retrieval
This system of everything in its proper place sounds pretty
good, but it has a flaw: It
is limited in scale by human memory. Although it works for the
books, hammers, and
spoons in your house, it doesn't work at al l for the volumes
stored, for example, in the
of Congress.
In the world of hooks and paper on shelves, we make use
of another tool to
help us find things: the Dewey Decimal system (named after its
inventor, American
philosopher and educator John Dewey). The idea was brilliant:
Give even' book title a
unique number based on its subject matter and title and shelve
the books in this
numerical order. If you know the number, you can easily find the
book, and other
books related to it by subject would be near by — perfect for
research. The only
remaining issue was how to discover the number for a given book.
Certainly nobody
could be expected to remember every number.
The solution was an index, a collection of records that allows
you to find the location
of an item by looking up an attribute of the item, such as its
name. Traditional
card catalogs provided lookup by three attributes: author,
subject, and title. When the
book is entered into the system and assigned a number,
three index cards are
created for the book, including all particulars and the Dewey
Decimal number. Each
card is headed by the author's name, the subject, or the title.
These cards are then
placed in their respective indices in alphabetical order. When
you want to find a book,
you look it up in one of the indices and find its number. You
then find the row of
shelves that contains books with numbers in the same range as
your target by
examining signs. You search those particular shelves, narrowing
your view by the
lexical order of the numbers until you find the one you want.
You physically retrieve the book by participating in the system
of storage, but you
logically find the book you want by participating in a system of
retrieval. The shelves and
numbers are the storage system. The card indices are the
retrieval system. You identify the
desired book with one and fetch it wi t h the other. In a
typical university or
professional , customers are not allowed into the stacks.
As a customer, you
identify the book you want by using only the retrieval system.
The librarian then
fetches the book for you by participating only in the storage
system. The unique serial
number is the bridge between these two interdependent systems.
In the physical world,
both the retrieval system and the storage system may be very
labor intensive.
Particularly in older, non-computerized libraries, they are both
inflexible. Adding a fourth
index based on acquisition date, for example, would be
prohibitively difficult for the .
Storage and Retrieval in the Digital World
Unlike in the physical world of books, stacks, and cards, it's
not very hard to add an
index in the computer. Ironically, in a system where easily
implementing dynamic,
426
associative retrieval mechanisms is at last possible, we often
don't implement any
retrieval system. Astonishingly, we don't use indices at all on
the desktop.
In most of today's computer systems, there is no retrieval
system other than the
storage system. If you want to find a file on disk you need to
know its name and its
place. It's as if we went into the , burned the card
catalog, and told the patrons
that they could easily find what they want by just remembering
the little numbers
painted on the spines of the books. We have put 100 percent of
the burden of file
retrieval on the user's memory while the CPU just sits there
idling, executing billions
of nop instructions.
Although our desktop computers can handle hundreds of different
indices, we ignore
this capability and have no indices at all pointing into the
files stored on our disks.
Instead, we have to remember where we put our files and what we
called them in
order to find them again. This omission is one of the most
destructive, backward steps
in modern software design. This failure can be attributed to the
interdependence of
files and the organizational systems in which they exist, an
interdependence that
doesn't exist in the mechanical world.
Retrieval methods
There are three fundamental ways to find a document on a
computer. You can find it
by remembering where you left it in the file structure, by
positional retrieval. You can
find it by remembering its identifying name, by identity
retrieval. The third method,
associative or attributed-based retrieval, is based on the
ability to search for a
document based on some inherent quality of the document itself.
For example, if you
want to find a book with a red cover, or one that discusses
light rail transit systems, or
one that contains photographs of steam locomotives, or one that
mentions Theodore
Judah, the method you must use is associative.
Both positional and identity retrieval are methods that also
function as storage systems, and on
computers, which can sort reasonably well by name, they are
practically one and the
same. Associative retrieval is the one method that is not also a
storage system. If our retrieval
system is based solely on storage methods, we deny ourselves any
attribute-based searching
and we must depend on memory. Our user must know what
information he wants and
where it is stored in order to find it. To find the spreadsheet
in which he calculated the
amortization of his home loan he has to know that he stored it
in the directory called Home
and that it was called amortl. If he doesn't remember either of
these facts, finding the
document can become quite difficult
An attribute-based retrieval system
For early GUI systems like the original Macintosh, a positional
retrieval system
almost made sense: The desktop metaphor dictated it (you don't
use an index to look
up papers on your desk), and there were precious few documents
that could be stored
on a 144K floppy disk. However, our current desktop systems can
now easily hold
250,000 times as many documents! Yet we still use the same
metaphors and retrieval
model to manage our data. We continue to render our software's
retrieval systems in
strict adherence to the implementation model of the storage
system, ignoring the
power and ease-of-use of a system for finding files that is
distinct from the system for
keeping files.
An attribute-based retrieval system would enable us to find our
documents by their contents.
For example, we could find all documents that contain the text
string
427
"superelevation". For such a search system to really be
effective, it should know
where all documents can be found, so the user doesn't have to
say "Go look in suchand-
such a directory and find all documents that mention
"superelevation." This
system would, of course, know a little bit about the domain of
its search so it wouldn't
try to search the entire Internet, for example, for
''superelevation" unless we insist.
A well-crafted, attribute-based retrieval system would also
enable the user to browse
by synonym or related topics or by assigning attributes to
individual documents. The
user can then & dynamically define sets of documents having
these overlapping
attributes. For example, imagine a consulting business where
each potential client is
sent a proposal letter. Each of these letters is different and
is naturally grouped with
the files pertinent to that client. However, there is a definite
relationship between each
of these letters because they all serve the same function:
proposing a business
relationship. It would be very convenient if a user could find
and gather up all such
proposal letters while allowing each one to retain its
uniqueness and association with
its particular client. A file system based on place —on its
single storage location —
must of necessity store each document by a single attribute
rather than multiple
characteristics.
The system can learn a lot about each document just by keeping
its eyes and ears
open. If the attribute based retrieval system remembers some of
this information,
much of the setup burden on the user is made unnecessary. The
program could, for
example, easily remember such things as:
. The program that
created the document
. The type of
document: words, numbers, tables, graphics
. The program that
last opened the document.
. If the document is
exceptionally large or small
. If the document has
been untouched for a long time
. The length of time
the document was last open
. The amount of
information that was added or deleted during the last edit
. Whether or not the
document has been edited by more than one type of program
. Whether the
document contains embedded objects from other programs
. If the document was
created from scratch or cloned from another
. If the document is
frequently edited
. If the document is
frequently viewed but rarely edited
. Whether the
document has been printed and where
. How often the
document has been printed, and whether changes were made to it
each time immediately before printing
. Whether the
document has been faxed and to whom
. Whether the
document has been e-mailed and to whom
The retrieval system could find documents for the user based on
these facts without the
user ever having to explicitly record anything in advance. Can
you think of other useful
attributes the system might remember?
One product on the market provides much of this functionality
for Windows. Enfish
Corporation sells a suite of personal and enterprise products
that dynamically and
invisibly create an index of information on your computer
system, across a LAN if
you desire it (the Professional version), and even across the
Web. It tracks documents,
bookmarks, contacts, and e-mails — extracting all the reasonable
attributes. It also
provides powerful sorting and filtering capability. It is truly
a remarkable set of
products. We should all learn from the Enfish example.
There is nothing wrong with the disk file storage systems that
we have created for
ourselves. The only problem is that we have failed to create
adequate disk file
retrieval systems. Instead, we hand the user the storage system
and call it a retrieval
system. This is like handing him a bag of groceries and calling
it a gourmet dinner.
There is no reason to change our file storage systems. The Unix
model is fine. Our
programs can easily remember the names and locations of the
files they have worked
on, so they aren't the ones who need a retrieval system: It's
for us human users. |
|
|
|
|