Forum Discussion
Modern subsites?
i would say that from a performance viewpoint, resolving sub-sites has always been an overhead as it reduces the amount of work that can be delegated to SQL by the need to translate internal sharepoint only meta-structures. Now that the old limitations around site collections and database sizes have gone, it makes sense to evolve the granularity and use site collections as the atomic site so that performance can be accelerated. it is only because we have got in the habit of subsites that we are nervous about moving away from them. The advantages they gave in inheritance are much outweighed by the problems of broken inheritance. The inability to separate them in SQL can become a problem as a site grows and then forces a restructuring.
For small segregations then List/ Library structures can be used instead of subsites to partition data physically for security purposes.
The https://www.unily.com/insights/blogs/microsoft-ignite-2017-announcements-you-need-to-knowarchitecture looks like a more formalised evolution of cross-site publishing which delivers a very robust and flexible system where I have used it before. excellent pattern that really leverages search.
perhaps those with a love for subsites could bullet point their advantages to see if we can suggest how that functionality would be designed into a site collection approach.
I'd rather not have to sacrifice information architecture and usability for the sake of performance, especially in an Intranet as its main function is to provide information. So my concern is more whether we are losing an aspect of information architecture that can be beneficial for certain types of users, those that prefer browsing to searching.
At least one scenario we use is a site collection of clients. Each client is a subsite which in turn has subsites for those projects. We could have a hub that surfaced the site collections of clients, but then what about the projects and searching across all of that structure?
I'm glad you qualified the multiple List/Library approach for small segregations. I've seen the opposite, and the job of trying to split that information apart into separate sites is quite a bit more difficult than moving a subsite into its own site collection.
But that said, we haven't had a lot of people "with a love of subsites" chiming in :-). And maybe I just need to get my head to think a different way.
Mary,
We currently have the same information architecture on premises. One site collection per client (> 150,000) and one subsite per project (2-50 per client). We could use a hub per client but then we loose the «all clients» scope.
If we stay with the subsites, it prevent us from using Teams and Planner for the projects.
We have to make on decision on our 2.0 architecture for the cloud and I think we will have to leave the subsites strategy.
As you probably have seen there will be 2 navigation bars one for the the hub and it linked sites and one on top which lets you navigate to other hub sites. As it is not Live at this moment i do not have exact specs.
Yes, I did see that. But I do know that in the current Hub specs (or in the talk), they said you cannot make a hub part of another hub. Certainly, you can link to another hub, but searching and rolling up across two hubs might not work.
I can see making a site directory with a list and Site Designs that use a flow to post to the list which could provide category and sub-category information for sites in the list. But I've often longed to be able to assign metadata to sites using the UI (rather than programmatically using the property bag) If we could do that, we could more easily provide some kind of automatic navigation between site collections based on categories.
