Branding SharePoint: The New Normal
Published Sep 04 2018 11:54 AM 41.6K Views
Microsoft

Modern SharePoint is catching on, and sites are looking better than ever right out of the box. With mobile-ready pages and easier editing, customers and partners are starting to ask for it. And as SharePoint 2019 brings the modern experience on premises, the demand is likely to grow even more.

Yet even as sites look better than ever "out of the box", there are constraints on how they can be customized. Partners and customers who want to completely change the look sometimes run into these boundaries and get frustrated.

 

NOTE: In this article, customization means changing SharePoint's behavior or rendering in ways not built into SharePoint, generally using some kind of code. Configuration means changing SharePoint's behavior or rendering using settings and content.

 

This article will explain what you can and can't customize on modern SharePoint pages and why. It will also offer alternatives for those who absolutely must color outside the lines.

How did we get here?

The story really began with SharePoint 2007, when Microsoft Content Management Server (MCMS) was "merged" into SharePoint. MCMS was based on a wonderful web content management (WCM) system called NCompass Resolution, and it gave designers complete control over page rendering. SharePoint introduced Publishing Sites which included most of the MCMS capabilities, among them the ability to start with a design composite (image) and make an editable page that looks exactly like it. Indeed, you almost had to brand it since the out of the box site was really bare-bones.

 

SP2007-PublishingSite.png
Figure 1 - Out of the box publishing cite, circa 2007

Microsoft started to promote SharePoint as a general purpose WCM system for building any site, public or private. If you'd like to see some examples of public facing sites with deep branding, check out Top SharePoint Sites; notice that they're mostly pretty old.

 

While SharePoint never did capture more than a sliver of the fragmented market for web publishing, it became the market leader for internally facing Intranet sites. Its flexibility led to an assumption that you could hire designers and developers to build any imaginable site from scratch, and it would benefit from SharePoint's powerful document management, search, security, and other enterprise features.

 

The resulting solutions were pretty cool until it came time to upgrade SharePoint. Each upgrade required a lot of rework, and sometimes a complete rewrite of the solution. Many enterprises resigned themselves to maintaining multiple versions of SharePoint rather than incur the expense of upgrading their most customized sites.

 

Here are some of the architectural issues that led to this situation:

 

  1. SharePoint and customizations share key files, such as master pages and page layouts, with code from customizations and SharePoint freely intermixed. There was no easy way to upgrade just the SharePoint parts of these files without breaking the customization. This situation remains in today's SharePoint Online "classic" sites, except now it's compounded by SharePoint's constant and ongoing upgrades, which are pretty standard for a SaaS (Software as a Service) cloud offering.

  2. Many of the customization methods required installing code directly on SharePoint servers, which isn't workable in a multi-tenant environment like SharePoint Online. Server-side changes also created problems when migrating to a new version of SharePoint; if every customization isn't installed perfectly on the new servers, the result is broken features and often the dreaded "correlation ID".

  3. Many of the customization methods such as JSLink and Display Templates are designed to be performed right on SharePoint sites, and don't lend themselves well to use of source control or testing outside of production. The same goes for tools like SharePoint Designer.


The pendulum swings the other way

All of this led to another school of thought: instead of "completely customize SharePoint", many wary customers and partners learned to "never customize SharePoint; it only leads to problems later on."

There are good reasons to brand SharePoint, however. Intranets are supposed to drive employee engagement, and branding is an important part of that. And SharePoint is primarily a website, and web sites are nearly always branded.

In addition to branding, customizations allow tailoring SharePoint to the policies and workstreams of each customer. Building solutions on SharePoint can save money vs. building an application from scratch, and empower a company's workforce. So it's worth figuring out how to be smart about customizing SharePoint rather than running away in fear.

Fortunately, Microsoft learned from the painful issues that arose from customizing classic SharePoint. Modern SharePoint is designed for the cloud, where multiple tenants and ongoing changes are a fact of life. It's also designed to allow developers to follow established best practices, like managing code in a source control system and testing that code before placing it in production.

