Overview of SharePoint 2003 and Introduction to the Components of the User Interface, Part Two

Overview of SharePoint 2003 and Introduction to the Components of the User Interface Part Two

» Back to Part One

The Components of the SharePoint 2003 User Interface

Within SharePoint, Microsoft has provided several ways to customize the user interface of both SPS and WSS. This is great because we have several options for customization and we can select the method that best suits our needs and skill set. The downside is that it can also be very confusing as to which method to use and what the strengths of each one are. We are going to step through each available method, what it is, where it is, which product uses it and what can we do with it. We will cover:

  • Custom Definitions – Site Definitions and List Definitions
  • Custom Templates – Site Templates and List Templates
  • Themes
  • Cascading Style Sheets (CSS)
  • JavaScript
  • CAML
  • FrontPage

At the end of this article is a component diagram that shows the relationship and storage locations between the user interface components. There is also a Quick Guide that provides quick reference high level information about each component.

The Site User Interface Components

There are two components available for site customization, site definitions and site templates. There is a lot of confusion around what is a site definition and what is a site template and what are the differences between the two. A lot of this is because a site definition is a template in general terms. In SharePoint however, the terms site definition and site template are used for very different things.

What is the difference between a Site Definition and a Site Template?

A site definition is a collection of files that serves as an architectural template for a SPS area or for a WSS site. A site definition is stored on the web server and consists of several key folders and files. The files define the SPS area or WSS site.

A site template is a customization to a site definition done through the user interface and stored in the content database. A site template is tied to the site definition off which it was based and can’t be used if the site definition is not present on the web server.

The relationship between a site definition and a site template can be likened to a bakery making and decorating cakes. A bakery uses the same ingredients over and over to make several cakes, and then uses icing in different ways, like themes or names, to make each cake look different. The site definition files make the sites. Site templates then customize the sites to make each one look different.

More detail about a Site Definition

A site definition is stored on the web server and consists of a hierarchy of specially named folders that contain ASPX and XML files. The ASPX files are the web part pages SharePoint uses to display the screens in a site. The XML files define the properties for site creation, lists, views and other general information in regards to content appearance on the site.

SPS and WSS are both based off default site definitions that are a part of the product’s installation. Copying a default site definition and modifying that copy is the best way to alter the design and content of a site definition to meet our needs.

Customizing a site definition is much more involved than customizing a site and creating a site template from it. Site definition customization involves modifying files on the web server and any modifications will effect the entire SharePoint environment. A benefit however is that the site definition will be available for new site creation from anywhere in the environment.

A site definition is ideal in situations where we need to brand and customize SharePoint and deploy many sites off that customization.

More detail about a Site Template

A site template is a type of custom template. A site template tracks the changes we make to a site’s navigation, web parts, lists, libraries and content (optional). It will also include any list templates and theme specification. Creating a site template is taking a snapshot of the site’s current state. This snapshot is stored in the content database. Site templates can’t be larger than 10MB. If updates are made to the site after the site template is created, the template will not be automatically updated. Instead another site template has to be created.

A site template can be used for both SPS and WSS. It can be moved from WSS site to WSS site or it can be added to the Central Template Gallery using the
STSADM command tool on the web server. A site template is only available on the site on which it was created or a site it has been copied to unless it is added to the
Central Template Gallery. In regards to SPS, the site template will only be available if it has to been added to the Central Template Gallery. Once added, the site template will be available for site creation from the portal or any WSS site.

Site template doesn’t mean portal area template
Site templates can only be used to create WSS sites. If we need to create a custom area, we have to use a custom site definition.

A site template can be used to create new sites. The new site will automatically have all the navigation, web part, list, library and content changes that we applied and saved from the original site. A site template can be particularly useful if we have to create the same type of site over and over. For instance, a project manager needs a specific task list and document library for every new project site. We can create a site, customize the list and library and save out a site template. That template can be used going forward for every new project site.

Role-based templates
Role-based template is an industry term for templates based on set requirements or roles within the company. A role-based template could be for project management, employee activities, sales, managers, etc. and include the necessary lists, libraries, navigation and content. An effective way to plan site taxonomy is to identify roles within the company that could benefit from using SharePoint and create role-based templates accordingly.

When Should a Site Definition be used Versus a Site Template?

