Information fragmentation is a pervasive problem in personal information management (PIM). Even a seemingly simple decision (such as whether to accept a dinner invitation) often depends on information from a number of sources, including calendars, paper flyers, Web sites, and email. That information may be fragmented by physical location and device. On a single device, it may be fragmented by the very tools that have been designed to help us manage it. Applications often store their data in their own particular locations and representations that are inaccessible to other applications.
Consider the information we might have concerning a friend named Jill. We keep her address in our address book, her picture in our photo album, her home page in our Web bookmarks, a document we are editing with her in our file system, and an appointment with her in our calendar. This fragmentation leads to problems using and updating information. There is no single directory we can go to for all this information about her; nor is there a way to “link” the various pieces of it to one another. Instead, we must launch multiple applications and perform numerous repetitive searches for relevant information, to say nothing of deciding which applications to look in. We may change data in one place (perhaps a new married name in the address book) and fail to change it elsewhere, leading to inconsistency that makes it even more difficult to find information; for example, which name should we use to search the photo album? If the computer is an unintended instrument of information fragmentation, it can also be used to help us put the pieces together again. Here, we survey some of the ways our personal information might be integrated more effectively. Some integrations follow from simple extensions to current applications; others depend on more fundamental changes in the way we represent and manipulate data.
We begin by outlining several existing unification strategies in PIM (see the table here). Each chooses some lowest common denominator of the information to be unified, ignoring many particulars of the data in each application. Using a common denominator is, however, in tension with each application’s need for rich, specialized representations of its content. Rich representations let applications deliver powerful domain-specific operations. To compensate, a shared representation may let applications interact with information from outside their domains, perhaps in ways that increase the application’s utility. The trade-off is that a simplified shared representation lets tools interact in a unified fashion with data from many applications without their having to understand too many rich representations.
Perhaps the most universal and shallow unification takes place at the display. In today’s GUI environments, nearly every application launches a window to display its information. Relying on only this common representation, users resize, move, hide, and reveal different information objects, regardless of what they are or which applications manage them. Bringing up several application windows at once lets us view several information objects simultaneously to seek and find patterns among (and connections between) the items in view.
Unfortunately, windows can also cause problems of display management. The items we are interested in (such as documents, email messages, Web pages, and addresses) are presented in large windows with attendant menus, toolbars, jumping-off points, and default presentations. When we want information from multiple applications, each one needs a separate window. A common consequence is window clutter—a display filled with windows obscuring one another, all competing for our attention. A tool called WinCuts [10] aims to alleviate this clutter, letting users “cut out” small pieces of an application window and close the rest, so only the parts they care about remain in view.
Display-level unification, no matter how accomplished, also has significant limitations. Since the underlying data is not unified, there is no way to pass data from one application to another or to create machine-usable linkages or shared organization structures among data from multiple applications. The unification offered by simultaneous display is ephemeral, vanishing when the system shuts down. The fact that one can display information about a person in an address book and, at the same time, a photo of the same person in a photo album offers no guarantee that one will be able to use either application to permanently associate the person’s contact information with her photo.
Text represents a powerful least common denominator, since most applications manage data that is at least partially textual. The standardized cut-and-paste facility provides an easy way to move data from one application to another and even between nominally incompatible applications. Unfortunately, textual cut and paste is “lossy,” so when we copy the name of a person from an address book, we get the text, but not necessarily the fact that it represents the person whose name was copied. This imperfect transfer leads to the kinds of information duplication and fragmentation discussed earlier.
The text in many applications can also be extracted and indexed by various desktop text-search engines (such as Google Desktop). These tools let users perform textual queries that find information regardless of which application owns it (see the article by Cutrell et al. in this section).
A central activity in information management is the grouping of related items. Grouping would seem easy to support in an application-independent, unified manner because a group is defined by referencing the items in it. Thus, the only required common denominator among applications is a shared naming scheme for all the items a user might want to group. For example, the fact that operating systems offer a common namespace for files means we can group files of arbitrary types into directories, regardless of which application created them.
Unfortunately, despite the fact that grouping depends on being able to refer to items by name, different applications insist on managing collections of their own information in their own “internal namespaces,” files go into file folders, email messages into email folders, Web references into bookmark folders accessed through Web browsers, and address book entries into address book folders. People rightly complain they have too many hierarchies to maintain [3, 5, 9]. When each application manages the grouping of its own data, these groups cannot be heterogeneous.
Metadata, or information about our information, is another important means of managing our information. Files have creators and creation dates; media files have genres, composers, and bit-rates; mail messages have recipients and subjects; and appointments have times and places. People often manage information by grouping or seeking items according to metadata attributes (such as sorting files by file type or locating a bookmark based on the time we visited the page). As with the creation and use of collections, there is no single, agreed-upon way of defining and using metadata. Thus, file creation times and creators are stored in the file system; email message creation times and creators are stored in email headers; and music composers and composition dates are stored in the ID3 tag headers of audio files. While the pervasiveness of metadata representations demonstrates the value of metadata, the fragmented formats generally mean a user must launch a specific application to annotate or search for a particular type of object. Until recently, even a simple task like “finding the stuff I created yesterday” required the launching of multiple applications. The recent crop of desktop search tools (such as Google Desktop and Yahoo Desktop) all attempt to extract metadata from different file formats to support integrated searching over that metadata, though they extract only a specific set of metadata from specific applications.
Users benefit from being able to orienteer from a document to one of its authors, to a photograph of that person, to a representation of the location where that photograph was taken, to a map of that location, and so on.
XML is an increasingly popular representation that may help unify the use of metadata. It offers a standard syntax for describing a series of attributes of a given object and values for each of the attributes. Whereas a traditional word processing program would store its documents as an opaque file, an XML representation can use the standard syntax to expose, as separate elements within the file, along with the creator(s) of the document, its title, its subject keywords, its citations, and its individual sections. Such a unified syntax for metadata representation would allow us to group or seek arbitrary information objects by shared metadata, regardless of their managing applications, much as we currently might group files independent of their managing applications.
Beyond grouping and metadata, a third use of references involves directly linking information objects together. Our interest in a piece of information is often focused on its connection to another piece of information. For example, we might want to know that a given individual is indeed the author of a given document or that a given email message is relevant to a particular appointment. Studies have shown that users prefer to find their information by “orienteering” [11]. That is, rather than jumping directly to needed information, they often start with a known object, then take repeated navigation steps to related objects, aiming to home in on the desired information.
The Web represents a successful application of this approach, defining a single, shared URL namespace that lets users name arbitrary Web objects. By placing references to these objects in other Web pages, authors let users navigate smoothly from object to related object. Highlighting the fact that only shared names are required, Web pages can even refer to objects a Web browser could not interpret; this failure becomes apparent only if the user chooses to navigate to the named object.
As with grouping and annotation, linking requires only a shared namespace with which to name the linked objects and a common syntax for describing the relationship between them. Again, we are often stymied by the lack of a common scheme. Users sometimes attempt to effect linkages by recording cross-references in various comment fields; however, the fact that these links can be interpreted only by the user, not the application, means that link traversal becomes a laborious task involving searches in other applications, and that inconsistencies can arise at the two ends of a link.
As XML was for metadata, the resource description framework (RDF) is an emerging Web standard for recording arbitrary relationships between arbitrary information objects. It offers a simple model in which pairs of items, each named with a URI, can be linked using an arbitrary predicate (relation) also represented with a URI. The RDF-XML standard defines a syntax for recording collections of these relationships in XML.
Looking Ahead
The article by Whittaker et al. in this section describes what the authors term an “email imperialism” approach that attempts to unify personal information through an expanded email client application. Here, we describe two additional approaches to unification. The first attempts to integrate personal information through modest extensions to existing applications (including the email client). The second approach seeks a more fundamental unification through underlying representations of data.
The Universal Labeler (UL) is a prototype effort in the Keeping Found Things Found project [6] at the University of Washington. Helping extend existing applications to support PIM, it is motivated by fieldwork observations that people invest considerable effort in organizing their information—particularly their file folders [2, 7]—and that they are reluctant to adopt new applications if they require the use of yet other ways to organize it or if they force them to abandon the work they’ve already invested in their current organization schemes.
The UL includes modules that work as add-ons and extensions to existing applications (such as a user’s file manager, email client, Web browser, or word processor). A guiding principle of the UL is that information management and task/project management represent two sides to the same coin. Moreover, given the right support for project planning and management, an integrative organization of information might emerge from the effort to plan a project and manage its tasks.
The UL’s Project Planner module allows users to begin working on a project (such as “house-remodel”) top-down by building an outline where major headings (such as “kitchen” and “media room”) represent high-level project components. Alternatively, users start bottom-up by typing in notes and gathering bits and pieces of information from Web pages, email messages, and e-documents through a drag-and-link operation. With drag-and-link, information is hyperlinked back to the source, so users drag only a small, key part of a larger document (such as an email message or Web page) with the assurance that more information is just a click away.
Over time, a basic plan emerges (such as the one in Figure 1)—essentially providing another view into a part of the user’s file folder hierarchy where headings are folders, subheadings are subfolders, and hyperlinks are shortcuts. Users switch to more conventional file folder views if they want. However, they may prefer to stay in the planner view for the rich-text, document-like features it provides. In addition to drag-and-link and the ability to type formatted notes, they can also order headings and subheadings in ways that help them make sense of a plan or see first things first—just as they might in a word processing application. Users can also create new email messages and new documents directly from a project plan, so the email or document is linked to an appropriate task heading (and its underlying folder).
Behind the scenes, the Planner supports its more document-like outline view by distributing XML fragments as hidden files, one per file folder that contain information concerning notes, links, and ordering for the folder. This approach is also used to support other views as well, including a table view, where two levels of a hierarchy (such as students and assignments) are displayed in a single tabular format.
The Haystack project [8] aims to provide a unified data environment from the ground up, creating a uniform namespace for referring to all individual information objects, so they can be grouped, annotated, and linked however the end user might want. For example, people are a data type that appears in a variety of PIM applications that manage their relationships to email messages (as senders in an email application), to music (as composers in a jukebox application), and to appointments (as people to meet in a calendar application). Some users (such as in the entertainment industry) may find that these sets of people overlap. It is therefore worth treating individuals as first-class information objects that are themselves annotated, organized, and linked.
The only real prerequisite for such an approach is the need to give each information object a unique identifying name. Haystack uses RDF, the emerging Web standard model for naming information objects and recording relationships about them. In the Haystack data model, a typical application file is shredded into many individual information objects of various types that are connected through application-specific relationships.
The Haystack user interface (see Figure 2) assembles the objects into traditional-looking information displays (such as an email client or address book). But the unified data model also means that arbitrary data can be assembled; for example, a user’s inbox might contain not just email but RSS news items and even people. Each item offers embedded checkboxes the user can tick to quickly place items into relevant collections. Since each information object in view is itself a distinct entity in the data model, the user can click on anything in view and immediately navigate to the clicked object in order to get more information about it. Moreover, the user can use context menus to invoke all relevant operations on an object any time it is in view, not just when it is being presented by a particular application.
Haystack gives users a Web-like navigation paradigm. By clicking on, say, the author of the message, a user navigates to a view of that author (constructed by looking up important objects related to that person and laying them out in the style of an address book). Users benefit by being able to orienteer from a document to one of its authors, to a photograph of that person, to a representation of the location where that photograph was taken, to a map of that location, and so on until they reach the information they are seeking. Similarly, users might use traditional drag-and-drop operations to create collections of related objects or create annotations to link information objects together.
Conclusion
Many technical challenges complicate our desire to unify our personal information; a good example is the effort required to disambiguate references. The same person can be referenced in many different ways, and, conversely, the same reference (“Jill”) might refer to any one of several people [4]. Moreover, with so many promising approaches to explore, we need ways to evaluate and compare them (see the article by Kelly in this section). User needs have driven several important but incomplete unification efforts based on least common denominators (such as windows, text, and references) that allow grouping, annotation, and linking of information. Better unification techniques promise to help improve personal information management in the future.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment