Hello!

We begin a new discussion topic here based on a request that was made to me about how best to put Wiki Pages to good use in a SharePoint-driven environment. Aside from all the standard marketing that could be discussed, one particular idea that struck useful with the client was building their organization Safety Manual via Wiki Pages. Originally, they considered simply creating the document in Word and saving it in a normal Document Library, and then providing links in their department sites' pages to the document as a whole. Thus I undertook an exercise of planning a simple layout and structure for what the manual should become.

The notion of a Wiki-based manual made sense to me, since the Wiki Pages would be effective documents for not only building the structure of the manual but would benefit from other SharePoint-based functions such as Check In/Out, Content Approval, Versioning, and of course Web Publishing. Thus we will examine the construction of such a manual to provide a functional blueprint from which almost any form of manual could take. In this scenario, we will build a simple Employee Manual and use Wikis to construct the manual as well as take advantage of Web Content Management features available for Wiki Pages.

Wiki Pages, Libraries and Sites

A Wiki is known for its fast, simple and community-oriented features as far as a content authoring tool is concerned because it is browser-based, requires little knowledge of web design or development and can be open to anyone as far as editing and updating content is needed. In SharePoint, it is an effective document collaboration tool because it allows nearly everyone to access the content of a Wiki page through a browser and participate in the content generation. However, instead of requiring a Business Productivity tool such as Microsoft Word, a browser is the minimum client and thus creates a broader sense of content ownership since the organization is not bound to a specific application for content management.

Wikis are essentially deployed through three models: a Wiki Page, a Wiki Library and a Wiki Site. However, at the heart of any of those is the Wiki Page, as it is the content vehicle for anything created in a Library or a Site. Wiki Pages are implemented as a Content Type but are also formed into a Page Layout in SharePoint 2010. This makes the use of a Wiki Page much like a Publishing Page in that it can be managed similarly to Publishing Pages. Because of this shift in its architecture, the Wiki Page uses a Rich Content control for managing the content placed in it, and supports the use of Web Part insertion as well as managing the HTML of the page as it had done in the past.

A Wiki Page is bound to a Wiki Library as a Content Type, and in a SharePoint 2010 Team Site it also becomes the default web page type when creating web pages in a site. This library, called Site Pages, is a Wiki Library which is made available through the Wiki Home Page feature, and when the Publishing feature is not activated in a Team Site, all new web pages are generated as a Wiki Page and stored here. A Publishing Site still uses a Pages Library with Publishing Page Layouts attached to them, but two are not necessarily mutually exclusive. But after activating Publishing in a site, the Site Pages library does not become the default storage location for new web pages, and Wiki Pages are no longer used. However, this feature can be set so that Wiki Pages may continue to be used even if the Pages Library is active.

In SharePoint, a Wiki Library can also be deployed through a Wiki Site, called an Enterprise Wiki in SharePoint 2010. Normally, this is deployed as a Top-Level Site only, unless the Site Collection has the Publishing Infrastructure activated. This Site Template deploys a single Wiki Page library called Pages and has the Enterprise Wiki Content Type Page Layout attached to it, and also becomes the default location for all new web pages. However, the Publishing Feature is not activated, and the Wiki Home Page feature, which provides the Site Pages Library, is also not activated in the site. This provides a simplified view of all web pages being brought together in one location, as the activation of the Publishing feature to the Site or Web provides a single library for all web pages, be them Wiki Pages or Publishing Pages.

Analysis

When considering which page to use to deploy our web page-based manual, SharePoint provides an array of types of web pages that can be generated directly through the tool itself, without addition additional types of pages through other clients such as Word, OneNote or SharePoint Designer. Thus a quick assessment of available web pages will help us to understand what benefits and detriments we may find in deploying our Wiki Page-based manual. One important change to note is that the Basic Page, a simple HTML-based page, is no longer supported.

