The SharePoint customization conundrum

Posted by Eric Shupps on May 4, 2016 11:56:46 AM

Back in the early days of mass SharePoint adoption (circa 2008), the most popular request from customers was to make their shiny new intranet “not look like SharePoint.” It was a reasonable request; after all, the product was created to simplify online collaboration and document management, not to be an internal marketing platform, so the user interface naturally reflected a utilitarian design aesthetic that many found less than appealing. Of course, that didn’t stop customers from taking the platform in all sorts of directions it was never meant to go, the result of which was a proliferation of highly-customized implementations that required a great deal of time, money and custom code to deliver.

As the product matured, features were introduced that made it somewhat easier to create a branded user experience. Custom master pages, themes, publishing pages, design manager, and so on all purported to make the customization process easier and more supportable. With maturity came a certain amount of hindsight and clarity into the challenges that heavy customizations created. But it seemed that no matter how much Microsoft changed the basic user interface, customers would continue to demand a branded experience that was as far away from the out-of-the-box design as they could possibly achieve, even when such customizations made it difficult or outright impossible to upgrade to the next version.   

And then came the cloud.

Suddenly, despite years of trying to give customers what they wanted in a platform that wasn’t explicitly designed for it, Microsoft abruptly changed course and started advising customers to avoid SharePoint branding whenever possible. Customer master pages? Out. Web templates? Deprecated. Full trust code? Undesirable. While this decision makes a lot of sense in the cloud, where there is no possible way Microsoft can support millions of customers all changing the core look and feel of their service, the message was also pushed downstream to on-premises customers. Branding had become the visual equivalent of site definitions, a complex yet extremely robust mechanism that, although used internally throughout the product, quickly fell out of favor when customers (often with the help of ill-qualified consultants) started making a mess of their SharePoint farms by doing it wrong.

Even now, with many organizations having moved completely to the cloud, one thing hasn’t changed: They still don’t like the out-of-the-box user experience. Part of this is due to the legacy ASP.NET architecture of SharePoint, which makes things like responsive design and fluid branding extremely difficult to implement, and part of it is Microsoft trying to please everyone with major iterations in interface design that, in reality, ended up pleasing nobody at all. But an even bigger part of the equation is the requirement to reflect the organizational design ethos within the company intranet. For some customers, this isn’t just a “nice to have” feature: It is a key part of their organizational DNA, and they simply cannot deploy a critical business platform without applying their own branding principles.

So what can be done to reconcile the desire of the vendor to minimize customizations with the desire of the customer to provide a branded experience to their users?

First, it helps to understand exactly what Microsoft is saying. Despite what many may think, there is no official guidance advising against all customizations. While Microsoft would certainly like to see customers move away from custom master pages and other heavyweight design modifications, they haven’t said customers absolutely cannot use them. Rather, they are trying to help customers understand the long-term cost of such initiatives. In the cloud, where iterations occur rapidly, customizations can break more often than they do in a more controlled on-premises environment, resulting in a great deal of effort and cost required to maintain complex customizations. Furthermore, many customers with highly customized experiences will miss out on valuable new features because their design changes will not easily facilitate them.

Perhaps most importantly, customers need to understand that they are buying a service, not a product, when they purchase SharePoint Online through Office 365. It helps to think of it like a vehicle lease compared to a traditional purchase. When you lease a vehicle, it comes with restrictions on things like modifications, miles driven, types of use, and so on, whereas purchasing one allows the owner to do whatever they want with it. Following this metaphor leads to an obvious conclusion: If you want to heavily brand SharePoint, then buy it outright and deploy it on-premises. Don’t try to impose company design principles on a vendor-provided service that is subject to frequent change, as that will inevitably lead to costly maintenance and reductions in functionality. Instead, deploy the full product into your own data center where IT personnel can dictate the pace of change more effectively.

As a service, SharePoint Online has some very compelling selling points but one thing it absolutely is not is a good corporate intranet platform. Intranets are internal-facing platforms that, by their very nature, are expected to promote organizational design themes, integrate with core line-of-business applications, provide employee-centric information, and facilitate organization-wide collaboration. That sounds like a product you buy, not a service you rent. Here’s the great news: If that’s what you want, Microsoft has you covered! SharePoint, the tried-and-true product used by thousands of organizations across the world, will continue to provide a great platform upon which to build highly customized intranet solutions capable of meeting the needs of just about any organization, no matter how demanding their requirements.

In technology, there are a lot of gray areas and very few absolutes, but the decision to customize or not to customize SharePoint is actually easier to make now than it ever has been. Need a robust collaboration solution that can be quickly deployed, requires no capital expenditures, integrates with corporate identity-management systems, and provides worldwide, highly-secure accessibility? SharePoint Online via Office 365 is only a few clicks away. Need to create a scalable, feature-rich corporate intranet platform that can be fully customized and extended to meet a unique set of requirements? SharePoint 2016 is right around the corner, ready and waiting to take its place in your data center.

Most of the confusion surrounding the SharePoint branding story comes from mixing up these two very clear-cut choices. Once the decision has been made to go the customized route, it then becomes a simple matter of choosing a mechanism that works best in your organization: farm solutions, add-ins, low code, no code, or any combination of the above that effectively meets the requirements. If you avoid the temptation to try to force square pegs into round holes, then there won’t be any customization conundrum in your organization. Which is exactly how it should be.

Topics: SharePoint customization

Thoughts? Leave a comment: