To Brand or Not to Brand...What Was the Question?

While I was pontificating on the need for improved customization in SharePoint v.Next, Andy May suggests that it might be a good idea to find out if your client really wants to tackle the task of branding their portal. A fair question, and one that my clients have answered in multiple ways, from nothing more than an altered site logo to full, file-by-file customization of definitions and templates. As Heather points out, it's not that difficult to brand a portal implementation if you leave the underlying architecture definitions alone.

In my mind, there are three distinct types of scenarios:

1) Stock Portal - No branding or customization required. If you have limited resources or need to focus your resources elsewhere, such as application development or training, this might be the best option. This scenario is often chosen by those with little exposure to Intranet/Portal applications who just need a quick and affordable solution.

Example:




2) Branding - Applying a custom logo, colors, backgrounds, borders, fonts, buttons and other visual elements can be done in a few days from scratch or a few hours if you have a CSS template to work from. Assuming that time and resources are available, branding is an effective way to reinforce a corporate identity and create continuity with other line-of-business applications. Organizations with existing Intranets or portal-like applications often choose this route as it is both affordable and relatively painless. It is also a very good way to learn more about how SharePoint works behind the scenes.

Example:




3) Customization - Let there be no doubt: full portal customization is difficult, time consuming, expensive, and requires a high degree of skill and patience. Only clients who have deployed extensive portal solutions in the past request this level of modification, and rightly so; they have a solid understanding of the cost and risks involved. At best, a complete portal customization can be done in 30 days (I've done it and it was no picnic, believe me); at worst, it could take several months. And that's assuming that you're well-versed in all the mysteries of SharePoint; a neophyte who has to learn on-the-fly may never make it out of SharePoint Customization Hell alive (figuratively speaking, of course, and thanks to Heather for the highly appropriate terminology).

Example:





In the final analysis, it is up to you as the consultant or subject matter expert to explain these options to your client (or decision makers if you are part of the organization), make sure they understand the risk/reward ratio, and provide a realistic estimate of time and cost. One of the most common mistakes I see when consulting with clients regarding customization is the perception that SharePoint is limited in what you can do with the user interface. True, there are certain parameters which influence what the final outcome will be, but the truth is that there are very few things you can do with any web application that you cannot do with SharePoint.

I've discovered that even those who have worked with SharePoint for a good while are unaware of how extensively the product can be customized; not surprising, considering that most people probably give up after fighting with multiple site definitions, scads of similar-but-slightly-different list pages, CAML, never-ending XML files and a confusing maze of CSS. I don't blame 'em - it's enough to give anyone a headache (I keep an emergency supply of Advil on hand at all times).

Personally, I prefer a branded or fully-customized implementation over the stock look-and-feel simply from a business perspective. You wouldn't create an application or web site for a client without taking their corporate identity into consideration; the same applies to a portal implementation - you shouldn't avoid it just because SharePoint makes it more difficult than it really ought to be.

Here are a few tips to ease the pain:

1. Lean which CSS classes need to be modified to achieve your branding objectives and place them into a separate file, then use the custom CSS setting in portal admin to implement your alternate style sheets.

2. When overriding the default CSS classes, create a consistent structure that makes it easier to customize the files in the future (I like to nest related classes and define common elements, such as default fonts and colors, at the top of the file).

3. Once you've established the bare minimum required for branding a portal, use that CSS file as a template so you can apply it to subsequent implementations.

4. Study the Site Definition structures for patterns. Many of the files have similar code elements but for a few variances; learn what they are and where they occur. Once you have created a working definition, copying the files to new defs is mostly search-and-replace (your life will be much simpler with good diff and HTML search/replace tools; I suggest Beyond Compare and Search & Replace 98).

5. Do the same for admin pages in the /layouts/1033 directory. Take note of what works where (some pages are WSS only; others SPS; many are both). Learn which pages alternateheader.aspx works on and what it's limitations are.

6. Make extensive use of user controls (ascx pages). Like the include files of old, user controls give you the capability to modularize your definitions, sharing common code structures throughout the portal. All they require is a simple code registration in the header to tell the page where to find the file and what it's called. This can save you an immense amount of time and frustration. And, best of all, user controls allow you to execute code that may be blocked within certain files (did I mention alternateheader.aspx yet?).

7. Learn which web controls (<SPSWC:> elements) pages require and which can be deleted. Most pages can simply be wiped out and replaced with your own code but some, like txtlstvw.aspx, require fixed page elements in order to render properly (here's a hint: just comment them out, change the ID values, then substitute your own custom elements with the original ID's). Many Admin pages require the PortalHeader element but that doesn't mean you have to display it - just hide that pesky critter and go on about your business.

8. Watch those registrations! Some pages that look the same on the surface use different components to achieve similar results. Check the registrations at the top of the page to make sure that you have the right elements on the page. If you make extensive use of inline code blocks in user controls or admin pages be sure to include Microsoft.SharePoint.WebControls or the code will fail.

9. Look closely at the XML configuration pages. CAML is nothing more than a fancy superset of XML; anyone with a little bit of coding background can quickly determine what the programmer was trying to achieve and duplicate/alter it accordingly.

10. Get the SPS SDK and use it. It doesn't cover everything but there's a lot of good information in there that will help you out when you get into a bind.

11. Don't be afraid to break something! Test your changes extensively in an isolated sandbox that you can wipe out if things to awry. Keep a full copy of the original 60 hive handy to replace any modifications that don't work. Modify in small increments and test after each change, then proceed to more full-scale alterations.

12. Ask for help. There's no better resource at your fingertips than the SharePoint community. Yes, we all have day jobs, but we're happy to lend a hand if you need us. It takes time to maintain a blog or answer newsgroup postings; if we didn't care, we wouldn't do it. If we don't know the answer we can probably point you in the right direction.


Good luck!