Branding a SharePoint Portal Server 2003 Site: Part 1, Understanding the Use of a Corporate Brand

  • Article

 

Daniel McPherson
Microsoft Consulting Services

John Hooper
Microsoft Principal Consultant

December 2004

Applies to:
    Microsoft Office SharePoint Portal Server 2003

Summary: The first of two companion articles. Learn what it means to "brand" a SharePoint Portal Server site, and about the different types of branding you can apply to a portal site to reflect an organization's identity. Go on for a step-by-step example of branding in Branding a SharePoint Portal Server 2003 Site: Part 2, How to Apply Your Own Corporate Brand. (24 printed pages)

Contents

Introduction
Branding a Portal Site
Planning a Branding Exercise
Branding Using Microsoft SharePoint Products and Technologies
Technical Concepts in Branding a SharePoint Site
About Templates
About Template Folder Descriptions
About Template Descriptions
About Style Sheets
Conclusion

Introduction

A standard SharePoint Portal Server site provides an intelligent portal site for connecting users, teams, and knowledge throughout an organization. It also gives users an ideal location to start looking for information on their intranet, so it should reflect and reinforce the organization's identity.

Creating identity involves customizing the standard portal site "look and feel." You can incorporate your organization's images, logos, colors, and styles, and design the portal site to fit in as seamlessly as possible with any existing intranet or Internet sites that you have.

Note   This article is based on work performed by MCS on a number of projects, with varying numbers of customers.

What is SharePoint Portal Server?

SharePoint Portal Server 2003 is a secure, scalable, enterprise portal server built upon Microsoft Windows SharePoint Services. You can use it to aggregate SharePoint sites, information, and applications into a single portal site. Most of the Windows SharePoint Services features are available in SharePoint Portal Server 2003.

Note   Windows SharePoint Services is a collection of services for Microsoft Windows Server 2003 that you can use to create team-oriented Web sites. These Web sites enable you to share information and foster collaboration with other users on documents and lists. You can also use Windows SharePoint Services as a development platform for creating collaboration and information-sharing applications.

The additional features found in SharePoint Portal Server include:

  • Enterprise search
  • Personalization
  • Personal sites
  • Microsoft Single Sign-On service
  • Site directory
  • User profiles

Branding a Portal Site

Branding is how you apply an organization's identity to an existing software application through customization of a portal site.

To successfully brand a portal site, you need to understand the business drivers behind branding intranet-based solutions. In this section, we approach the topic of branding without regard to any particular technology, and establish what branding is and isn't, and why you need it. We also discuss common types of branding requirements described by organizations in their intranet design guidelines.

Why Brand?

You apply the organization's brand to the portal site for a number of reasons, such as the following:

  • To establish corporate identity and ownership. With the portal site home page becoming the primary interface between employees and their intranet, you should assure that it reflects and reinforces the organization's identity.

    Portal site users should understand intuitively that they are using an enterprise resource. Users should feel that they are interacting with the organization's portal site rather than a standard software application.

  • To reinforce enterprise standards. A number of organizations have made significant investments in the development of standards to guide the creation of their intranet sites. These standards include logos and images, colors, fonts, page layouts, and navigational models. Because a portal site is at the center of an organization's intranet, it must adopt such standards.

    Standards should promote a common look and feel throughout the organization's intranet to make it easier for users to navigate and find the information they need to do their jobs.

  • For ease of use. A corporate intranet is commonly made up of many different sites, created by diverse parts of the organization using a variety of tools. Any branding effort must ensure the greatest possible consistency with existing sites.

    You should always place higher priority on usability than on look and feel. A solution's look and feel refers to the visual, attractive elements of its interface; usability, however, is about making it easy for end users to interact with and use the interface.

  • To create a sense of place. Corporate intranets are often made up of many loosely connected sites, so any branding effort should communicate a clear "sense of place" to your users so they can understand where they are within the portal site quickly.

    Common approaches to solving this problem include elements such as breadcrumbs, navigation tress, and page titles.

What is Branding?

Branding of a portal site is the application of an organization's identity to an existing software application through customization of the portal site. It is an important requirement for any portal implementation and it has a significant impact on the end user experience. You typically brand a portal site to meet your organization's intranet standards and guidelines. By definition no two implementations are the same, making it important to understand both the capabilities of the chosen portal platform and the specific organization requirements.

