The world is not flat and neither should your SharePoint site be!

When designing a SharePoint site, you will likely need to create a number of supporting pages and this article is intended to give you some things to consider when building out these pages. In the end I will introduce you to what I think is a missing navigation element, namely breadcrumb links between SharePoint Modern Site Pages so that it is possible to construct a logical hierarchy from a flat storage structure because not all pages serve the same purpose. Many pages should logically sit in a summary > detail relationship and there should be an easy way to set up such relationships and facilitate simple navigation but there isn’t, so the Kaboodle Software team set about building such a system.

However, before we get started, let’s get a few fundamentals out of the way first.

SharePoint Modern

If you have been stuck in old SharePoint on-premises world, then it is just possible that you may have missed that the user interface (or as the Microsoft marketing-machine would prefer us to call it, the User Experience (UX)) of SharePoint Online has gone through a bit of a revolution. The traditional, server-based architecture of SharePoint pages, page layouts, webpart zones and web parts, is now referred to as SharePoint Classic, whereas the new, client-based framework that seeks to minimise post-backs and provide native support for Responsive Design and therefore users who access content on mobile devices is known as SharePoint Modern in this new world order. SharePoint Modern is completely different and really rather cool as it breathes new life in product that is fast approaching its 20^th birthday!

It is important to understand that the backend infrastructure is the same and that Classic and Modern are not different products or product versions but rather they are 2 separate interfaces onto the same data. They can co-exist and have done for quite some time now but not always with the best results for users as it led to a somewhat bi-polar UI where some parts were Modern and other parts remained Classic. Things changed earlier this year when Microsoft released 2 site templates (the new Communication Portal and the Modern Team Site) that where more-or-less Modern throughout (some things like Document Sets steadfastly remain Classic but that’s on Microsoft’s to-do list).

This article is not about comparing Modern and Classic, there are enough of those out there already, but rather seeks to highlight a few things that should be considered when building out your Modern Site Pages. So, I’m not addressing Classic pages here and that’s mainly because I think that ground has been covered and also because Microsoft are not investing any more money there. That’s not to say that Classic is going away any time soon but it seems obvious that future is Modern. So as an information architect or site designer/builder you need to get with the program and hopefully this article will help.

The Site Pages Library

All SharePoint Modern sites have exactly one Site Pages library. Unlike with Classic SharePoint, where you can create multiple web page and wiki libraries, the Modern UX limits us to the single library that is created when the site is provisioned. Nor can you delete the Site Page library. Even if you could circumvent the UI and delete it with code or PowerShell that would be a sure-fire recipe for a broken site.

Modern does away with the distinction we have previously lived with between Publishing Sites and standard SharePoint Collaboration Sites (Classic Team Sites) so no more confusion between the Site Pages and Pages libraries when you activate the Publishing Infrastructure Features. No, Modern is an altogether simpler affair in that regard, everything, all pages, go into the single container, the new Modern Site Pages library.

Site Pages and News Articles, Apples and Oranges

Much as I am a fan of Modern, I think Microsoft have got it a bit wrong in one regard and that is in their decision to store Site Pages and New Article in the same container, i.e. the Modern Site Pages library. The only distinction between a news article and a regular site page is by the grace of a hidden status flag. Set a page with a “Promoted” status then it can be picked up by the News web part as highlighted content. I suppose I can see why it might be appealing as it means less libraries to deal with but personally, I think this is a really poor design decision for a number of reasons.

First up, promoting a Site Page is a one-way-street. There is currently no way in the standard UI to un-promote a Site Page, so what do you do if you promoted a page by accident? That oversight aside I have some more fundamental issues with the approach.

Site Pages (in my view at least) are static with dynamic content and semi-permanent whereas News Article are temporary with static content and are transient. They are not the same. A Site Page should be a permanent (or near permanent) fixture where users can go to reliably consume trusted information or access commonly used services. News pages, generally have a short shelf life and service a single purpose, to convey some specific information. Putting them together is simply mixing apples with oranges.

Also, assuming Apples to be Site Pages and Oranges are News Articles then, over time the number of Oranges will grow and grow making it ever more difficult to find the lonesome apple trees in an ever-expanding orange grove!

