Information Organization

In traditional file systems, users organize information by using folders and descriptive file names. Folders and file names must accommodate all the possible reasons that one would separate, categorize, secure, or enforce business policy on various types of information. This type of folder structure can result in folder proliferation and arbitrary, subjective nesting of subfolders. At the same time, the file system offers few, if any, mechanisms to locate information within an ever-expanding folder tree, and few built-in clues as to the content or purpose of documents after they are found.

Figure 9.1. Traditional folders: single axis of organization

SharePoint Portal Server provides a richer set of tools for organizing your information. Instead of the single axis of organization represented by traditional folders, illustrated in figure 9.1, SharePoint Portal Server offers the following three axes:

• Folders
• Properties and document profiles
• Categories

Each of these axes, shown in Figure 9.2, enhances the overall view of information within the workspace. Each provides a different benefit to SharePoint Portal Server users.

Figure 9.2. SharePoint Portal Server: three axes of organization

Using Folders

Within SharePoint Portal Server, you can use folders to store documents, a very familiar concept. Because SharePoint Portal Server presents three axes of organization, folders need not proliferate to address every organizational need. In fact, minimizing the number of folders has its advantages for those who manage in addition to those who use the folder hierarchy. Very few instances require the creation of new folders. You can use folders to decide where a document is stored, and what policies apply to that document.

Folders are useful for

• Delegating management (coordination) of a subset of content in the workspace.
• Applying different security to a subset of content.
• Applying a different versioning choice to a subset of content.
• Excluding a subset of content from inclusion in an index.
• Avoiding redundancy in naming documents.

New SharePoint Portal Server users may feel most comfortable using folders because they represent a familiar organizational tool. However, folders need not carry the same overloading of purpose as traditional file system folders. In cases where none of the previous reasons applies, use of one of the other organizing tools can minimize the depth and expansion of the folder hierarchy, making folders easy to find and manage.

Users who create or import content into the workspace use folders most heavily. In order to store new documents in the workspace, a contributor must select a folder for that document. You should consider this when designing the structure of folders.

Adding Properties and Profiles

Properties store metadata, or information about content, in the workspace. Facts about a document such as who created it, how it is described, and which customer it pertains to are stored as properties of those documents. Each document in the workspace has its own set of properties associated with it. Properties help an organization define what information they know about a particular document.

You can designate properties as mandatory or optional. An author must supply a value for mandatory properties of a document before successfully publishing the document.

The use of properties enhances the ability to locate documents within the workspace. Within the detailed view of Microsoft Windows^® Explorer, properties head the columns. You can sort documents in a folder according to these properties.

Documents that have a related purpose often share a common set of properties. For example, the invitation to a meeting, its agenda, and its minutes all share common properties such as the meeting place, the time, and the list of attendees. A document profile is a named group of properties that you can apply to a document. Document profiles apply to documents with a common purpose, rather than a common file type or a common storage location. Coordinators select the list of profiles that are available for documents within a given folder, and users use that list to associate a specific document profile with a document. You can make a single document profile available simultaneously within any number of folders.

A coordinator designing the set of document profiles within a workspace must make trade-offs concerning profile sizes and the number of profiles per folder. Larger document profiles that have more properties, especially mandatory properties, provide richer information to locate and organize documents. However, very large document profiles burden users, making publishing troublesome and discouraging use of the workspace. The proper balance depends heavily on the culture of the organization, the type of users, the importance of the metadata, and other unique considerations.

Likewise, coordinators must determine how many document profiles to create in the workspace, and how many to make available within any given folder. A coordinator can create a large number of very specific document profiles. In this case, each document profile targets a particular purpose, simplifying the choice for authors who must select a document profile to apply to a document at the time of publishing. It is recommended that you keep the number of properties in each document profile low and primarily mandatory. However, authors would have to sort through a large list of document profiles to find the correct one when publishing content. Conversely, a coordinator can choose a smaller set or more broadly targeted document profiles, but this choice can expand the number of properties in each document profile, and force many of them to remain optional so that you can apply the document profile more flexibly to a broader set of documents. Users tend to ignore optional properties, which reduces the ability to locate content.