Following are some common branding requirements (or standards) described by organizations in their intranet design guidelines.

Note   Any customization that goes beyond modifying the look and feel of the portal site is not considered branding. These customizations are functional modifications, or changes to the product that add to or modify one of its functions.

Color and Style

Applying color and style are the most fundamental elements of any branding exercise. You should consider any organization requirements in this area to be essential and probably governed by very strict guidelines. Apply these elements of a brand completely and consistently throughout any solution.

The most common branding requirement is developing a page "banner," also known as a "brand-box" or page "header." This element is common to all pages and most organizations will already have a design in place.

Figure 1. Standard SharePoint Portal Server site banner

Ensure that your banner (brand-box or heading) does not use too much of the screen space, particularly at lower screen resolutions.

Organizations have various requirements for site navigation, typically including one or more horizontal and vertical menus. The location of these menus varies; in particular, you can place the horizontal menu along the very top of the page or immediately below the banner. Menu style also varies; some organizations prefer a "fly out" style, others a collapsible style, and still others their own custom design.

Page Layout

Organizations often have one or more standard screen layouts. These are page designs that define where to position elements such as navigation, banner, footer, and body on a page. You must accommodate any number of these page designs within the portal site design, promoting consistency throughout the intranet and in turn making it easier for people to use.

Features and Functionality

Different organizations refer to certain product features in different ways. For example, some customers refer to items added to the portal site as "News," while others prefer to call these items "Announcements." Accommodating these vocabularies can have a significant impact on overall ease of use.

In addition, some organizations want to emphasize some product features over others, making some more obvious or discoverable. These same features may not be relevant to other organizations who may want to hide them altogether.

Finally, you must take care to ensure full support for accessibility standards, screen resolutions, and different types of browser.

Planning a Branding Exercise

Planning a branding exercise can help you and your organization make the important decisions, identify key stakeholders, and find the skill sets you need for your branding to succeed. This section discusses high-level concepts around which you can plan a branding exercise and explores some of the most common requirements.

Note   This section focuses on branding as a general requirement, not specific to SharePoint Portal Server. We cover the technical concepts of branding later in Technical Concepts in Branding a SharePoint Site.

When to Brand?

Because branding is a fundamental requirement of any portal site deployment, you need consider it during the initial planning and design phases. Also, as branding can potentially impact every page on a portal site, you need to put it in place early in a portal site's development cycle, and carefully consider the amount of branding you do and its impact.

Choosing a Portal Site Technology

While organizations often already have guidelines and intranet applications in place, the branding of these systems can be based on the capabilities and suitability of the technologies used to create them. These technologies may not be appropriate for the newly selected portal site platform, or you may need to change and possibly improve the portal site to take full advantage of the features of that new platform. If you don't take the flexibility and inflexibilities of the chosen platform into account, you may need a great deal of custom code and can significantly lower the return on investment of a portal site platform.

The Portal Site Development Cycle

Though an organization may have portal site design guidelines in place, these are often open to interpretation. Therefore, the branding you do should take into account a number of feedback cycles, involving those areas of the business capable of assessing whether designs meet the organization's requirements.

Because a portal site often hosts a number of sites or applications from across a business, you should assess any branding functionality in this context, possibly prototyping these applications to show how they fit into a portal site context and are branded. Branding can also significantly affect the usability of a portal site if it uses large banners that consume screen space better suited to application functionality, which might also require usability testing.

Over the lifetime of a portal site, a company's branding can change. Deploying a portal site inside an organization is a long-term commitment, and you should expect the need to accommodate changes to the organization's brand, or identity.

Portal Maintenance

You should be able to maintain any customizations you make to achieve branding, and you should document and fit all changes within product support boundaries.

Consider the following in support boundaries:

  • The organization's support capabilities.
  • The portal site technology vendor's support capabilities.
  • Any third-party developments and add-ons that require support.

Branding and the development associated with it can significantly change any supplied products or technology and can be affected adversely by fixes or upgrades to this technology. In some cases such fixes, be those security fixes, bug fixes, or new features, can inadvertently remove branding.

Point of Modification

Wherever possible, move brand elements that are shared across multiple pages into a shared component. You can then modify this component in a single place and grant the following benefits:

  • Lower maintenance costs.
  • Quicker development time.
  • Lower margin of error.

Deployment

