06-20-2019 11:24 AM
06-20-2019 11:24 AM
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:
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!
06-21-2019 08:06 AM
06-21-2019 10:15 AM
@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:
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....
06-21-2019 10:35 AM
@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.
06-21-2019 11:02 AM
10-16-2019 04:57 AM
@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?
10-16-2019 07:26 AM
@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.