As a simple example, a coordinator might need to choose between creating Design Specification and Test Specification document profiles, each targeted to the particular function, or a single Specification document profile that serves both functions.

Creating Categories

Categories represent a subject matter view of content in the workspace. Like folders, the workspace features a hierarchy of categories. However, unlike its folder location, a document can be simultaneously placed in any number of categories. Categories help an organization identify what a document is about, and how a reader might search for it.

Categories stand completely independent of folders, properties, and profiles. All categories are available for tagging all documents in the workspace. As a result, the category hierarchy can aggregate content by subject matter regardless of its location inside (or outside) the workspace, providing the third axis of organization. Users performing searches also receive matching categories.

Just as you design a folder hierarchy with the needs of authors in mind, you design a workspace category hierarchy according to the needs of readers. Visitors to the workspace who are unfamiliar with the content or organization of the workspace can use categories to search for content. Because different readers approach searching differently, using multiple category tagging allows the coordinator to anticipate more than one way of searching for content, leading users to the most relevant documents through different paths.

Comparing Folders and Categories

When creating an initial set of workspace categories, some coordinators start by copying the folder hierarchy. Although this structure functions adequately, it fails to take the fullest advantage of SharePoint Portal Server. Search results match both folder and category names, so having folders and categories with the same name directs searchers to the same content and yields redundant search results. Instead of enhancing the ability to locate relevant content, such a category structure adds no value.

Coordinators should take advantage of the ability of categories to aggregate content across folders—a purpose quite different from that of folders. Categories free coordinators from the concerns about security policy that drive the folder layout, allowing a purer, subject-matter view of content in the workspace. In addition, coordinators should think about the diverse audiences that use folders and categories: folders primarily serve authors, while categories primarily serve readers, especially those unfamiliar with the structure and contents of the workspace.

Equating Folders and Properties

The expansion of folder names beyond the very short Microsoft MS-DOS^™–supported format has allowed those names to be more descriptive. This ability to describe the folder completely by using its name is a boon to an organization that uses a traditional file structure. By using SharePoint Portal Server terms, however, many such names contain information more appropriately stored as properties within the folder.

In addition to a folder name storing embedded properties, coordinators often rely on the relationship between parent folders and subfolders to store implicit information. By using SharePoint Portal Server, a user can capture this information as properties. For example, you may organize a database of actors' filmographies by actors' names, each containing subfolders for the decades of that actor's career. The fact that many actor folders contain subfolders called "1970s" causes no ambiguity due to the position of those subfolders beneath their parent folders.

In the previous example, the information presents a naturally hierarchical organization. Although you could find some value in having a folder for each decade, and the list of active actors below it, few people design a folder hierarchy in this manner. However, many folder hierarchies present no such clear choice. Consider a file share that holds documents concerning airplane parts that were used in particular aircraft in particular years. You could easily encounter either of the two folder organizations shown in Figure 9.3.

Figure 9.3. Two possible folder organizations

The traditional single axis of organization of a folder hierarchy forces the arrangement of folders that have no intrinsic hierarchical relationship. Because of this, either organizational structure has equal validity. In fact, the needs of a given user at a given time primarily determine the usefulness of each choice.

In SharePoint Portal Server, properties—rather than folders—contain information about content. SharePoint Portal Server can recognize that the name of the aircraft part and the year it was installed are in fact properties of the documents stored in the folders of this hierarchy. Because properties provide far richer search capabilities than folder names and relationships, you can make the best use of SharePoint Portal Server by extracting implicit properties and turning them into explicit ones. In fact, you can readily convert sets of folders into a smaller number of folders plus a set of properties and property values. This conversion retains all information in the original folder hierarchy and leaves fewer folders in the workspace, making it easier for authors to decide where content should be stored.

Revisiting the previous example, Figure 9.4 illustrates how you can represent the original 11 folders as a single folder, within which each document has two properties. The following method presents a systematic way to apply this principle to a full hierarchy, yielding a content organization better oriented for use in a workspace.

Figure 9.4. The new content organization