SharePoint WCM Pt 1 - Planning

There's been an increase in questions about SharePoint's* web content management (WCM) features of late, including how to build accessibility compliant web sites on SharePoint. So I thought I might write some posts on the basic 'how-tos'. Whether or not there is a Pt 2+ will depend on how popular or useful this post is...

*I may be repeating myself, but I'm bored with the MOSS acronym and am back to just using 'SharePoint'. I'll try and make the distinction between Windows SharePoint Services and SharePoint Server 2007 when necessary. And in this case, it's necessary. I'm talking about using the full Microsoft Office SharePoint Server 2007 for WCM. You can build WCM sites on just Windows SharePoint Services, but it's harder and requires a lot more configuration and development.

This first post is about planning. Whilst it can be tempting to just dive into the technology, planning can help improve outcomes, reduce time to build and mimimse mistakes along the way. Done well, planning can also double up as documentation to support your web site.

Before we start, it's worth making a distinction between WCM and web site design. If you just want to create funky-looking web sites, you'd probably go and use Expression tools or similar. WCM is really about two additional features within web sites: 1. Enabling end users to create pages, author and publish content using nothing more than a web-browser; 2. Integrated information lifecycle management, such as: workflow to manage publishing/expiration of content and controls to ensure consistent formatting of content. There's nothing stopping you from creating a great web site design that happens to include WCM. But this post is about the WCM bit, and how to plan to build it using SharePoint...

Scenario:

We are going to create a simple web site for publishing content. It will enable users to create and edit pages within the site without requiring any specialist skills or tools, i.e. 10 minutes of training and a web browser is all they are getting.

Planning Steps:

To design the site, you will need to decide on the following:

• Site map
• Page layouts
• Field controls
• Content management
• User roles

Site map

The site map displays your site hierarchy (i.e. site/sub-site/sub-site etc.). Depending on how detailed you want to be, you can also include identifying pages within each site to create a full site map. The image below is a basic summary site map (i.e. sites and sub-sites only, pages not included)

The site map helps you to structure your web site and identify the number of levels to be created. It also helps to determine hierarchical navigation between sites.

Tip: Keep the number of levels within your hierarchy to a minimum (ideally 3 max). URL depth is often used as an indicator of relevance in search results. Sites buried deep in the hierarchy can become difficult to find from a hierarchical navigation perspective and also via web searches.

Page Layouts

Using wire frames to create page layouts will help identify the number of different page layouts that you need to design, the navigation structure of the page and the required field controls. If you don't do this step, you will often end up duplicating work. Wire frames help identify common and recurring elements that can be re-used throughout your site.

Normally, each page would be presented separately with a report detailing its navigation elements, page layout and field controls. The image above is a basic summary for 3 page layouts - the home page for the site, the home page for the sub-site 'Products' and a product-specific page within sub-site 'Products' to show you the similarities and differences. The process would be repeated for all other sites and pages in the site map. At the end, you will have a list of required page layouts. Some areas of the web site may share the same page layout (for example, news articles and customer references) and some areas may have a page layout based on another (for example, you may later create a 'beta' products sub-site - at level 3, beneath products - and have a 'beta product name' page layout based on 'product name' but with additional field controls such as 'planned release date').

Creating page layouts can also show you dependencies between sites and pages. The 'Products' page is the home page for the Products sub-site. It contains a field control - Product-related news - that will display items from the News sub-site (the field control will automatically retrieve news items tagged as 'product').

If we were also covering web site design in this post, the next step from wire frames would be to create full mock-ups of the pages to show the precise look-and-feel and functionality to be achieved. These visuals would highlight required style sheets and branding (logos etc.) for the site.

Field Controls

Field controls are elements on the page that can contain content. Some field controls will be user editable (such as 'title' and 'description'). Some fields will be non-editable because they are dynamically updated based on other content, such as displaying a summary of news articles on the site home page. Some fields will be visible to everyone (navigation and page content), some fields will not (review date, page owner). To complicate matters, SharePoint provides two types of field controls (also known as place holders). Standard field controls are embedded in a page layout. When a new web page is created, it contains an instance of each field control from its associated page layout. But a web page can also contain 'web parts'. Web parts are displayed within web pages but their content is independent of the web page. If I get as far as writing Part 2, we'll delve deeper into the SharePoint page architecture. For now, we are just looking at standard field controls, not web parts.

A field control matrix identifies what fields need to be created, their properties, and which page layouts will be using them. The image below shows a partially completed matrix for our sample site:

Content Management

The whole point of a WCM system is to manage content. Planning should include identifying any information lifecycle and workflow policies that need to be applied to web pages within the site. The image below shows a list of the content management processes that will be created for our sample site:

Each process would also have an associated visual workflow to identify events and associated actions.

User Roles

User roles are an easy-to-manage way to apply permissions and access rights to web pages. Create a matrix that highlights the different types of role to be created and where the roles will be applied throughout the site map. In our sample site, we are just having 4 simple roles that are applied throughout the site - Reader (Anonymous), Author (creates/edits pages and content), Approver (approves pages and content for publishing), and Admin (manages the overall site). All sub-sites will be inheriting the top-level site permissions.

As you work through each of the above steps, you may (should) find yourself revisiting earlier steps as new elements arise. For example, if you scan the images above, you'll notice that the field control labels in the page layouts do not match the matrix. For this reason, it can be beneficial (time saving) to not do the visual designs until the end of the planning process - wireframes are quicker and easier to update.

So. that's it. Planning is complete. The next stage is to build it in SharePoint...

Filed under: SharePoint - Web Content Management

Technorati tags: SharePoint; SharePoint 2007