This is good news, but it comes at a price: there are limits to the ways you can customize modern SharePoint. Some of them are probably temporary, as Modern SharePoint is still a work in progress. But, like most SaaS services, there will always be some swim lanes you need to stay in. That's the new normal, and it requires thinking differently about branding and customization.

For example, you can still hire a designer to come up with a look for your new Intranet, but he or she needs to be aware of what can and can't be changed on modern SharePoint pages, or you need to choose a different path entirely. The next section explains exactly what you can and can't change in modern SharePoint, and the section which follows offers alternatives to consider if you decide you can't live within the boundaries.

Customization or Configuration?


Nearly every part of a SharePoint page can be configured - you can set up your own content, colors, logos, etc. And most of the page can be fully customized with custom coded web parts and SharePoint Framework extensions. In addition, modern sites support theming to apply custom styles in addition to the configuration and customization shown here.

Figure 2 shows the home page of a modern Communication site, which is typically the one used to publish information on an intranet. Gold boxes and callouts show the portions of the page that SharePoint owns, so you can configure but not customize them. Green boxes and callouts show the portions of the page where you can put use custom code to create anything you wish.

CommunicationSitePageRegions.png
Figure 2 - Communication site home page elements

The callouts point to specific areas of the page as follows:

  1. Suite Bar: This bar is common to most Office 365 services, and allows navigation between products, access to the user profile, help, etc. It can be configured with your choice of colors and a company logo.

  2. SharePoint Framework header: This is fully customizable (with code) to hold anything you wish.

  3. Hub site navigation: This allows navigation within a set of sites that belong to a hub. You can configure the links and add your logo here. You can also add a color to the hub site navigation and header using the new theme "Accent colors" (rolling out to production now).


    HeaderEmphasis.png

  4. SharePoint page header: This displays navigation within the site, the site classification, and some common features such as following, sharing, or editing the page. You can configure this with colors (the site "theme") and a logo.

  5. Web parts: You can put any web parts you want on the page. This can include custom web parts written using the SharePoint Framework. So-called "full bleed" web parts can span the width of the page, inviting use for single page applications. (Full bleed is jargon from the printing industry; no animals are harmed when developing these web parts!) So you can really put anything you wish here. This typically makes up the majority of the page, with more screen real estate than all the other elements combined.

  6. SharePoint Framework footer: Like the header, this is fully customizable to hold anything you wish.

  7. Pop-up buttons: These buttons overlay the bottom of the page, and currently can't be customized or configured. There is a tenant setting in development (see -UserVoiceForFeedbackEnabled) but it's not yet respected by modern pages, and maybe we need another user voice for the Mobile app button.

Branding options


This section offers a number of approaches for branding SharePoint, some of which go beyond modern SharePoint, but generally at a price.

Option 1: Stay within the guardrails


There are a lot of compelling reasons to leave classic SharePoint and move to the new modern experience, and Microsoft expects that most customers won't mind working within the guardrails. The official branding guidance is here.

While it may seem desirable to customize everything, it's a good idea to evaluate the business benefits to the changes. Is there real business value, or are egos and expectations involved? (Actually I'm hoping this article helps set the right expectations up front, which I think would have helped in a couple projects I'm aware of...)

I once watched a marketing VP have a complete melt-down when the Office 365 suite bar appeared in the wireframes for a new Intranet I worked on. We found a way to hide it, but at what benefit and cost? I'm still not clear on the benefit of removing it, but the cost was that users could no longer navigate to other Office 365 properties, or easily manage their user profiles. Plus, it required a hack (see the next section).

If you've identified customizations that go beyond modern SharePoint's guidelines, and there is a clear business benefit, there are other options. Read on!

Option 2: Take a chance on a few hacks


Don't get me wrong, I'm not recommending that you do this! But that doesn't mean some people won't. (Wait, did I just admit to it in the last section? It was my friend who did it actually!)

OK let's back up a little. SharePoint pages run in web browsers which render HTML and CSS. Unless you use IFrames (which have challenges of their own), there's nothing stopping the code in a SharePoint Framework web part or extension from overriding CSS or manipulating the HTML Document Object Model (DOM). It's up to you, but you should at least understand the risks. When you do this, you're hoping that SharePoint won't change the page in some way that would break your code, and potentially the whole page.