After reviewing the differences in a site definition and site template the question may still remain, so which one do we need to use? The answer will depend on the implementation situation and the available resource’s skill set.

A site definition requires more time for development and a method to either access or request uploads to the web server. The resource creating the site definition will need to be very comfortable with editing .NET code and possibly CAML. A site definition will be available across the entire SharePoint environment, which could be a benefit or a drawback depending on the sensitivity of the content.

A site definition is an all encompassing vehicle for user interface customization. Within a site definition lie list definitions, view styles, and XML code. A site definition can reach far and wide in regards to customization of a site. It is something that needs to be developed, tested, and then deployed.

A site template on the other hand, is fast to create, move and reuse. Site templates can be created on the fly and are controlled entirely through the user interface and can be maintained by less technical resources. A site template will take a snapshot of the majority of the changes we have done to a site, including the addition of a theme. It will then be available only as much as needed since we have a choice to copy it selectively to sites or to add it to the Central Template Gallery for all site creation.

A site template can be used to move an entire site from one location to another if it is under 10MB and will save you from moving it via site backup and restore. Site template files can easily be sent and used by other users with a quick save from the gallery to a local or shared drive, or by emailing the file.

Both site definitions and site template have great uses in any SharePoint environment. In fact their purpose is similar to the purposes of a portal and a WSS site. A portal is equipped for a large audience, static content and permanence. A site definition is geared for a large customization, consistent content and longevity. A WSS site is quick to create and is ideal for small teams and short term content. A site template works great to create quick site copies that are both usable and disposable.

The List User Interface Components

Lists may not be the first thing that comes to mind when we think about user interface customization, but formatting and content display is a very important part of the end user experience. The majority of content that is in a SharePoint site is contained in some type of list. We have several options for creating and maintaining the user interface for lists. Just like for sites we have definitions and templates, and additionally we have View Styles.

About List Definitions

Similar to a site definition, a list definition is an architectural template for a list. It is also a component of a site definition. A list definition is stored on the web server and is a collection of files that usually consists of ASPX files and one XML file. The ASPX files are the different view or action pages for a list. The XML file defines the views, forms, toolbars and any special fields for a list.

SPS and WSS both have a default collection of list definitions that are a part of the product’s installation. Copying a default list definition and modifying that copy is the best way to alter the interface of a list definition to meet our needs.

Customizing a list definition can be as simple as basic field changes, or become more complex and require a higher level of development skill. The customization involves modifying files on the web server and any modifications will affect any site based off the parent site definition. List definitions are a powerful way to create custom lists that meet user requirements. They are ideal in scenarios where a collection of sites need the same custom list available on every site.

About List Templates

A site template is one type of custom template, list template is the other. A list template tracks the changes we make to a list’s columns, forms, pages and content (optional). Creating a list template is taking a snapshot of the list’s current state. This snapshot is stored in the content database. List templates can’t be larger than 10MB. If updates are made to the list after the list template is created, the template will not be automatically updated. Instead another list template has to be created.

A list template can be used for both SPS and WSS. It can be copied and used on other sites, but it is associated with the site definition from which it was created. This can create a problem when trying to move lists within portal areas or around WSS sites based off different custom site definitions.

Using lists on other site definitions
There is a workaround available to move a list template from one site definition to another for the following scenarios:

  • WSS site to another WSS site
  • WSS site to a SPS area
  • SPS area to another SPS area

Use of the workaround should be limited to a skilled SharePoint administrator instead of content owners. The workaround is explained in
this blog post:

Create a list in a portal area based on a list template
.

Once created, a list template can be used to create new lists. The new list will automatically have all the column, form, page and content changes that we applied and saved from the original list. A list template can be particularly useful if we have to create the same type of list over and over. For instance, the HR department wants to provide a hotel and restaurant list for each office location with address, phone and rating information. We can create a list, customize the list with the required columns and options and save out a list template. That template can be used going forward for each office location.

When Should a List Definition be used Versus a List Template?

The decision on when to use list definitions versus list templates is a very similar question as to when to use site definitions versus site templates. It depends on the implementation situation and the available resource’s skill set.

Like a site definition, a list definition requires more time for development and web server access. The resource creating the list definition needs to be comfortable with CAML. The list definition will be available for use anywhere within the parent site definition and needs to be developed, tested and deployed.

