The most common misunderstanding regarding this work is the impression that
VisualIDs are intended to be a long-term and exclusive file identifier,
something that can be remembered months or years later and without
relying on other evidence such as filenames and dates.
On the contrary the studies validate VisualIDs for accelerating active
short-term file search and memory. (In fact
filenames are also probably most useful for short-term access
and do not serve in the supposed role of a long-term identifier --
do people really remember filenames months or years after last
seeing them?).
Some other comments and objections are:
Aren't meaningful icons better than arbitrary ones?
Why not use content analysis to automatically make meaningful icons?
Why not just use a file search dialog?
Why not just have people assign their own icons?
Is this really worth it?
Filenames are a more exact identifier than these vague "doodles".
I can't possibly remember icons for all my files.
These large icons take room away from displaying the actual content.
When will this be available?
What are the limitations of this approach?
Aren't meaningful icons
(such as an image of a postal box to represent your mail)
better than these abstract ones?
Yes, no argument. Such "meaningful"
icons require no learning on the part of the user.
However, meaningful icons can only be created for a small
fraction of all files. There are more files for which
there is no obvious choice for a meaningful icon, and in many cases it
is not worth the time to have an artist create such an icon
even if there was an obvious choice.
A major principle underlying this work is that,
while "meaningful" icons would be ideal,
people actually have little trouble learning to recognize arbitrary icons
and their relationship to content. Learning and recognizing
somewhat arbitrary appearance and associated information is something
that is often done instantly and effortlessly in the real world,
and learning icon appearance does not appear to be an exception
to this phenomenon.
Consider the example of finding your way
to a new restaurant. The amount of information involved
is actually considerable (a number of different street intersections
and other landmarks; each intersection has buildings or other
objects with their associated size, color, etc.).
But one or two trips suffice for most people to learn
this information---it's not something that requires a training course
and at-home study. To clarify, note that the relationship
of the landmarks to the restaurant is frequently arbitrary,
as is the case with our icons. You cannot find the Italian restaurants
in town by looking for a series of intersections that remind you
of Italy, or by looking for any other correlated set
of scenery. Refer to the studies for evidence that
people have little difficulty learning the appearance and
associated content with arbitrary icons.
Why not use content analysis to automatically make meaningful icons?
Some people have suggested to us that automatic content identification
might allow the creation of meaningful icons for all files.
This initially seems like a great idea, however
on deeper examination there are a couple issues that prevent it
from working in all cases:
What should happen if the file content is changing?
Files that are actively being worked on are arguably
the ones that are most in need good identifiers such as icons.
But if the icon changes as the content changes, then it becomes
much harder to recognize the file.
If the icon does not change, then it no longer correctly
reflects the file content.
More importantly,
what is really desired is not content at all,
but rather meaning.
For example, a journalist might save an article on the war,
not for its subject, but because it has a particularly interesting
(or bad) writing example, or because the article itself is written
by a potential romantic interest (or for any of thousands of other
reasons).
This article should then be filed under "writing" or even "romance"
rather than "war". Clearly content analysis would not discover this.
Why not just use a file search dialog?
Searching by content has good uses,
but it is faster to just scan filenames when you know
the file is already in front of you somewhere.
Scanning Visualids would be faster still.
Computer work frequently involve repeatedly accessing various
files or other data objects from a particular project.
In such work, the sought file is often one of a number that
are already visible.
You could use a search dialog to call up particular files.
But it is probably faster to just scan filenames (requires roughly
400 msec. per filename in the cited Byrne study).
It would be faster still to scan the visualids.
The principle is similar to switching programs in using
the operating system taskbar -- it is easier and faster
to scan icons than to read names.
VisualIDs may also help in some cases when revisiting
data after some time. It is possible (and arguably likely)
that memory for the visualid of a frequently viewed file
will be stronger than memory for its name.
If the visualID is remembered, it may be faster to scan for it
than to call up a search dialog and think of terms that would
distinguish the particular file from others.
Even if a search dialog is used, the visualID may
help in scanning the results if there are multiple matches.
Of course the visualID may not be remembered. If so, nothing
is lost -- VisualIDs just give one additional clue to remembering
and recognizing data.
Assigning custom icons is possible already (and has been so
for more than a decade in at least one operating system).
Why not just have people assign their own icons?
Some people do assign custom icons to a handful of their most
important files. On the other hand, no one takes the time
to assign a custom icon to every file they create,
and average computer users may not know how to assign icons.
On the other hand, the act of assigning an icon will
lead to better memory of that icon, and will likely
result in a more appealing icon as well.
Thus, we encourage people to replace the visualID with their own icons.
VisualIDs are merely an automatically generated default appearance,
to be used for the the many files that people do not have the
time or knowledge to customize.
Is this really worth it?
We show strong effects relative to finding files by name only.
Although the absolute costs for a single file are generally small
either with or without visualIDs, Nielsen notes that
even small effects become significant when multiplied across
millions of users (and thousands of files per user).
Filenames are a more exact identifier than these vague "doodles".
Yes.
First let us state that a VisualID should be used
in addition to the file name, rather than as a replacement
for the name. We expect the additional information will only help.
Certainly the file name is in some way a more "exact" identifier
than a picture. However, psychological evidence indicates
that people are better at searching and remembering appearance
than we are at finding and remembering names.
You've seen this yourself: when you scan the bookcase for
a particular book, you're generally looking for it by appearance,
rather than by scanning the title of each and every book.
And, you've probably said something like
"that white compiler book" plenty of times -- appearance is
more robust than names.
Consider a scenario where you resume working on a project
from last year. Probably you have forgotten many of the filenames,
though you might remember a few visualids. Quite possibly
even the contents of some files have been forgotten.
After working on the project for a bit, you've re-learned
the files, their names, and their visualids.
In the course of the day you need to repeatedly open particular files.
Scanning the folder for a distinctive visualID will be faster and
less effortful than scanning filenames.
I can't possibly remember the visualIDs for all my files.
Certainly, but you probably can't remember the names of all your files
either...and you don't need to.
In order to work efficiently we need to remember the identifiers
(whether name or visualid) for a good fraction of the files
we are working on.
In a survey of 15 computer users (mostly students, but several
other professions were included) people estimated
that they worked with between 8-100 unique files per day.
It is known that people can recognize members of a set of several thousand
images after only limited exposure and no study,
so these numbers (8-100) may be well within what is easily learned.
It should be pointed out that learning an identifier
(with its associated content)
is a different thing than simply recognizing an image.
Further work is needed here.
Nevertheless, our ability to effortlessly learn the appearance
and identity of the thousands of objects and places that we encounter in daily
life strongly suggests that learning the appearance of a small number
of files is possible, and even easy.
Survey acknowledgment: Hea-Juen Hwang
These large icons take room away from displaying the actual content.
While the algorithm can be adjusted to produce large and very detailed icons,
the user studies used 64x64 icons;
see the supplementary material for screenshots.
We show that
if all other things are equal
(text label, spacing, etc.), including icon size,
people perform better if the icon is distinctive than if it is generic
|
(and also show how distinctive icons can be generated automatically).
When will this be available?
It might seem that VisualIDs could only be implemented by
an Apple or Microsoft (or the Linux community).
Although it would be great for one of the OS vendors to take the lead,
a more gradual introduction of scenery is also possible.
Individual software vendors could implement a visualID system
for their data icons (both files and other types of data),
as a competitive feature.
Regardless, we expect that the idea that GUI scenery is lacking and needed
will become known in the community and this idea will influence interfaces
in various ways, small and (perhaps) large.
What are the limitations of this approach?
Actually no one asked this yet, but it's a chance to qualify the work.
On the positive side, visualIDs can coexist with the existing
interface (filenames, find-by-date views, etc.), so nothing is lost.
On the other hand, we do not believe that the icon-generation
algorithm shown is the only approach to this problem,
and further work is needed both to identify other appearance-generating
approaches and learn how to best evaluate their effectiveness.
Further, the icons generated with this algorithm are fairly
"chaotic", and some people may not like this aesthetic.
additional FAQs are found in the supplementary pdf
|