If your code uses a documented SharePoint API and it breaks, you've got a legitimate support case with Microsoft. And trust me, Microsoft does its best to keep its APIs stable and provide plenty of notice in case of a change.

On the other hand, if you reverse-engineer SharePoint and code against an undocumented CSS class or DOM element, all bets are off. Microsoft could change it without notice because they don't know about your change, and notifying everyone about every little change would be ridiculous. If you called support they'd probably be sympathetic, but they're unlikely to back out the changes that broke your code. That's the very meaning of the word "unsupported."

Hacking SharePoint is a rocky path, and if you decide to go there, it's your choice to slow down and hack carefully or just barrel on through. If you make 100 changes and forget what they are, what happens when it breaks? Chances are you'll have a small crisis on your hands (or maybe a big one).

It is possible, however, to hack carefully. For example a large enterprise I've worked with has exactly one of these hacks across their entire intranet. It's on the home page, where a hidden web part uses CSS and DOM manipulation to change the page heading. They maintain a copy on a Targeted Release tenant where they test it regularly, knowing that any breaking changes will appear there before they reach production. If there's a problem, they can remove one hidden web part from the production home page and it will revert to the out-of-box look, and give them time to come up with a new hack.

If that sounds like a lot of work, well it is. There's a tradeoff between risk, resources, and reward; if you're going to hack, at least make the tradeoff consciously.

Option 3: Stay on Classic


This is the path chosen by many who have already invested in branding a classic SharePoint site. Microsoft has pretty much stopped enhancing classic SharePoint, which will limit your ability to take advantage of new web parts and other features. An upside to this is that if Microsoft doesn't enhance classic SharePoint, all that intermingled code on the master page is less likely to break.

Bottom line is you'll need to live with the limitations of classic. For example, classic SharePoint pages don't work well on small screens like phones and tablets; you can add your own responsiveness in the master page or page layout, but you'll soon discover that none of the built-in classic web parts are responsive either and you end up writing all custom web parts.

Option 4: Use SharePoint as a headless CMS


With SharePoint's rich set of client API's, you can surface SharePoint content in any application. You can design any site, host it as you wish, and have it call SharePoint API's to bring in the content. You could even surface SharePoint content in another CMS such as SiteCore or WordPress.

While this works, it's likely to be costly as you're now maintaining more code and possibly a second product to make your Intranet work.

Option 5: Use an Intranet in a Box solution


There's a huge market of Intranet in a Box solutions out there, most of which are either built on or somehow integrate with SharePoint. These solutions generally come with their own limitations, but perhaps you'll find them more acceptable than the ones in modern SharePoint.

However this isn't really a 5th option, since every Intranet in a Box solution will need to choose one of the other options to build their product! Looking at the big list of products, I recognize some which run on classic SharePoint, some on modern, and some outside of SharePoint entirely. And they may or may not resort to a few hacks along the way.

My advice here is to discuss this with the product vendor, and be aware that the same tradeoffs exist for them that would for you.

  • If it's built on classic SharePoint, are you ready to live without enhancements from Microsoft? Do they have plans to move off classic SharePoint, and will there be a migration if they do?

  • If it's built outside of SharePoint, are you ready to forgo the SharePoint ecosystem of web parts and add-ins?

  • If it's built on modern SharePoint, did they hack it, and if so, how carefully? What's the support plan?

Getting the genie back in the bottle


There are a lot of benefits to modern SharePoint, not the least of which is improved stability, even in the face of the constant updates made to Office 365. You might not be able to move the search box, but you'll never spend another sleepless night trying to upgrade your Intranet to a new version of SharePoint.

The broad WCM capabilities introduced in 2007 set an expectation that, for a custom UI, any wish can be fulfilled. Now we have to reset that expectation.

Modern SharePoint will continue to evolve. In all probability there will be more opportunities for customization over time, as well as more features which can be configured in new ways.

Given that reality, it would be smart to educate decision-makers and designers on both the benefits and the boundaries of modern SharePoint. So far, for most customers I've asked, the boundaries aren't really a problem and the benefits are significant. If you're one of the few who need to customize beyond what's possible in modern SharePoint, it's a good idea to understand the options and tradeoffs, and make a conscious decision.

