Implementing a Brand in a SharePoint Server 2007 Publishing Site
Summary: Learn how to select the best approach for implementing a brand in a Microsoft Office SharePoint Server 2007 publishing site. (6 printed pages)
Andrew Connell, Critical Path Training, LLC (Microsoft MVP)
November 2008
Applies to: Microsoft Office SharePoint Server 2007, Windows SharePoint Services 3.0
Contents
Introduction to Branding SharePoint Publishing Sites
SharePoint Sites Are ASP.NET 2.0 Applications
Site Content Is Not Branding
Deployment Options for Branding Files
Conclusion
Acknowledgements
Additional Resources
Introduction to Branding SharePoint Publishing Sites
Microsoft Office SharePoint Server 2007 publishing sites are commonly used as the external face for companies and organizations. As the online presence, SharePoint publishing sites should employ a consistent appearance ("look and feel") to make navigation and discovery of information as easy as possible for users. Implementing a brand for a site, however, presents challenges. There are various implementation options, and each has advantages and disadvantages. However, it does not make sense for all projects to adopt the same process and technique.
Office SharePoint Server 2007 introduced the capability to host content-centric sites on the SharePoint platform. These sites, commonly referred to as publishing sites because of the SharePoint publishing features they employ, take advantage of a series of concepts and capabilities in Office SharePoint Server 2007 called Web content management (WCM). Publishing sites are frequently used in an Internet-facing scenario as the public face for a company or organization. Therefore, it is very important for these sites to have a consistent look and feel—also known as branding. However, the various options available for how to implement and deploy the site's brand can quickly confuse developers and designers.
This article explores what a publishing site project team should consider when planning how to implement a brand within Office SharePoint Server 2007. While many of this article's concepts and issues address Windows SharePoint Services 3.0 sites, this article focuses exclusively on Office SharePoint Server 2007 publishing sites.
SharePoint Sites Are ASP.NET 2.0 Applications
Before exploring the details of branding a SharePoint publishing site, you may find a brief SharePoint overview to be helpful. SharePoint projects are frequently overcomplicated by users because many think of Microsoft SharePoint Products and Technologies (which include both Office SharePoint Server 2007 and Windows SharePoint Services 3.0) as much more complicated than they really are. Starting with the third generation of SharePoint Products and Technologies, the SharePoint platform is built natively on top of the Microsoft .NET Framework. The SharePoint product team has developed a custom HTTP application and custom HTTP handlers and modules to create SharePoint Products and Technologies and change how Microsoft ASP.NET 2.0 works.
Note
The implementation of the architecture of SharePoint Products and Technologies is detailed in Chapter 2: SharePoint Architecture, excerpted in the MSDN Library from Inside Microsoft Windows SharePoint Services 3.0 (Microsoft Press).
While there are many similarities between a SharePoint site and one developed by using ASP.NET 2.0, as you would expect, there are also many differences. The following sections describe some of the differences that are encountered most frequently.
Similarities Between ASP.NET 2.0 Sites and SharePoint Sites
Because SharePoint Products and Technologies are built on top of ASP.NET 2.0, there are certain striking similarities between the two technologies, and most aspects of ASP.NET 2.0 sites have direct correspondence in the SharePoint platform. SharePoint Products and Technologies take full advantage of ASP.NET 2.0 concepts, such as the navigation provider and membership provider models. You might need to configure the SharePoint platform to recognize certain aspects of ASP.NET 2.0 technologies, for example, as in the case of the membership provider model. However, SharePoint Products and Technologies still fully offload that work to ASP.NET 2.0.
Specifically addressing the theme of this article, the technologies and techniques used to brand SharePoint sites are almost the same as those used in ASP.NET 2.0. Images and cascading style sheets (CSSs) are used to implement a custom brand within a traditional ASP.NET 2.0 site. SharePoint Products and Technologies use exactly the same techniques. In addition, ASP.NET 2.0 sites offer master pages, which simplify the global branding of a site. SharePoint Products and Technologies also take advantage of master pages, but in a different way from ASP.NET 2.0, as described in the following section.
Differences Between ASP.NET 2.0 Sites and SharePoint Sites
This section describes the key differences between ASP.NET 2.0 sites and SharePoint sites, which are:
Customized versus uncustomized files
Master page use
Code and custom file deployment
Customized vs. Uncustomized Files
One key difference between ASP.NET 2.0 sites and SharePoint sites is the concept of customized and uncustomized files. In an ASP.NET 2.0 site, it is relatively easy (when techniques such as URL rewriting are not employed) to determine where a file resides by inspecting the URL. This is because ASP.NET 2.0 is configured by default to retrieve files directly off the file system. This approach does not work in SharePoint Products and Technologies because one .aspx page on the file system is typically used as the template for many pages in one or more SharePoint sites.
To address this, the SharePoint product team implemented a virtualized file system that is stored in the SharePoint content database for each SharePoint site. In addition, files in a SharePoint site can be customized or uncustomized. An uncustomized file is one that simply exists in the virtualized file system as a pointer to the template it is based on, which actually resides on the file system. Customized files, however, are modified from their original state, and their source is stored in the SharePoint content database. This enables power users to customize the same file on a site-by-site basis without affecting other sites that use the same template on the file system. For more information about using customized and uncustomized files, see Understanding and Creating Customized and Uncustomized Files in Windows SharePoint Services 3.0.
Master Pages
As discussed earlier, the use of master pages is one similarity between ASP.NET 2.0 sites and SharePoint sites. However, while the same technology is used in both environments, the implementation is a little different. In an ASP.NET 2.0 site, content pages reference a specific master page. The master page is defined by the site designer or developer at design time. This model does not work for SharePoint sites because, when developing .aspx pages, you cannot always be certain which SharePoint site the page will be used in. Therefore, the SharePoint team chose to allow site owners to select a master page for use across all pages in a site. As a result, the .aspx files or content pages in a SharePoint site should not be configured to point to a specific master page file. Instead, dynamic tokens are used to tell Office SharePoint Server or Windows SharePoint Services, at run time, which master page to use. Office SharePoint Server or Windows SharePoint Services replaces this token with the URL of one of the two master pages that were selected previously by the site owner for use in the current SharePoint site. For more information, see Customizing Master Pages in Windows SharePoint Services in the Windows SharePoint Services 3.0 SDK.
Code and Custom File Deployment
Another big difference between ASP.NET 2.0 sites and SharePoint sites is how code and custom files are deployed. In ASP.NET 2.0 sites, custom code and files—including DLLs, .aspx files, .ascx files, .gif files, .jpg files, .css files, and .js files—are typically deployed as loose files to production systems. While Microsoft Visual Studio 2008 does have deployment and publish capability, developers do not usually have write access to a production server. Another deployment option for an ASP.NET 2.0 site is to create a Windows Installer (.msi) file or to package all the files into a compressed file (such as a .zip file) for an administrator to use in the deployment on a production server. A management application such as Microsoft Systems Management Server or a third-party deployment application can also be used to deploy an ASP.NET 2.0 application.
Windows SharePoint Services, however, includes a robust custom code and file deployment mechanism. The Windows SharePoint Services Solution Package framework (also known as the solution framework, SharePoint solutions, or just .wsp files) is the SharePoint internal deployment vehicle for custom code and files. Developers package all custom code and files into a .cab file with the .wsp file name extension, add a special manifest file (manifest.xml) to the top-level (root) of the .wsp file, and then add the solution to the SharePoint farm's solution store. The manifest file lets Windows SharePoint Services know about all the files in the solution—what each file is used for, and where it should be deployed on the server. Then, either on demand or at a scheduled time, SharePoint Products and Technologies deploy the files to the other servers running SharePoint Products and Technologies, based on what is defined in the manifest and selected in the deployment settings, such as which Web application the solution is deployed for. If Windows SharePoint Services is running in a load-balanced environment, the solution framework automatically determines which servers to deploy the solution to and does deployments to all servers at the same time. The solution framework also supports retracting or "undoing" the deployment. For more information about the solution framework, see Solutions Overview in the Windows SharePoint Services 3.0 SDK.
Site Content Is Not Branding
Before discussing the branding of SharePoint publishing sites, it is important to understand the difference between content and branding assets. Branding is anything that is used to implement the "skin" of the user interface of the site. Branding assets can be master pages, images, or CSS files—elements that implement a corporate brand or theme. The brand of a SharePoint publishing site typically does not change very often. Instead, an organization typically changes its SharePoint publishing site when it undergoes a rebranding campaign in which it either slightly customizes or completely changes the look and feel of the company. The files associated with the brand itself usually do not change on a frequent basis (every few days or weeks). In addition, the branding files are usually owned and controlled by the site developers and designers—not the team responsible for creating and maintaining the site.
Content, however, changes much more frequently. Content consists of the text and media, such as images and collateral, that are the reason for the site. These are the press releases, product information pages, and images of the organization's products. Content is controlled by the content owners and authors instead of by the production team responsible for the site. Content also usually follows a publishing process with workflow, permissions that limit who can create, approve, or publish the content, and versioning. Another difference between content and branding is that content files, by nature, are usually updated more frequently than branding files. Certain pages might be updated daily or every few days; other pages might be updated less frequently. Regardless, the time between content updates is usually much shorter than the time between branding updates.
The reason it is important to make this distinction between content and branding is that the two types of assets are stored in different locations on publishing sites, and should be kept separated. There are multiple reasons for this separation, including the following:
The individuals who own the content and branding are typically different people or groups. If these files are stored in the same location, the permissions can get mixed.
As discussed previously, content typically follows a publishing process with robust workflow and business rules within production, whereas branding is validated in a development or test environment and is ultimately rolled out into production.
With an understanding of the differences between content and branding assets, it is now time to look at the various deployment options for branding assets used in a SharePoint publishing site.
Deployment Options for Branding Files
As described previously, branding files are different from content files, and should be treated differently. A first consideration for deployment is where content should be located within a publishing site. Every publishing site within a publishing site collection contains three specific types of libraries: Pages, Images, and Documents.
The Pages library is where the content pages, also known as the Web pages, should be stored for each site. Images libraries and Documents libraries are where content collateral that is referenced from pages in that same site should be stored.
The purpose of these libraries in each site is to facilitate a certain level of control over what sections of the site certain users can manage. For example, perhaps contributors to the Press Releases section of a site should not have the same rights or access to the materials in the Products section. SharePoint Products and Technologies allow contributors to the Press Releases section to have rights in both, but keeping things isolated is also supported, if the business requirements demand that.
There are two special libraries in the top-level site of the site collection: Site Collection Images and Site Collection Documents. These libraries provide a storage location for assets that everyone should have access to, regardless of rights. For example, the company logo or privacy policy should be available to all content authors. Instead of having multiple copies of assets stored among the various Images libraries throughout the sites, these assets should reside in only one place. Content sites that are well-implemented take into consideration content reuse and prevention of content duplication.
Branding files should be kept separate from the content files for reasons described in the previous section. Therefore, branding files should not be stored in the Images, Documents, Site Collection Images, or Site Collection Documents libraries throughout the publishing site collection.
So where should you deploy branding files?
As with most things in SharePoint Products and Technologies, there are multiple options and each has advantages and disadvantages. The following sections describe three options for where to deploy branding files and the advantages and disadvantages of each.
Deploying Branding Files to the Site's Top-Level Folder
One obvious choice, especially to those with an ASP.NET 2.0 development background, is to simply deploy the branding files to the top-level or root folder (or a subfolder within it) of the Web application that hosts the SharePoint publishing site collection. This choice works just as well for, and is familiar to, traditional ASP.NET 2.0 developers and designers, because it follows a model similar to traditional ASP.NET 2.0 Web sites. However, this approach brings with it many disadvantages.
First and foremost, there is no built-in automated deployment option when deploying files to the top-level Web folder. SharePoint solutions cannot deploy files to the Web root of a Web application. They can only copy files to a location within the SharePoint "12" folder (the path is usually c:\Program Files\Common Files\Microsoft Shared\web server extensions\12), modify code access security policies, deploy assemblies to the server's global assembly cache or \bin folder in the Web root, and make minor changes to the Web application's web.config file. This means that the deployment of the brand cannot be scheduled by using the same built-in solution framework vehicle, and if a SharePoint farm employs multiple load-balanced front-end Web servers, the deployment must be coordinated for all servers. This challenge can be mitigated by using a deployment management package, as previously described.
Building off this point, when a new SharePoint site is added to a farm, if the SharePoint Web services are started, Office SharePoint Server automatically deploys all previously deployed solutions to the new server. However, because the branding files were not deployed by using SharePoint solutions, they are not automatically deployed. Therefore, farm administrators must be aware of what manual deployment steps to implement on the new server.
In this approach, files are stored outside of the SharePoint site. This means that the files cannot be versioned as they can be within a publishing site, cannot be scheduled, and cannot take advantage of workflow or site permissions. For example, perhaps there are a few files that make up branding changes, such as a CSS or a new company logo, which should not be used before a specific date and time. If the assets are in a publishing site, they can be scheduled to go live at a specific date. However, this also means that the files are not tightly coupled to the site, and must be backed up separately from the site.
Another concern with this approach is backup or restore and disaster recovery. When the publishing site is backed up, either by using Microsoft SQL Server database backups or by using the SharePoint backup capabilities, only the content within the site is backed up; none of the files on the file system are backed up.
In addition, if multiple publishing site collections are hosted in the same Web application, they all have access to the same branding files. This is because all files in the Web application's top-level folder are accessible by all site collections in the Web application. Granted, this might or might not be an issue in the business requirements, but it is something to be aware of. It might be considered an advantage of this approach because it is possible that the brand should be shared across all site collections in the Web application.
Deploying Branding Files to the _layouts Directory
Another option is to deploy the files into the SharePoint _layouts virtual directory. This folder maps to the [..]\12\TEMPLATE\LAYOUTS folder. Deploying to the _layouts folder mitigates a big disadvantage of the previous technique because administrators can deploy files by using the SharePoint solution framework. Administrators can schedule the deployment of branding files and they can automatically deploy these files to all SharePoint front-end Web servers in the farm when the solution is deployed.
A disadvantage of this approach is that the files still reside on the file system, and so most of the same concerns mentioned in the previous approach carry over to this one. This includes the inability to version or schedule the deployment of branding files.
Another potential concern with this approach is that files deployed to the _layouts virtual directory are available to all SharePoint sites within the farm—not just to publishing sites. This is because all SharePoint front-end Web servers in a farm should be virtual mirrors of each other, so each has a single [..]\12\TEMPLATE\LAYOUTS folder. Each SharePoint Web application has a separate _layouts virtual directory, but it also points to the same folder on each server. This means that every site has access to the same files. Again, this might not be a concern in a specific implementation, but if it is, administrators should be aware of it. As with the previous approach, this might be an advantage rather than a disadvantage; for example, maybe the same brand is used across all sites within an organization. It all depends on the specific business culture, deployment concerns, and business requirements.
Deploying Branding Files to the Site Collection's Content Database
Deploying branding files to the content database of the site collection is very different from the previous two approaches. Files do not have to live on the file system. Instead, they can be deployed to the publishing site collection, and so can be included in the site’s virtual file system. This is how the default SharePoint Publishing Portal site template implements its brand.
The biggest advantage here is that all the branding is included in the same SharePoint content database that contains the content of the site. This means that either SQL Server database backups or SharePoint backups will also contain the branding files. In addition, because the files live in the content database, they can be versioned or even scheduled.
Simply saying "the files go in the site collection" or "the files go in the content database" does not say much. Where exactly should they be deployed?
Recall the discussion earlier in this article about the differences between content and branding and how content files should be kept separate from branding files. Images related to the brand should not be stored in any of the site’s Images libraries or in the top-level site's Site Collection Images library. Instead, place all branding files in the SharePoint Style Library, found in the top-level site of the site collection. All authenticated users in the publishing site are granted access to the Style Library automatically, which is a good thing when you consider that the brand will be persisted across almost all pages in the publishing site. The same cannot be said for the Images or Site Collection Images libraries. It might not be terribly common, but there are many publishing sites where users are not granted access to the top-level; users have rights only within a subsection of the site. While the Style Library is in the top-level site of the site collection, all authenticated users in a site—even those who only have access to a subsection of the site collection—have access to the Style Library.
This approach might be more comfortable to developers and designers because they can add content directly to the site's virtual file system by using tools such as Microsoft Office SharePoint Designer 2007. But remember the details of the earlier discussion about customized and uncustomized files; there can be challenges to maintaining the files that live exclusively in the virtual file system (the content database). However, these challenges can be mitigated by using the technique of provisioning files by using Features. The brand can be packaged in a SharePoint solution for a clean and repeatable deployment scenario, with relatively easy updating. For more information about the technique of provisioning files by using Features, see Understanding and Creating Customized and Uncustomized Files in Windows SharePoint Services 3.0.
Conclusion
This article explores the various options available to those who are implementing a custom brand in a publishing site. The goal is not to define the right or wrong approach to implementing a brand in a publishing site. Instead, this article provides guidance and education around the various options for implementing a brand. It likely does not make sense for all projects to adopt the same process and technique. To adopt the right approach, you must consider all the options, the advantages and disadvantages of each, and the specifics of each publishing site project.
Acknowledgements
I would like to acknowledge Randy Drisgill and Heather Solomon (SharePoint MVP) for their feedback in discussions that contributed to this article.
Additional Resources
For more information, see the following resources:
Windows SharePoint Services 3.0 SDK: Software Development Kit
Understanding and Creating Customized and Uncustomized Files in Windows SharePoint Services 3.0
Excerpted from Inside Windows SharePoint Services 3.0 (on MSDN)