You will likely run into issues when developing a custom design for clients’ large, responsive SharePoint implementations that utilize the full stack of Office 365 features. These features leverage SharePoint Online, Office suite, Skype for business, One Drive, Delve, and integrations with some pretty cool third-party products like DEG Dialogue. To minimize those issues, I’ll introduce some of the dos and don’ts when designing a custom UI for SharePoint Online and Office 365.
Learn more about DEG’s Portals & Collaboration
practice and Microsoft
By now you have probably heard Microsoft’s rant about not customizing master pages for SharePoint Online unless you want to pay the consequences. Custom master pages are still supported, but before going all in, here are some of the things to consider.
SharePoint Online is evolving constantly
The main argument against customizing master pages revolves around the fact that Microsoft updates SharePoint Online with new features on a regular basis, and these updates can affect certain types of customizations. So, if you are making master page changes, it’s up to you to stay up to date with the ongoing product updates applied to SharePoint Online. Luckily, you can preview new changes within your tenant by going to the SharePoint Online admin center and enabling preview features. This by no means is bulletproof, since bug fixes might be pushed at any time. However, you can proactively find out more about the Office 365 roadmap.
Bottom line: customize your master page only if you are prepared to constantly babysit Office 365 features and quickly react to them.
Office 365 Services extend beyond SharePoint
When implementing a custom UI for SharePoint, always consider other services such as One Drive, User Profiles, and Delve. Any CSS, JS, or master-page customization applied to SharePoint will not propagate across these other features. The only shared tool is the top suite bar. Fortunately, the top suite bar can be partially customized by using Office 365 themes. Themes are pretty limited, but at least colors and logos can be configured.
Switching declarative XML provisioning to a code-base approach
First, for the non-developers out there, what is XML provisioning? In general terms, XML provisioning is the automation of all steps required to upload, deploy, create files or resources on a SharePoint site. You do this by using XML files containing a list of instructions to define what these resources are, and what properties should be applied to them. Up until SharePoint Online, this was the recommended approach for packaging and deploying SharePoint components. This approach was a time-saver, since modern tools such as Visual Studio can generate most of the XML markup for a SharePoint 2013 deployment. However, it always caused some headaches when upgrading to the next version of SharePoint, mostly due to cross-file dependencies. No wonder Microsoft is against it now.
So, what to do in the future? Use remote provisioning, which is a code-based approach that programmatically created every element (fields, content types, files, libraries, webs) on your site. There are multiple resources online (some of them below) to help you get started with this new model. Nonetheless, switching development approaches will require more development time, so keep that in mind when assessing costs.
Avoid custom master pages
Microsoft maintains control of a set of master pages, allowing them to regularly update Office 365’s ‘evergreen’ platform with new functionality. So, when you apply a custom master page to your site, even if it is an exact copy of an OOTB master page, your new master-page version will grow increasingly out of date. This popular graphic borrowed from a conference presentation explains it.
Just keep in mind that custom master pages are still supported, but not recommended, in order to minimize future maintenance. As a rule of thumb, you may consider custom master pages or web templates only for publishing sites, and avoid them for team or collaboration sites.
If you would like to learn more about the pros and cons of custom master pages, this blog post is a great resource.
Need an expert partner?
Contact us to start maximizing your intranet’s potential.
Leverage Office 365 and SharePoint themes
One of the recommended options for branding SharePoint Online and Office 365 is using custom SharePoint themes. Themes allow you to define colors and fonts to support your corporate brand standards. For SharePoint sites, there is a tool for creating themes called SharePoint Color Palette, which provides a user-friendly way to generate a color palette file for your ‘Composed Looks’. This blog post will teach you exactly how to set things up. Unfortunately, SP themes, or ‘composed looks’, do not apply beyond SP for sites, such as One Drive, Delve, Admin dashboard, etc. However, Office 365 provides a rudimentary theming engine to customize the top navigation bar (colors, fonts, and logo) for everyone, everywhere.
Follow Office365 PnP (Pattern and Practices) development recommendations
Office 365 PnP is a community-driven set of recommendations, documentations, and samples to help you transition your development from full trust, on-premises solutions to SharePoint Online and the app model. I cannot emphasize this enough: download the samples, watch the videos, and read the guidelines (links below) before starting any custom development for Office 365.
There are three main branding best practices for SharePoint Online that are different from its on-premises counterpart. First, use alternative CSS instead of adding references to files on your master pages.
Finally, adopt the remote provisioning pattern for ‘deploying’ components to your SharePoint sites (fields, content types, lists, pages or files).
If you have any other questions about designing custom UI for SharePoint, let us know in the comment section.