11 The Subjective Project Classification Principle

Information items seldom exist in isolation. Usually, when we work on a document or presentation, we need to discuss it over email with collaborators, maybe basing its contents on data from a website that we have bookmarked. It is imperative when working on each information item that such related materials are easily retrieved and viewed together (Dumais et al. 2003). It has been repeatedly observed that users experience problems in integrating information that relates to a common project, because that information is scattered across different applications or folders (Balakrishnan, Matthews, and Moran 2010; Yarosh et al. 2009; Bergman, Beyth-Marom, and Nachmias 2006; Kaptelinin 2003). Take Jane, for example, a chemistry student who has a Chemistry folder in each of three format-dependent hierarchies (documents, emails, and favorites). Her chemistry project is fragmented between these three collections. When she works on chemistry, she needs to navigate among these separate folders, and doing so can be quite onerous (see figure 11.1). We describe this problematic situation as the project fragmentation problem (Bergman, Beyth-Marom, and Nachmias 2006). Project fragmentation occurs when a user who is working on a single project stores information items relating to that project in

separate, format-related collections from which he or she also retrieves them.

The subjective project classification principle addresses this problem, specifying PIM designs that allow users to straightforwardly store related information items together regardless of application or format. Other work observes that items in PIM are often classified under the projects¹Close that the users are involved in (Jones, Phuwanartnurak, et al. 2005). Project is a subjective attribute of an information item chosen by the PIM user, and thus the same information item might be classified under different projects for different users. For example, a person attending a conference might classify the URL of the conference hotel in a folder with the conference name within her web favorites, but the same URL could be placed in a Honeymoon folder by a future bride planning to visit the hotel for during her honeymoon.

The subjective project classification principle states that designs should allow all information items related to the same project to be classified under the same category regardless of their technological format. Although project-based classification has been encouraged in experimental systems (Bellotti and Smith 2000; Dourish et al. 1999; Freeman and Gelernter 1996; Jones, Munat, and Bruce 2005; Kaptelinin 2003; Karger and Quan 2004; Boardman 2004), current PIM system designs discourage such classification (Boardman, Spence, and Sasse 2003). Instead, current systems encourage users to classify their information items according to projects—but within their format-related hierarchy. The result is fragmentation: documents relating to a given project are stored in one folder hierarchy (e.g., in My Documents), emails in a separate mailbox hierarchy, and favorite websites in yet another browser-related hierarchy (these will be referred to as the three hierarchies). The only exception to this fragmentation problem in current PIM systems design is in the case of documents, in which all different formats of documents (e.g., Word, Excel, and PowerPoint documents) can be classified in the same file hierarchy.

Observations of user behaviors provide motivation for the project principle. Bergman, Beyth-Marom, and Nachmias (2006, 2008) explored the use of the project attribute in current PIM systems. We found that personal computer users tend to refer to their information items according to the project the items are associated with rather than in terms of their formats. Although users often concurrently use different information-item formats (documents, email, and web favorites) while working on a project, they nevertheless usually save these items into the three separate, format-related hierarchies. Occasionally, the folders in which those common items are stored (in the different hierarchies) are named consistently according to the relevant project (Boardman, Spence, and Sasse 2003; Jones, Karger, et al. 2005). However, consistent naming by project is the exception and not the rule. Bergman, Beyth-Marom, and Nachmias (2006) also found that when the interface design encourages it, personal computer users will store project-related information items of different formats in one project folder and retrieve them together from that location. However, when the design does not encourage it, users store project-related information items in the three hierarchies.

To address project fragmentation and to implement the subjective project classification design principle, we propose the single hierarchy solution, in which all project-related information items are stored in the same folder regardless of format (Bergman, Beyth-Marom, and Nachmias 2006) by combining the three hierarchies into a single folder hierarchy. One possible implementation of the single hierarchy solution is Project-Folders, which has been designed but not yet implemented or evaluated.

The ProjectFolders system design is an instantiation of the project classification principle. It allows a user to store all project-related documents, emails, and web favorites as well as related tasks and contacts in a single folder, separated by tabs. This allows users to work in the context of their projects and retrieve all project-related items from a single location. Figure 11.2 shows a concept illustration of ProjectFolders as envisioned when users open a folder via Finder or Windows Explorer. When opening an application, only related information items will be presented (emails for the mailbox and favorite websites for the browser). Note that this solution does not require or even advise

the unification of different PIM applications, only their default storage locations.

We are not alone in addressing this problem, and we will now review prior solutions. Early attempts to address project fragmentation can be divided into two categories: integration through search and integration through an additional structure distinct from existing format-dependent hierarchies.

Several search tools address the project fragmentation problem by enabling users to search for items related to the same project in the context of a single query, regardless of format. Such tools include SIS (Dumais et al. 2003), Lifestreams (Fertig, Freeman, and Gelernter 1996b), and Presto (Dourish et al. 1999). Query results are presented in a single context, allowing a user to see all documents within a project. This approach is now implemented in both Mac OS X and Windows search engines. The ability to search across multiple formats is certainly a positive feature of search tools, but the effect on the fragmentation problem might be limited. As we indicated in chapter 5, users prefer navigation to search and use search only as a last resort. Another limitation of the search approach relates to the accuracy of desktop search, which often returns items that are only tenuously related to the original query. Such marginally related items may compromise the benefits of project-based search by introducing irrelevant or distracting content.

Additional structure tools allow a user to create projects in an additional structure distinct from the three hierarchies. Several experimental systems employ this strategy, such as Raton Laveur (Bellotti and Smith 2000), UMEA (Kaptelinin 2003), TaskTracer (Dragunov et al. 2005), and SWISH (Oliver et al. 2006), as well as commercial software such as OneNote, Snippets, and DragStrip. Although the additional structure solution allows users to work in an integrated project environment, it requires managing yet another structure and may increase cognitive complexity. As well as the additional requirement to create a new structure, the user now has yet another retrieval location to maintain and remember.²Close

Integrated search and additional structure approaches both assume that project fragmentation is inevitable. In contrast, ProjectFolders addresses the problem by avoiding fragmentation in the first place. Some may consider ProjectFolders a radical solution because it unites information items of different applications (file browser, email, and web browser). Moreover, it requires users to change their storage habits. However, interface design often dictates users’ preferences and strategies, so changing the interface may change user behavior and improve usability (Shneiderman and Plaisant 2010). For example, in the early 1990s, each document application suggested a separate storage location; for example, WordStar documents were stored in a separate location from Lotus Notes files, and Photoshop files were in yet another place. This led users to follow these defaults by storing application files in different locations. However, now that current systems offer a single storage location for all documents (e.g., My Documents), users tend to store project-related documents of different formats in the same folders, as indicated by our data (Bergman, Beyth-Marom, and Nachmias 2006). Thus, the ProjectFolders design may lead to a similar change for all project-related information items.

Our data show that users tend to think about their information items in terms of projects. They simultaneously retrieve information items of different formats when working on the same project and store files of different formats together according to projects when the system design allows them to. However, current system designs discourage users from storing emails and web favorites with files, so people currently store these items in separate folder hierarchies. Following the subjective project principle, we address project fragmentation by proposing a single hierarchy solution in which all project-related information items are stored in the same folder hierarchy regardless of format, so files, emails, web favorites, tasks, and contacts are stored together and separated by tabs. In future research, we hope to develop ProjectFolders to evaluate the single hierarchy solution.