There are more problems; the people you want to have create news for your organisation are unlikely to be the same people who should manage your Site Pages. You might want to have content approval for news articles but feel that’s not necessary for Site Pages because the Site Pages don’t really contain much content at all but rather, they provide a context in which information, contained elsewhere, can be surfaced. So, putting them together will just cause an unnecessary set of issues with regard to approval, security and access control.

Whenever I roll out a SharePoint Modern Communication Portal, I always get the customer to understand that News and the Site Pages of the Intranet need to be separated. This can be done very easily, just create a Modern Team Site as a site dedicated to News (or create several of them if need be) and empower the news authors to create their content there. The new News web part makes it really easy to select sites from which it can harvest news articles. This leaves the Site Pages library of the portal to be dedicated to the storage and management of Apples without an Orange in site.

Having disposed of news articles, the rest of this article can now focus on Apples, I mean Site Pages.

All Site Pages are created equal, but some are more equal than others

This bastardised Orwellian quote is intended to stress that all Site Pages are provisioned in the same way with the same start-point but they don’t all serve the same purpose, can expect to command the same footfall in terms of user traffic or have the same prominence in the navigation. To put it simply:

Some pages are more important than others
Some pages will be accessed more frequently than others
Some pages are general and may simply be a launch pad to other pages and resources
Some pages are specific and focused on help the user archive a specific business outcome

Before moving on, I want to stress that all Site Pages should have a focus on helping users (visitors of the page) to achieve at least one specific business outcome. Site Pages should be like the rooms in you house. You have rooms where you cook, eat, sleep, watch TV and take a dump! Even corridors have an outcome, they ensure a guided and protected passage between rooms. If you have Site Pages with no business outcome for users, even if that business outcome is to be an aggregation point to accesses other pages (like a corridor), then users will have no need to visit it and you have no need for that page to exist. All the best portals are based around wearing the hat of the visitor and asking the question, “If I were coming to this page, what is it I would want to achieve here?”.

In Classic SharePoint, and especially within Publishing sites, a user tasked with creating a new page had a bewildering set of standard page-layouts from which they could choose. And organisations could also create their own custom page-layouts if they wanted too. But choice is not always a good thing and especially when users are unaware of the implications of choosing one page-layout over another or don’t understand when to choose a wiki page with a yet a different set of layouts (text-layouts) over a web part page which uses web-part zones. It was all a bit much and rather confusing.

In Modern, all Site Page start out the same. Each page can have a header section and one or more content sections and each content section contains between 1 and 3 columns and web parts are stacked vertically inside a column – and that’s it. It is more constraining no doubt and yes it would be nice if I could occasionally slice up a column with sub-columns and rows to get that perfect layout. But perfect layout for whom, and here lies the rub. If Microsoft built Modern pages with such flexibility (and they surely could) then the pages might look great on a full-size desktop but end up looking ugly on a tablet or smart phone. We’d be back with all the problems that plague Classic. By keeping us “on rails” we may indeed have to compromise on that perfect page structure but what we get in exchange are pages that are consistent and usable on a wider range of devices. I think this is a reasonable price to pay and applaud Microsoft for making a good call here.

Whilst, all Modern Site Pages might start out the same, they can have an essentially infinite set of configurations and that might not always be a good thing. I always try and get my customers to think of pages in 3 levels:

Level 1 – Site Homepage: There can be only one of these of course and depending on the purpose of the site this might be the only page you need, but in most cases, you will want additional supporting pages.
Level 2 – Functional and Common Service Pages: Although Functional Pages and Common Service Pages sit at the same level, they serve two very different purposes:
- Functional Pages: These are pages that provide access to information and resources concerning different functional areas of the business. So, there may be functional pages for HR, IT, Operations, Sales & Marketing, Work Health & Safety, Finance etc. Functional pages always have a business context.
- Common Service Pages: These are pages that support specific business outcomes, not tied to any particular functional area, such as:
  - Search Pages: To search and retrieve information.
  - People Search: Staff directory or org-chart.
  - Controlled Documents: Provide access to documents that should be used to govern business processes such as policies, procedures and forms.
