Not that long ago, it was quite typical to create a major SharePoint UI solution for a SharePoint intranet. It would contain one or more Master Pages, CSS stylesheets, images, JavaScript, Page Layouts etc. The solution package was deployed to the server, the feature activated and automagically the intranet got its fancy custom UI and functionalities. A slight inconvenience though, that even the smallest change or improvement in any of the shipped files required updating the whole package.
It hasn’t been too long since I last was involved in such a big intranet solution. These days such projects are more of the exception than the rule. So, what’s changed?
One thing, or maybe I should say THE thing is Office 365. Cloud is becoming more and more popular and doesn’t even allow such huge full-trust solutions. Sandbox solutions are still an option, though according to Microsoft they are not the technology of the future – they already once declared them deprecated, but actually had to take it back pretty quickly. However, apps and other alternative ways of doing things (PowerShell, Azure powered functionalities etc.) are the modern and flexible way to build stuff on top of SharePoint, while keeping it separate from SharePoint.
I believe it’s not inaccurate to say that all the rest is just a byproduct of this. While more and more companies are switching to the cloud environments and Microsoft is developing “cloud first”, it is only natural for attitudes and ways to adapt to this change. Lightweight tweaking as opposed to heavy – especially with a heavy update process – custom software development sounds quite enticing.
Years ago, when SharePoint 2010 was launched and companies started to migrate from the old 2007 environment to the shiny new SharePoint in a fast pace, the game of the day was using OOB where ever possible and doing as little customization as possible. Mostly this still meant creating easily retractable solution packages for UI and custom web parts and services, distributed as features. SharePoint wasn’t re-coded anymore as it used to be in many cases with MOSS 2007; the solutions were built on top of SharePoint without touching the OOB stuff.
Then, along came SharePoint 2013. For quite some time the development and customization story was pretty same as with 2010, up until Online made its breakthrough and started to mold the models towards the more lightweight facelifts, apps, external services etc. The process of UI customization, branding, has shrunk from a heavy solution package to creating themes, some custom CSS and maybe a bit of JavaScript.
A color theme is a rather easy and quick way to apply the company branding colors to SharePoint. It already takes you a long way – the company colors are applied to the top suite nav, links, emphasis colors, headings etc. Creating a font scheme adds to this by implementing the company font – even a custom one – everywhere with one setting. What cannot be done by a theme is changing the placement and fancier styling of page elements.
The current default Master Pages seattle and oslo are built using div elements. This means that working with them – the placement, float, etc. – is pretty flexible and easy without needing to change the HTML of the Master Page, i.e. there is no need to create custom Master Pages simply to change how and where the elements are rendered on the page. There are limits to this, but you can do a lot with CSS.
Themes and an alternate CSS stylesheet are easy to implement in the UI of SharePoint, in the site settings, and they are inherited by any subsites with publishing feature activated. Implementing them to sites without publishing feature is a bit more work. Generally, this means pushing the inheritance from the top level each time a new site has been created.
JavaScript adds its own challenge to the equation. It is possible to globally inject JavaScript to all sites in a site collection using PowerShell. However, this should then be done for each new site too, when one is created. In single pages the Script Editor Web Part works nicely, but the global injection is always a bit of an issue. Mainly the options apart from the manual PowerShell injection are adding the script links to the Master Pages or creating an Azure powered service for provisioning the sites.
The latter option is actually something to consider. Basically the idea is that people don’t create their sites manually but order them by creating a new item into an order list. A timer job polls the list and notices a new site order and launches a PowerShell script that then provisions the site with the exact settings, stylesheets, logos, Web Parts, lists, JavaScript links that are needed for each new site.
Add responsive design to the equation. Currently SharePoint Online offers two view for mobile devices and the possibility to switch between them. One is the mobile list oriented view, the other one the full desktop view. The list oriented view works fine in team sites where all the content is mainly in lists, but publishing sites, the informative intranet pages, need to be viewed in full desktop experience on mobile devices too – in a responsive way so that it actually is readable.
Unfortunately, responsive SharePoint is still a bit of a everyone for their own – or has been, but I have just discovered that PnP has actually come forth with an awesome fully responsive solution that is purely CSS based! Previously the options have been e.g. bootstrap (heavy version), a responsive SharePoint solution from Codeplex (kinda heavy solution too); both of these require changes to the MasterPage. A bit of a no-no.
Be as it may, responsive design is always more expensive for a customer than the basic design only. However, as the costs of branding have come down significantly with the lighter approach, it most definitely pays off to invest in responsive design, if not go mobile first. That’s where this world is headed anyway.
[Originally published in Finnish in our company blog]
No comments:
Post a Comment