A list definition is a major customization component of a site definition. It really allows us to tailor the content entry and display to help make the site definition unique and meet user needs. A list definition is also the only way to make a custom list available automatically with sites created off a site definition when a site template isn’t used.

A list template, like a site template, is fast to create, move and reuse. They can be created quickly through the user interface and be maintained by less technical resources. A list template takes a snapshot of the majority of changes done to a list and that list template can be moved and used on other sites and SPS areas. List template files can quickly be saved to a local or shared drive for other users or sent via email.

List definitions and list templates can both be very useful in SharePoint. List definitions are more for static lists and to help customize a site definition. List templates are easily accessible, usable and disposable.

About View Styles

One of SharePoint’s more powerful features is allowing the user to setup custom views for list or library data. Part of the view creation or modification, is a style selection. SharePoint provides several default styles like Boxed, Newsletter and Shaded. Selecting a style will format the interface of the list or library accordingly. Custom view styles can be created so we can have even greater control of the list or library interface. This is beneficial if we want to provide a display other than the standard table column and row design.

View styles are stored in an XML file in a site definition on the web server. They can be deployed to either only be available in specified lists and libraries or to be available in all lists and libraries. Creating a view style does require a resource with XML or CAML experience.

Custom View Styles are useful in situations where the data needs to be formatted and the default styles do not meet the user’s needs. We can create a custom view style to tailor the format of the content so it meets the requirements.

Additional User Interface Components

Customizing the SharePoint interface doesn’t stop at definitions and templates, there are also several other ways to change the display. These other components can work alone or in tandem with each other and the definitions and templates.

About Themes

A theme is a custom design that can be saved and applied to WSS sites. A theme consists of design and color changes that are applied on top of a site after it has been created. The theme will apply to all existing pages and any new pages that are created in the site. However, the theme will not apply to any new or existing sub sites that are present under the parent site. A theme has to be individually applied to each site.

A theme consists of CSS and image files and is stored on the web server like a site definition. Unlike a site definition, a theme is available to, but do not affect, all WSS sites in the environment. The theme has to be applied to the site. A theme is more permanent than a site template because it lives as files instead of as a snapshot in the content database. A theme does not however store list, library and content changes like a site template can.

Many preset themes ship with Microsoft FrontPage 2003 and FrontPage can additionally be used to create new themes.

Common misconception about creating Themes
A common misconception is that you must use FrontPage to create new themes for WSS sites. FrontPage is not required to create new themes. You can create themes using a code and/or image editor to modify the style sheets and image files.

Themes are an ideal solution if we need to apply different designs or brands to several WSS sites that can use the same site definition. For example, if a company needs to provide a team site to several satellite offices, a theme could be used to uniquely brand each satellite office site.

Cascading Style Sheet Customization

The use of style rules is heavily utilized in SharePoint. There are two main Cascading Style Sheet (CSS) files that SharePoint uses that are stored on the web server. A best practice is to copy the contents of these files into a custom style sheet, make edits, and specify the custom style sheet in the site definition. We can also specify a custom style sheet through the SPS administrative screens.

All of the site colors, font specifications and many images are specified in the style sheets. A SharePoint site can easily be branded by updating the style rules alone. There are over 550 style rules however and a resource comfortable with editing CSS is required.

Nearly every situation or scenario would benefit from customizing the styles. It is the most efficient way to change the SharePoint design from the default look to a branded and custom look.

Using Custom JavaScript

Often clients have very specific needs and requests for functionality for a SharePoint site. Sometimes the functionality isn’t possible unless a script can be used. A site definition allows for specification of a custom JavaScript file. The file is stored on the web server and can contain scripts that execute within a site that is created from that site definition.

JavaScript can also be added to a specific page in a SharePoint site by using a hidden web part on the page in order to add the code and effect the functionality of that page.

Custom JavaScript code could contain scripts that modify or add functionality to the SharePoint site. Some simple examples of this are navigation modifications, altering the CSS, hiding sections of the page and requiring user input for certain functions. A resource with JavaScript experience would be required.

About Collaborative Application Markup Language (CAML)

Collaborative Application Markup Language (CAML) is used to define a SharePoint site or list. CAML is also used to define tables when provisioning WSS sites. It is an XML-based language that can be used in several ways to customize a SharePoint site and will be referenced the most in this book when discussing custom site and list definitions and custom view styles.