Level 3 – Sub-Functional Pages: These are pages that support specific sub-functions within a parent functional area of the business and might provide ready access to Line of Business (LOB) applications, although the LOB Application might be hosted in a different SharePoint site altogether (or a different technology for that matter). So, a sub-functional page of IT might be User Support and that could provide access to Help Guides and the IT Helpdesk application where users might be able to raise a trouble ticket. The Help Guides do not necessarily have to be stored within the site that hosts the page, it merely has to surface the content and make it accessible to consumers.

I generally try and discourage customers from going any deeper than the 3 levels presented above but occasionally it a 4^th level for even more specific and detailed content can be justified. Information structured this way is presented as going from the general to the specific. It also provides us with an opportunity to classify pages and as such we might like to consider applying some standardisation and governance over the layout and structure of pages that are of the same type. We could, for example, provide a standard layout for all Functional pages and a different layout for Sub-Functional pages. That way we can achieve a consistent look and feel or at the very least start out that way.

The Site Homepage for an Intranet Portal is almost certainly going to be unique but when it comes to provisioning collaborative working sites, we might like to consider a consistent homepage layout for say Project sites over Team sites over Community sites. It must be said that SharePoint Modern does not currently make it easy to create custom site templates, this something that is much easier in Classic, but better support for site templating is on the horizon.

Building a hierarchy out of flatness

Going back to our 3 layers, we have a bit of a problem now because Site Pages are just pages in the Site Pages library and they are flat, whereas what we want it a nice hierarchical structure that allows users to seamlessly navigate from the general to the specific and never get lost along the way. So, we have to find a way to build that logical hierarchy out of the flatness.

Note, that we need to build this navigational structure in 2 directions:

Top Down: Going from the general to the specific.
Bottom Up: Going from the specific back up the chain to the general.

We might also want to consider how we might allow users to skip a layer, going straight from Level 3 to Level 1 without the need to route through Level 2.

Navigation controls at our disposal

SharePoint provides a number of standard navigational controls at our disposal, including:

Menus: Of which we have 2 to deal with
- Global Navigation/Hub Site Menu (for hub sites only)
- Current Navigation
Quick Links Web Part
Highlighted Content Web Part

Let’s take a quick look at these.

Global Navigation / Hub Site Menu

Hub Sites are a fairly new concept but they are set to become and incredibly useful construct for pulling sites together to provide an integrated environment. One of the key features of the sites in the same hub is that they can share the same global menu structure. Behind the scenes, the Hub Site Menu is nothing more than the Global Navigation menu in SharePoint Classic and it needs to be manually assembled. However, remember that Site Pages are more or less static so once the plumbing is in it should require little on-going maintenance. If the site is associated with a Hub Site it will use the Global Navigation specified in the Hub Site, otherwise it will not use the Global Navigation at all in either the Modern Communication Portals or the Modern Team Sites. Read that last bit again and make sure the penny drops!

The screenshot below shows the homepage of a customer’s portal with the Resources Menu (as part of the Hub Site Menu) linking to the set of Common Services pages at Level 2 and then a more specific set of Level 3 pages.

Current Navigation Menu

This menu system is unique to each site and is also known as the Site Navigation Menu. When in a Modern Communication Portal, the Current Navigation is presented as a 2^nd set of menus beneath the page title as shown in the screenshot below:

In a Modern Team Site, the Current Navigation is presented on the left side of the page. This was confusing in Classic and it’s still a bit confusing in Modern but just to reemphasise the key points:

In a Team Site the Current Navigation is presented on the left
In a Communication Portal the Current Navigation is presented across the page underneath the page title
The Global navigation is now used as the shared global menu system for all sites in the same hub
If the site is not associated with a hub then the global menu is not used

Personally, I don’t like using both the Hub Site menu and the Current Navigation Menu for a Communication Portal. It just looks too busy and, in my view, you don’t need 2 horizontal menus going across the page. I tend to use the Hub Site Menu and not bother with the Current Navigation Menu. When in Team Sites I think its fine to use both, in fact you don’t really have much of a choice as the left navigation area is there whether you want it or not.

The Quick Links Web Part

The Quick Links Web Part is a gem. It’s a marvel of modern software engineering and I love it. It’s incredibly versatile with numerous configuration options and adapts beautifully to fit the amount of column space allocated to it. Again, you need to set the links up manually but that’s no real problem for an essentially static structure.

