The strategic goals (from a company perspective) of the MOSS branding project were as follows:
1. Brand intranet.
2. Role/Persona approach versus functional. We developed a persona based approach to content delivery. Identified roles in the company and organized content so that these roles would have most of their daily needs served in one place. (We conducted a company-wide survey in which we asked people to organize information into buckets based on their roles and factored those results into our solution).
3. Minimize clicks / navigation to critical information. This is aligned with the above goal. We wanted to allow colleagues to get to information as fast as possible.
4. Page based delivery. We wanted to surface information in terms of pages which colleagues could easily read instead of abstract documents in a document library where a guess was usually required to find the needed information.
We identified two distinct project tasks in line with the above goals:
1. Develop the company brand.
2. Create the content to support the strategic goals. This was an important step because the content had been created in terms of documents in libraries. We had to pull out this information into user-friendly pages to enable employee self service.
The distinct pieces are explained below:
Develop the company brand
We engaged a design company to create the brand for us. Here is what the original provided design looked like:
We modified the design slightly to make the best use of SharePoint features. We then signed off on the design and got to work on implementing it.
The various elements of the user interface are master pages, page layouts, site definitions, Web Parts, navigation controls and xsl transforms for placement of content.
There are three ways we could have chosen to build the custom master pages.
1. From scratch - not recommended as SharePoint 2007 needs a few placeholders to be present in the master page or else the pages will not work.
2. From minimal.master - not recommended for a collaboration intranet, serves a .com site much better. The reason is that in a collaborative environment, you want to use OOB features and controls that SharePoint provides and a lot of these are declared in default.master.
3. From default.master - recommended as this allows you to use most of the collaborative controls already present on the master page. This master page does have a learning curve though.
We chose #3 and developed the master page for global branding. We took out what we did not need but retained a lot of the collaboration functionality declared in default.master. The master pages were developed using SharePoint Designer along with the style sheets that are discussed below.
These master pages were deployed as features to the target server. A note worthy of mention is that Microsoft recommends that we do not change application.master so we left it as is. That did cause a little confusion but we covered it pretty well in training. Only the site admins and the content authors saw this difference anyway, the majority of users did not.
We worked with the design company to come up with page layouts that would enable us to serve content in line with the corporate strategy. This meant modifying the 9 predefined page templates to provide the desired content layouts. This was done for both the SMARTPGS templates as well as the BLANKPGS template.
We used SharePoint designer to modify the page templates. We took off the override for the left navigation placeholder to allow the site left navigation to show up from the master page. We also changed the percentage widths of the table columns to better suit our business requirements. This provided all our pages with consistent branding so as to reduce user confusion.
The business requirement was that when new sites are created, a predefined set of Web Parts should appear on the default page for ease to the content author as well as from a governance perspective. The other requirement was that the brand should be applied to the site upon creation.
We developed 5 new site definitions that would serve 95% of the typical needs. We modified these site definitions and created/modified the WEBTEMP.xxx.xml and the ONET.xml files to place the selected web parts on the page. The recommendation here is to copy from the existing sts site definition and then rename and modify that to create a new site definition. We also wrote a custom provisioning provider that would intercept the site creation request and assign the correct site template and master page to it to meet the business requirement.
We needed consistent global navigation across many site collections to ensure consistency and enforce the brand. We also needed current navigation that could be maintained at a site level. After some investigation we decided to develop list based custom navigation providers that would meet the needs of global and current navigation. This was also a very user friendly solution in that it allowed the appropriate users to set up and easily change global and current navigation in a custom list, with no IT involvement. To improve performance, we cached the global navigation tree so it would not need to be assembled for every site.
This is a view of the global navigation shared across all site collections. It includes one level of dropdowns.
We created custom site columns, custom content types and then a custom list that used these content types to allow users to easily build hierarchies that the navigation provider could read and deduce the navigation levels. Here is an example of the custom list for the top navigation content. The actual URLs below in the Url Link column have erased, but this should get the point across.
Building custom navigation providers means that we did not have to build special navigation user controls, we made minimal changes to the master page to switch to our navigation provider for navigation content. One tip here is to start debugging your provider early and often. For folks developing custom providers for the first time, it would be prudent to develop them in ASP.NET first to get a good understanding of how they work, only then proceed to build them in SharePoint. We used Visual Studio 2005 to develop and debug the custom navigation providers.
We would like to point out that not only did we reuse SharePoint to hold the data, but we are also using the SharePoint security permissions to secure who is able to get access to and change the data in the list, and ultimately the navigation.
We used CSS styles to achieve our design goals. Core.css defines most of the standard SharePoint CSS classes. Every site and application page is linked to core.css. We left core.css intact (as is recommended by Microsoft) but 1) changed the direct references to core in default.master to point to a custom style sheet and 2) overrode some of the other indirectly referenced core styles by defining a few styles in the master page itself. We also developed secondary style sheets that would enable us to change the color theme on sub sites easily and used the AlternateCSS setting to attach the secondary style sheets. The effect is shown below.
We purchased a few third party Web Parts that served the business needs really well. These included a stock ticker Web Part, weather Web Part and an image rotator Web Part that gave us quick bang for the buck. We also used XSL transforms to place information in a desirable manner using the Content By Query Web Part.
The final design looked like this:
As discussed earlier, most of the content was previously stored as documents in libraries. From a company strategic perspective, we decided that in order for the more relevant content to be of greatest use to colleagues, it would need to be pulled out from documents and surfaced on pages along with action items that users might consider after reading the information. In our mind, this strategy would go a long way in driving user adoption and employee self service. We assembled a content creation team that encompassed content authors from all departments who would then be responsible for the relevant content for that department.
This strategy did indeed pay off and user adoption increased many fold.
This entire branding project was fast paced and was completed in 6-7 weeks from the inception date. The newly branded site went live on October 1, 2007 with only 4 support calls the entire first week. There have also been no issues reported since that time, so the project team is proud of the work we have done.
Update on Persona based approach: Persona based approach basically means (to us) as understanding the user types (personas) that will be visiting the intranet. Once we divided people into categories (such as general workers, managers, executives) we went ahead and developed persona based sites so that these classes of people could get all or most of their day to day needs served in one place (as opposed to trying to find this information and wasting time). Examples of day to day needs include employee benefits information, travel guides, travel expense forms, career center, information for new colleagues to get started, rewards information, recognition information, performance mangement tools for managers, learning center links, ethics and compliance links. This simplifies the dissemination of information, updates, as well as keeps the single source of information intact.
Here is a snapshot of the Departments and Teams page. This is just a listing of where to find more information, most of our departments were in different site collections.