Microsoft SharePoint 2007 Technologies

384 14.2 Branding Pain Points in SharePoint Portal Server 2003

If a Web site is easy to use, there is a higher likelihood of a user returning to

the site for information. Branding is also used to establish identity and own-

ership. For example, when you first install SharePoint Server 2007, the

default branding is easily recognizable as Microsoft’s branding (Figure 14.1).

You have the default Microsoft color scheme, the default Microsoft naviga-

tional structure and the default Microsoft logo. Most companies will want to

override the Microsoft identity with their own corporate identity, thereby

making the site specifically their own. This factor is important, especially in

an environment where users are collaborating and sharing data with each

other. When a user visits a page that applies the corporate branding and

adheres to all the corporate publishing standards they are much more likely

to trust the source and provide information to that site.

Applications of branding are wide and varied, with the more common

aesthetic applications relating to color and style, header/footer regions, navi-

gation, and the structure of pages in the Web site. The remainder of this

chapter focuses on these aspects of branding.

14.2 Branding Pain Points in SharePoint Portal

Server 2003

SharePoint Portal Server 2001 had significant limitations when it came to

applying custom color schemes, banners, layouts, and navigational structure.

For example, to apply your corporate banner to the title area of the portal, it

was necessary to customize some of the system dashboard template files. Cus-

tomization of these system files took your SharePoint deployment into

unsupported territory, and they were susceptible to being overwritten by ser-

Figure 14.1

Collaboration

portal using default

Microsoft branding.

14.2 Branding Pain Points in SharePoint Portal Server 2003 385

Chapter 14

vice packs and hot fixes. SharePoint Portal Server 2003 improved the cus-

tomization capabilities of the SharePoint platform with the introduction of

site definitions and custom templates, in addition to its tight integration

with FrontPage 2003. A site definition, first introduced with SharePoint

Team Services, is basically a set of files used when creating sites that provide

information about the site’s lists, views, Web Parts, pages, and navigational

structure. Custom templates are created through the user interface or by

using the SharePoint object model, and instead of residing on the file system,

they are stored in the SharePoint content database. Both WSS v2.0 and

SharePoint Portal Server 2003 support the use of multiple site definitions

and templates, meaning that you can create sites that reflect the needs of the

target audience by enabling the appropriate functionality up front through

the use of custom lists, Web Parts, and custom pages. With respect to look

and feel, site definitions provide the basic foundation for SharePoint Portal

Server 2003 sites. Customization of a site definition often results in manipu-

lation of the Collaborative Application Markup Language (CAML) code in

the base XML files. The main XML file of a site definition, known as the

ONET.XML, contains a number of significant elements that control various

components of a SharePoint Portal Server 2003 site. For example, the List-

Templates element defines the lists included in the site definition, and the

AllUsersWebPart element implements the Web Parts to appear on the page.

By now you are probably thinking that this doesn’t sound so bad! Site

definitions allow you to perform advanced customizations to SharePoint

sites, and if you apply all your changes to custom site definitions and not the

base system files, then you avoid your implementation being unsupported.

However, WSS 2.0 and SharePoint Portal Server 2003 site definitions have

significant disadvantages. If you examine the content of a SharePoint Portal

Server 2003 ONET.XML file, you will see that it is poorly structured and

that many of the site definitions share common element definitions. For

example, site definitions that contain the same lists still require a separate

copy of the list definition. In addition, working with site definitions requires

a basic knowledge of CAML, which can prove to be quite challenging for

even the most experienced programmer. Applying simple changes to a site

definition, such as adding a new banner or footer, involves applying the same

customization repeatedly to many files. For example, the AllUsersWebPart

element in the ONET.XML file of a site definition can be used to implement

a banner and footer on the default.aspx page. This element would run in

conjunction with custom code inserted on the default.aspx page to render

the custom banner Web Part. To apply the banner and footer to all pages, the

default.aspx customization would then be repeated on every .aspx page in the

site definition. Not only is this customization technique cumbersome, it is

also difficult to keep track of all the changes made to your system. When a

site has been instantiated from a custom site definition, it is difficult to apply

changes to the site, and in fact, Microsoft recommends that you avoid apply-