This series of posts is border line ridiculously long, but I hope it is a fruitful endeavor nevertheless. In my vast journey's around the great world of SharePoint, I have drawn many conclusions on what is good to do and what is not so good regarding SharePoint branding. I started documenting my thoughts in what will become a whitepaper on the subject, but it became clear to me early on that the whitepaper will be quite lengthy, and since I still have a day job, I figured it best to break it up into a series of posts with the paper serving as a supplemental and combined read when it is finished. My goal in this series is to outline the best practices and major concepts, the "what" when it comes to branding, and to outline the "how" and detailed steps in the whitepaper that will follow. Hopefully I will have the 10 posts done within the next 4 weeks (among posts on other subjects I plan on doing), with the whitepaper to follow 2 weeks thereafter.

Additionally, my desire is that these posts will generate feedback, enough so that the community can help shape the outcome and depth of the top 10 list. I will also use such feedback to help shape the contents of the whitepaper. Feel free to leave a comment if you want to contribute or raise concerns around my conclusions. Also – be sure to check out Bill & Ben's new book on SharePoint best practices, that book is sure to be a hot seller.

Branding SharePoint Best Practice #1:

The very first tool that comes to most people's minds when it comes to SharePoint branding is SharePoint designer. SharePoint designer is a power tool that interfaces directly with SharePoint sites, and enables you to customize the look and feel of those sites even without writing code. However, there are some special considerations that need to be taken into account regarding Designer, and in many cases if the implementation of this tool is not thought through, undue hassle can easily arise.

The main issue with Designer is also its greatest strength. The phrase "Wild, wild, west" helps translate the issue, in that the ease of use that the tool brings to the table can lead to an uncontrolled and inconsistent environment. The purpose behind the tool is to give SharePoint end users the ability to do things that typically only developers can do, which is good, but it also makes the environment feel like a "sandbox". The information technology department spends thousands building a brand for the home page, but as you drill lower, that brand starts to dematerialize. Some sites are pink, and some are blue. Some are even broken entirely because a user didn't know quite enough to not delete a particular control. The key here is brand consistency. With Designer enabled it is impossible to force brand consistency across an entire farm, because of its prevalence to end users. Designer is a powerful tool, but with anything, power is only a good thing in the right hands.

The solution to this isn't just to not give Designer to the masses, because any ambitious soul could pick it up from their favorite software retailer and they would be off to the races on any SharePoint site they have full control on. A better option is to disable the use of designer across your sites entirely. You can do this by making changes to the 12 Hive file system on each web front end in the farm (See appendix A for more details in my upcoming whitepaper). However, this isn't right for everyone. One reason you like Designer is its workflow capabilities. A savvy end user can build workflows themselves, saving the IT department valuable resources. If you disabled designer, end users won't have access to this workflow functionality. Also, designer can maintain brand consistency across any given site collection. If a given brand is only going to be applied onto one site collection, all sites within that collection can be made to use that brand (See appendix B in my upcoming whitepaper on how to configure this). In that case, Designer can be a helpful tool. However, most companies have hundreds, if not thousands of site collections, which raises this consistency concern. If you're a developer and you need to change a logo, you're not going to want to edit one thousand copies of a master page. This in turn leads to the drawing of the first of ten best practices for branding SharePoint sites, to only use Designer to brand sites when the scope of the customizations will never need to grow beyond a single site collection. That and to disable it all together if possible.

The recommended alternative to using SharePoint designer to brand sites is to build custom site definitions that are controlled and maintained by a SharePoint team within IT. The next post in this series will discuss this concept in detail.