In a recent article by Redmond Magazine, titled The SharePoint Future Isn’t Cloudy, It’s Hybrid, a negative perspective on SharePoint branding caught my attention. Here it reads:
The Branding Problem
Klindt said that SharePoint’s native interface can be kind of “overwhelming” for end users. Just having the SharePoint name on a portal can seem kind of “dirty,” he added. Consequently, there’s an impetus for organizations to customize SharePoint and brand it.Himmelstein pointed to the issue of putting branding on SharePoint as one of the No. 1 problems for organizations. He said that branding just needs to be selective. IT pros should not put branding across a whole SharePoint farm as there will be performance penalties. He added that some people think of SharePoint as a developer platform, but it just should be kept simple. Organizations should look at ways of customizing SharePoint without writing custom code. “Don’t let the developers into your platform,” Himmelstein added.
Klindt said that there’s a “technical debt” that comes with altering pages and CSS with SharePoint.
“Branding is mostly just terrifying for me,” Klindt said. “If everything didn’t go with blue jeans, I wouldn’t be able to dress myself in the morning. But I think with any kind of change you make — anytime you deviate outside the [SharePoint Server] box — there’s going to be a cost to that.”
In keeping with the theme of the talk, Klindt noted that Microsoft doesn’t allow branding for its SharePoint Online service. It could be a tacit acknowledgment of the branding problem, he speculated.
Jason Himmelstein and Todd Klindt address the negative implications of SharePoint branding and encourage organizations to keep the platform “simple” in order to prevent performance penalties. The idea behind branding across a whole SharePoint farm is unadvised, “terrifying,” and the number one problem for organizations using SharePoint. At the same time, Klindt acknowledges the growing desire to customize SharePoint as the native interface can be overwhelming for users.
So how does an organization reconcile those two conflicting objectives?
No one can argue that from a pure engineering perspective, it is ideal to avoid branding and other customizations. Maintaining a “clean” environment makes migrating and applying updates less prone to issues. However, while avoiding customizations may reduce potential performance penalties, it also impacts adoption and limits the solutions SharePoint can enable. By preventing one problem, you’re creating another with potentially more significant impacts. If user adoption is low because the interface is overwhelming and lacks an intuitive user experience, utilizing SharePoint at all becomes less attractive.
Deploying custom branding solutions while maintaining responsiveness and minimizing the risk of issues is possible. We’ve done, and we’ve done it successfully many times. Branding the portal in a way that maximizes the user experience and minimizes risk is the goal. This is accomplished by designing the branding solution to be minimalistic and avoid areas of the SharePoint interface that are most likely to be impacted by updates and service packs. No custom branding solution of any substance can be designed without some risk of issues or consume slightly more resources than the default interface. However, developing one which drastically improves user experience and maintains a low likelihood of issues is very possible.
If your needs are such that you can get away with building a SharePoint portal without involving developers inside your platform – do it. That should be your first option, not your only option. Be smart about your branding initiatives and have clear objectives defined. There is such a thing as “bad branding” so it’s important that critical questions receive thoughtful answers on the front-end. Ask yourself:
- Where am I storing collateral?
- Am I customizing areas of the page that are likely to change in an update?
- How often is my portal used?
- What are my adoption goals?
- How am I caching content?
I also think it’s an important distinction that technical debt is not always directly related to altering pages and CSS with SharePoint. Technical debt is accrued from shortcuts taken by solution developers to get across the goal line and pays interest in the form of increasing maintenance costs as the system evolves. Technical debt is no more likely to accrue in a SharePoint branding initiative than it is with any other custom solution.
So, before you dismiss the prospect of branding SharePoint to avoid performance penalties, consider the penalties you might face by presenting an inferior user experience. Then do what makes the most sense for your organization. Light branding at a minimum is a requirement to maximize end user adoption. Without it, we agree SharePoint can be overwhelming and dirty!