Develop a process to guide customization from development through to production. This requires moving code and data from various computers, and potentially various networks, a number of times, so you should try to manage it efficiently. Different environments may consist of:

  • Different numbers of computers.
  • Different configurations of computers.
  • Different network configurations.

This deployment process needs to include testing, user acceptance, performance impact assessment, and security review.

Note   High availability and scalability are often important criteria when developing a portal site. Because these criteria are often achieved by using multiple computers, be sure to have a clear and effective deployment strategy.

Ongoing Development

Portal sites are often ongoing developments that grow and change as an organization grows and changes. Because you will need to add new sites and applications to a portal site to accommodate growth, your branding development needs to be flexible enough to accommodate new development.

Identifying Key Stakeholders

In developing a portal site brand, you need to identify the key people who will develop and move the portal forward. These are your stakeholders, and the people you will consult and ask to approve any designs.

Key stakeholders would often include people from the following areas:

  • User representatives
  • Marketing and branding
  • Operations
  • Development
  • Business representatives
  • Corporate sponsors

Key Team Skills

A team planning to create a portal site branding strategy needs the following key skills:

  • Usability expertise, including user interface design.
  • Development expertise, including a knowledge of portal technologies and initial applications
  • Corporate branding knowledge, including knowledge of corporate style and layouts.
  • Management understanding of key stakeholders and desired business solutions.
  • Infrastructure expertise, including knowledge of Microsoft Windows Server 2003, TCP/IP, Internet Information Services (IIS), firewalls, and so on.

Branding Using Microsoft SharePoint Products and Technologies

Now that we have established principles for effective branding, we can apply them to SharePoint Portal Server 2003 to assist those involved in any branding exercise.

Following are some of the typical products and technologies that can be involved in developing a portal site with Microsoft technologies:

  • Windows SharePoint Services, used for collaboration and team sites
  • SharePoint Portal Server, used for personalization and search, and that is installed on top of the underlying Windows SharePoint Services and team sites
  • Windows Server 2003, the operating system
  • IIS 6.0, the Web hosting engine
  • SQL Server 2000, the information store
  • Microsoft Exchange Server, for messaging
  • Microsoft BizTalk Server, for back-end integration

Following is a list of typical Microsoft technologies used to develop and brand a portal site:

  • Microsoft ASP.NET to develop custom functionality
  • XML for the interchange of data
  • HTML to render the portal pages
  • XSLT to manipulate XML data
  • Microsoft ADO.NET to extract data from back-end systems
  • C#, Microsoft Visual Basic .NET or any other Microsoft .NET Framework-enabled language
  • Microsoft Visual Basic or ECMAScript (Microsoft JScript or JavaScript code) to develop client-side functionality

Branding SharePoint Portal Server vs. Windows SharePoint Services

In this article, we focus on SharePoint Portal Server 2003; however, it is important to highlight the ways in which branding a Windows SharePoint Services site differs.

In general, the look and feel of a portal site is more disciplined than that of an individual Windows SharePoint Services site (also called a team site). For example, users often modify team sites using Microsoft Office FrontPage, but this method is not recommended for portal site areas for reasons outlined in the following table.

Table 1. Comparison of SharePoint Portal Server and Windows SharePoint Services sites

SharePoint Portal Server site Windows SharePoint Services site
Small number of portal sites with a large number of users for each Large number of sites with a small number of users for each
Organization-wide audience Team-based audience
Primarily for organizing, publishing, and summarizing Primarily for collaborating with other users on documents and creating lists
Created and owned by named portal administrators User-created and owned
Planned and designed based on specific business requirements Unstructured, created as a requirement is identified
Centralized administration, with area delegation Decentralized administration

Limits of Branding SharePoint Pages

SharePoint Portal Server is designed to allow only a subset of its pages to be freely branded. Portal site pages can be described in one of two ways:

  • User-facing. User facing pages are also referred to as site or area templates. These templates define the features and functionality available when a team site or portal area is created. These pages are designed, with some limitations, to accommodate product customization. For details about customizing these pages, see About Templates.

  • Administrator-facing. Administrator-facing pages are also called layout pages. They are stored in a single location on the front-end Web server file system but are virtualized so they can be accessed from any portal area or team site. They provide access to shared functionality, for example, permissions, document library and list management, area settings, and so on. They are easily identified by the _layouts folder in the page URL.

    For example,****when a page in the _layouts folder is opened, it understands the context in which it is called: http://Portal/Area1/_layouts/1033/mcontent.aspx manages the content in Area1, andhttp://Portal/Area2/_layouts/1033/mcontent.aspx manages the content in Area2.

