Wherein we review the pros and cons of choosing an intranet-in-a-box vendor that has elected to piggyback on native SharePoint Online Modern pages.
The below applies to the Modern Experience in SharePoint Online.
Valo and Powell 365 made the decision to load their customized content and artifacts directly into SharePoint Online's pages. Along the spectrum of the developer's control over its platform, with your own hosted hardware at one end and apps you upload to Facebook at the other, this approach is closer to the Facebook model.
It's the cloud model; you don't own the hardware and you don't own the pages, and you are uploading "tenant" components for someone else to host (with all the rules and limitations of tenancy). There are disadvantages, but also advantages, to this approach.
If your intranet-in-a-box vendor has rewritten the UI, you may be limited to the web parts provided by that vendor. If it's a smaller vendor there may not be an ecosystem of third parties writing web parts; there may not even be an SDK or toolkit for you to write your own, in which case you are limited to whichever ones the vendor decides to release. If you're lucky, the vendor has found a way to load SharePoint Framework web parts into their pages.
When you piggyback on native SharePoint, you get all the free web parts that come with it (I count fifty-one in my tenant), plus any Modern web parts you can get from third parties. With a widely-known and fully-featured development platform (the SharePoint Framework), you can also write your own web parts rather easily, or hire someone to do it.
Sometimes, a lack of options can be a kind of freedom. Since Microsoft owns the hardware and the software, they are fully responsible for maintaining it. If there's a service outage or other issue, unless it's your web part code that's breaking there's often not much you can do but wait for Microsoft to fix it. It's on their shoulders, so you can focus on the higher-level details.
Although it's been re-engineered from the ground up for the cloud, the Modern page still loads many, many scripts and outside resources from Office 365 and SharePoint Online. Although scripts are minified and loaded on demand, among other load-time strategies, et cetera et cetera, there are a lot of resources that must load, and your components must join the queue. We as SharePoint developers/consultants have no control over this.
Microsoft can (and does) change the SharePoint UI whenever it wants to. During a Powell 365 rollout in 2018, we experienced this firsthand, as Microsoft rolled out numerous breaking changes to the UI (most notable to CSS class names) without warning.
Microsoft has made it abundantly clear: outside of the few extension points they provide you (header, footer, individual web parts, etc.), do not alter the SharePoint UI. SharePoint is not a website, it is an application, like Outlook or Excel; this is why Slater Hill has always warned graphic-design-minded clients that restyling SharePoint pages is the lowest bang for your buck. In the Modern Experience, Microsoft has doubled down on this, taking away many branding options (I'm looking at you, fonts) to keep load times down and maintain the Office Fabric UI look.
You can use the theming engine, but that's just skinning, and the look of the platform should not be messed with beyond that. This is actually not a bad idea, for performance reasons as well as end-user familiarity and training. Wherever you are in Office 365 (SharePoint, Outlook for the Web, Power BI, Planner), there is a common visual language and style, and radically rebranding your SharePoint Sites will break the consistency across the platform.
So if you still want to rebrand your intranet pages, SharePoint Online Modern is not a good choice for you. Some vendors provide additional re-branding tools (Valo's Lightsaber feature comes to mind), but they are generally limited to styling their own injected extensions, like headers and footers.
When Microsoft rolled out the Modern Experience, only two site templates/classes were provided: Communication Sites, for broad corporate communications with larger audiences, and Team Sites, task-focused places for smaller workgroups.
The Classic publishing features that made up a (somewhat) sophisticated web CMS (content management system) did not make the leap. If you want page layouts, Master Pages, publishing scheduling and other CMS features, you'll need to stick with Classic Sites (still available, but very inconsistent with the Modern Experience when you mix them) or find some other solution.
That's a quick take on the advantages and disadvantages of choosing an intranet-in-a-box vendor that lives in the native Modern UI. In part three of this series, I'll look at the pros and cons of going with a vendor that has rolled its own interface pages.