SharePoint uses CAML in two ways, to render the type of data in a field, and to render HTML that is displayed in the browser. Sites and lists both use data-defining and HTML-rendering elements in CAML to construct and display views, fields and forms. A resource familiar with CAML would be recommended for creating custom list definitions and for parts of site definition modification.

Customizing a SharePoint site using Microsoft FrontPage 2003

One of the product relationships that are promoted with SharePoint is Microsoft FrontPage 2003 (FrontPage) for site customization. FrontPage is cited as a way to create themes, make customizations to sites and lists, create data view web parts and update the navigation and web part pages.

If Office 2003 is installed on the client machine, FrontPage will provide two handy methods to easily open a site for edits. In Internet Explorer under the File menu is an Edit with Microsoft Office FrontPage option that will open the current SharePoint site in FrontPage. The second is an option in FrontPage under the File menu, Open Site, which allows you to browse to a network location and open a SharePoint web site.

All of the following information is in regards to customizations done by opening the site through the above described methods. It is not in reference to using FrontPage as a regular code editor.

Additional information in regards to FrontPage
Opening a SharePoint site in FrontPage can possibly create problems and dilemmas for the SharePoint environment down the road. These potential pitfalls are covered in Chapter 15: Some Notes About FrontPage.

FrontPage has several Task Panes directly related to SharePoint such as Themes and Web Parts. The Task Panes and other similar features in FrontPage make customization very easy through the GUI Builder interface. Additionally there is a hierarchical tree view of the lists and libraries in the SharePoint site. Changes to these elements can be done directly from within FrontPage utilizing the same interface.

A major item to note is any changes done to a SharePoint site using FrontPage are stored in the content database, even if the changes are to ASPX files that are stored on the web server. A copy of the page is created in the content database and the sites references that copy from that point forward.

A resource familiar with FrontPage, design and HTML is recommended for SharePoint customization through FrontPage.

SharePoint User Interface Component Relationship and Storage Map

The following map shows which user interface customization components are stored on the web server versus the content database and any relationships that exist between components.

» Click to view larger

SharePoint User Interface Component Quick Guide

The following chart outlines the knowledge we have reviewed for each customization component in a quick reference chart so we can quickly compare the components.

Component What is it? Where is it? Applies to which product? Benefits Drawbacks Recommended Skill Sets
Site Definition Architectural template for a SPS area or a WSS site. On the web server. SPS and WSS. – Most thorough and complete way to customize the design, lists and libraries for a site or area.
– Available for site creation from anywhere in the environment.
– More labor intensive
– Once deployed, a SPS area or WSS site can’t change which site definition it is based on.
– Editing site definitions after it has been deployed can create bugs, break the site and is not supported by Microsoft.
Minimal:
– HTML
Optimal:
-.NET
– CAML
– Design
Site Template Custom template that tracks navigation, web part, list, library and content changes. Once saved, it is stored in the content database. Can be saved out locally as a STP file. WSS – Top level site, sub site or site created from SPS. – Fast to create.
– Easily portable to other sites.
– Complete management through the user interface.
– Does not require server admin access.
– Saves the theme as a part of the template.
– Has to be added individually to the site template gallery for each top-level site or added to the Central Template Gallery using STSADM command tool.
– A template file can’t be updated post creation, it has to be recreated.
– 10MB template size limit.
Minimal:
– SharePoint training on how to create, use and delete site templates
List Definition Architectural template for a list. On the web server. SPS and WSS. – Most detailed way to create and customize a list.
– Available for list creation from any site that is based on the parent site definition.
– Tied to a site definition and not available for sites based off another site definition.
– Can become labor intensive and require higher development skills.
Minimal:
– HTML
Optimal:
-.NET
– CAML
List Template Custom template that tracks column, form, page and list content changes Once saved, it is stored in the content database. Can be saved out locally as a STP file. SPS and WSS. – Fast to create.
– Easily portable to other sites.
– Complete management through the user interface.
– Does not require server admin access.
– Has to be added to the list template gallery for each top-level site.
– A template file can’t be updated post creation, it has to be recreated.
– 10MB template size limit.
Minimal:
– SharePoint training on how to create, use and delete list templates
Custom View Style Styled formatting for a view state of a list or library. On the web server. SPS and WSS. – Allows for exact required customization for data display.
– Can be deployed in either specified or all lists and libraries.
– More labor intensive. Minimal:
– HTML
– XML
Optimal:
– CAML
– Design
Theme Custom design changes to CSS and images. On the web server. WSS Sites. – Quick way to create multiple designs based on the same layout.
– Available to any WSS site in the environment.
– Has to be applied to each site individually including child sites.
– Doesn’t allow for list, library, web part attribute or content changes.
Minimal:
– Design
– Graphics
– CSS
Cascading Style Sheets (CSS) Style templates that specify how different elements appear on a web page. On the web server. SPS and WSS. – Quick way to change out colors and images of the existing layout. – Limited to working with the existing styles. Minimal:
– CSS
Optimal:
– Design
JavaScript Scripting language that can interact with HTML code. On the web server or in the content database. SPS and WSS. – Add functionality otherwise unavailable in SharePoint. – Required JavaScript fields and thorough site testing. Minimal:
– JavaScript
CAML An XML-based language that defines sites and lists. On the web server. SPS and WSS. – Most detailed way to customize a site or list. – Can become labor intensive and require higher development skills. Minimal:
– XML
Optimal:
– CAML
Microsoft FrontPage 2003