In both cases, however, the same Web page is called.

Although it is common to customize user-facing pages, you should not customize administrator-facing pages for the following reasons:

  • These pages are tuned and tested to ensure reliability and performance.

  • The ability for Microsoft Support Services to debug any issues in a page after it is modified is significantly impeded.

  • Service pack releases and new software versions remove any customizations, and at worst, fail to install.

  • It is impossible to determine the impact of any change in this area and whether it can result in a significant testing requirement.

  • Many of these pages are shared across SharePoint Portal Server and Windows SharePoint Services.

    This can be a difficult distinction to make, and it is important to consider this restriction in the earliest discussions with an organization regarding the branding of SharePoint Portal Server.

Costs of Branding

Branding is product customization, and like any customization comes with both upfront and ongoing costs. The more complex the customization, the higher the cost.

For this reason, you should consider SharePoint Portal Server features and capabilities when designing your intranet guidelines. While in some cases development is the only way to meet a specific requirement, you can often save costs by compromising less important aspects of the brand or design guidelines to take advantage of out-of-box functionality. This has the additional benefit of then taking advantage of any improvement to the SharePoint Portal Server platform in future releases.

Supportability

Microsoft cannot support all possible customizations performed by customers or partners.

Before calling Microsoft product support about an issue that you consider product-related, you should try and reproduce the issue on a version of the portal site without any custom branding applied.

Product customization could also have a significant impact on scalability and performance. As part of the customization process performance, you should perform benchmarking, comparing your customized portal site with a standard out-of-box version.

Technical Concepts in Branding a SharePoint Site

There are many different approaches to branding a SharePoint site. In this section, we provide an overview for each approach, including information about its functionality and when to use it.

To help you decide which approach is right for you, we rate each approach in the following areas:

  • Impact of customization, which describes the level of impact the customization has on the standard portal site, along with guidance about maintenance costs. (Low is the least costly.)
  • Complexity, which describes the technical complexity of a customization, along with guidance about the required skill level of the developer and the initial cost of customization. (Low requires only basic development skills and the lowest initial cost.)
  • Supportability*,* which**describes the ease of supporting the customization in the event of fixes, service packs, and new releases. (Low is difficult and expensive to support.)

Product Configuration

A number of SharePoint features provide administrators with the ability to change the site look and feel. Examples of these include changing the SharePoint Portal Server logo, shown in Figure 2.

Figure 2. The standard SharePoint Portal Server logo

This functionality enables organizations to display their own logo on every page.

Note   Ensure that the size of the logo is appropriate for the page and that it fits in with the color and style used on all the pages.

We recommend that organizations customize their portal sites in this way. These customizations apply to all pages on the site, both user-facing and administrator-facing.

Configuration Details

  • Impact of customization: Low

  • Complexity: Low

  • Supportability: High

    Note   This type of modification is not impacted by the application of service packs or fixes. However, future versions of the product may introduce changes or additions to the styles that require rework. This solution requires no custom code and is considered out-of-the box functionality.

Style Sheet Customization and Image Replacement

The look and feel of SharePoint Portal Server is determined largely by a set of cascading style sheets (CSS) and a library of SharePoint Portal Server images. You can customize the look and feel significantly by:

  • Complementing the existing standard style sheets with your own custom style sheet by using the Custom Cascading Stylesheet property on the portal site.
  • Modifying the standard style sheets for Windows SharePoint Services.
  • Replacing standard images.

This approach allows more flexibility than the previous approach, but does require that you develop additional style sheets or change existing ones. Both this approach and the previous one do not significantly change the layout or behavior of the portal site.

**Note   **For a list of the standard style sheets that are installed with SharePoint Portal Server, see Customizing SharePoint Sites and Portals: Style Sheet Class Reference Tables, Part 3.

You should always ensure that you document any modifications you make to standard SharePoint Portal Server components and that you back up the files.

Configuration Details

  • Impact of customization: Low to medium

  • Complexity: Low

  • Supportability: Medium to high

    Note   The application of service packs, fixes, and future releases of the product will have an impact on the modification of the standard style sheets and images. However, as long as the changes are backed up and documented it should not be too difficult to reapply them.

Development in FrontPage

