Core to designing a successful SharePoint Server 2007 deployment, and one that will be readily adopted by your customer base, is factoring in the organization, or categorization, of your content and deciding how people will find that content. For instance, will you structure the design of your SharePoint sites on your company's organization chart, such as creating sites based on Department or Office location? Or will you structure it based on your company's products or product groups? Happily, with SharePoint Server 2007, you can build multiple, dissimilar taxonomies in the same interface so that users have a choice as to how they find information.
This section will help you to understand taxonomies and adoption of taxonomies for Web-site design, and it will provide some considerations for implementing taxonomies in SharePoint Server 2007.
Taxonomy is effectively an information architecture that defines how you categorize or group content and metadata into a logical and easily identifiable structure for your target audience. Taxonomy architectures are important in designing taxonomies that have the following characteristics:
Are suited to their intended purpose
Can be maintained over time
Provide strong application support to information applications in the new challenging Web environment
Taxonomy can be summarized by the following formula:
architecture + application + usability
There are four types of taxonomies:
You can encounter problems when creating a taxonomy if you fail to identify which type of taxonomy should be used before the taxonomy is developed.
Flat taxonomies are merely a listing of items. They are best suited for 30 or fewer objects and do not require a complex design. More than 30 objects can be presented in a flat taxonomy, but only if the list items are intuitive to the users of the taxonomy. Flat taxonomies have the following characteristics:
They group content into a controlled set of categories.
There is no inherent relationship among the categories; they are equal groups with labels.
The structure is one of membership in the taxonomy and can include the following:
Alphabetical lists of people
Lists of countries or states
Lists of currencies
List of security classification values
An example of a flat taxonomy would include an eCommerce site with a pull-down list of product categories and horizontal list of stores. In SharePoint, flat taxonomies are best for simple lists of items that don't need to be nested. The items can be links to sites or lists or libraries. Also, if you have a flat taxonomy that has large list of content items in a list, such as a large list of documents, you can use the filtering capabilities in custom views of the lists to ensure that users can find the content items they are looking for quickly. Finally, the filtering Web Parts can be used to help build a limited but flat view of a large list of items.
A hierarchical taxonomy is represented as a tree architecture. The tree consists of nodes and links. The relationship between two linked nodes (the way they are associated with each other) will be based on meanings. The meanings define the hierarchical link depending on which direction you are going. For example, with Refrigerated>Drinks>Juice>Orange, the meaning of the link between Refrigerated and Drinks is drinks stored in the refrigerated section. Meanings in a hierarchy are limited in scope-for example, to group membership or type. In a hierarchical taxonomy, a node can have only one parent.
Hierarchical taxonomies have the following characteristics:
Hierarchical taxonomies structure content into at least two levels.
Hierarchies are bidirectional.
Each direction has meaning.
Moving up the hierarchy means expanding the category or concept.
Moving down the hierarchy means refining the category or concept.
An example of a hierarchical taxonomy would be a Web site which includes a Web Site Directory categorized by subject hierarchy. In SharePoint, every site collection's Web structure is a hierarchical structure. In addition, this type of taxonomy is well suited for finding sites via your organizational chart, because those charts are hierarchical in nature and list key individuals and divisions or departments within the hierarchy.
There is more than one way to implement a hierarchical taxonomy in SharePoint Server 2007. For example, you can progressively disclose layers of the taxonomy across sites or pages. You can use cascading or expanding menus to present a hierarchical taxonomy. Or you can use category and subcategory labels in a multicolumn display. The Sites Directory is well suited for building nested, hierarchical lists.
Bear in mind that hierarchical taxonomies should have content at every level. Empty levels mean nothing to the end user. In addition, each level should have a clear and unam-biguous reason for existing in the hierarchy. Each level should be related to the parent and child levels in clear, obvious ways. Best practice is to stay away from hierarchies that are more than four levels deep.
Network taxonomy is a plex architecture. Each node can have more than one parent. Any item in a plex structure can be linked to any other item. In plex structures, links can be meaningful and weighted differently (meaning that their relative importance varies from link to link). You can think of this as a modified mesh topology, in which the relationships within the nodes of the taxonomy are different, both in weight and quality.
Network taxonomies have the following characteristics:
They organize content into both hierarchical and associative categories.
They combine hierarchy and star architectures.
Any two nodes in a network taxonomy can be linked.
Categories or concepts are linked to one another based on the nature of their associations.
Links can have more complex meanings than you find in hierarchical taxonomies.
Examples of network taxonomies include the following:
Knowledge maps and knowledge representations
In SharePoint Server 2007, you can use the thesaurus to build expansion and replacement sets for query terms, as well as creating "dotted lines" between content items that appear in different layers of different, dissimilar hierarchical taxonomies.
A faceted taxonomy looks like a plant start, where each leaf node is connected to the center node. A faceted taxonomy must be suited to its purpose, and the facets must be needed in the taxonomy. Each facet should have a distinct behavior or reason for existing. In addition, each facet should have a clear relationship to the central object around which the taxonomy is being built. Most faceted taxonomies, when explicitly presented, are built using a records or table format.
Faceted taxonomies have the following characteristics:
Facets can describe a property or value.
Facets can represent different views or aspects of a single topic.
The contents of each attribute can have other kinds of taxonomies associated with them.
Facets are attributes, and their values are called facet values.
Meaning in the structure derives from the association of the categories to the object or primary topic.
For example, Metadata is one type of facet in a faceted taxonomy. Consider that the following list can be metadata about a single object type:
An example of a faceted taxonomy includes the Universal Description, Discovery & Integration of Business (UDDI), which you can find out more about at http://www.uddi.org. In SharePoint, every time we associate metadata with a content item, we're building a faceted taxonomy.
Building taxonomy is hard work and is more art than science. Experts say you should start with a well-thought-out blueprint that allows you to map out how you'd like your taxonomy to look. Keep in mind the following elements when designing a taxonomy:
Users want options, but not complexity.
The quality of metadata affects the quality of the taxonomy; ensure that you're using metadata that is rich and accurate.
Scalability means that the quality of the metadata must increase as the taxonomy scales into millions of represented objects.
Consistency of metadata is achieved better programmatically than by human intervention.
Persistency of metadata is foundational to building a taxonomy that will persist over time.
Enterprise taxonomies must take the following into account:
Content types and locations
A key factor in planning a successful taxonomy is the methodology you employ, which must be the most effective model and structure for your design. To avoid inheriting a singular view of content and deploying a Web site structure that falls well short of meeting your navigational needs, consider using some of the proven methodologies to determine your content structure. Two such methodologies include card sorting and Unified Modeling Language (UML).
Card sorting will help to identify taxonomies through user involvement. Users will be asked to place cards into the most relevant categories, or the best fit. For instance, you might create a primary set of cards that represents a suggested top-level navigational hierarchy and then have users place cards, representing subsequent hierarchical items, into those primary categories. From this, you'll be able to determine your secondary categories, tertiary categories, and so on, until all the cards can be matched against a category. This will often result in items being placed in more than one parent category or in using a category as both a primary and secondary category. This setup is shown in Table 8-1, where Drinks is a primary category but is also a secondary category to the primary category Refrigerated.
UML helps to identify taxonomies by placing actors in scenarios to determine how the actors interact with and navigate throughout a system. There are many papers available detailing UML methodologies.
Resources for Planning and Developing Taxonomies
The following references may prove useful in planning and developing your Web site taxonomy:
SharePoint Server 2007 includes a wealth of possibilities for structuring content and navigating throughout sites. Unlike its predecessor, SharePoint Portal Server 2003, SharePoint Server 2007 by default offers flexible navigational options, including the option to include tree view navigation throughout your sites. Figure 8-1 shows an example of tree view navigation in a SharePoint site's navigation.
Figure 8-1: SharePoint Server 2007 tree view navigation
Another new navigational feature in SharePoint Server 2007 is the ability to edit the subsite navigational items through in-place editing via the user interface. This includes the ability to update item titles, links and audiencing on menu items. Figure 8-2 shows the navigational editing and sorting editor for the Fabrikam site.
Figure 8-2: Navigational editing and sorting editor shown in user interface
Reciprocal navigation is offered through bread crumb navigation and is enhanced with the option to include the parent site tabbed navigation within sub sites, or throughout site collections. Where personalization is enabled, users will easily be able to navigate to their member sites through the My Links link in the personalization tier of navigation, which remains constant throughout site collections.
Figure 8-3 highlights the Home page of the Fabrikam site, which includes horizontal tabbed navigation from the parent site, vertical navigation, representative of the items within the Fabrikam site, and breadcrumb navigational path.
Figure 8-3: Home page navigational options
SharePoint Server 2007 also includes a customizable Site Directory where you can create and categorize sites. By default, Site Directory includes the categories Division, Tasks and Tools, and Region. But you can edit, or remove, these default categories and add your own categories to better match your business needs.
When you create a site from the Site Directory's Create Site link, you have the choice of associating that site with one or more categories, at the time of creating that site. You can also add links to existing sites and associate those sites with one or more categories. Figure 8-4 shows the default Home page of the Site Directory. An additional category, Global Projects, has been included.
Figure 8-4: Default Home page of the Site Directory
Additionally, the Site Directory includes an option to list sites as Top Sites. For instance, you can nominate sites listed in the Site Directory to be included under Top Sites by selecting the Top Sites check box when adding sites to the Site Directory. The Site Directory also includes a configurable Site Map. Figure 8-5 shows a site map configured to display sites at the existing level, but you could have sites displayed three levels deep.
Figure 8-5: Site map
Navigation is one mode by which users will find content, and we've just provided an overview on how you can effect site level navigation using some of the built-in functionality offered through the user interface. Second to navigation, users will choose to locate content by using search. Using content types, you can define the metadata throughout your sites, site collections and lists. Designing effective metadata and leveraging metadata in your search means you can more granularly define search queries and search scopes. For more information on content types and metadata, including instructions on how you can use content types to enhance search, see Chapter 15, "Managing Content Types."
Real World Designing your SharePoint Taxonomy
Remember, that in designing your SharePoint Server 2007 taxonomy, you still need to consider the fundamentals of Web site design and plan on designing your SharePoint Server 2007 structure before going ahead with the implementation-don't assume that by simply implementing Office SharePoint Server 2007, your design needs will be met!
As a guide, you should consider reviewing and addressing the following during design phase:
Existing business processes
How employees currently store their documents
Types of documents
Existing naming conventions
Presence of backend systems for integration
Most importantly, you should involve your users, or customers, in the design phase to ensure that navigational needs are addressed and to also to avoid unnecessary duplication. For example, a customer may cite a requirement for a knowledgebase for one group and an additional knowledgebase for another group, when in fact you may, through working with the customer and explaining options available within SharePoint Server 2007, discover that the knowledgebase needs to be a shared entity.
Workable taxonomy is a blend of communication and pre-deployment design. If you are planning for a large SharePoint Server 2007 deployment, you may also consider hiring an Information Architect to help structure your design.
Following are limitations to consider when designing your taxonomy:
10,000,000 items in a library
100,000,000 items per search indexer
2000 sites per site collection
2000 lists per site
2000 items per folder
2000 items per view (after indexed filtering)