VisualIDs: FAQ




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