Using Microsoft Office FrontPage, you can customize both Windows SharePoint Services team sites and SharePoint Portal Server areas. FrontPage is the premier editor for SharePoint Products and Technologies, enabling a range of modifications from simple to complex.

The following list highlights some of these capabilities:

  • Full Web Part management, including adding, removing, deleting, and moving.
  • Wizard-based development of dynamic data based on the Data View Web Part and connected Web Parts that use data from a variety of sources.
  • Look and feel page customization, including styles and layout.

Using FrontPage to modify SharePoint pages is relatively simple, but may have some impact on ongoing supportability of the portal site. Pages you customize in FrontPage cannot be replicated across a portal site or enable a single maintenance point because the page, after it is customized, is handled differently from pages that are based on the template (described in the following section).

For this reason, FrontPage is a great customization tool for team sites, but you should restrict its use in customizing enterprise portal sites. We strongly recommend that you customize SharePoint templates when branding portal site pages, which keeps the SharePoint page from being customized, or ghosted, and enables global changes to a portal site's look and feel.

For more details about page handling, see Working with SharePoint Pages.

Note   FrontPage themes and Dynamic Web Templates are not supported by SharePoint Portal Server. However, they are supported by Windows SharePoint Services.

Configuration Details

  • Impact of customization: Medium to high

  • Complexity: Medium

  • Supportability: Medium

    Note   The application of service packs or fixes will not have an impact on modifications made by FrontPage. Future versions of the product may introduce changes or additions that may require some rework.

Customizing Templates

When you customize SharePoint Portal Server by customizing SharePoint templates, you get the greatest flexibility and perform branding using the recommended method. In the remainder of this article, we will focus on customizing templates. Each instance of a portal site is based upon a set of templates. By branding a portal site using the templates, you ensure maximum page performance and simplified page maintenance.

You should apply the same level of rigor to a project that customizes templates as you apply to any custom development project—including version management, testing, and user acceptance.

Configuration Details

  • Impact of customization: Low to high

  • Complexity: Medium to high

  • Supportability: Low to medium

    Note   The scope of modification possible with this type of customization makes it difficult to provide a specific assessment of impact or cost. The application of service packs, fixes, and future releases of the product will have an impact on the changes. However, it is the most complex but arguably most flexible type of modification.

Creating Custom Web Parts

One way you can customize templates is to develop custom controls as part of the template definition. These should be standard SharePoint Web Parts embedded as static Web Parts directly in the page. You do this in the same way you add standard SharePoint server-side controls to a page.

Static Web Parts behave exactly the same way as those added dynamically to a page, with the following exceptions:

  • They do not exist within a Web Part zone.
  • They cannot save property values in either shared or personal view.

Configuration Details

  • Impact of customization: Low

  • Complexity: Low to medium

  • Supportability: Low to medium

    Note   The application of service packs or fixes will not have an impact on this type of modification. Future versions of the product may, however, introduce changes or new features requiring some rework.

Using Client-side Script

You can also customize templates by using client-side script and dynamic HTML to manipulate the template page. You can modify a screen element managed by a server-side control while avoiding having to write it from scratch.

You can embed the client-side script in the page in two ways:

  • Write a Web Part that outputs the script.
  • Embed the script directly into the .aspx pages.

Configuration Details

  • Impact of customization: Low to high

  • Complexity: Medium to high

  • Supportability: Low to medium

    Note   The application of service packs, fixes, and future releases of the product, depending on the method of implementation, may have an impact on client-side script. However, as long as you have backed up and documented the changes, you should have little difficulty reapplying them.

About Templates

The most common approach to applying a corporate brand to a portal site is to customize templates. Each instance of a SharePoint site is based upon a set of templates, and customizing these templates is the most important aspect to branding the portal site.

**Note   **For a description of the area templates that are installed with SharePoint Portal Server 2003, see About Template Folder Descriptions.

We discuss some important concepts about working with SharePoint pages—how "ghosting" works with SharePoint Portal Server templates, an overview of SharePoint Portal Server areas, and finally, some detailed information about branding a portal site by customizing the pages of SharePoint Portal Server area templates.

Working with SharePoint Pages

Before you perform any template modification, you should understand the implications of customizing individual SharePoint pages rather than templates.

Pages that have not been customized (whether they were created using standard or customized templates) are stored as virtual portal pages, that is, only a pointer to the template on the front-end Web server is stored in the content database rather than a copy of the page. These pages are sometimes referred to as "ghosted" pages.