(Edit in FrontPage option from browser or Open Site option in FrontPage)

HTML editor that can open any SharePoint site and make design and content changes. Once saved, it is stored in the content database. SPS and WSS. – Convenient tool for design, site editing, creating themes and data view web parts.
– Allows for site customization without server admin access.
– WYSIWYG interface.
– Saving changes to the content database breaks the connection to the site definition so future site definition changes will not be reflected on the edited pages.

– Have to edits sites and site pages one page at a time.

Minimal:
– FrontPage 2003
Optimal:
– Design
– HTML
– CSS
– Graphics

Tools, Skill Sets and Permissions Needed to Customize SharePoint

Before we launch into planning and customizing SharePoint, let’s review the tools and generally required skill sets we will need. Depending on the chosen level of customization, certain web server permissions may also be required to make the enhancements.

Tools

If the planned customization will involve editing or creating files on the web server, an application will be needed for making code edits. If the customization will be restricted to templates and options available through the SharePoint user interface, no special tools will be required other than the browser.

All ASPX and XML file code edits can be completed using a simple text application such as Notepad, which will be available on all web servers. Any Integrated Development Environment (IDE) code editor can be used and usually has added benefits such as code formatting, tag insight, intellisense and validators.

Graphics can be created with an image editing program or can be provided from an outside design firm or group. An image editing program can also be used to select colors for branding the site.

CSS can be edited in any text application or IDE code editor, or a CSS editor can be used.

Skill Sets

The majority of exercises and techniques explained in this book are geared for a more technical audience that is comfortable with Web site coding and design. The book audience should:

  • be familiar with SharePoint
  • be familiar with common design practices
  • be familiar with CSS
  • be familiar with HTML

There are some advanced exercises in this book that will require a comfort level with .NET user controls and XML.

Permissions

If the planned customization will involve editing or creating files on the web server, either web server access or file upload access to the web server will be required.

Some customization methods additionally require the resetting of Internet Information Server (IIS) in order for changes to be applied to the site. Only users in the administrator group on the web server can perform an IIS reset.

Additionally, there are some tools and administrative web pages that can only be accessed by users in the administrator group on the web server.

If the customization will be restricted to templates and options available through the SharePoint user interface, no special server access is required.

Summary

In this article we covered the following items:

  • An informative short history on past SharePoint products and we learned that knowing the background better helps us understand the product structure and purpose.
  • An effective way to explain SharePoint products to non-technical audiences to improve our taxonomy and requirements gathering.
  • Introductions to all the major SharePoint customization components and covered what each one was, what it could do, where it was stored, which product uses it and what type of skills are needed for the customization.
  • An overview of necessary tools, skill sets and permissions needed to customize SharePoint.

This article has been a high level overview of the available components to customize SharePoint.
For additional information about each one, refer to other articles and blog
posts at
http://www.heathersolomon.com/blog
.

Dustin Miller and Heather Solomon from SharePoint Experts