Essential SharePoint 2013: Practical Guidance for Meaningful Business Results (2014)
Part I. Planning
Chapter 6. Planning Your Information Architecture
One of the greatest strengths of SharePoint is the ease with which “regular” folks (i.e., non-IT people) can create incredibly sophisticated collaborative Web sites. Lots of them. With lots of content. As these Web sites start to acquire more content, it becomes very, very easy for small sites to grow into big messes—with usability and “findability” challenges, content management problems, and unhappy users and business sponsors. The information architecture (IA) for your SharePoint solution is the plan that helps you avoid the mess. It provides the structure and framework that help your users navigate and search to find what they need, complete the tasks they need to perform, and understand the context of information so that they can use it effectively.
Information architects create plans for Web sites much as architects create plans for new houses. They follow best practices and architecture design principles, but much of the work of the information architect is not an exact science. Just as an architect must accommodate your preference for a large family room in your new house and another client’s preference for a small family room with a large kitchen, information architects need to understand their users’ needs and preferences—and the kind of work that they do. Even more important, the information architect needs to understand whom the solution is for. In other words, it’s not just about the people who live in the home and bring in all the furnishings; it’s also about the visitors to the home, who may have different preferences and different needs.
Creating a good balance of experiences for both the owners and the visitors to a Web site is a particular challenge for information architects—and working hard to find the right balance for each site is what can make the difference between a SharePoint site that remains vibrant and adds value and one that gets stale and ignored.
The information architecture for the solutions you build with SharePoint includes the following:
Site architecture: the navigational structure of the solution. The site architecture is important because it defines how users will “browse” through the solution—how they will move from room to room.
Page architecture: the position of Web Parts and content on each page. The page architecture is important because consistency across similar pages helps users quickly find what they are looking for. In addition, placing the most important Web Parts in the most prominent and visible parts of the page ensures that users won’t miss important information. To continue our analogy, the page architecture defines what furniture is inside each room and how it is placed for ease of use.
Metadata architecture: the structure of the content within the solution. The metadata architecture is important because it attaches structure and meaning to all of the content in your solution. It defines the attributes that you will use to classify and organize your content in the same way a librarian uses classification terms like fiction or biography to organize (and find) content in a library. If all you knew about a book was its title, there would be only one way to organize books, and as your collection got bigger, it would be much harder to understand what you have and find similar books. The terms you use to classify your books represent the metadata about the books; the values and specific terms that you use depend on the type of your collection. For example, you would likely use different terms to describe your collection of scientific books from the ones you would use for your collection of science fiction books. This is one reason why you may find similar patterns for page and site architectures across different SharePoint solutions in different organizations, but you will rarely find identical metadata architectures, even in organizations in the same industry—because metadata terms are very closely related to the details of the domain of the collection and what the owner and consumers of the content need to know about it. In SharePoint terms, metadata architecture includes the content models that you will use (Content Types), the attributes for each content type (Columns), and the definition of which elements are shared on all sites and which are specific to just one site or list.
The metadata architecture is also important because it helps improve the search experience. The site architecture supports users who browse. The metadata architecture primarily supports users who search, but as you will see later, the metadata architecture also helps users browse for information in context because it allows you to add descriptive information about content that users can use to assess its value or filter and sort information in context.
If you get your information architecture right, your users will find that your solution is useful, valuable, accessible, and usable. If you get it wrong, you are likely to hear, “We put all our content in SharePoint and we still can’t find anything!” You may also hear, “Every time I land on a different page, I have to reorient myself because every page is organized completely differently, even when it presents similar content.” If you’ve heard either of these complaints as many times as we have, it is almost certain that the root cause of the problem is the information architecture—or lack thereof. Fixing a badly broken information architecture after the fact is a lot harder and more expensive than planning your IA up front. But don’t assume that information architecture is a “once and done” process. It’s unlikely that you’ll get your IA right the first time. It is especially important to have skilled information architects who have permanent roles in your center of excellence for SharePoint support. You want your solution to grow and change as your business and information evolve. Similarly, you want your information architecture to be adaptable and align with evolving business needs. Investing in information architecture helps ensure that your organization will get the most value from its information assets. The investment is certainly greatest in the planning phase, but it’s an investment worth nurturing as your solution matures to ensure that your content and valuable information assets remain current and “findable.”
Information architectures should be driven by purpose. A well-designed IA increases the likelihood that users will find what they are looking for with minimal “clicks.” An effective information architecture will assist users in understanding and interacting with the solution. Most important, the information architecture helps ensure that your organization can achieve the business value investment from SharePoint because a good information architecture ensures that users can both find and interact with the solution content.
Why Is Information Architecture Important?
SharePoint users expect intuitive navigation out of the box, but we often hear users complain, “It’s not intuitive” when they talk about their organization’s SharePoint solution. Most often, these users are not complaining about SharePoint as a platform; they are complaining about the way that their information architects have designed and implemented the sites they use. Investing in your information architecture helps
Improve user adoption. Well-organized content gets found, which helps users see the value of the solution and participate in the collaboration process.
Improve user satisfaction and productivity. When users can find what they are looking for, they are more productive.
Reduce IT costs. A good information architecture helps eliminate redundant content, thus reducing both storage and retrieval costs. Planning your information architecture may also help you identify redundant solutions (for example, two solutions for storing the same type of content), which can reduce both maintenance and support costs.
Reduce information overload. A good information architecture reduces information overload because it helps move the most relevant content to the top of search engine results, which means users can quickly get to the information they need.
Reduce compliance and bad information risk. When users clearly understand how content is organized, they don’t feel the need to store multiple “convenience” copies of the same document. Driving users to a single-source vetted document ensures that they will access accurate and timely content.
Your information architects need to understand how different audiences will navigate and search for information. The benefits of your SharePoint solution depend on how content is organized, labeled, and categorized. Your information architecture is thus critical to your solution’s success.
Understanding the Role of the Information Architect
A good information architect is well versed in the concepts and principles of information organization. We’ll provide a high-level overview of the most important concepts and some effective techniques in this chapter, but reading this chapter is not going to automatically turn you into an information architect. You will need to practice these skills in a variety of scenarios—and measure and evaluate the outcomes of various decisions—to be able to create solutions with effective organization, structure, and navigation. Additionally, a good information architect is also a business analyst—someone who can listen to, observe, and understand the needs of business users, both producers and consumers of information. An information architect cannot work alone; the information architect must work in partnership with the content or site owner and site users to iterate and validate the proposed structure and plan. Thus, information architecture is a team sport; the design process should be led by an experienced coach, but the coach needs a team—the users and sponsors of the solution.
Once the initial information architecture is created and tested, the ongoing role of the information architect depends on the type of solution being designed. Most organizations understand the need for a persistent information architect role for externally facing Web sites and large intranets. These highly visible sites impact a broad population of users, and the impact of a poor user experience can be costly in terms of lost revenue or compromised productivity on a large scale, so it’s easier to understand the value of the permanent role of an information architect, even though it might not be full-time. It’s a little harder to scale the same level of support for potentially hundreds or thousands of collaborative team sites.
We’ve found that in practice, it’s very difficult for a typical team site owner who only occasionally has to make changes to the structure of a collaboration site or has a new type of content and needs to decide whether to add a list, library, folder, Content Type, or Site Column to instinctively know the most effective approach from an information perspective. This is one of the reasons we made the recommendation for the evangelist and coach roles and center of excellence model in Chapter 4, “Planning for Business Governance.” While we definitely recommend training all site owners in basic information architecture principles, the practical reality is that information architecture is a skill that improves with practice, and you may find that your organization will get better outcomes by maintaining a central pool of information architects who can provide ongoing coaching and consultation to site owners who identify new information design challenges. If you can get your information architects to document the patterns they observe as they work with site owners over time, you can build best practices and models into your site templates or at least provide models that site owners can use if they encounter similar situations.
What’s New in SharePoint 2013?
SharePoint 2010 introduced several features that significantly improved the ability to manage and maintain a consistent information architecture. The most important of these features was the ability to store taxonomy structures centrally and reuse them on any site or site collection. The Content Type hub and managed metadata were really breakthrough features for information architects. SharePoint 2013 retains these breakthrough features and provides some evolutionary rather than revolutionary features to help with your information architecture design—with one exception: information architecture for search. Some of the key new IA features for SharePoint 2013 include the following:
New top navigation bar that provides persistent navigational links to the information users need the most. SharePoint 2013 has a new persistent navigation Suite Bar that shows links that are relevant to your access permissions. Figure 6-1 shows the new Suite Bar view for the administrator of an enterprise Office 365 deployment. The top navigation will show Admin only for the site administrator. Microsoft’s information architects have predefined what they consider to be the most important categories of navigational links for users: Outlook, Calendar, People, Newsfeed, SkyDrive, and Sites. These links are collectively known as the Suite Bar, and they provide a “superstructure” for your site architecture. (Depending on your Office 365/SharePoint Online plan and your on-premises environment, you may see only Newsfeed, SkyDrive, and Sites.)
Figure 6-1 Top navigational architecture for an Office 365 environment
Microsoft has issued guidelines for how to replace Newsfeed in the Suite Bar with Yammer in SharePoint Online, but for the most part, you cannot change the Suite Bar links in SharePoint Online. You can change these persistent navigational links in your on-premises environment (it’s not easy, but you can do it), but to ensure upgradability in the future, you should be intentional about changing the supersite architecture links provided natively in SharePoint. For the discussion in this chapter, we will assume that the Suite Bar is a predefined element of your navigational architecture and that you will use the Promoted Sites area of the Sites page to connect the “front door” to your major solutions in your environment (intranet and Internet home pages). Promoted Sites is a new centrally managed capability that allows you to promote links to different SharePoint sites to different users by leveraging SharePoint’s Target Audiences feature. Promoted Sites provide another element of your supersite architecture. In addition, individuals can create links to the sites they care about by following these sites, which automatically places them on their personal Sites page.
New Sites page to provide a single place to connect different portal environments. The Sites link on the Suite Bar takes you to the Sites “hub,” which contains both shared and personalized navigational links that help users navigate within and between SharePoint environments, with a special focus on the sites that each individual user chooses to follow. The Administrator view of the Sites page is shown in Figure 6-2. The Promoted Sites shown at the top of the page are controlled by the portal administrator, and can be targeted using Target Audiences. The default Promoted Links are shown in Figure 6-2, but you may want to create a Promoted Link to the top-level site of your intranet portal (the intranet home page) and additional links to the home pages of departmental portals such as HR—sites to which everyone in the organization will likely need easy access. In previous versions of SharePoint, you would have had to make these cross-portal connections in your branding or in the “tabs” in each environment. In SharePoint 2013, you can use the Sites page to provide these connections and also use the same methods as in earlier versions within a specific portal.
Figure 6-2 Administrator view of the Sites page
New site templates to provide new “starter” site and page architectures. As you will read more about later in this chapter, a key element of your information architecture is the organization of information on each site page. SharePoint 2013 sites have a new default user experience with changes to the default Quick Launch bar structure and site home page Web Part organization. These new page layout architectures reflect a much better understanding of how people actually work with SharePoint and, for some organizations and teams, might be usable out of the box with minimal configuration changes. Figure 6-3 shows the new home page of a publishing site (where you actually don’t get a whole lot of help for your IA), and Figure 6-4 shows the new home page of a project site, which has a unique page layout and custom Web Parts designed to help direct the attention of project team members and managers to important dates and deadlines, which provides a little bit more help for the page layout element of your IA.
Figure 6-3 Out-of-the-box publishing portal home page in SharePoint 2013
Figure 6-4 Home page of a project site in SharePoint 2013
New ways to define site navigation. The new managed navigation feature for publishing sites in SharePoint on-premises lets you define and maintain the navigation on a site by using term sets. Managed navigation supplements the existing SharePoint navigation that is based on site structure. Managed navigation is discussed in detail in Chapter 14, “Managing Web Content.”
New page layouts. For example, the new category page layout is used to display structured content such as catalog data. You can use category pages when you want to aggregate content based on specific criteria. Category pages are also discussed in more detail in Chapter 14.
New ways to interact with managed metadata. SharePoint 2013 includes a feature that many people in the SharePoint community were anxiously awaiting—the ability to edit managed metadata in a “datasheet” view, which is now called the Quick Edit view. This allows you to update any type of metadata “in bulk” in a view that looks and acts like a spreadsheet. In SharePoint 2010, you needed to open the properties of each document to change the values for any managed metadata attributes. (If you are new to SharePoint, managed metadata is described in the “Understanding Metadata Architecture” section of this chapter.)
New social terms. SharePoint 2010 introduced a common term set for keywords that could be shared across the enterprise. SharePoint 2013 includes a new type of keyword that has its own home in the term store—hashtags. Just like the keywords list, the hashtag list is updated when users create new terms in the newsfeed. However, as with enterprise keywords, you can “prime the pump” with terms that are relevant to your organization. To ensure consistency and save time for your users, you should definitely think about predefining a list of enterprise keywords as well as hashtags; both types of metadata leverage “type-ahead” features, so if a term has already been defined, it can easily be reused. For example, if yours is an engineering company, you may want to predefine keywords and hashtags for each major discipline, such as civil or mechanical. If you are going to ask users to enter values in the Schools field of the user profile, you might want to consider predefining keywords for the most common schools attended by your employees, which will ensure consistent spelling and acronyms and make it much quicker and easier for people to complete their profiles. Hashtags are stored in a separate term store and must be one word, so if you wanted a hashtag for business development, you could enter “BusinessDevelopment.” Enterprise keywords can have multiple words and include spaces.
New requirement to configure search as an application. Overall, the new search engine in SharePoint 2013 provides a far superior experience for users—even if you do no configuration at all. However, unlike SharePoint 2010 search, which automatically configured facets for you based on the managed metadata Site Columns in your information architecture, SharePoint 2013 search requires a more intentional approach to defining search refiners since no custom properties are automatically promoted to become search facets.
Planning Your Information Architecture Strategy—Site Collections and Sub-sites
Within each of the portal structures described earlier, SharePoint is typically divided into multiple site collections for performance, storage, and management. A site collection is a grouping of sites with a shared top-level site. Each site in the collection shares administrative settings, such as permissions, and can also share navigation. There are site collections that you will get by default. For example, each SharePoint 2013 user has a private site collection in which to manage his or her personal content called My Site1; this augments the My Site of previous versions with an offline synchronization feature—a new Sky Drive Pro document library within the My Site. In addition, if you choose to implement the new Community Portal in SharePoint 2013 or a Search Center, these are instantiated as unique site collections.
1. You’ll notice that we use the term My Site in the book—as does Microsoft in its online documentation. Although the feature set lives on, we anticipate that Microsoft will move away from the My Site branding in favor of the individual capabilities such as Newsfeed, SkyDrive Pro, and Sites.
If you plan to create both collaborative team sites and a “publishing-based” intranet, you could simply implement two unique site collections, each configured with different portal templates. But one of the first decisions you will need to make from an information architecture perspective is whether or not you actually need a unique site collection for each team site or within your intranet, for each departmental area, as an example.
As shown in Figure 6-2, the Sites page provides a convenient way to visually “connect” your publishing and collaboration portals if you want to provide your users with an easy way to navigate back and forth between the two environments. But, if you choose to implement multiple site collections within your collaboration portal, you may also want to figure out how to connect some or all of those sites to one another. If navigation and administrative settings are scoped to a single site collection, you may wonder why you would ever want to create more than one site collection in your collaboration portal. Isn’t that going to create a more complicated management structure and user experience? The simple answer is yes, but there are other reasons why you may not want to use just one site collection for all of your content—and this is why the information architect cannot make a recommendation about an overall IA strategy entirely without help from the solution technical architect. In addition to understanding how users will experience your solution, you also need to understand how much content will be managed and how actively content will be updated, because there can be significant performance implications associated with managing all of your content in a single site collection. You may need to isolate security permissions, for example, if you have a highly sensitive collection of content; or you may want to restrict a particular custom feature to a specific site collection. Table 6-1 lists some of the pros and cons of implementing your solution as multiple site collections versus a single site collection with sub-sites.
Table 6-1 Criteria for Evaluating One versus Multiple Site Collections
Planning Your Information Architecture Strategy—Gathering the Right Information
Building your information architecture includes four key foundational elements:
Knowledge of the domain to be modeled
Content organization
Firsthand understanding of site owner and user needs and capabilities
Knowledge of the features available to model the IA in SharePoint
The first key element of a well-designed information architecture is knowledge of the domain to be modeled. Information architects must work with content owners to establish an effective and useful taxonomy, which describes the structure and classification of your content. Carefully and thoughtfully designing the optimal model for site organization and the structure and values for metadata is a very detailed process. As painful as the process might be, content owners must actively participate in detailed data and site design reviews because they have the best knowledge of the domain. (It often helps to have a lot of chocolate available when you are working on your detailed metadata and site design!)
The second key element is content organization—this involves a combination of data modeling and library science skills. Content needs to be organized so that users who are not content experts can find it. In other words, the content taxonomy should not assume that all users have an in-depth knowledge of the content, the domain, or the authoritative terms that describe them. In addition to the authoritative terms content editors apply when they assign metadata to sites and documents, users can add “social” metadata in the form of tags and notes (also called “folksonomy”), which provides additional information to help users find what they need. Together with your content organization, authoritative metadata and social metadata can greatly enhance “findability”—the key goal of your information architecture. Of note, while search recognizes and leverages authoritative metadata and “social” tags, it does not (at least not at the time of the writing of this book) use likes and ratings (which are a form of metadata) to promote results. In other words, the likes or high ratings that a SharePoint item has will not help boost its “findability” in search results (though they can help users evaluate and compare content).
The third key element is a firsthand understanding of the users. In general, when there are trade-offs to be made in information architecture, design for the consumer of the content, not the person who contributes the content. For example, our experience has been that most people who are contributing content will have about 10 to 15 seconds of patience available for entering metadata. This means that you can probably include no more than about five contributor-entered fields in your design for most content types. The exception (and the trade-off) is for content that you will publish for a specific discipline or audience, where the job of the contributors is to communicate everything they can about the content they are publishing so that people can find it later. Entering more metadata (more than the recommended five or so fields) is generally not an issue for people contributing, as an example, human resources content on your intranet. In that type of scenario, the additional time spent entering metadata makes it significantly easier for people to filter or search for content and ultimately saves time for the human resources team responsible for the content—they get fewer phone calls asking for content that can be easily found via search.
The fourth key element is understanding how you can model the IA in SharePoint, which means that the information architect needs to understand how site collections, sites, page layouts, Content Types, Site Columns, and Web Parts all work together in SharePoint to model your information architecture. It also helps to understand how to represent the architecture to a stakeholder so that you can get feedback to ensure that the IA is going to work.
In Chapter 2, “Planning Your Solution Strategy,” we talked about the process you should go through with your key stakeholders to understand both their objectives for the solution and how they use and create information. The questions about information creation and use form the basis of the information-gathering activities that inform your information architecture. As a reminder, you will need the following general types of information to develop your information architecture:
Who are the key users/stakeholders? Do they include only people inside the organization, or do they also include your clients or customers, partners, and vendors? Look at who uses content and why they need it. Why is the content relevant to users? What is their desired outcome?
Do your users include the entire organization or just selected departments or roles?
Do geographical boundaries matter for your content access or storage?
How do your stakeholders use and access the information they need today?
Who creates content? What types of content do they create?
Who reviews and edits content and who might need to approve publication?
What types of content need to be identified as records?
How is information organized today? Take a look at your existing file shares, intranet, and collaboration sites. Do a comprehensive inventory and decide what can be deleted or archived.
What information will be migrated to SharePoint? Is there any information that might be indexed “in place” or migrated to archival storage?
How is content managed throughout the life cycle?
How much content will be managed of each type?
Manually defining and documenting information architectures requires significant effort and cost, but some manual effort is usually required. A good information architect starts by examining existing structures—typically found in folder hierarchies, existing intranets, industry sources, or organizational charts—and uses these existing structures as a starting point to review proposed architectures with domain experts. The process will most certainly be iterative—starting at the top and working down as well as working up from the bottom. As an alternative or complement to a completely manual process, automated classification tools can suggest an information architecture by analyzing the content from a collection of documents. Some of the automatic classification engines include algorithms that help the engines train themselves from example data. At best, automated classification systems can get you started with building your information architecture. For the most part, building effective information architectures requires at least some human analysis and manual effort. In this chapter, we provide a general overview of three different levels (site, page, and metadata) of information architecture or taxonomy. Each of these levels probably deserves a book of its own, so simply reading this chapter will not make you an expert information architect.2 Getting your information architecture right is not a one-time process—a good IA needs to evolve as your organization changes. Investing in expert support for your initial information architecture is well worthwhile. Look for an expert who will help transfer knowledge about IA best practices to your organization. You may not need someone to hang around for life, but you should consider engaging an expert, ideally someone with a background or degree in library science or information management, to help you get started and help your organization develop the skills needed to maintain and evolve your IA.
2. In fact, there is actually a great book that focuses entirely on building practical information architectures for SharePoint: Practical SharePoint 2010 Information Architecture by Ruven Gotz. In addition, there are excellent courses you can take that focus on building and managing information architectures for SharePoint 2013. Earley & Associates offers detailed IA training specifically for SharePoint. More information can be found at www.earley.com.
To improve adoption, we encourage usability testing of your site, page, and metadata architecture by representatives of key user areas and roles. Retest as your architecture evolves to ensure that you will continue to have highly satisfied users when you deploy or alter your solution.
Creating an Effective Site Architecture
In a portal or content management system, an effective site architecture helps users to navigate to content without having to search. Your site architecture allows users to see documents and other components of the solution in context, which helps them assess whether a document or component is relevant to what they are trying to accomplish. Our experience indicates that users use a combination of hierarchical navigation and search when both are available. It is impossible to predict who will be a “browser” and who will be a “searcher” in advance. The challenge is that while creating an optimal site architecture for navigation and content organization is vitally important, you probably won’t get it right until you get real users using the solution with real data. As you learn more about how users interact with your solution by observing their behavior, reviewing usage statistics, and gathering feedback after deployment, you can evolve your site architecture to make your solution even more effective.
As you conduct interviews and workshops to develop an understanding of user objectives for the solution and how they use information to guide their work, think about how that information fits within the overall conceptual organization of the company. Think about how content can be separated into major groups based on key business processes, major projects, key business roles, or organizational functions. Within each major classification, you may need to break each concept into subunits, depending on the type of content, who will “own” the content, and how you believe people will use the content.
Creating a new SharePoint solution is a great opportunity to learn about your organization. You will almost certainly discover that people in different parts of the organization or in different geographies have very different information needs. You want to be as comprehensive as possible when you do your analysis—be sure to include users who represent different roles, departments, and geographies. One key lesson we have learned: don’t ask your prospective users what they want on the new Web site. Instead, try to find out what kind of information they need to do their jobs—and the sources from which they gather this information. Focus on the work instead of the Web site. Focus on the outcomes and objectives, not the specific steps your users might define as requirements. User requirements are often expressed in the context of the user’s mental model and prior experience. If you focus on outcomes instead of requirements, you are often able to leverage more out-of-the-box functionality, which can save considerable time and money. If you can, observe people doing their jobs. It’s always amazing how much you can learn from watching what people do, which is sometimes very different from what they say they do. If you are replacing a current site, you can also gather key content concepts from an audit of the existing site. If you have only limited access to “real” users, you can create personas to stand in for different user segments. Personas represent archetypes of the key groups of users for your site. Creating and using personas can help guide decisions about the functionality and the design of your site. For example, a common persona helpful for the site architecture of an intranet is that of a new employee. Approaching your site architecture design from the perspective of each persona will help ensure that your design recognizes that different users have different needs and also that users may have different needs at different times based on what they are trying to do or the work that they have to get done.
Site Architecture Design Techniques
Information architects use many different techniques to design and validate proposed site architectures. In this section, we talk about two: card sorting and tree testing.
Card Sorting
One helpful technique you can use to create and iterate insights for your site architecture design is card sorting. The idea behind card sorting is to use the prospective list of content topics you have gathered during your stakeholder interviews, brainstorming, and content audit to engage users to help organize the information in a way that is useful and relevant to the people who will use the solution. The challenge with information organization design is that until you have validated the proposed approach with real users, anything that you do is purely theoretical. Card sorting is a technique that helps validate that your theory can actually work in practice. A word of caution: card sorting should be used only as an input to your site architecture, not the only approach to defining it. The main goal of card sorting is to look for patterns—to identify groupings of information that you didn’t expect and to validate some that you did expect. It sometimes tells you more about what you got wrong than about how to get the site architecture right, but it’s a great design technique to have in your IA toolbox. As you iterate through the site architecture process, you will want to take out duplicate items, combine similar items, and look for opportunities to create primary and secondary groups or subgroupings where appropriate.
In theory, card sorting is very simple. To start, you write on an index card each of the content topics that you have gathered during your stakeholder analysis, from existing documents and manuals, from the existing site, from planned solutions and processes, and from future content. Get prospective users (the ideal number seems to be around 20 to 30 but you can certainly use more) to group the cards into related piles and give the piles a name. Collate all the results and use them as input to your site architecture design. Donna Spencer has written an entire book on the topic—called Card Sorting (published in 2009)—and she has also written an excellent blog post that includes a spreadsheet you can download to record and analyze the results of a manual card sort. The blog post can be found at http://boxesandarrows.com/card-sorting-a-definitive-guide/. Manual card sorts can provide incredible insight because you can learn a lot about how users think about information by listening to their dialog as they work through the decisions they make during the card-sorting process. But tracking the results of multiple participants in a manual card sort takes a lot of effort. For this reason, many information architects also use online card-sorting programs (such as OptimalSort from Optimal Workshop) to supplement the insights from manual card sorts.
Tree Testing
Tree testing is a variation of card sorting that is focused more on tasks than on topics. While you can potentially use card sorting before you have an IA in mind, with tree testing you need to have your proposed site architecture defined—and then you can use this technique to validate which parts of your navigational “tree” are more aligned with user expectations and which ones may need rework. With card sorting, you give your users topics and ask them to categorize the information in meaningful groups. With tree testing, you give the users a task and then, using your proposed site architecture, ask them to tell you where in the navigational structure they would expect to find the information to accomplish that task. Tree testing is a form of usability testing that you can use to test your proposed architecture even before the site is developed.
Tree testing can also be done manually, using a series of index cards large enough to include all of the elements of a particular “branch” in your site. Tree testing can also be conducted online using software such as Treejack from Optimal Workshop.
Note
Neither tree testing nor card sorting helps you with other factors that help users navigate your site and find content such as the visual design and layout of the Web Parts on each page. This is why the page architecture design, described later in this chapter, is also critical for your overall IA.
Site Architecture Best Practices
One mistake made by novice information architects is organizing their site architecture based on the organizational structure of their company or department. The company organization chart should not be the starting point for your site architecture. That doesn’t mean you should ignore how your company is organized; it just means that you should use the organization chart to inform your site architecture, not to guide it. That said, there are some organizational units that are also functional units—for example, human resources and legal. It is perfectly fine to represent HR and legal in your intranet site architecture because while these may, in fact, be represented on the organization chart as “departments,” each is also a function within a typical organization that all of your users will understand. The mistake designers often make is putting a business function like corporate communications “under” HR in the site architecture because the corporate communications department happens to report to the head of HR in their company (or when they put HR and legal under finance because these two business units report to the chief financial officer). This structure might make sense temporarily, but if there is a reorganization and communications moves to another business group, the site architecture will no longer make sense. In addition, new employees who are not familiar with the company’s organizational structure will be far less likely to understand the site navigation if functions are aligned by organizational “ownership” rather than key functional area.
A well-designed site architecture can contribute to organizational goals and objectives. It should allow people to quickly find the information they need to do their jobs, effectively improving operational efficiency. It should also help people place the context of their work in the overall context of the organization, enabling them to gain an understanding of what is available in the solution as a whole, even if they primarily focus on their own particular space. It is important to provide meaningful labels to the elements of your site architecture. It is even more important to test your chosen labels with representative users to make sure that your nomenclature makes sense. (You can use the tree testing described previously to validate that your nomenclature resonates with your users.) Labels should be succinct—not more than three words each. Terms should be straightforward and consistent and should convey the desired tone for your solution. Try not to make up words for your navigation—use terms that users will understand (like “Human Resources” rather than “People Team”). There is no single “right” way to organize the content in your site. However, there are some approaches that are frequently used in well-regarded solutions:
About: Many Internet sites and internally facing intranet sites group general information about the organization in a section called “About Us” or “About [Company Name]” or “Our Firm.” You can put information such as the mission and vision, directions, company history, and organization charts in this section. Because this is such a familiar concept, users will generally know what to expect in this category. (But be careful, because this can easily become the catchall for new content that doesn’t seem to fit anywhere else.) The SharePoint 2013 community site has a predefined About page built into the template. This is a site-specific About page that allows the community moderator or owner to describe the community objectives as well as “rules of the road” for participating. This particular page template also includes a Web Part called “About this community” that displays the date that the community was established, a property of the community site that can be set by the moderator or site owner but defaults to the date that the site was created. Figure 6-5 shows the default About page for a community site. A navigational link to the About page is included in the left-hand site navigation (Quick Launch) by default. All of the site templates in SharePoint 2013 have some elements of the site architecture predefined. For the most part, these are suggestions based on feedback from real users and usability testing, but that doesn’t mean that you can’t change them for your environment if you find that they are either distracting or confusing for your users. As stated earlier, you can’t validate that your site architecture is “correct” without testing it—before, during, and after deployment.
Figure 6-5 Community Site About page
Functional groupings based on “what we do,” “who we serve” (both customer groups and industries), and what employees need to do their jobs. Different organizations will have different terms for these groupings, for example, Customers, Clients, Life and Career, My Role.
Activity groupings based on primary activities. This structure may work for a departmental-level in addition to an enterprise-level solution. For example, the following types of activities might form a basis of your site architecture:
Project work: activities that are designed to produce a specific result during a finite period of time
Support work: ongoing services that maintain an existing process (such as application maintenance and support)
Enabling work: initiatives such as career planning, a project management office, or portfolio tracking that help your organization deliver project or support activities
Customer work: activities related to engaging with partners, suppliers, and customers
Team work: activities related to administering a team such as managing vacation and travel schedules and conducting regular team meetings
Leadership work: information and activities for management personnel only, such as performance management, budgeting, and sharing other confidential information
“Duplicate” groupings if content “belongs” in more than one collection. One of the biggest benefits of organizing information online is that the same content can be grouped logically in more than one location even if it “lives” physically in only one place. For example, you may organize your sites based on industry groups, but there may be a subgroup that could be classified in more than one industry. For example, imagine an information architecture for an executive search firm. The site that supports the CIO practice could appear under the CxO group and the Information Technology group, which would help users navigate to the practice page no matter where they are looking for it. However, be careful about overusing this capability and creating lots of “weak” categories to organize your content because this will confuse your users, who will wonder why the same topic appears in so many places.
In some organizations, the solution design team will define the major organizational groupings for the site architecture but leave the detailed architecture to content-planning teams at the division or group level. This practice works effectively if experienced information architects are available to support the divisional teams and if some common architecture principles are defined at the enterprise level to ensure consistency in user experience across the solution and to ensure that the optimal SharePoint features are leveraged in the architecture design. The key to success in a delegated model is to ensure that you empower all users who have Design permissions with information architecture skills and best practices. This means that you will need to define a training program to ensure that users get the knowledge they need to effectively define their information architecture. In addition to training, you should also consider providing expert coaching to new information architects until they feel proficient.
Before you implement your site architecture, it is important to review it with several stakeholders and, ideally, use one of the techniques described earlier to gather data to validate that you are on the right track. While you may be tempted to immediately implement your proposed architecture in SharePoint, this is not a good idea. You should go through at least one round of “paper” site architecture documentation and testing. There are several techniques that information architects use to document a site architecture visually. Many information architects like to use mind maps and a mind-mapping tool such as MindManager (www.mindjet.com) to document a proposed site architecture. Others use Microsoft Office Visio or PowerPoint. The goal of your site architecture diagram is to show the relationship of the high-level elements of your proposed site navigational structure in a picture that allows you to review your proposal with your key stakeholders. The documentation technique you use isn’t nearly as important as the conversation that you need to have, so choose a diagramming technique that best facilitates your conversation. Figure 6-6 shows a very simple site architecture diagram created with Microsoft Office Visio. This example shows some diagramming techniques that you might use to help facilitate your architecture conversation. The first level of sites below the “home” page represents the top-level tabs for this site architecture design. Each of the pages below the home page could be a sub-site or just a page, depending on how you want to manage the content.
Figure 6-6 Example site architecture
Your site architecture diagram should include the following:
Hierarchical diagram showing each level (“node”) and how the nodes are connected. Try to limit your nodes to no more than three levels deep. This is not a hard-and-fast rule, just a guideline. Don’t use this rule to eliminate useful “landing” pages for major sections in your site. Category or landing pages help provide context when users land on sub-pages or sub-sites from search results.
Labels for each sub-site or page and, if possible, a general description of the content on the page.
Plan for navigation (using tabs and/or other navigational links).
As you consider whether a particular topic, process, or function needs a separate “node” (page or site) in the site architecture, it is also helpful to consider several factors in overall site administration:
Content ownership. If a particular business group is the primary owner of all of the content to be published on the page or site, creating a separate site (“node”) for that business group probably makes sense.
Security. If a significant collection of content is highly sensitive or targeted to a specific user group, creating a separate node in the architecture allows you to more easily control the security settings for that content.
Database administration. If you think that you might want to back up, restore, or otherwise manage content in a single group, having a unique portal node for that content will make these processes easier to manage.
Navigation. Try to minimize the levels of nesting in your information architecture. It’s a good practice to keep the number of levels in the hierarchy to no more than three so that users do not have to continuously “click through” if they are browsing for content. If you don’t need to create a node in the architecture for any of the other reasons previously outlined or your content group does not need a “landing” page, don’t create it.
Effective site architecture design is not a simple or quick process, even for small organizations or simple sites. If you invest the time to learn about your users’ information needs, the result will be a site that is easy to learn and use and provides much greater value. Once your site architecture is established, you will need to have a process to maintain it and to review suggestions for changes as part of your governance process, as discussed in Chapter 4, “Planning for Business Governance.”
Implementing Your Site Architecture
Once you have designed how your sites will be organized in your architecture, you have several options for how to display the architecture for your users. As outlined in Table 6-1, if you implement your solution in a single site collection, SharePoint can “automatically” surface your site architecture because you can show each sub-site in the top links or “tabs” area of your site. Collaboration sites have simple navigational options that allow you to automatically show one level “below” the root site as your top links and share parent navigation on all child sites. Publishing portals (or collaboration sites with publishing features enabled) allow you to automatically create a multilevel hierarchy for your solution. Figure 6-7 shows the site architecture diagram for a team site. Figure 6-8 shows the navigational settings required to automatically surface a link to Sub-site 1.1. The screen shot shown in Figure 6-8 was made from a collaboration site where publishing features have been enabled. Selecting Structural Navigation and “Show sub-sites” displays a navigational link to the “grandchild” site called Sub-site 1.1 when the user clicks the drop-down button next to the child site called Sub-site 1 on the parent site called Team Site.
Figure 6-7 Example multilevel site architecture diagram
Figure 6-8 Navigation settings for sites with publishing features
Figure 6-9 shows the more limited top links navigational options available in a collaboration site where publishing features have not been enabled. In this instance, you can automatically surface a child site of the parent site, but you do not have the option of automatically surfacing a grandchild site (a sub-site of Sub-site 1).
Figure 6-9 Top link settings for a collaboration site
In either of the two scenarios (publishing or collaboration), you can manually add links to sites that fall outside the physical sub-site hierarchy. This allows you to create a site architecture that reflects how users need to find information no matter how your sites are implemented from a structural perspective.
Managed Navigation
In publishing portals for SharePoint 2013, you can use managed metadata to define and maintain site navigation. This feature is described in more detail in Chapter 14, “Managing Web Content.” Using managed navigation doesn’t really change any of the best practices for site architecture design, but it does allow you to create a more dynamic site architecture with “friendly URLs” for pages. It also allows you to break up your content into multiple authoring site collections and use the central term store to manage a navigational framework that you can reuse in one or more publishing site collections.
Note
Refer to Chapter 14, “Managing Web Content,” for more information on how to leverage these new features to manage your site navigation.
Page Architecture
The overall site architecture for your solution is typically reflected in the top links area of your site. Think of the top links area as where you will most often provide navigation to functional topics that reflect how your solution is structured. However, each of these functional sites has a home page that needs to be laid out in a way that helps your users find what they need in the most expeditious way. As described in the previous section, these logical “home pages” don’t actually have to be implemented as separate sites. But to simplify the discussion, we’ll assume that to be the case, because whether they are separate sites or just pages in a site, you still have to answer the following question: When a user lands on the home page of the site represented in the site architecture, what does that page look like? The answer to that question is found in your page architecture or page layout design.
Consistent page layouts contribute to an effective user experience. Following consistent layout patterns, such as always showing links on the right side of the page and a contact person at the bottom, makes it easier for users who navigate from page to page to find what they need on your site because while the content differs, the orientation of the page follows a pattern. This doesn’t mean that every page has to look exactly the same—especially if an element of the pattern doesn’t apply to your content. However, if every page that has essentially the same purpose is completely different, users will have to spend valuable time orienting themselves as they go from page to page or site to site, and that wasted time can significantly impact productivity.
There are several best practices when it comes to page layout design, and these practices apply whether you are using a publishing or a collaboration template for your solution. In both cases, SharePoint includes a starter layout for all pages. Depending on how you customize your site, either with custom branding or by taking advantage of the many options available out of the box via the “Change the look” settings option, your page layout may not include all of the same layout configuration areas because some of the different layout themes include a left-hand navigational area (Quick Launch) and others do not. In most cases, however, you will have the Quick Launch (left-side navigation) and body of the page to design (because we are assuming that the top links or tabs are going to reflect your navigational site architecture).
In a typical Web site design (publishing portal), you will have at least two different page layout templates—one for the home page of the site and one for pages below the home page—but most often you will have several additional structural page layout templates that content owners could choose to use based on the “story” they are trying to communicate on their page. SharePoint provides several publishing page layouts out of the box, including some of the ones shown in Figure 6-10. And, of course, you can design your own to meet your specific needs. Be careful how many you design because this becomes a supportability and upgrade challenge. Try to be flexible in the design so that users will have the options to lay out their page, but consider your ability to support a large number of alternative page layouts. There is no magic number to recommend; the goal is to find the minimal number of page layouts that provides a balance between consistency of user experience and flexibility to present information in the most “consumable” way. With a publishing portal, you will almost always create custom page layouts that provide structured content areas and sometimes areas where page owners can add their own Web Parts. Publishing portals are designed to be configured using page layout templates that you will customize to best meet your business needs, though you may need to do only minimal configuration. If you look at the default home page for a publishing portal as shown in Figure 6-3, you can see that you are expected to look at your publishing portal design from the perspective of both an information architect and a visual designer. With collaboration sites, however, anyone with Full Control privileges (typically site owners) has the ability to configure the layout of a page.
Figure 6-10 Default publishing page layouts (partial list)
Every collaboration site template in SharePoint 2013 also comes with several “starter” page layouts, including a home page. Figure 6-11 shows the home page for a team site in edit mode. This view shows the areas of the page layout that you can edit in a default team site. Notice that you can select alternative text layouts in the ribbon. The default text layout shows two columns with a header, but as you can see in Figure 6-12, you can change the layout of the home page, a wiki page by default, to create the specific experience you want to provide for your users. In the default template “theme,” the Quick Launch links on the left of the page remain permanently in the layout even if you change the structure of the rest of the page. This means that you will design the Quick Launch navigation only once for each team site, no matter how many pages you have within it. If you create a child sub-site of your team site, it can share the top navigation from the parent as described earlier, but the Quick Launch is always local to the individual site. The default Quick Launch shows several predetermined links (Home, Notebook, Documents, Site Contents), but you can edit the list. Different types of team site templates have different initial links in the Quick Launch area.
Figure 6-11 Default page layout for a team site
Figure 6-12 Default text layouts for a team site
Designing a page layout for a site thus includes thinking about what goes in the Quick Launch, the layout of the page (the number of columns, whether you have a header, and so on), and the Web Parts (or content areas in the case of a publishing page) that you will display on the page.
Even if you start with a template provided in SharePoint 2013, you still need to think about how users will use each site. Consider the following basic design principles when configuring your page layout architecture:
Consistency: Provides standard design templates for all pages on the portal, and take steps in your governance processes to ensure that these design standards are followed. For intranets and Web sites, this ensures that users can navigate around the solution without getting surprised by changing design standards. But even in a collaboration environment where you are distributing Full Control permissions to different team site owners, consistency helps. If each team site has a completely different layout, people who work on more than one team will have to spend time learning the structure of every different site for all the teams or projects they work on. Consistency provides a very real benefit for your organization because you will not have to pay people to spend their time trying to figure out what the site or page owner is trying to say as they navigate through the solution or start work on a new team or project.
Speed: Make sure that users can get information as fast as possible. This goes along with consistency but should inspire you to think about a few additional design principles. For example, does the information or placeholder you are adding improve the ability for users to quickly find what they are looking for, or does it get in the way? Think about using the new Promoted Links feature of SharePoint 2013 to direct users to important content on your site.
Scrolling: Does the page layout require that users scroll up or down or left to right to find important information? Design your page to fit your organization’s standard screen size, and then make sure that users do not have to scroll to find the most important information or Web Parts on the page. Scrolling may be acceptable in your design standards, but scrolling should never be tolerated for critical information. Think about designing your page the way that news editors design a newspaper—the most important information should be “above the fold.” As a best practice, avoid designing sites that require left-to-right scrolling for sites viewed using your organization’s standard display size; up-and-down scrolling is generally OK.
Important content at the top, above the fold: Put your most important content toward the top left of the page. This is where readers will “land” visually when they get to your page. If the most important information is in this location, you have a better chance of capturing your user’s attention than if the information is buried somewhere else on the page. One mistake we see pretty often is that site designers put large images or content that never changes (for example, “welcome” messages) in prime real estate on the site. You want to avoid this at all costs—put content that changes frequently in the places where users will be most likely to see it. Move content that never changes or changes infrequently to a page that you might reference in the Quick Launch or “below the fold” on your page. The Community Site template in SharePoint 2013 includes an About page that is in the default Quick Launch for this type of site. You can add an About page to any type of site, and if the About page is in a consistent place in the Quick Launch on every team site, your users will learn where to find helpful reference information about the team or the site. A separate About page is generally a better approach than a lot of wasted space with “welcome” messages that never change.
Identified content owner(s). Every top-level site and major content page should have an owner clearly identified and visible on the page. Some organizations list both a sponsor, the executive or manager sponsoring the page and ultimately accountable for quality, and an owner or content manager/steward who is accountable for day-to-day management of the site or page and to whom content questions should be directed.
One link per page: One of the key decisions that you will need to make in the layout of a team site is whether to provide links to content in the Quick Launch, in a Web Part, or neither. This decision is what we call the page layout dilemma, and the options are discussed in the sidebar. As a general rule, however, you want to have one visible link to a content area on each page. For example, if you show your Announcements or Links list in Web Parts on your page, don’t also have a link to each list in your Quick Launch. This is by no means a hard-and-fast rule, but the idea is to minimize link confusion for your users. Also, make sure that the label for your link clearly tells your users what they will find when they click it. A link labeled “Miscellaneous” is not likely to be helpful to anyone.
Images: Use images to help create visual interest on your site and also to provide visual cues for key site content. You can easily create clickable images by inserting an image in a content editor Web Part and adding a hyperlink to the target content, or use the out-of-the-box Promoted Links feature to create friendly, visual navigation to important content. However, be sure to size your images to work effectively in your screen real estate, and use an appropriate resolution for the Web to minimize screen “paint time,” especially for users who will access your site at slower speeds. When you select images for your site, be sure they are relevant, and be sure that you have the right to publish them on your site. One of the things that you will quickly notice about SharePoint 2013 site templates is that you can easily add a background image to your sites. Be very, very careful about using this feature because in many cases, background images obscure text content and make it much harder to read. This is what we call a “bright shiny object” feature—it’s tempting to try because it’s new and shiny. Keep in mind: just because youcan, doesn’t mean you should. Our best advice: don’t use background images on your sites, even if you are tempted to do so.
Images that move: Avoid moving or rotating images, especially when the user has no control over the movement. You have probably seen a lot of Web sites with image rotators or image carousels, especially for news. They’ve become the de facto standard on many, many Web sites, and as a result, your users will probably want one on at least the intranet home page (if not also on their team sites). Use them if you must, but be aware that many of your users will find automatic rotation very annoying, so be sure to do some usability testing to get user feedback. You can have a news carousel without automatic movement—or one that changes the image each time the user lands on the page. You don’t have to automatically rotate the images—even if your business sponsor is enamored with that feature. If you must automatically rotate, be sure the frequency of rotation is not so fast that users don’t have time to process the image or text that you are rotating. Make absolutely sure that users can stop the rotation by clicking on an image. Finally, make sure that the number of items in the rotation is visible so that users know where they are in the rotation and how many items there are in total.
The Page Layout Dilemma: Web Parts versus Quick Launch Links
One of the many decisions that information architects wrestle with is determining what content gets to be promoted as a Web Part and what content is surfaced in the Quick Launch bar. The general guideline is that you want to make the most important content easy to find on the page, which means that you don’t want users to have to work too hard to find it. Since Web Parts surface individual content item details and links in the Quick Launch surface only a type or class of content, you should use Web Parts for important content where your users need to see the details of the content or content item and the content is time-sensitive, and the Quick Launch bar for more reference-type information. This is why you will see many sites with an Announcements Web Part—because each individual announcement is important, and if the details aren’t surfaced in a Web Part, site visitors would never know that there is something new to see.
As a general rule, documents are more likely to fall into the reference information category, so you probably don’t need to have a Web Part to surface document content. However, you might consider having a link to your document library in the Quick Launch and have a Web Part that shows New Documents (a view showing the most recently updated five to ten documents). Since Web Parts provide a window into the content of lists and libraries, use them to surface information that you don’t want users to have to click to see, such as the most recent content for a list or library.
Page architecture designs (also called wireframes) are often configured on paper before a prototype is created in SharePoint. There are several wireframe tools that you can use to help lay out the content on your site, including Visio or even PowerPoint. However, we love a very inexpensive mockup tool called Balsamiq (www.balsamiq.com). James Sturges has shared a set of SharePoint 2010 wireframes configured with Balsamiq that you can download from his blog at http://sharepoint.jsturges.com/2011/11/sp2010-wireframe-template/. In addition, the folks at Flucidity have created a downloadable set of Balsamiq templates for SharePoint 2013 sites at http://flucidity.com/2013/02/sharepoint-2013-balsamiq-mock-up-template/. There are also quite a few community-contributed mockups for Balsamiq that you can find athttps://mockupstogo.mybalsamiq.com/projects. There are several SharePoint elements in the community-generated content, though most are for SharePoint 2007. Figure 6-13 shows a very simple page wireframe for a community site created using Balsamiq. What we really like about Balsamiq is that the layouts clearly are not meant to be “real”; they are meant to help facilitate a design conversation with your users and sponsors.
Figure 6-13 Sample page architecture created with Balsamiq
In general, plan to develop an initial page layout proposal when you are designing your site, but consider offering stakeholders additional opportunities to reevaluate page layout design as you configure each layout. Use the recommended usability testing approaches described earlier to validate the effectiveness of both your site and page architectures. You will get a chance to improve even your best ideas for page layout when users can see the solution with “real” data.
Page Architecture and the Three-Click-Rule Myth
Do not get hung up by thinking that all content has to be “findable” with no more than three clicks because the “three-click rule” is just a myth. The truth of the matter is that users are very willing to click to find information as long as they are confident that with each click they are headed in the right direction. That doesn’t mean that you shouldn’t try to surface the most important or most frequently used content toward the top of each page. That is always a good practice. The three-click rule is a myth because in practice, we have seen that the number of clicks doesn’t matter as long as you are providing a strong enough “information scent” to guide your users to the content they need. Information scent on team sites can be achieved with clear, mutually exclusive labels for lists and libraries that tell users what they will find when they click on the Quick Launch link. Information scent on publishing pages can be achieved in the same way. Strong information scent is also achieved when you don’t have more than one link to the same content area on the same page or have links with different labels that go to the same place. Spend some time crafting meaningful labels and take advantage of the ability to add “hover messages” in your Web Part and Quick Launch labels so that you can add more information scent for your users.
Understanding Metadata Architecture
Metadata (literally, data about data) defines the structure of the content within your SharePoint solution—the attributes that you will use to classify and organize your content the way a librarian organizes content in a library. Why do you need to think about metadata? Metadata makes it easier for users to find content; in other words, “findability” is the key rationale for metadata, just as it is for the other elements of your information architecture. Metadata can also provide context for content, helping users to quickly identify whether a document or other asset will be helpful—without having to examine the content of the document in detail. Now you understand metadata, right? Probably not so much. So, let’s try to make the point about why metadata is important by using an analogy that you can use with your users as well.
Explaining Metadata
Think about your online music collection. Every song in the collection is a unique item, just like documents in a document library. And, whether you know it or not, you are already taking advantage of metadata to organize them. Every song is by a specific artist or artists. Unless the song is a single, it comes from a specific album (though it’s possible that some of you reading this book have never actually seen a real record album). And each song was written by one or more composers. Each of those attributes—artist, album, and composer—represents different metadata associated with each song. The values of these attributes, along with the name of the song, are what you need to be able to find an individual song in your library—because without these attributes, the song is just a bunch of bits and bytes on your computer. Artist, Album, Composer, and Name are among the many attributes used to describe songs in an online collection. Each of these particular attribute values is something that you as a user typically don’t have to enter because in the world of online music, they are already associated with the songs that you purchase online. Essentially, they are part of the metadata that you get “for free,” along with other attributes such as Genre. The collection of attributes that you (and others) use to understand or make sense of your online music collection represents the metadata for the item Song. With just a little information about each song in my collection (see Figure 6-14), I can find
Figure 6-14 Sample song metadata
How many songs in my collection were cowritten by Elton John and Bernie Taupin
All the songs on the album Here and There
All songs sung by Elton John
Now let’s think about how this concept applies to the documents that we store in SharePoint. In the world of documents, just as with songs, there is some metadata that we get “for free” when we create or upload a document in SharePoint. The most obvious is the file name, which your document acquired when you saved it to your hard drive or your file share. If I am the author of a document, I get to decide its file name when I save it the first time, no matter where I save it. When the contributor or “uploader” adds a previously saved document to SharePoint, the file name is still a primary reference for the document in SharePoint—but it is not the only metadata attribute available to identify the document. In a single document library, the only metadata value that must be unique is the file name.3 In other words, every document in a document library must have a unique name. In SharePoint lists, every item also has a unique identifier, but this unique identifier is stored “behind the scenes,” so you can have a list where each item has the same name (or Title) unless you add a rule to require the name/Title to be unique. Some of the other “free” metadata attributes for documents are Created (the date the file was first uploaded to SharePoint or created inside SharePoint), Modified (the date that the file was last modified), Created By (the user ID of the person who first created or uploaded the document), Modified By (the user ID of the person who last changed the document or any of its attributes), Version, and File Size. But notice that the “free” attributes of your music collection are actually very descriptive, and if you wanted to group your songs by album or sort them by artist, you could pretty easily do that without ever having to add any metadata of your own (but note that someone has added the metadata for your music; it just wasn’t you). In the case of documents, the “free” metadata isn’t very descriptive. And, because every document creator or “uploader” has complete and total control over how his or her documents are named, you can see that even with file-naming standards you might not get very valuable metadata to help you find a document if all you can use is the metadata you get “for free.” Figure 6-15 shows a list of all the “free” metadata that SharePoint 2013 provides out of the box for all documents and that you can expose in document library views. The Type shows an icon if SharePoint recognizes the file type such as Word, Excel, and PowerPoint but also any of the standard image formats and .pdf files. Name is the file name. All of the other attributes are determined by SharePoint, and with the exception of the file Name and Title, users do not enter or maintain these values. As you can see, these attributes are not particularly descriptive even if they might be useful in some scenarios.
3. Technically, file names have to be unique only within folders in a document library.
Figure 6-15 Default document metadata available in list views
“But wait,” you say. “I know how we can help organize and find our documents! That’s what folders are for!” Folders, also known as the dreaded “F” word, are, in fact, the way we have traditionally organized our online documents in file shares. It’s the metaphor that we all know and are used to. Here’s the problem: Have you ever actually tried to find a document in a hierarchy of folders that someone else has set up? Was it easy? Probably not. What if your library is designed to hold sales reports and your organization is divided into six sales regions and you sell four different products? Are you going to name your documents Sales Report-[Product Name]-[Month]-[Year]-[Region]? Are you going to create a folder for each product and then a sub-folder for each region and then a sub-folder for each year and then a sub-folder for each month and expect contributors to click-click-click their way through all of your folders to store a document? Are you then going to expect users to click-click-click their way through all of your folders to find a document? What happens if I am looking for the August 2013 sales reports and they haven’t been added to the folder yet? I just clicked my way through multiple levels only to find out that the folder is empty! As you can probably imagine, while your folder structure technically adds some descriptive metadata about your document, that metadata isn’t that useful because it doesn’t really help users quickly find what they need the way the song metadata does. And the folder metaphor gets really complicated when a document needs to go in more than one place. For example, how would you file a sales report that covers more than one region? Would you store it in two folders, thereby creating a duplication issue? What if the report gets amended? Will you remember to update the file in both locations? As you might be able to tell, your folder idea may not be as useful as you thought.
Metadata provides a far superior organizational framework for document classification than folders because it allows you to “slice and dice” your information depending on what you need to know at the time. Metadata also doesn’t “bury” content behind multiple clicks, and, more important, if you use metadata to organize your content, you have to store each item only one time, but you can associate it with more than one attribute value. You can then use your metadata attributes to create different views grouped by any single-choice value, which allows you to create the illusion of folders in views that provide the ability to visualize document lists in multiple ways without the problems associated with folders. This is the same concept as using the same song in multiple playlists in your music collection. You don’t have to buy the song twice to use it in your “road trip” and “exercise” playlists. For the type of content called Song in a music collection, you have seen that there are some standard attributes (aka metadata) that provide meaningful descriptive information to help us organize, navigate, and find music in our collection. For the type of content called Document, there are no universal descriptive attributes that will apply in all organizations or sometimes even in all departments of the same organization. So, for each type of content in your SharePoint solution, you need to create your own collection of helpful descriptive metadata so that users can answer the same types of meaningful questions that you can about your music collection and authoritatively find all of the content they need to make a decision or take an action. In the folder example, you could have used just a few simple descriptive metadata attributes to organize your sales reports—Product Name, Sales Region, and Month/Year—and you would be able to easily fulfill the following types of information requests:
Show me all the sales reports for any product in April 2012.
Show me all the sales reports for Product A in June of 2013.
Show me all the sales reports for Product C in Regions 1 and 2 for July 2011.
Moreover, you wouldn’t have to do any clicking at all to find out that no sales reports have been posted for August 2013. A quick sort of the files would show that nothing has been added with a Month/Year value of August 2013.
One thing that is important to note about creating custom descriptive metadata for documents in your SharePoint collection is that you need to keep it simple. While you could certainly add an unlimited number of attributes that would help describe your documents the way all the song information describes your songs, since you have to both define and add the metadata for documents and essentially all of your metadata is “custom,” you want to define custom metadata only for attributes that you need frequently enough to take an action or make a business decision to make the tagging and defining process worthwhile. In other words, the constraining factor for defining your metadata architecture is reusable business value. You don’t need to create a metadata attribute for every possible way you could want to sort or group your documents; you just want attributes for the most common and business-critical ways.
So let’s go back for a moment to the “F” word (folder). You are now probably wondering if folders are bad in the context of SharePoint. The answer is mostly no, folders are not “bad.” In fact, starting with SharePoint 2010, folders can have metadata, and when you put a document in a folder that has its own metadata, the document “inherits” the metadata from the folder, so you can define the values of metadata one time for each folder and then automatically “tag” your documents with those values. In other words, you can use a combination of folders and metadata to create a familiar construct for filing or storing documents but still create a “findable” asset collection by using views to display content that show documents without folders. Folders are also helpful if you want to add security within your document libraries because you can secure a folder, and then all of the documents in it will share the parent folder permissions. This does not eliminate the issue that a document can live in only one physical folder, but, as you can see in the sales example, that is a problem only for reports that span multiple regions. If no reports ever span multiple regions, you could technically mimic your folder hierarchy within SharePoint and, in views that don’t show folders, find the information listed above. The problem with that approach is that it’s massively confusing if human beings are doing the uploading—because each contributor still has to navigate or find the one and only one folder where his or her documents need to be stored. If you are getting your sales reports from a reporting system, on the other hand, using the folders for uploading and “no folders” views for consuming information would be perfectly fine.
If Metadata Is Good, Are Folders Always Bad?
One of the most challenging jobs for any information architect is convincing users of the benefit of organizing their documents with metadata rather than folders. Folders, the traditional organizational framework for documents in file shares (and file cabinets), have several problems:
It takes lots of clicks to get to the content you are looking for.
Folders are inflexible—you either put the same content in two different folders if it applies to more than one folder, which immediately creates version control challenges, or you have to live with the structure you created and make sure all users understand how to correctly put documents “where they are supposed to go.”
Using folders to organize content assumes that you and your colleagues all have the same mental model for content organization.
Folders don’t let you easily sort, filter, and create ad hoc views of your content—folders assume you know today how you might want to see your content tomorrow.
Metadata is a better organizing principle for several reasons:
It’s easy to see what content is available in a library or list.
Users can look at, sort, or filter content by any dimension that is useful today ... and use a different dimension tomorrow.
Metadata improves the ability to serendipitously discover what is available in a content repository—it surfaces rather than buries content.
With metadata, you have the option to use “group by” in views if you need to collect content of a similar type to create an organizing experience similar to folders, but still have the flexibility to group your content along multiple dimensions.
Metadata improves search engine results. SharePoint search uses the content metadata in the algorithm that returns results. In essence, metadata provides bonus points that can boost the content’s position or rank on a results page.
Information architects and good SharePoint designers have spent many years trying to break users of the “folder habit.” However, starting with SharePoint 2010 and continuing in SharePoint 2013, folders have an opportunity for a comeback because they are the vehicle through which location-based metadata is assigned. In SharePoint 2013, you can assign default metadata values to a folder using the “Column default value settings” feature in Library Settings, and then all the documents that you create in or upload to that folder will automatically “inherit” the metadata value associated with the folder. Since folders can actually provide a valuable “service,” they may have a place in your information architecture—especially if you create views that show your items without folders. Folders have other benefits as well, including the fact that you can assign security to folders and thus use the same document library for documents that have different access privileges so that users with the highest level of privileges can see all content and users with lower privileges can see only the content that their permissions allow. But while you can use folders for security, you do not want to use folders for both security and metadata grouping in the same library because you will create a very confusing model for content contributors.
Does this mean that we are now recommending that you use folders to organize your content by default? Not necessarily. However, you have additional options you can consider for your information architecture depending on the type of repository you have and whether or not you want to take advantage of document routing and location-based metadata features that are described in Chapter 13, “Managing Enterprise Content.” Chapter 13 also talks about a special type of folder called a document set that effectively allows you to create a template and act on a group of documents at one time. Document sets can have default metadata just like regular folders, but they can also provide a way to manage a deliverable that contains multiple documents in a unified way.
Basic Metadata Concepts for SharePoint
For the most part, people think of metadata as attributes that are assigned to documents, but you can use metadata attributes to classify and organize any type of list content. The basic design principles are the same, no matter what type of content you are organizing. However, we will primarily talk about document metadata in this section.
There are two primary constructs in SharePoint that you will use to design your metadata architecture: Content Types and Columns.
A Content Type is a collection of settings that define a particular type of information, such as document, list item, or folder. Content Types allow you to manage the settings for a particular type of information in a central, reusable way. One type of setting associated with a Content Type is its Columns or attributes. For example, the Columns of a Content Type called Sales Report might include Name, Product, Region, and Month/Year. A Content Type can be defined at the top level of your site collection (the root) and be reused in any document library and/or any site below the root, or in a sub-site and be used on any library on that site or in sites “below” that site. You can also define Content Types in a single site collection (called a hub) and share them across multiple site collections. All SharePoint assets are associated with a Content Type, so even if you don’t think you are using them, you are! The attributes shown in Figure 6-15 are the ones that are included in the base Document Content Type in SharePoint, but you can also add attributes of your own. SharePoint includes a long list of base Content Types for all different types of content. (To see the list, navigate to Site Settings and click on Site Content Types under Web Designer Galleries.) As a best practice, you should not modify these core Content Types. Instead, create a custom Content Type that is derived from the most appropriate core Content Type and add your custom metadata to your custom variation.4 Content Types can be associated to a specific list or library, which essentially allows you to restrict the type of content you can add to that list or library to just the Content Types that you have specified. Users see the list of associated Content Types for your document libraries in one of three ways: when they click the New button to create a document, when they upload a document with required metadata attributes, or when they edit an existing document’s metadata properties. Note that when a user uploads a document to a library that has more than one Content Type associated with it, the document is associated with the first Content Type in the list by default.
4. Microsoft strongly recommends that you do not modify any of the core Content Types. However, if you must do so, please refer to the “Guidance for Editing Pre-defined Content Types and Site Columns” white paper from Microsoft at http://go.microsoft.com/fwlink/p/?LinkId=260922.
Columns are the properties or attributes of a particular type of content. Columns have a unique type such as “single line of text” or “date” or “number.” Columns can be defined at the “root” of a site collection so that they can be used across the entire site collection. They can also be defined at the root of a sub-site and then be used in the sub-site and its children. Columns can also be shared across your entire environment when they are used in Content Types that are shared via a Content Type hub. Columns at the root of a site collection or site are called Site Columns, but the context of “site” depends on whether you are at the root site of the collection or a sub-site. Columns can also be defined in an individual list or library. In this case, they are usable only within that list or library, and they are typically referred to as “local” or List Columns. Column labels are scoped to the location where they “live,” but behind the scenes each Column has a unique identifier called a GUID. Though you might have a local Column called Document Type in each of two different libraries, the values for Document Type are not shared across the two libraries and you have really created two different Columns with two different GUIDs behind the scenes. To avoid Column name confusion, especially if you want to share values across more than one list, library, or site, you should try to create most Columns at the highest possible level in your collection—at the root of the site collection where the values are scoped to a single site collection or in a Content Type hub where you want to share values and labels more broadly. (But please keep reading, because there are even more variations for sharing Columns and Column values.)
You will need to plan how you will use these features across your entire solution as well as in individual sites, lists, and libraries. Metadata planning requires careful thought and a significant interest in details. However, a wonderful feature of SharePoint is that your metadata architecture can evolve and grow as your business and knowledge about user needs change. Your metadata architecture should be thoughtfully planned, but you do not have to agonize over every decision that you make. Put a stake in the ground, try it out, and continue to monitor your solution over time.
Content Types
It is often difficult to find related information when you are searching through a large repository. For example, let’s assume that you need to create a project plan for a new project and you know that there have been other projects similar to yours in the past. In a portal with many project team sites, it can be challenging to find all of the project plans. Content Types in SharePoint help simplify this task. If you define Project Plan as a Content Type, you can then find all project plans in your portal easily with a single search. Content Types also let you associate specific Columns with different types of content. For example, you can associate an Effective Date with a Policy but not with other types of documents. If you share and manage the Policy Content Type across your entire farm, you can ensure that all policy documents, created in any site collection, will have Effective Date as an attribute. You can also share a Column in all Content Types, such as a Records Retention Code.
A Content Type contains these elements:
Metadata (Site Columns). Every Content Type has an associated set of Columns or attributes. A specific Column might be required in one Content Type and not required in another. You cannot define default values for Columns based on the Content Type in which they are used, just which Columns are associated with the Content Type. The values for a particular metadata Column are defined for the Column, not the Content Type. If the values for a particular Column are unique to a Content Type, consider defining a separate, unique Column that is associated with a particular Content Type.
Properties. When a user edits a Microsoft Office document in SharePoint 2013, a Document Information Panel is displayed at the top of the document. The Document Information Panel provides a convenient way to update the document’s properties. You can configure a custom Document Information Panel using InfoPath 2013, which would allow you to, for example, create a custom document creation experience for different types of users.
Template. Document (or Column) templates can be used to create files with predefined styles and boilerplate content. You can assign one unique document template to each Content Type. For example, you can associate a predefined Excel spreadsheet for a Content Type called Expense Report. You can have only one template for each Content Type, but you can add multiple Content Types to a single library to make different templates available in one location. For example, in the Expense Report library you could have a Content Type for Expense Report: Travel and a different one for Expense Report: Entertainment, each with its own template to capture different metadata, support different layouts, or trigger separate workflows if needed.
Workflows. Some Content Types have a consistent process that can be assigned for approval. For example, all status reports may have to be routed to the project manager before they can be published on the portal. A workflow can be associated with a particular Content Type. Workflows can be triggered automatically based on a specific event or manually with a user’s action.
Information management policies. Your organization may have rules about how particular Content Types should be managed. This is particularly useful for records management. You can associate policies with a Content Type to manage characteristics such as retention period.
You can also associate workflows, properties, templates, and policies directly in a list or library. However, when you associate these items locally, they are not reusable, even within a specific site.
Content Types are organized in a hierarchy that allows one Content Type to inherit characteristics from another Content Type in a parent-child relationship. For example, while a memo is an “instance” of a document, if your organization wants users to leverage a standard template when creating a memo, you will want to create a new Memo Content Type as a child of the parent Document Content Type. The Memo Content Type can inherit all of the properties of the Document Content Type but can leverage a different template.
As a general rule, define Content Types at the highest possible level in your solution so that they are reusable and manageable across the entire solution:
If you want a Content Type to be available to a specific site (and its sub-sites), define it in the site Content Type gallery.
If you want a Content Type to be available to all sites in a site collection, define it in the site collection Content Type gallery.
If you want to create a Content Type to be used across multiple site collections (at the enterprise level), define a site collection to be a Content Type hub. The Content Types created in the hub can then be associated with each site collection using the Managed Metadata Service. Once an enterprise Content Type is published, it can’t be changed within the local site collection.
As you might imagine, if you are going to define metadata at the enterprise level, you are potentially introducing the need for a new governance role—an enterprise information architect or metadata planning group. Someone (or some group) in the organization should be responsible for planning and managing enterprise-level Content Types and other shared metadata. This does not have to be a full-time job (though it may be in large organizations), but the role will clearly need to be defined in someone’s job description.
As much art as science is required to determine what Content Types you need in your solution. Consider the following when you are planning Content Types for the enterprise, site collection, or individual site:
Does this type of content have unique requirements based on the Content Type elements listed previously?
Should this Content Type be available across the entire enterprise or in one site collection or one site? For example, if your organization has implemented a records management policy, you may want to add a Records Retention Code to one or all enterprise Document Content Types and make it a required field. This will ensure that users will assign a Records Retention Code to all content assets.
Would a user want to search for this type of content uniquely? For example, if you think that your users might want to be able to search for all project plans in your portal, no matter who publishes the document, you will want to create a unique Content Type called Project Plan. However, if IT project plans have a different template or workflow from Accounting project plans, you will want to create a parent Content Type called Project Plan and two children Content Types, perhaps called IT Project Plan and Accounting Project Plan.
Many users find that having too many unique Content Types creates more confusion than value. A smaller number of Content Types is probably better, especially for document repositories.
The Content Types that you define will be very specific to your organization; however, here are a few examples of the types of documents for which you might want to create unique Content Types:
Article
Brochure
Case study
Job description
Lesson learned
Policy
Project plan
Sales report
Trip report
Figure 6-16 shows a simple example of how Content Types can inherit metadata (Column) values from their parent.
Figure 6-16 Content Types and Columns: working together to organize content and improve reuse
Columns
Columns are basically the lowest level of your SharePoint metadata architecture. The “container” in SharePoint where metadata attributes are defined is called a column, but a SharePoint Column is an attribute or property of a list or library. Columns allow you to define descriptive attributes for documents or lists. In a document library, the file name is one of the default Columns, but as we discussed earlier, the name alone is usually not descriptive enough to help organize content in a document library. If you want to be able to get insights from your content or even group and organize your documents in meaningful ways, you will need to create custom Columns that are relevant to the type of content you are trying to organize. Going back to the music library example, if your songs were stored in SharePoint, Song would be the Content Type, and Artist, Composer, Genre, and Release Date are examples of the Columns that you could use to describe each individual song. People often use the term metadata to mean the Columns in your list or library even though technically Content Types are metadata, too.
Columns can be defined at the site collection or site level and can be inherited by child sites or defined locally in a library or list. Columns have a name and a type, such as
Single line of text
Multiple lines of text
Choice (menu to choose from: drop-down, check box, radio button)
Number
Currency
Date and time
Lookup (information already on this site)
Yes/No (check box)
Person or group
Hyperlink or picture
Calculated (calculation based on other Columns)
Managed metadata
There are other Column types that are used primarily in publishing sites, which you can learn more about in Chapter 14, “Managing Web Content.” Managed metadata is a special type of choice Column that allows you to define and use a hierarchical set of centrally managed terms across your entire SharePoint infrastructure or just within a single site collection. Choice Columns allow you to present users with a predefined list of values for an attribute. For example, if you want to have a Column called Status for your documents, you could restrict the list of choices to be Not Started, In Progress, and Completed. Since a document can be in only one of those states, you would further restrict the choice Column to be a drop-down or single-choice Column. “Regular” choice Columns can have only a flat list of values. Managed metadata, on the other hand, allows you to store attributes in a hierarchy that can be up to seven layers deep. Refer to the “Managed Metadata” section later in this chapter for additional information about this special type of Column.
Even if you are not using managed metadata to share values for Columns, you should still consider creating all Columns as Site Columns at the top site in a site collection. Managing Columns centrally allows you to automatically propagate new values to any library or list that uses that Site Column. For example, if you maintain a list of offices centrally in a “global” (site-collection-level) Site Column called Office and you open a new office, you have to update the list of offices in only one place if Office is a Site Column at the top level of your site collection. You can also use lookup Columns with reference lists supplying value choices. Unlike managed metadata, lookup Columns are scoped to an individual site collection, and if you need to use a lookup Column across your entire site collection, you must create the list and the Column that “looks up to it” at the top or root site. Of course, you may also want to manage Office as a managed metadata term if it makes sense to share these values across multiple site collections or if you want to maintain an office hierarchy by country or state. Deciding the best structure for your metadata requires knowledge of the domain and business purpose, but it is also possible to evolve your metadata architecture over time.
Effectively planning your Content Types and Columns can make or break the effectiveness of your SharePoint solution. It’s very frustrating to look at solutions in organizations that have been “experimenting” with SharePoint by essentially throwing the platform at users without providing any support for metadata architecture design. What typically happens is that users tend to use the same structures they are used to—folders—as the only method for organizing content rather than exploring the multiple ways of collecting and organizing content that are enabled by assigning just a few Columns and Content Types. While SharePoint supports the concept of folders in document libraries, folders can be a restrictive way of organizing content because a piece of content can “live” in only one folder. By contrast, the same document can be classified into multiple “groups” using Columns. For example, Columns allow you to create views that group the documents in your document library by author (to associate a document that was written by Sue and Scott and then find all of the documents written or cowritten by Sue) or all of the documents for the West region or all of the documents written by Sue for the West region. Folders do have a new role to play in your information architecture, but they are not necessarily the best organizing principle for your content (see the earlier sidebar on folders for a discussion about when you should consider using folders in your document libraries).
In addition to planning whether or not you will use folders to organize your content, another very common IA dilemma is whether to use multiple Content Types in a document library to identify the types of documents in the library or whether to use a single content type with a Column called something like Document Type to differentiate the different types of documents. There is no right answer to the “Content Type versus Document Type” or “Content Type versus Column” decision, but Table 6-2 summarizes some of the pros and cons of each method for organizing the types of documents in a document library.
Table 6-2 Choosing between Multiple Content Types and a Single Content Type in a Library
Table 6-3 provides a list of metadata Column best practices to help guide you in the choices you need to make regarding metadata Column labels and values.
Table 6-3 Metadata Column Best Practices
Enterprise Keywords: the “Folksonomy” Column
Document libraries in SharePoint 2010 and 2013 include the ability to enable a special type of enterprise managed metadata Column called enterprise keywords. Unlike other managed metadata, enterprise keywords are stored in a single, flat list in a system term set called Keywords. In other words, there is no hierarchy of enterprise keywords. This Column can be added as part of a Content Type, or it can be enabled in a setting called Enterprise Metadata and Keywords Settings for a document library. If you enable enterprise keywords, users who have content contribution privileges can associate one or more keywords of their own choice to a document. These attributes are best thought of as “sort of controlled” because as with other types of managed metadata, enterprise keyword values are displayed with a “type-ahead” feature so that when a user starts typing, keywords entered previously by other users are displayed. However, users don’t have to select a previously entered term, and they don’t have to spell any new terms they enter correctly. In fact, you cannot restrict the values—these are truly user-generated attributes. Newly entered terms become part of the overall list of enterprise keywords that become available for everyone in the organization to reuse. (The administrator for the portal can update or delete enterprise keywords.) If enterprise keywords are enabled, they essentially allow content contributors to create their own attribute tags for a document.
In SharePoint 2013, there are thus three ways an attribute can be assigned to a document:
When a content contributor or editor selects or adds a value in a Column defined by the content designer. This is a form of authoritative metadata; it is assigned by the content contributor in a structured field.
When a content consumer assigns a social tag to a document. A social tag can be any value entered by the user using the Tags and Notes property in the document library ribbon. As the user starts typing a value, SharePoint provides a list of previously used social terms (from the same term set used by enterprise keywords), and the user can select from this list. Since any user can add social metadata, these tags (or keywords) are not considered authoritative.
When a content editor adds an enterprise keyword. Enterprise keywords are authoritative tags because they are added by users with content-editing privileges, but the source of their values includes both the managed terms for the site as well as the social data values used by other content contributors and visitors. You can think of enterprise keywords as social tags assigned by a content editor.
Like any other Column, enterprise keywords help users find content in a library. However, unlike other Columns, the values of enterprise keywords are more flexible and less structured, which provides a very dynamic way to quickly react to evolving terms, opportunities, and emerging business needs.
More than one enterprise keyword can be assigned to the same document. By default, enterprise keywords act like a check box attribute. However, there are some conventions that must be used to assign enterprise keywords:
Separate values with semicolons.
Do not use commas to separate values. Commas in a list of enterprise keywords will automatically be replaced with semicolons; so, for example, if you enter “X, Y, and Z” as your keyword, SharePoint will replace your entry with three separate values (and the third will be called “and Z”).
Use “&” or spaces to separate words that should be combined as a single keyword.
Managed Metadata
As mentioned earlier, managed metadata is a special type of Column that allows you to create a hierarchy of options as choices. In addition, when you select managed metadata as a Column type, you can manage the value list centrally even if you are not using centrally managed Content Types. Note that managed metadata is not available in SharePoint Foundation 2013. It is available only with the enterprise versions of SharePoint, whether on-premises or online. In SharePoint 2010, information architects had to make trade-offs when they wanted to use managed metadata for a Column because you were not able to edit managed metadata in a Datasheet view (which is called the Quick Edit view in SharePoint 2013). In SharePoint 2013, managed metadata can be edited in the Quick Edit (or Datasheet) view, which allows you to make changes to any type of metadata in bulk using features available in spreadsheets like dragging a value across adjacent rows.
With managed metadata, you can create a “local” label for a shared list of values. For example, one part of your organization may refer to your external partners as Business Partners. Another part of the organization may call them Third-Party Organizations. A third part may call them Vendors. Even in an ideal world, each part of the company may have valid reasons for referring to these external parties by different names, even though the actual values—the names of the external companies—are the same. In SharePoint 2007, you would have had to try to get everyone to agree to the same label and values and used either manual processes, custom code, or third-party products to ensure that everything stayed synchronized across multiple sites and site collections. With managed metadata, you can create a shared list of values once, use the values to group similar content in search results, but allow each department to refer to the “external people who might be business partners, vendors, or third-party organizations” by whichever Column label makes sense in their context.
There are a few important terms that are used to describe managed metadata:
A term is the word or phrase that is associated with an item. Terms are the values that you select when you assign managed metadata to an item.
A term set is a collection of related terms. Term sets belong to a term set group. When you define a Column as being of the type Managed Metadata, you associate the Column with a particular term set and restrict its values to the values in the term set.
A local term set is created in the context of an individual site collection. Its values are visible only to users who have access to the site collection.
A global term set is created outside the context of a site collection. What makes managed metadata special is that you can maintain the values for the terms separately from the Column itself. And you can delegate responsibility for managing the term set to someone who wouldn’t otherwise have Full Control privileges in the libraries where the term set is used. So, for example, the overall term store administrator could create a term set called Offices and designate a person in the facilities department to manage and maintain that group.
Managed metadata is “consumed” in a Managed Metadata Service. You must have at least one Managed Metadata Service to share Content Types and term sets across more than one site collection.
The Term Store Management Tool is used to create and manage terms and term sets. You can use this tool to
Create a new term set or delete one that is no longer needed.
Add, change, or remove terms.
Create a hierarchy for terms and identify which terms in the hierarchy can be used to assign tags to content and which terms are just used for grouping terms. (You typically will want to use only the lowest level in the term hierarchy for tagging.)
Define alternate terms (synonyms) so that if users use different terms for the same thing or you are introducing a new term to replace an old one, “taggers” will be able to use their familiar term to find a tag but the new authoritative term will actually be assigned to the document. Note that the synonyms that you define for terms in a term set are not automatically available as search synonyms. Search synonyms must be configured independently, as described in Chapter 16, “Planning Enterprise Search.”
Import terms from an existing list. Unless you have only a few terms to add to your term set, you will probably want to use the import capability to add your terms. You act on each term independently in the Term Store Management Tool, so while it is convenient to use for updates to existing terms, you will not want to use it to add a large collection of terms.
Predefine enterprise keywords. If you already know that there are some common terms that your users will want to associate with documents, you can add some enterprise keywords in advance to create consistent spelling and formatting. For example, if your organization is an engineering firm, consider adding enterprise keywords for each of the major engineering disciplines used in your work.
There are some helpful worksheets on the Microsoft Web site that you can use to document and plan potential term sets for your solution. You can download the Term Set Planning Worksheet at http://technet.microsoft.com/en-us/library/ee519604.aspx. Table 6-4 shows how this worksheet could be used to organize a small set of sports-related products. (The list of product names was borrowed from eBay.) As part of the planning exercise for a term set, you will want to look for existing places where potential term set values are stored (such as product lists, regional office lists, or department lists) and organize the values into a meaningful hierarchy. This process should include a data cleanup exercise where you will remove duplicates and rationalize terms (select one term to be the primary value and then identify synonyms for alternative values). Standardizing terms may require negotiating. When it is clear that differences are minor (such as different abbreviations or spellings for the same value), our best advice is to use the “get over it” approach—pick a primary term, make the others synonyms, and move on with your life.
Table 6-4 Planning a Term Set
Figure 6-17 shows the first step in creating a new term set. This tool can be accessed from either central administration or from within Site Settings if you have the appropriate permissions. The Term Set Name and Description are identified, along with an Owner, a Contact, Stakeholders who should be notified before major changes are made to the term set, and whether or not new terms can be added to the term set.
Figure 6-17 Create a term set
Figure 6-18 shows the new Intended Use tab. This allows you to specify whether a term set is intended to be used for tagging, as in this example, or for managed navigation (see Chapter 14, “Managing Web Content”).
Figure 6-18 Define the intended use for the term set
If you plan to manually add terms, or if you need to assign synonyms for terms after you have imported a term set, you will use the term properties editing screen shown in Figure 6-19. For parent terms in the hierarchy, you will see an additional tab called Custom Sort that will allow you to specify a custom sort order to child terms. Using a custom sort order ensures that terms appear in consistent order, even if the default label for a term is changed.
Figure 6-19 Define terms in the term set
Figure 6-20 shows how the product term set appears to users when it has been associated with a Column called Product in a document library. In this example, you can see an instance where the user is attempting to assign a Product value of “T-shirt” to the document. Notice that since “T-shirt” has been declared a synonym for “Short-sleeved shirt,” this term is “available” as a tag. The actual tag value that gets assigned to the document is “Short-sleeved shirt,” not “T-shirt,” because “Short-sleeved shirt” is the primary term.
Figure 6-20 Synonyms help users use familiar terms to assign metadata
One of the best features of managed metadata terms is that when you manage term values in a term set and you change the value of a term for any reason, the value will be updated automatically in all the locations where you have used that term. For example, let’s say that you accidentally typed Puter instead of Putter when attempting to add metadata to a collection of golf-related documents. By the time you realize that the term has been misspelled, several hundred documents have been added and assigned the incorrect term. When you change the spelling of Puter to Putter in the term set, all of the documents with the incorrect spelling will be automatically corrected, even if you don’t open them. This feature will be particularly useful in organizations like pharmaceutical firms where a drug starts out as a compound and may get several interim names before it gets an official brand name prior to public launch. When the drug is approved, a single change to the term store is all that it takes to assign all content tagged Compound ABC to Blockbuster Drug. The term Compound ABC can also be added as a search synonym for Blockbuster Drug so that a single search for either term will return all relevant documents, even if the document metadata or content has not been updated with the new managed term. This feature alone should encourage you to carefully plan your use of managed metadata and who will be allowed to make changes to it.
It may not be necessary to run out and hire a consultant to support this process (though it’s not a bad idea for your first deployment). If your organization has a corporate library staffed with someone with a library science degree, you already have a great resource with the relevant knowledge and experience to guide the planning and implementation of your managed terms hierarchy.
Metadata and Search
In SharePoint 2010, search recognized managed metadata in search results and automatically created search refiners based on those attributes. If you wanted to see additional attributes (nonmanaged metadata) as search refiners, you had to configure them manually. With SharePoint 2013, none of your content attributes are automatically “promoted” as search refiners and so you must be much more intentional about determining which attributes of your content should be “promoted” as refiners in search results. This means that you really need to commit to spend time planning and configuring the user experience for search and should incorporate this effort into your project plan. We discuss how to create search refiners in Chapter 16, “Planning Enterprise Search.” Use the following suggestions to help determine which properties should be added as search refiners:
SharePoint automatically creates refiners for Result Type, Author, and Modified Date. You will need to determine which additional attributes will be helpful as refiners.
If you have attributes that you are using in all content types, such as Business Unit or Geography, it makes sense to create refiners for these attributes.
If you have an attribute that you use in a lot of document libraries, like Topic, this value will also be a good candidate for a search refiner. Many if not all of your managed metadata properties will be good candidates for search refiners.
You do not actually have to have metadata to create a search refiner; you can also use the entity extraction feature of SharePoint search to extract terms from content and then create refiners from these terms. Using this capability requires a detailed understanding of the content and user scenarios, but the capability is extremely helpful when you want to try to extract a structure from a large number of unstructured documents.
Maintaining Your Information Architecture
Ideally, when you first deploy your new SharePoint solution, the information architecture is well structured and content is appropriately cataloged because designers and application sponsors have taken a lot of time to ensure that the initial implementation is successful. Over time, new content enters the system, along with new sites, and if you aren’t careful, the well-structured information architecture devolves into chaos. When the information architecture becomes less relevant, so do the applications that depend on it. When that happens, users become frustrated and management wonders why they continue to make investments in the solution.
Even though features such as managed metadata give you more opportunities to control your information architecture, it is still important to pay attention to your IA to ensure that it evolves with your business and user needs. There are many reasons that an information architecture can degrade over time. The key to overcoming the challenges associated with maintaining your information architecture is to recognize up front that maintaining your information architecture requires a continual investment. Building a successful information architecture is not a “build it once and walk away” process. There are several business process recommendations that can help you manage and maintain your information architecture. Table 6-5 provides a list of some of the reasons an information architecture can degrade over time and proposes several mitigating strategies to overcome these problems.
Table 6-5 Recommended Actions to Maintain Your Information Architecture
Key Points
Keep the following key points in mind as you plan your information architecture:
Effectively planning and deploying an information architecture for your solution should be an iterative process. Assume that you will not get it right the first time out of the gate, and plan to engage users in a series of deployment reviews to evolve the architecture based on user needs and organizational changes over time.
Conduct usability tests before you deploy your solution to make sure that your information architecture makes sense to users, and conduct usability tests at least annually as your solution matures.
Leverage Content Types and Columns to manage metadata, using inheritance to propagate changes throughout the solution.
Take advantage of the enterprise metadata management features, especially the ability to share Content Types across site collections and the ability to create managed metadata terms.
Allocate time to plan search and configure search refiners when you are creating your solution design.
Emphasize the user experience over the content contributor experience in most information architecture trade-off decisions.
Ensure that maintaining your information architecture is a continuous investment—don’t assume that you can design your architecture and walk away. The information architecture and portal content need continuous nurturing in order to remain relevant and valuable.
Consider adding a new role to your solution team for an enterprise information architect (or enterprise “taxonomist”) to ensure that someone is accountable for ensuring that your information architecture is maintained.