With pages that are not customized, you can achieve the following:

  • Maximized performance because it is faster to read pages directly from the front-end Web server.
  • Changes that are reflected across any pages that use this template.
  • No need to store large numbers of identical pages in the database.

After you customize a page using a SharePoint-compatible editor such as FrontPage, SharePoint stores a copy of the entire page in the database. You cannot reverse this customization process. These pages are sometimes referred to as "unghosted" pages.

Following is a diagram illustrating these steps.

Figure 3. Processing a page request in SharePoint

Customizing a page has a number of impacts, including the following:

  • Page performance decreases because retrieving a page from the database is slower than from the front-end Web server.
  • You will incur additional maintenance overhead because you must make any future changes to this page directly, rather than changing the template in a single, central location.

In addition to storing the page entirely in the database, customized pages are rendered differently. The standard ASP.NET parser renders pages that are not customized; however, for security reasons, customized pages are processed using the Windows SharePoint Services Safe Mode parser. The Safe Mode parser specifically prevents the following:

  • Execution of server-side code.
  • Rendering of controls not registered as safe.

SharePoint Portal Server Areas

Each portal site instance is made up of a number of portal areas. Examples of an area include the Home area, the News area, and the Topics area. Each of these areas can have any number of subareas, forming a hierarchical tree structure that organizes information and drives the portal site navigation model.

Figure 4. Hierarchical structure of a SharePoint portal site

Each area is made up of two elements: area pages and sites (described in the following section). While both can be customized, you typically achieve branding by modifying area pages.

Sites in SharePoint Portal Server

Behind every portal area is a tightly integrated Windows SharePoint Services team site. This provides most of the Windows SharePoint Services list and document library-based capabilities to the portal area. This team site includes a site definition that determines how each instance of the team site is provisioned during area creation. It defines items such as the following:

  • Lists available for creation.
  • Lists created by default.
  • Fields that make up a particular list.
  • Available views.

A Windows SharePoint Services team site is a combination of HTML files and XML-based configuration files. (For more information, see the Microsoft SharePoint Products and Technologies SDK.)

While this article only covers modifying area pages, the site definition also determines what capabilities SharePoint-enabled editors have when modifying a portal area. We do not cover customizing Windows SharePoint Services templates and XML in this document, although many similar principles apply.

Note   Enterprises often want all editing capabilities disabled to prevent customization. For more information about how you can achieve this, along with considerations for working with SharePoint Portal Server and FrontPage 2003, see the Microsoft Knowledge Base article -Considerations that apply when you use FrontPage 2003 to edit SharePoint Portal Server 2003 sites.

Customizing Area Pages

Each instance of a SharePoint portal site is based on a set of standard SharePoint Portal Server templates. You can modify the page component of these templates to meet specific branding requirements. Because the scope of these changes can be significant, you must support any modification by performing thorough requirement analysis, design, testing, and deployment planning.

Every area in your portal is created with a default.aspx page; this is the page displayed when a user accesses an instance of a portal area. It is a SharePoint Web Part Page which means it includes the necessary SharePoint controls for hosting Web Parts and performing page personalization. In addition, the Home area also contains a number of additional pages for performing tasks such as displaying portal listings or performing searches.

The following figure shows where the area templates are located within the file system (under \Program Files\Common Files\Microsoft Shared\web server extensions). For example, the SPS folder shown in the figure contains the template pages for a default SharePoint Portal Server portal area, the SPSNEWS folder contains the template pages for a News area, and so on.

Figure 5. SharePoint Portal Server 2003 area template folder

You can customize SharePoint Portal Server pages using any standard text editor. However, you should ensure that the editor you use doesn't automatically insert or remove any aspects of the page.

Note   Do not edit SharePoint templates or pages by opening them directly from the file system in FrontPage as the HTML can become corrupted. When editing in FrontPage, always open files over HTTP, that is, by opening the site.

SharePoint area pages are standard ASP.NET pages, which are predominantly server controls and HTML. As a first step, you should apply the proper indentation to the pages to assist your understanding of their structure, so that you can more easily insert a new element, such as a banner, in the correct place.

Custom Banners

Implementing a custom header, banner, or brand-box is probably the most requested portal modification. In addition to designing the new banner, consider the following issues.

How should I implement the new banner?