16 Comments
Brass Contributor

Thanks Bob. This is an excellent post. All the important points covered and so well that I've already shared with key decision makers in our migration project from SP2010 to Office 365 and SharePoint Online to help them better understand the issues surrounding branding.

 

While this post succinctly explains why we're limited to what we currently have we still need to be able to provide larger organisations with greater branding and UX control over their entire tenant. The missing piece is that organisations have to cede branding control of their most actively used online properties to the Office 365 app launcher and a logo link. Users transitioning between Office 365 apps such as SharePoint Online to Outlook to Planner to Teams loose access to rich navigation controls to move seamlessly to other organisational web properties. With Office 365 becoming more and more prevalent this is the missing feature.

 

Microsoft has progressively expanded the Office bar deeper into the various apps within the Office 365 ecosystem which is good and probably provides enough for a SME but larger organisations are going to have a significantly larger digital footprint and have a need for global navigation structures not available in the Office 365 app launcher. A global header and potentially footer such as those available in SharePoint Online via SPFx would provide that additional reach back into organisations back end systems and fill that gaping hole that this article addresses and brand managers are seeking to fill.

 

I don't see this as a feature that Microsoft needs to build as their own with easy CRUD features as I don't necessarily see that SME's are necessarily going to use it but providing a global placeholder below the Office bar will allow those with SPFx skills to easily provide global reach capability to those that need it.


And yes I will be adding this to user voice as a feature suggestion.

Copper Contributor

Great write up! I was a little disappointed that some web parts don’t work with modern pages yet, like the Tasks web part but all in good time. Overall I am excited to see what we can start creating with these new pages, they are such an improvement over how we used to have to add web parts and configure properties.

Great post Bob! Recognize everything you mention and been on every path. It has become one of my main tasks in advising clients and decision makers. Most of the time it works and this article will help a lot as a good refference! Tnx! 

Copper Contributor

An excellent post to explain the various routes to customisation. A very valid point about intranets-in-box either having to extend classic to give it a custom and modern look, or hack modern sites to suit the rich branding these products offer. Can I just add my voice to the other pleading for an OOTB way of providing footers?  The hub site menu is a nice start in the direction of shared navigational elements, but lacks the shine of mega menus that many customers want and get with intranets-in-box.

 @Dylan Hayes have you seen the new MegaMenu for navigation that comes out of the box now?

 

It was released a few weeks ago, recently it's dissapeared from a couple tenants. But that may work for your needs!

Copper Contributor

 @Beau Cameron That would be a big nope, I haven't seen such a OOTB mega menu. I did spend some considerable effort a few months ago investigating the options for mega menus, and didn't find any mention of such a thing. Where does this live within SharePoint so I can see if any of our tenants have it, and how does one enable all that mega menu goodness I so desperately crave?

Vesa Juvonen tweeted about it last week or so. Only blog post about it and how to enable it can be found here:

 

https://mattipaukkonen.com/2018/08/22/manage-sharepoint-communication-sites-megamenu-with-csom-and-p...

@Dylan Hayes  Check out the road map! https://products.office.com/en-us/business/office-365-roadmap?filters=&freeformsearch=mega&featureid... I think it was released by accident and then retracted.

 

Check out this thread for pictures. Both Top Nav and Hub Site Nav

https://twitter.com/vesajuvonen/status/1032253273745571840

 

Copper Contributor

@Beau Cameron fascinating stuff. I also noticed the some degree of colour customisation of the hub site menu has just arrived on our tenant just this morning: https://twitter.com/dylan_hayes/status/1037294475842863104 It's a long way from a mega nav, but it is at least a different colour to the rest of the page.

Copper Contributor

 By a strange coincidence I noticed that at last there's colour options on the regular hubsite menu on our tenant as of this morning: https://twitter.com/dylan_hayes/status/1037294475842863104

Copper Contributor