The screenshot below shows another customer portal which has a Quick Links web part on the right for navigation to 9 functional pages.

Configured in full-size tile mode, it looks a bit like the much-loved Promoted Links list in Classic SharePoint but without the sliding up reveal-text and title, only it wraps beautifully without the need to resort to adding JavaScript hacks to the page.

The screenshot also shows the Hero Web Part on the left of the page. Pretty as it is, the Hero Web Part is limited to a maximum of 5 links, still it’s engaging and has its place.

The Highlighted Content Web Part

This is another highly versatile web part that can be used for surfacing content which can include Site Pages and so can be used for site navigation. What makes it different is that the content presented is served up search and is therefore dynamic and security trimmed.

The screenshot below shows a Highlighted Content Web Part on the Finance function page. The web part is configured to show a card that provides some summary information and linked access to any pages in the Site Pages library that have a page property that is equal to Finance.

This page property, called the Business Classicisation Scheme (BCS), is a Managed Metadata Column that provides terms that describe the functional areas of the organisation in a consistent way. As the BCS is linked to a specific Term Set in the Term Store it can be used throughout the tenancy. The same BCS can be used to set the business context for all documents stored anywhere in the system.

The BCS has to be set up of course and then the Site Pages library needs to be extended to include the BCS column and then pages need to be tagged with the appropriate business function which seems like quite a bit of effort but once this is in place the upside is that there is no additional effort required on the functional page. That is to say, if a new Site Page is added and tagged with a BCS of Finance, it will simply show up in the Highlighted Content Web Part on the Finance page without the need to re-configure anything. This what I mean when I say that Site Pages are static but with dynamic content.

I have found that using the Highlighted Content Web Part in this way is most useful when setting up Level 2 pages to provide ready access to Level 3 pages that are related to the same functional area. In the screenshot above you can see that Customer Accounts and Credit Limit are accessible from the Finance page and that these are clearly in support of specific sub-functions i.e. we are moving from the general to the specific.

The missing link

So far, we have focused on the top down navigation by using the Quick Links web part on a portal homepage (Level 1) to provide access to functional pages (Level 2) and then using the Highlighted Content Web Part on functional pages to provide access to related sub-functional pages (Level 3) but what about retracing your steps and getting back from a detail page to a parent context?

Getting back to the site homepage is easy. Users quickly learn that the Site Logo will get them back to the homepage at a single click from wherever they may be in the site. But what about if you are at a Level 3 page and want to get back to the parent Level 2 page without having to go via the homepage? Well we could provide a parent link on every level 3 page, simply by adding another Quick Links Web Part to the page. That would do the trick but it will take quite a bit of effort as there may be several sub-function pages for every parent function page. Also, the quick links might take up too much precious screen real estate and we’d want these parent links to be accessible in a consistent way so that users will easily learn where go when they want to climb out the detail and back to the general.

So how do we do that? I’ve been thinking about this for a while and concluded that what I’d want is a way to add Site Page breadcrumb links to the Command Bar as highlighted in the screenshot below:

The Command Bar is under-utilised and it takes up the entire width of every Site Page, making it the ideal place for Site Page breadcrumbs as it will allow us to show links to parent pages in a simple and consistent way.

These breadcrumb links are made possible by adding a custom SPFx Client Web Part, called the Site Page Breadcrumbs Web Part, to the page as shown in the screenshot below.

I won’t explain how to configure the Site Pages Breadcrumb Web Part here but rather refer you to the product page for that detail.

In summary

SharePoint Modern is the future but setting up the Site Pages for a site takes some considerable thought and planning. Not all pages in a site, especially and intranet portal, will have the same purpose or prominence. Generally, users expect to land at the homepage for the site and then drill into the details from there. So, pages need to be constructed in a hierarchy and although Site Page are stored in a flat container (the Site Pages Library) there are some standard capabilities and features that can be used to construct this logical structure and facilitate easy navigation. These include the menu system and web parts such as Quick Links and Highlighted Content.

However, there is no standard or consistent way to lay a breadcrumb link from a page to its logical parent page. However, the Site Pages Breadcrumb Web Part has been built to address this shortfall. Please visit the product page and try it out and then let me know what you think.