Intranet Site Structure with Hub Sites

[Charisma Riley]

Hi, all. I have a project currently where I am to build out a sample of our existing Intranet using modern sites, so that we can show leadership not only how much we will benefit from the transition (new technologies that become available to us, etc), but also how the transition will look. IN this new "hub site - associated site" structure, however,  I'm a little confused about the layout. In the end, I want our new Intranet to be structured in a way that will allow us to not only take full advantage of all of the most current technologies, but also future-proof it as much as possible. Therefore, I am seeking advice on how to accomplish this.

Currently, the section I am building in my sample currently exists in our Classic Intranet, as:

Intranet > Product Org > Products and Services > ProdOps

1. The first question I have is a bit of a clarification: in this new "hub sites" and "associated sites" world, is it semantically correct to create sub-sites anymore? Or do we just make sites and associate them to each other?

2. Secondly, I understand that we create Communication sites and convert them to the hub Sites. In my structure, I would probably want to originally make the Intranet and Product Org sites as Communication sites, convert them to Hub sites, and then associate them all with each other, correct?

3. For a site like Products and Services (which currently has sub-sites), what types of Modern site is recommended? It's not just a single team, and will either need to link to (or house directly) document and asset libraries. Originally, I thought a Communication site, but then I read that those cannot have sub-sites, and that if I want those, I should consider Publishing sites instead. But THEN, I read that publishing sites are not available as modern sites, and that doesn't work for us. 

4. One part I am trying to incorporate in this new structure is our wiki. I think it would work great to have each component of the wiki to be in each department's own site as wiki page libraries. HOWEVER, I read that with wiki page libraries, we cannot control the entire layout of the page, only the content. We will want to design it all out, with full control of the pages with SPFx, Office Fabric UI, Fabric React, and other technologies. Therefore:

1. Would an Enterprise wiki be a better idea? 
2. Is the Enterprise wiki a modern site?
3. Would I built it as a separate site and just associate it to each and every other site?

5. Associating sites: Currently the job of associating sites seems extremely manual and tedious and error-prone (leaving out a site that should be associated to one of the millions of others, seems inevitable), so what is the best practice to automatically ensure sites re associated with each other? Is there a way to do this?

Thanks, guys! The answers to these questions will help me get started! Thanks, in advance!

~Charisma

[#2]

Your questions really require a more detailed answer than can be provided in this forum, but here are a few concepts to think about:

- To be "future proof," your new structure should have no sub-sites. Create each site in the intranet as an independent communication site.
- A site can be connected to one and only one hub. You can link hubs together in navigation but you cannot "nest" them. You will need to plan your navigational architecture to accommodate this limitation.
- If you are concerned about making sure all sites get associate to the "right" hub, you may be over-thinking. Not all sites need to belong to a hub. You can connect sites in navigation with or without leveraging hubs. You can also, however, determine who can associate to a hub and if you like, make it hope so that anyone creating a site can associate that site to any available hub. It then becomes the responsibility of the site owner to choose the appropriate hub. I think that hub association as well as navigation should be planned - and yes, this does require some effort but the outcomes are well worth it for creating a great user "findability" experience.
- You should be able to get the exact same outcomes you have with a legacy wiki site with a modern communication site (each page in the site is analogous to the pages in the legacy wiki site and if you use metadata to organize the pages, you can create a navigation experience that is probably even better than what you might get with a classic wiki.

Here are two reference articles you should review for planning guidance:
Planning Navigation for the Modern SharePoint Experience: https://docs.microsoft.com/en-us/sharepoint/plan-navigation-modern-experience

Planning Your SharePoint Hub Sites: https://docs.microsoft.com/en-us/sharepoint/planning-hub-sites

I hate to make a shameless plug but I will because I think it would really help you in your journey. You may want to consider attending SharePoint Fest in Seattle in August. I'll be teaching an all day workshop on Information Architecture for SharePoint that will address virtually all of your questions in some detail (and more). Planning an IA for a great intranet is not trivial - and it's really hard to communicate all of the best practices in a forum like the TechCommunity. https://www.sharepointfest.com/Seattle/aboutus.

[#3]

@Charisma Riley  Just looking at this piece:

For a site like Products and Services (which currently has sub-sites), what types of Modern site is recommended? It's not just a single team, and will either need to link to (or house directly) document and asset libraries. Originally, I thought a Communication site, but then I read that those cannot have sub-sites, and that if I want those, I should consider Publishing sites instead. But THEN, I read that publishing sites are not available as modern sites, and that doesn't work for us. 

Here's how I would design it if it was for us. We're starting our rewrite from our old SP2013 intranet to the new SPO structure, so these are just my thought process...

I'd create a communication site 'Products and Services'. I would make it a public site if there are documents/lists/news articles that would be shared with the whole company. Make it a hub.

Then all those other subsites I'd make team sites, and associate them to the 'Products and Services' hub.  Benefits:

• Communication site hub has extra navigation where you can use mega menu to get to all the associated sites.
• Searching from the hub would easily surface information in all the other associated team sites.
• You can now have 2 levels of news - teams can create their own news that is accessible to their team, and for 'public' news you can publish those on the hub site...

Then on the main Intranet site, or wherever needed, I'd add a link or a menu option or a hero webpart or image that links to the 'Products and Services' site. 

For wikis, to stay modern, you'll want to use modern pages. You can create page templates so all pages can look the same, you can add metadata to the Site Pages library, and you can surface those pages anywhere with the Highlighted Content web part...

You could even create a separate team site, or another comm site even, and use it for all wiki pages if there aren't security concerns....

[#4]

@Robin Nilsson Be very careful with this approach. Whether the product sites should be communication sites or team sites depends on the objective for the site and who is authoring content. If these sites are for "consumption," not editing, they should be communication sites. There may ALSO be team sites for the teams working on each product, but associating those team sites to the main Products and Services hub may not get the best outcomes. If a user doesn't have access to the team sites (which are private by default), then they will not see results in searching from the hub. Products and Services does not have to be a hub at all. It can just be a "navigator" site that provides navigation to, for example, a hub for products of "type A" or a hub for HR, where HR services are grouped. This is why planning your information architecture cannot be done without carefully understanding the users, what they need to know, what their primary journeys are, and what business outcomes you need to enable. Hubs are a very powerful tool in your IA arsenal - but your user experiences and outcome goals need to be aligned with the super-powers they provide.

[#5]

All good points - thank you for clarifying. We've found that the permissions needed always changes how you think things should be associated. I should have been clearer about how that influences a design.

[#6]

---

@Robin Nilsson wrote:

• Communication site hub has extra navigation where you can use mega menu to get to all the associated sites.

@Robin Nilsson , my understanding is that one manually have to create all the links in the hub site, so for the hub site "My hub" to link to associate site "My site", then one would manually have to create a link in "My hub" mega menu. Is this correct, or is there some way of automatically having the hub site link to all it's associated sites? 

[#7]

@kenneho You are correct - you need to manually create those links. The hub menu never gets anything automatically.

We diagrammed out all of our sites on Whiteboard and made sure that all the main sites of interest lived on a hub somewhere.. hopefully there will be improvements in hub menu maintenance coming out of Ignite next month.