Hi Bob, thanks for spending time and writing this up.
I am a branding specialist - to be honest I was a bit disappointed reading this - I was so excited to  read on 19th version and see a spectacular change on process. 
for other reader I have been consulting with big (fortune 500 and 1000) across US and EU for the last 6 years - specially when it comes to office 365 and it has become a real pain to customize without direction. I found many online training helping me to learn more on HTML to Master (how it should be) some PNP (for brave hearts not afraid breaking the entire site!) and some CSS/ jQuery tricks but so far the best one is on Udemy - look for Branding SharePoint that works (I don't remember the exact guys name) but that is my bible every time I was to customize SharePoint beyond SharePoint. 

Good luck and keep writing great articles 

Brass Contributor

@Bob German - This is a good article explaining what is possible with SharePoint Modern customization. Being an active SharePoint technical person since its 2003 version I agree that considering classic SharePoint, Modern Site pages and associated features uses most recent technologies and user experience which is truly great, "SharePoint is not boring to users anymore". 

 

Some statements from Microsoft these days causes a huge irony. For example, in this article it said is large bold text "You don't brand Word or Outlook, why should you brand SharePoint?" - SharePoint and MS Office Suite apps co-existed over few years and it was the same Microsoft who thought earlier that having a customization support master page and themes based model for classic sites was a brilliant idea and offered several supported ways of introducing the company brand in SharePoint sites. Having worked on several of Fortune 500 companies intranet pages, I have seen people liked the idea of branding their key SharePoint sites. Golden rule then was simple, keep OOTB for Team sites, and customize SharePoint design and brand for sites like Intranet Portals to reflect corporate culture and theme.

 

Hoping that when the customization framework for Modern site evolves, then there would be a different statement

"You would brand SharePoint because it's Modern Web and not Word or Outlook".

 

Cheers,

Microsoft

Hi @Arun James, glad you enjoyed the article!

 

Did you read the text underneath that headline? I went on to explain why branding SharePoint is important. I used those words because I heard them spoken several times and wanted to respond to them.

 

Sorry for the confusion!

Brass Contributor

@Bob German - thanks for your response, appreciate in clarifying that statement which indeed caused confusion to me. :) Looking forward to more options for customizing Modern SharePoint soon.

Deleted
Not applicable

Following up on the "We don't brand Outlook so why should we brand SharePoint..."

 

I'm wondering could a modern take on this be that "we don't brand the SharePoint app so ...."

 

Thanks for posting.

 

 

 

Copper Contributor
Great, hopefully on the next version you can get back to the basics like making the basic setup not as horribly complicated as it is today: I mean… setting up authentication O-M-G. You make the user base (Active Directory, LDAP, Kerberos, NTLM), you make the federation server (ADFS) and not that it matters but you also make the host and database server. At nearly 7 grand a license I would expect a flawless set up: I'm talking give me some checkboxes for ADFS, for the AD, for Azure so I can mix and match what runs where and have it federate and tokenize and certify do whatever it has to, and for seven grand, throw in the competition as well, AWS, PingFederate, G Suite, Okta, anything with over a dozen employees, there. I'm sure with our cloud magic any identity provider should be easy to find. Make us remember what exactly are we paying for 'cause the setup nightmare nor the constant discard of brands/technologies and thus investment (Office comms, Lync, Skype, Teams--seriously!?), isn't worth it. Just the other day, on brand new, well, it was newer then, SharePoint 2019 I spend forever writing on a Wiki I thought it's be trivial to localize in to another language but the docu and the process were so frustrating that I ended up storing the server in favor of a DokuWiki instance, occupying a few megabytes to serve the site. Theming it to carry the color scheme I had in SharePoint was a matter of changing some hex colors, all in its included GUI. 5-7 minutes finding how it's done plus installation, another 5-7 to copy/paste the content from SharePoint. That sort of efficiency and user friendliness that the free software delivers should be first and foremost in Enterprise-grade software. ...and no, Azure is not the answer for everything. Forget the next version, fingers crossed for maintenance updates. I know now that we have our farm online again, we'll keep an eye on updates, because it's true that SharePoint does feel more…"airy". Much more pleasant.
Version history
Last update:
‎Sep 01 2020 02:21 PM
Updated by: