The first factor that must be considered is where the customization changes will be stored. Depending on the tools used, customization changes will be stored in one of four places:

The location of the stored changes is important because it will have a long-term effect on the scope of future changes that may be made. For example, if SharePoint Designer 2007 is used to edit a master page, then the results will be stored directly in the content database used by that site collection. This process is called customization. The customization process has the negative effect of limiting the scope of any future changes to this particular site. Activating the publishing infrastructure feature can partially mitigate this limitation by allowing inheritance of changes made to a master page to all sites in a site collection. But most publishing master page modifications are made via SharePoint Designer 2007, and the publishing infrastructure feature doesn’t change how SharePoint Designer 2007 works; changes are still stored at the site level in the content database. The advantage is site inheritance, and through inheritance the scope of future changes will be expanded to the site collection. Even so, the changes made with SharePoint Designer 2007 never apply beyond the level of a site collection. However, modification made with Visual Studio and deployed to the 12 hive will affect the entire farm. For instance, a master page deployed to the 12 hive with Visual Studio can be referenced by pages throughout the farm.

Another factor to take into customization consideration is security. Modifying security to remove elements from the page can lead to performance issues due to a decrease in caching effectiveness. SharePoint Server 2007 pages follow a pattern in which a control is placed on the page that is always visible, but what happens or what is displayed in a submenu when that control is activated varies depending on the security of the user. For example, most SharePoint Server 2007 pages contain a Site Actions menu that is displayed for anyone who has more than read-only access to the page. But when the Site Actions menu is activated, users see only the menu entries to which they have security access. This allows the main page to be cached in only two formats, one for Read Only and one for other users. Adding code to the page that removes or hides the Site Actions menu would cause excessive invalidation of the ASP.NET Page and Fragment cache. This excessive invalidation results in an increase of trips to the SharePoint databases and a resulting decrease in Web front-end server performance. This example demonstrates why it is considered a best practice to apply security to the results of an action on a page rather than applying security to objects on the page itself.

Audience targeting is another native capability that can be leveraged to customize what a user sees on a page. Audiences are not the same as security. For example, if the contents of an existing Web part are being filtered by an audience, a user can add another instance of that Web part that is not filtered. Audiences provide a way to provide content relevance and should not be used as an alternative security mechanism. A good use of audience targeting is limiting which Web parts show up on a shared page based on audience membership.

Activating the publishing infrastructure feature for a site can affect the choice of tools for branding. As we have already discussed, activating the publishing infrastructure feature provides for inheritance of master pages from the top-level site of a site collection to subsites. This inheritance increases the scope of changes made using SharePoint Designer 2007. Additionally, the use of the publishing infrastructure feature can affect branding decisions in other ways. For example, when a user creates a new page in a site where publishing has been activated, she is required to use a preapproved page layout for the new page. This extends a company’s ability to control the look and feel of the pages within a site beyond the constraints applied by a master page. Master pages are used to provide a consistent framework of navigation, colors, and the basic layout of a page, but publishing layout pages provide control down to the level of content placement and formatting.

Prior to the inception of ASP.NET 2.0, Web pages usually enforced a common look and feel by using a common set of user controls or HTML includes files. ASP.NET 2.0 introduced the concept of a master page. Think of a master page as an HTML template that contains named regions where content from an HTML content page can be inserted. The regions on the master page are called content placeholders and are actually ASP.NET server controls. Content pages are composed of ASP.NET server content controls that encapsulate all of the content to be displayed on the rendered page. When a content page is requested from the server, the associated master page is retrieved, content is inserted into the content placeholder controls, and the resulting page is rendered and returned to the user. SharePoint Products and Technologies fully supports the use of ASP.NET 2.0 master pages.

Master pages make it easy to define the overall look and feel of pages in a site. A master page is created using HTML just like any other Web page, but in the case of a master page, spaces are left for content to be filled in by placing content placeholder controls at the appropriate locations. Because any HTML in the master page applies to all rendered pages that use it, the overall look and feel of a site can be changed by simply changing the master page. The master page also provides one file that can define how events are handled for things such as site navigation. This prevents errors that find their way into code through duplication. It’s always a best practice to keep common code in a single centralized location where it’s easier to manage. Figure 11-2 shows some content placeholder controls on the default.master master page being edited in SharePoint Designer.

Figure 11-2. Content placeholder controls on the default.master master page

Although master pages provide the promise of a single centralized file to define the branding of a SharePoint installation, how the master page is created, modified, or installed can detract from the efficiency of this approach. Master pages created or modified using SharePoint Designer can be customized and, once customized, will no longer reflect changes made to a centralized master page stored in the 12 hive. Each site where the master page was saved using SharePoint Designer will have its own unique copy of the master page. Activating the publishing infrastructure feature will expand the scope of a master page to an entire site collection, but there is no easy way to synchronize customized master pages across multiple site collections, Web applications, or an entire farm.

SharePoint Server 2007 also makes use of many pages that are not stored in the content database in either a customized or uncustomized fashion. For example, the page for uploading files into a document library is retrieved from the _Layouts virtual directory that is mapped directly to the TEMPLATE/LAYOUTS directory in the 12 hive. These pages all use a master page called Application.master, and it is also stored in the 12 hive. Unlike other master pages, there is no way for files in the _Layouts directory to use an alternative master page. The only way to brand the Application.master page is by directly editing the page on the file system. Because this page may be overridden automatically by an upgrade or service pack, it is never a good idea to change one of the default files in the 12 hive.

In addition to master pages, SharePoint Server 2007 makes extensive use of cascading style sheets (CSS). The default style sheet is CORE.css, which contains over 800 styles. In a default SharePoint Products and Technologies installation, styles are used to control things like the height, width, color, and fonts used by controls on the rendered page. But CSS can also be used to reformat the rendered page of a SharePoint site. When used in conjunction with HTML, <Div> and <Span> tags have the advantage of decoupling the contents of a page from its eventual layout. This can be used to create a site that is more compliant with accessibility standards for devices like screen readers because it replaces the use of tables, rows, and columns for formatting the rendering of a page.

Although custom CSS files can be used to change the layout of a Web page, there are several potential problems with this approach. First, this would require a complete rewrite of the master page to remove the hard-coded table, row, and cell elements that currently format the page. Second, this would provide no practical advantage because the page is already abstracted via the required master page. A third problem is that browser support for advanced CSS is often inconsistent. This may limit who can effectively view the customized site. Because of these issues, it is best that the use of custom CSS be limited to controlling the visibility and styling of elements on the Web page and not their layout.

If CSS is used only to control styling and not layout, how will sites be made compliant with the current accessibility standards? The problem isn’t that sites that use HTML tables can’t be compliant with accessibility standards; it is simply more difficult. Although the default SharePoint Server 2007 sites fall short of meeting accessibility standards, Microsoft began working on a toolkit shortly after the release of Windows SharePoint Services 3.0 to extend for this functionality. The toolkit is called The Accessibility Kit for SharePoint (AKS) and is available as a free download. Using the templates, master pages, and controls included in the kit, accessible sites can be created without implementing custom CSS files to control the layout of SharePoint Web pages.

Themes and CSS are often used interchangeably, but they are actually different. Themes are related to CSS because they are a collection of alternate CSS, image, and skin files that can be applied to a site. The CSS and image files replace existing files that are used by the site. Skin files define the visual properties of ASP.NET controls by overriding the default property settings. This means that themes can be used to quickly apply alternative graphics and color schemes by site administrators. For example, three corporate branded themes could be approved so that site administrators can select which one they want to use for a specific site. Themes could also be used to provide alternate sets of culturally specific graphics for use in a multilingual installation that makes use of SharePoint Variations.

The limitations inherent in the use of themes involve the way that they are applied to a site. When a user selects a theme, the directory in the 12 hive that contains the corresponding theme files is copied to a subdirectory of the site and stored in the content database. Subsequent changes to the original theme in the 12 hive are not picked up by the site. This means that any changes to a theme will need to be manually applied to each site that currently uses that theme.

Another limitation inherent in the use of themes is that they do not include a master page. Because themes contain CSS and do not contain master pages, they can be used to control graphics and color schemes but not the basic layout of the page. As noted previously, it is a best practice to control the layout of pages in a site by using master pages.

Due to their limitations, themes are not a perfect way to maintain centralized branding. But they work well in a limited fashion and are useful when the objective is to empower site owners to select approved brandings. Themes can also be used to provide approved images available for use as part of a branding effort. You should remember that changes to themes after deployment will be very laborious. Therefore, planning and quality assurance are crucial to preempting unnecessary changes to themes after they are deployed.

Themes can also be used to address one of the problems with pages that use Application.master. If a theme is applied to a site, that theme will affect the graphics and color scheme of pages retrieved from the _Layouts directory, just like every other page in the site. The theme will not affect the layout of the pages referencing Application.master, but it does provide a look-and-feel branding solution that does not involve editing the master page.

For several of the methods discussed so far, improper deployment strategies may make it difficult to maintain the customizations. These maintenance issues are usually the result of using SharePoint Designer 2007 to create a custom brand that is stored as customized files in the content database. Because these files are specific to an individual site (or site collection if publishing is enabled), using them in a broader context is problematic. A way to mitigate this problem is by creating a file in a parallel development environment, exporting it to the file system, and then deploying it to the production environment using a solution. For example, a custom master page can be created in a development environment using SharePoint Designer 2007. That customized master page can then be exported to the file system and deployed in a production environment using a solution.

Custom features can also be used to support deployment scenarios. The URL address of several key components for branding, like master pages and alternate CSS files, are stored as properties of the SPWeb object that represents a SharePoint Products and Technologies site. Custom features can be created to set these properties to point to custom master pages or CSS files that have been deployed via a solution. It is also possible to deploy and activate features as part of the solution, which automates the entire process. This combination of features and solutions is used to overcome some of the limitations of updating themes. Modifications made to themes in the 12 hive can be packaged as a solution, with the same solution containing a feature that would deploy the theme to sites. This feature could copy the theme from the 12 hive to the site’s content database. Doing so allows for centrally controlled updates to existing themes.

Web parts aren’t normally used to brand SharePoint Products and Technologies sites, but they can be an asset when leveraged intelligently. One of the issues of centrally controlled branding is a perceived lack of local control by the end-users. Allowing users to personalize the content of a specific site using Web parts may alleviate some of the problems associated with this "control" perception. Although users won’t have the freedom to change the color scheme of a site or how to navigate between sites, controlling the content that is on the site itself may provide users with the independence that empowers them.

Now that you have seen some of the strengths and weaknesses of the various tools and methods available for creating a custom brand, we need to look at the different ways that they can be used. We’ll examine the following four approaches: