Sites within a site collection are automatically related to one another by a parent-child relationship (see Figure 1-1). The first site that is created within a site collection is referred to as the top-level site and it often defines the navigational relationship with all its subsites (child/ grandchild/great-grandchild and so on).
[caption id="attachment_10679" align="aligncenter" width="297"]
A site collection and its sites[/caption]If you possess a single site collection for your navigational taxonomy, site navigation is easily configurable. In sites that have the publishing feature enabled, it’s a simple task to move the sites around to suit the needs of the business as the organization changes and grows—to a point.
Scalability issues
The initial issue with placing all content within a single site collection is not apparent to users. They are readily adopting the new environment, adding new sites, permission groups, workflows, branding, and content. This site collection is stored within the confines of a single content database; and, more importantly, cannot be scaled across multiple content databases.
As the site collection continues to grow, other issues begin to surface, affecting users and admins alike. These issues include the following:
- Security groups: As site owners begin creating new sites and subsites, they have the option to specify that the site will not inherit permissions (this is not the default). Each new site can, in theory, add up to three new permission groups: visitors, members, and owners; the sheer number of additional groups can quickly become unwieldy to administer.
- Permissions inheritance: As the volume of data within a site collection increases, the surface area affected by a permissions change becomes larger. A minor permissions change near the top of a site collection can potentially expose sensitive data at a lower level site, list, or library.
- Taxonomical changes: Structural taxonomy changes in site columns and content types begin to affect the granular sites as well, especially if the parent column or content type is heavily altered.
- Recycle bins Individual sites recycle bins remain fairly easy to administer for the site owners, but the site collection recycle bins begin to have thousands and thousands of documents that must be sorted through by the site collection administrator (SCA) in the event of a restore request.
- SQL backup and restore: As the sheer volume of content increases within the site collection (and its related content database), backup and restoration times increase in duration along with the amount of data that can be influenced by a database corruption.
Navigational terms
There are four terms that should be defined as Navigational Terms
- global
- current
- structural, and
- managed navigation.
Current and global navigation refer to the two major navigation page areas present in traditional web design (also known as the “inverted L”), as shown in Figure below.
[caption id="attachment_10680" align="alignnone" width="300"]
Global and current navigation[/caption]Global and current navigation.
When discussing intersite navigation taxonomy, this section will be concentrating on the global navigation section, although the current navigation section might be occasionally
mentioned.
SharePoint 2013 provides two distinct ways to generate navigation for a SharePoint site or sites, structural and managed navigation. Structural navigation is a defined structure that possesses both automatically generated elements (for example, new links generated when a new list, library, or subsite is added to a site) and manually generated links (perhaps linking to a distinct site collection).
A newer component of SharePoint is the capability to build a metadata structure that assigns the navigational taxonomy to a site. As you might imagine, this structure is fluid, enabling multiple sites and site collections to be unified into a navigational structure that can be subscribed to by a site or site collection.
EXAM TIP
each of these navigational types has merit. For a group of users who are unfamiliar with creating and maintaining terms and term sets, structural navigation might be a more appropriate choice.
Because the managed navigation option is the newer of the two navigational types, be familiar with how to create this structure within the term Store Management tool.
Designing a basic taxonomy
We have already shown that there is an implied parent-child relationship present within a site collection, so designing an intersite taxonomy is then dependent on how navigational relationships can be configured between distinct site collections.
Defining the relationship between sites or site collections is less about the technical details and more about the philosophy of how the SharePoint farm will be used. Toward the end of this section, the technical actions required to configure site collection relationships will be addressed.
Prior to setting up these relationships, other considerations should be discussed:
■■ Who are the audiences for the respective web applications/sites?
■■ Will publishing site collections be separated from collaborative site collections?
■■ What purpose does each web application/site serve?
■■ What is the preferred URL for each site/site collection?
Org chart navigation
One of the easiest site taxonomies to build echoes the organizational chart. Users visiting the site are immediately greeted with a navigational menu system that starts with each major unit in the company (human resources, information technology, accounting, and so on). This design might be sufficient for a smaller organization with few subdepartments, but tends to be inflexible in a larger organization.
As an example, take the situation in which a user needs to view the status of their 401K benefits. Depending on how large the organization is, the navigation could go something like this:
Intranet → North America → Business Units → Human Resources → Retirement
Benefits → 401K Status
If a person needs to get to that site on a regular basis, they might wind up choosing to do either of these:
■■ Bookmark the 401K site
■■ Search for the 401K site
One of the constants in business is change; organizational structures are not exempted from this fact:
■■ New acquisitions As a business grows, other businesses are often purchased and folded into the structure.
■■ Departmental change As departments grow within an organization, it is not uncommon to see them split into two different units (for example, accounting becomes accounts receivable and accounts payable).
As you recall from the last section, people might choose to bookmark or search for a site that is nested deeply within the navigation structure. Altering that navigational structure to accommodate change in the org chart might result in the following:
■■ Broken bookmarks
■■ Errant search results (depending on how up-to-date your search index is)
Functional navigation
The challenge is not to necessarily make the navigational hierarchy about the structure of the company; instead, you might consider making the hierarchy about the actions taken by a person visiting the site.
Designing the site navigation around activities enables the site to be flexible in purpose. For example, instead of building an HR header that lists all the HR subdepartments, you might instead build a header that lists a series of actions such as these:
■■ New to the company? A site that is dedicated to the onboarding process of a new employee, which enables them to do the following:
■■ Complete all necessary HR and IT forms
■■ Kick off workflows and requests for items such as telephones, computer accounts, and so on
■■ Check retirement status
■■ Check leave/vacation status
As you can see, these navigation items function as verbs; they have action and intent behind them. If users decide that they would rather visit the HR site to see what items are presented by that team, the HR header link will take them to the HR site.
It becomes apparent that deciding which items get promoted to the navigation requires some interaction with the respective business units. Before proceeding to meet with these groups, develop an arsenal of requirements, gathering questions such as these:
■■ What are the major components of your business unit?
■■ What functions do you see your group(s) serving?
■■ When people call your group, what are the three most common things that they are looking for?
■■ If people within the organization were to search for your groups, what are the top 10 terms you might see them using?
When you meet with these units, it is important to throw the rule book out: a large white board, some sticky notes (to foster navigation activities), and an open forum is all that is necessary to foster a solid navigational design. Challenge the members of the group to act not as managers or information workers but instead to act as a normal business user would when navigating the site.
Later in this objective, managed site structure will be discussed; in that topic, we will compare the two types of navigation available, managed and structural. These navigation types are discussed at length and compared from a functional standpoint.
