Branding SharePoint Online

In Blog, Branding, Development by Janniek starren

Options:

  • Custom Masterpage
  • Page Layouts
  • Alternate CSS
  • Display Templates
  • Themes (composed looks)
  • Third party packages
  • Inject JavaScript (CSOM)

Custom Masterpage
Challenge:
When a custom masterpage is used, the standard O365 masterpage is inherited. As O365 has a gradual evolution (evergreen) this would leave the custom masterpage without the rolled-out updates or in the worst case break customisations.

Mitigation:

  • Discuss with client if identifiable potential changes to the masterpage are required in the future (O365 roadmap)
  • Do not change the default masterpage. This will ensure that the standard masterpage is updated manually when new and desired features roll out.

However this may also lead to a potential issue, the branding applied via alternate methods may not be valid any longer when overwriting standard SharePoint classes that may be deprecated or superseded.
Retaining the evolution of functionality across SharePoint Online may be a good path to go down for some customers, however, there may be clients that would rather control which functionality is released to the end-users by updating the master page at a later stage after PMO, change management and training for end-users.
In the latter case it can be beneficial if gradual updates do not get included in the masterpage.

Page Layouts
Masterpages wrap around page layouts. There is no discoverable mention that page layouts would also contribute to loss of data as, as far as SharePoint is concerned, only structure editable content on a page. It is the masterpage that holds the quick and global navigation, ribbon and suit bar.
Therefore the page layout can be used to create HTML structures that include placeholders for editable content, but also allow for

  • CSS references
  • JavaScript references
  • Non editable HTML structures, such as layout elements or DIV Id’s that can be populated by JavaScript.

By changing the page layouts to implement the desired design, you can, almost style everything that is required, without touching the masterpage.
The downside of this approach is that every page-layout that is created must have the html structure and references defined. This means that in a publishing environment, only the page layouts that have the custom design implemented, can be used through-out the intranet.
Planning of the page layouts and configuration on the site-collection level of useable layouts when creating and editing pages must be managed.

 

Alternate CSS
The masterpage elements that need to be changed can be altered by their css class or id in a custom css file and linked to the masterpage via the site settings.
Most styling and even placing of elements can be achieved by CSS. Powerful but simple example by Heather Solomon:
http://blog.sharepointexperience.com/2015/02/sptechcon-austin-february-2015/#more-2766
The risk in overwriting the SharePoint CSS classes is that they may change during roll-outs, breaking the design customised design for end-users.
Changing only the CSS won’t allow to add JavaScript libraries, however they could be added to the page using a script editor, obviously, this would need to be done on every single page where the library is required.
When JavaScript is used to build an application such as a chart or slider the CEWP can be used, linking to a .js or txt file that is stored somewhere in an accessible SharePoint site.

Themes (composed looks)
Themes come out of the box with SharePoint and can be used to change the colour scheme of common elements and are linked to Master pages.
The out of the box functionality provides a broad scala of different options and colour schemes, however as the themes are still linked to the master page, the SharePoint ‘look’ remains, it is just this that many want changed.
Themes (composed looks) can be created by making a .spcolor file or by using a GUI provided by Microsoft ‘SharePoint Colour Palette Tool’.
Themes are great to use in combination with custom page-layouts. In this case the page layout will define the look of the page, whilst the theme can be used to define the colour of the SharePoint aspects.
The themes can also be used to distinct colours between sites.

Third Party
There are a number of third party providers available that do support designs for SharePoint Online. These packages do change the master page.
Examples are:

 

Via CSOM
The SharePoint product team has released certain patterns and best practises to deploy designs via CSOM and VS.
For more information, download the .sln’s and watch the video in the resources.
So then, what is the best approach…
Bottom line is that the community is divided on how to proceed and looking at this document, I would say it is also dependant on the business requirements. Ask yourself the following questions:

  • How often does SharePoint really change? (The roadmap provided by Microsoft gives a good indication).
  • What will be the impact and how can it be managed?
  • Do I really need to change the master page

For me, the approach is to

  • Leave the masterpage alone.
  • Use Page Layouts to dictate the look of the site and to reference libraries where required.
  • Create a custom CSS file to create the CSS for custom aspects of the design or to overwrite SharePoint classes
  • Attach the CSS file via the Alternate CSS method.
  • Use a theme for the overall colour scheme, only create a custom .spcolor file if you absolutely must.
  • Use the theme to define a background image if such a thing is still used in this day and age.

But what about responsive design?
Let’s be honest, SharePoint has missed the responsive design boat completely, although device channels can be used, but I find it tricky.

Alternatives are to use bootstrap, it’s library can be included in the page layout or use @media in CSS to determine viewports.
Be aware that web parts (this includes document libraries) do not necessarily play nice.
Mind you, SharePoint has been playing catch-up on this front and I am expecting changes here in the near future. If the mobile view feature is activated, you will notice that document libraries are already fairly responsive. (WPC/_layouts/15/touchapp.aspx?Mode=)
Therefor my approach is to make pages responsive, leave the system pages (including libraries) be what they are.