Following are a number of ways you can implement the new banner.

  • Standard HTML. You can create a block of code (typically a combination of SharePoint server controls and standard HTML), which is pasted into each file requiring a header, replacing the standard one. This approach uses the standard SharePoint templates and is probably the simplest to implement. It is difficult to maintain, however, because any changes need to be made in multiple places.
  • Web Part. You could take the standard HTML code that makes up your new header and include it in a server control or Web Part. Unfortunately, you cannot call standard SharePoint controls from within your custom control. The benefit to using a server control, or Web Part, is that, depending on the scope of changes, you can make most of your changes in a single place by modifying the Web Part. This approach does require a development effort.
  • Server Control. You can develop a text-based server control in which you paste any combination of SharePoint Portal Server server controls and standard HTML, which you can then be referenced as a control in each template page. The advantage to this approach is that you can make changes in a single location, and the initial development effort is limited because it can be maintained like a Web page rather than compiled in a development environment.

What files do I need to modify?

There are a number of files that you need to modify to replace the standard SharePoint banner, regardless of how you choose to implement the new banner.

  • In each area template, you need to modify the default.aspx files, for example, <%SystemDrive%>\Program Files\Common Files\Microsoft Shared\web server extensions\60\Template\<Loc ID>\SPSNEWS\default.aspx.

    Note   Each folder in this

    <Loc ID>

    directory that is prefixed with SPS represents a SharePoint Portal Server area template. For a list of area template descriptions, see About Template Descriptions.

  • In the Home area (<%SystemDrive%>\Program Files\Common Files\Microsoft Shared\web server extensions\60\Template\<Loc ID>\SPS), you must modify the following files:

    • TXTLSTVW.aspx
    • SEARCH.aspx
    • MOREINFO.aspx
    • DMFramesetTopFrame.aspx

  • In the Sites area (<%SystemDrive%>\Program Files\Common Files\Microsoft Shared\web server extensions\60\Template\<Loc ID>\SPSSITES\LISTS\SITESLST\) you must modify the SUMMARY.aspx file.

  • The Windows SharePoint Services sites hosted within a portal area have a system property that ensures these pages render with a portal header rather than the standard Windows SharePoint Services header. This is called the AlternateHeader property, and by default it is set to PortalHeader.aspx. To ensure consistency, update <%SystemDrive%>\Program Files\Common Files\Microsoft Shared\web server extensions\60\Template\<Loc ID>\PortalHeader.aspx.

SharePoint Server-side Controls

SharePoint Portal Server includes a number of server-side controls, which provide functionality like top navigation, left navigation, actions, and a logo. A number of these controls have parameters that you can specify to change their behavior.

Following are the SharePoint controls that are commonly manipulated as part of a branding exercise, along with details about the parameters they accept. Any of these controls can be removed or replaced by your own custom controls. For additional sample code demonstrating usage of the controls, see Branding a SharePoint Portal Server 2003 Site: Part 2, How to Apply Your Own Corporate Brand.

Note   For more information about SharePoint server-side controls, see the Microsoft SharePoint Products and Technologies SDK.

**Control name:
**<SPSWC:CategoryNavigationWebPart>

This control manages the left-hand and top navigation elements.

Left-hand navigation, as displayed on the Home area, is shown here.

Figure 6. CategoryNavigationWebPart control in vertical mode on area Home page

By default this control displays all areas that are one level below the Topics area.

You can modify this control using parameters in the following way:

  • To display the children of any other area within your portal hierarchy.

  • To render it in horizontal mode, as it is in the top navigation bar shown in the following figure.

    Figure 7. CategoryNavigationWebPart control in horizontal mode on area Home page

Control names:
<SPSWC:BreadCrumbTrail>
<SPSWC:CategoryNavigationWebPart>

The left-hand navigation on all other areas is made up of two controls:

  • The Bread Crumb control.

    Figure 8. BreadCrumbTrail control in vertical mode

  • The CategoryNavigationWebPart (as discussed in the previous section).

    Figure 9. CategoryNavigationWebPart control in vertical mode

Using parameters, you can modify the breadcrumb trail in the following ways:

  • Display the breadcrumb in a horizontal mode.
  • Anchor the breadcrumb to a specific area.
  • Include a specific separator in the breadcrumb trail.
  • Use lead-in text, a type of left-hand label.

These modifications are shown in the following figure.