• Web Part Page – The Web Part page is used for supporting Web Parts and does not provide a method for including text directly in the page itself. Normally this is handled through a Content Editor Web Part, or a tool like SharePoint Designer may edit a page directly to include content. Because it lacks versioning capability since the Web Part container file holds the text and not the page itself, Web Part versioning does not provide a good standard for editing, drafting, approving and publishing content. Also, content approval is not available as a function by default although the approval process would not focus on the change of data, only the inclusion or removal of a web part.
• Page (Wiki Page) – The Page is the Wiki Page, which provides a Rich Content field that can include text, images, web parts and HTML-level control to content. Because it is implemented as a Page Layout, the metadata, which includes the Rich Content field control, is stored in as any entry in a list and support versioning, content approval and publishing. Also, because of its simple client nature, the Page can be edited through the browser with no additional client need. Unfortunately, there is no direct integration with products like Word and OneNote to produce pages through Smart Client Authoring, although copy and paste operations are fully supported. Also, the Page Content Type is limited to the Wiki Page Library only, although Publishing Libraries can use the Enterprise Wiki Page Layout.
• Publishing Page – The Publishing Page uses the Page Layout model to store and managed web pages much like the Page/Wiki Page as discussed previously. Field Controls for Page Content, Images and even support for Links and other custom field types, makes the Publishing Page highly versatile and useful in almost any scenario. Because they also support Web Parts in SharePoint 2010, they are also as functional as a Wiki Page in this regard. However, because the Publishing Infrastructure for the Site Collection must be activated, additional complexity is applied to the Site Collection.
• Business Productivity Pages – These pages, produced through Word or OneNote, could also produce web-page based content, especially since SharePoint support Smart Client Authoring and Document Conversion from Word documents to Web Pages. However, additional load for Document Conversions is a significant factor for Word, and the OneNote pages can have some formatting issues when converting into Web Pages through SharePoint. Also, these applications are required for editing the documents as well.

Thus in analysis, the Web Part Page, while useful in some areas, does not provide the degree of control needed to support a web-based document structure. However, the Publishing Page can certainly appear superior to the Wiki Page just in customization and field control availability alone, but often is more suited toward web publishing rather than document publishing and management and does create more complexity for the average content author. Normally, powerful clients such as Word or OneNote could certainly be used, but the goal is to provide an effective collaboration and publishing structure that does not primarily rely on the Business Productivity client.

Setup

In creating the Employee Handbook, there are several considerations that need to be considered:

1. A structured, well-defined document that is accessible to the organization
2. A well-managed publishing path, from creation to approval
3. Support for organizational formats, brands and compliance
4. Support for updating, publishing, and printing and employee concerns

While there can be additional considerations, we will begin our scenario with these items in mind as we progress toward the goal of developing our Employee Handbook through SharePoint.

In this scenario, the development of a Wiki Page-based documentation system seems to provide a functional document creation and management environment but also a publishing environment to provide both staging and production environments to control the presentation and compliance requirements as dictated by the organization. This is not to say that other options are not useful or have no place in this solution, but that the Wiki Page-driven system will be the main and primary way content is created, editing, approved and published through the SharePoint infrastructure. Additional features through SharePoint will be considered as the solution is developed.

The main goals to reach when deploying our solution will be:

1. Create an infrastructure to support the creation, editing and approval of web-based content
2. Manage the entire life cycle of the manual through the infrastructure
3. Maintain control over availability of the information
4. Provide tools to drive user adoption of the manual and infrastructure
5. Ensure appropriate levels of organizational compliance and support for users

Observation

Wiki Pages provide a powerful yet user-friendly method for creating, publishing and managing content through a web-based system. Coupled with many additional Web Content Management features in SharePoint, they can be extended without too much complexity or development and provide a strong foundation for a publishing structure to manage necessary documentation. But the solution is borne from many different pieces, and further examination becomes necessary to adequately deploy a useful and sound solution.

In my next post, we will examine how our Wiki Page-based documentation infrastructure can be created and deployed, as well as examine the initial steps in implementing this solution.