Szerkesztés

Megosztás a következőn keresztül:

Information architecture guidance for SharePoint Online portals

  • Cikk

Having a solid information architecture is an important prerequisite for realizing a well-maintained and well-performing portal. Designing the optimal structure requires detailed planning. If not done properly, you can adversely affect user adoption or have significant performance issues; the likelihood of both is very possible. 

Consider the following factors:

  • Business objectives and the organizational structure.
  • The kind of content you are dealing with. Is the content collaborative or published content?
  • Content classification and confidentiality.
  • Life-cycle of the content, and possible retention/disposition strategies. This also applies to sites as well. 
  • Users of the content, their behaviors, common tasks, and expectations.

After you know more about the users, the content, and the portal's intended usage, you will have a good foundation to start with and can possibly avoid some of the common pitfalls around information architecture.

Information architecture is not a one-time process, rather, it a continuous process. While an optimal information architecture may not always be obvious to end-users, a poorly designed and managed information architecture will certainly be remembered if the experience is a bad one. Keep measuring, keep evolving, and keep it relevant and fresh.


Implement-Govern-Measure-Improve diagram


Note

Although this guidance primarily targets SharePoint Online, most of it also applies to portals hosted in an on-premises SharePoint environment.

This article is not meant to go deep into every aspect of governance and information architecture. The intended point is to highlight common issues that affect user adoption and/or performance.

What not to do

The following list contains the key things not to do when you design your portal information architecture.

Don't:

  • Have too many top-level parent portal site collections. This will cause confusion and can have adverse impacts on management, security considerations, usability, navigation, and adoption in general.
  • Use deep hierarchies in a single site collection with unique permissions. This can cause performance challenges.
  • Have too many sub sites in a single site collection. All sites in a site collection are stored together in the same SQL database. This can potentially affect site and server (on-premises) performance, depending on how your site collections and sites are structured, and depending on the purpose of the sites.
  • Bury content. Content that is too deep impacts discoverability as well as adoption. If the user cannot find the content that they are looking for after a few levels, they will abandon their efforts and deem the portal as inefficient, which in turn, kills adoption. 
  • Keep stale content. Nobody likes stale content, and after a few times of seeing it, they won't come back for that reason. 
  • Not use content disposition strategies. These are needed to help avoid stale content and to stay within the defined capacity boundaries. 
  • Rely on poor enterprise master data management. This results in a poor SharePoint Online taxonomy design.   

The following sections address some key areas that you should consider when building your information architecture.

Site organization patterns

Consider minimizing the number of top-level site collection nodes and the number of subsite levels within your information architecture.

The discussions have changed around horizontal/flat site collections versus vertical/hierarchical. In the past, we promoted flattening hierarchies into potentially several separate site collections; reasons included factors such as IA best practices, menu structures, content database management, and capacity. As far as capacity is concerned, that is no longer relevant with SharePoint Online. However, there are other considerations now, such as URL limitations.

For more information, see SharePoint Online limits.

Recommended patterns include grouping site collections and sites into different logical groupings such as Enterprise level and publishing sites. These might include search centers, records centers, and ediscovery centers. These can be either at the root level or under the "/sites" managed path. Intranet publishing/portal sites can also be at the root level or under the "/sites" managed path. For example:

Sites considered enterprise level sites might be structured as:

  • /sites/
    • Search
    • Records Center
    • eDiscovery Center
    • Media
    • Compliance Policy Center
    • BI Portal
    • Content Type Hub

Sites considered as publishing portal sites might be structured as:

  • /sites/
    • Intranet Home
    • Corporate Function A
    • Corporate Function B
    • ...
    • Business Unit A
    • Business Unit B
    • ...

Usually, not everything migrates to the cloud immediately and all at once, so plan for a hybrid IA and evolve as necessary. Plan accordingly for hybrid scenarios.

For more information, see SharePoint hybrid sites and search.

Permissions

Structuring for permissions is a difficult task, and is another topic that requires some careful planning. The use of user accounts, SharePoint groups, and Active Directory groups/Azure AD groups to set permissions can be very challenging at times. SharePoint Online can use a combination of the three:

  • Direct user permissions approach
  • SharePoint groups approach
  • Active Directory security groups (Azure AD security groups)

Note

If you are in SharePoint Online, sync your groups with AD Connect.

Follow these guidelines when planning for permissions:

  • Follow the principle of least privilege to start, expanding as needed.
  • Use the standard, default groups first (Members, Visitors, Owners). Obviously, limit the the number of individuals to the Owners group.
  • Use permissions inheritance, and use groups over individuals when granting permissions.
  • Organize content to take advantage of the permissions inheritance, or organize by unique permissions and segment by classification levels if possible.

Inaccessible content that should not be will cause frustration and eventually hinder end user adoption and cause search results issues as well.

There are many design considerations related to configuration choices specific to search in SharePoint Online. A detailed search specification should be developed, especially for advanced configurations. The search experience can be tuned for performance and relevancy, and can be customized for users.

This includes:

  • Defining searchable managed properties.
  • Identifying high-quality pages for relevancy tuning. 
  • Managing query rules and result sources.

Content aggregation can have significant impact on the performance of your portal and its pages. For more information about content aggregation, see Content aggregation guidance for SharePoint Online portals.

Taxonomy

Taxonomy covers both site navigation as well as data. Careful planning is required from a governance perspective, as well as a performance perspective. Think about core business functions to start, but also think about future growth and manageability.

Content types

Proper planning, configuration, and implementation of content types and their associated metadata is fundamental to the ability to organize, manage, classify, and find information in SharePoint.

Define a small set of global content types, which may be based on legal or records management team requirements, as well as authoring requirements for tagging, etc.

These content types should have at a minimum, some fields such as:

  • InformationClassification
  • BusinessFunction
  • CorporateFunction
  • ...

Create these in the content-type hub and use SharePoint CSOM to create content types using unique IDs. You still need to manually publish these content types. Don’t use the content-type hub if you think that you would need to change the content types at the site collection.

For more information, see Introduction to content types and content type publishing.

Managed metadata

This is another topic that is too big for the scope of this article. For a good start and more information, see Introduction to managed metadata.

Metadata in SharePoint enables organizations to combine the advantages of formal, managed taxonomies with the dynamic benefits of social tagging in customized ways mapping to different information usage and management scenarios.

Enterprise metadata hierarchies can be based off of information security classifications. Managed metadata can also be mapped to documents or list items by using site columns and content types. These managed metadata term sets can be managed by managers and contributors, and the ability to add terms to term sets can be controlled as well.

Enterprise term store hierarchies are typically managed by a governance steering committee with an input process from other teams in the organization.

Important

Poor planning and poor management can cause issues around large taxonomy hierarchies and deep sorting. The data needs to be sorted client-side, so we recommend that you carefully consider the potential depth of the hierarchy, and the number of terms being returned. The depth of the hierarchy and the number of terms can cause the client Document Object Model (DOM) sort to take several seconds.

Don't delete term-store items; deprecate them. Keep the term store clean of potentially missing objects or faulty permissions, causing delays in data being returned.

Terms are not security-trimmed, so sensitivity needs to be considered.

For planning managed metadata, the following worksheets are available:

For more information about navigation best practices, see Navigation solutions for SharePoint Online portals.

Large media

Large files, such as videos, images, and PowerPoint files, can cause grief for users as they are expected to be retrieved fairly quickly. Files such as videos need to stream at certain rates, and some apps might not render until they have retrieved the files needed. Consider externalizing large media files. This helps with user adoption. 

Consider these options:

For information about CDNs, see:

See also