Figure 10. BreadCrumbTrail control in horizontal mode

**Control name:
**<SPSWC:PageHeader>

This control displays the page header:

Figure 11. Standard SharePoint Portal Server page header

Using parameters, you can modify the PageHeader control in the following ways:

  • Render only the links displayed on the right-hand side.
  • Render only the image displayed on the left-hand side.
  • Render both the links and the image.

Actions

Control names:
<SPSWC:ToolBar>
<SPSWC:ToolBarButton>
<SPSWC:ToolBarSeparator>

The ToolBar control acts as a container for the actions available in an area. Each standard action is a custom ToolBarButton control.

Figure 12. Toolbar, ToolbarButton, and ToolbarSeparator controls on area page

You can remove any of these actions or add your own with parameters that specify the following:

  • The URL where the link will navigate you to.
  • Text to display.
  • The ToolTip to display.
  • Whether it is visible in Edit mode.

Use the ToolBarSeparator control to add a separator.

About Template Folder Descriptions

The following table describes the folders contained in the Templates folder located at <%SystemDrive%>\Program Files\Common Files\Microsoft Shared\web server extensions\60\Template\. It is essential that you understand these contents to ensure safe customization.

As a general rule, you should keep any customization separate from any standard functionality to ensure the safe application of service packs and upgrades.

Table 2. Folders contained in the Templates folder

Folder Contains
\1033 This folder contains a folder for each of the site templates available on the front-end Web server. Do not modify the pre-existing site templates.
Note   Site templates are language specific;1033 is the locale ID for US-English. If your organization hosts sites in multiple languages on the same server, you will find additional numbered directories for each language pack you have installed. You need to create site templates for each language you support.
\1033\XML This specially handled folder is where you configure any new site/area templates into Windows SharePoint Services and SharePoint Portal Server.
\ADMIN This folder contains all pages used by SharePoint Central Administration. You should not customize the contents of this folder.
\IMAGES This folder contains all the standard Windows SharePoint Services image files. Customize the images by creating a new subfolder, such as \IMAGES\CUSTOM, and placing your custom image files into this location.
\LAYOUTS\<Loc ID> This folder contains all pages required for standard site administration. You should not customize the contents of this folder.

You can implement custom ASP.NET applications that run within the context of a Windows SharePoint Services site or SharePoint Portal Server area by creating subfolders within the \LAYOUTS folder.
\LAYOUTS\<Loc ID>\STYLES This directory contains the key style sheets used by SharePoint Portal Server.
\LAYOUTS\<Loc ID>\IMAGES Administration image storage.
\SQL This folder contains SQL scripts for creating the configuration and content storage databases. You should not customize the contents of this folder.
\XML This folder contains configuration files.
\XML\DOCICON.XML This file contains contents you can modify to customize the mapping of document types to icon images.

About Template Descriptions

Each area template is contained within its own folder structure. These folder structures are described in the following table.

Table 3. Folder structure and area templates

Folder Area
SPS Home
SPSCOMMU Community
SPSMSITE My Site Homepage
SPSPERS My Site Team Site
SPSNEWS News
SPSNHOME News Home
SPSSITES Site Registry
SPSTOC      Topics Home
SPSTOPIC Topics
STS WSS Team Site
MPS WSS Multi-Page Team Site

About Style Sheets

SharePoint Portal Server uses a number of style sheets to achieve its look and feel. These style sheets are detailed in the following table.

Table 4. Style sheets and what they affect

Style sheet name Description
SPS.CSS SharePoint Portal Server styles
OWS.CSS Windows SharePoint Services styles
MENU.CSS Styles used to create the drop-down menu
OWSMAC.CSS Styles used when rendering on the Apple Macintosh
OWSPERS.CSS My Site styles

Conclusion

In this article, we have discussed the importance of branding, what branding can involve, key concepts to consider, and techniques for branding with SharePoint Portal Server.

SharePoint Portal Server is a very flexible product and offers a variety of branding techniques. In general, you need to consider branding in the same was as any other development project in terms of the types of planning, development management, and testing you need to do. We have focused on this concern, offered you some of the important choices you can make and techniques you should consider when branding with SharePoint Portal Server.

Additional Resources

Microsoft SharePoint Products and Technologies 2003 SDK
Branding a SharePoint Portal Server 2003 Site: Part 2, How to Apply Your Own Corporate Brand
Daniel McPherson's blog