Tuesday, October 9, 2012

Examining a Wiki-Based Infrastructure in SharePoint 2010

By Timothy Calunod - EPC Group Sr. SharePoint Consultant

Our goal is to create a publishing Wiki system relying on the Wiki-based features and possibly leveraging other related technologies. In this post, we will examine how we can deploy Sites and Site Collections to support our Wiki-based publishing infrastructure.

Infrastructure Overview


It is not the logical infrastructure – the Web Applications, Site Collections and Sites – that complicates the solution, as the creation and configuration of these objects are not where the challenges lie, but rather the features and limitations of the Wiki Sites, Libraries and Pages to meet the need of the goal. Therefore, discussion of those particulars will be limited.

Our infrastructure will be simple to begin: one Web Application hosting at least two Site Collections, one Site Collection for the specific department and related manual, and one Site Collection for general information, navigation, and other resources. We will begin our focus on the departmental Site Collection and the individual manual site. Within the manual site, a default Table of Contents page will be created and each chapter will be isolated to a Wiki Library.

Creating the Structure


1) Create the Wiki Web Application

Nothing of particular challenge in this stage; we choose the host header name and set DNS entries, then create at least one Content Database for either the entirety of the Wiki content or different databases for each Site Collection. This would provide support for restoring the Wiki-based content separate from other content, as well as support individual manuals by department if each divisional Site Collection has been placed in its own database. It would also be a good idea to generate a wildcard inclusion managed path to separate the naming for the content as well.

2) Create the Wiki Site Collections

We create at least two Site Collections, one at the root and additional ones under our wildcard inclusion managed path, such as /dept in case additional needs may arise that will create other manuals for different reasons. The root Site Collection will act as the main navigation point and hold collected resources and tools for everyone generating content within the Wiki Site Collections. This will not contain any of the Wiki-based manuals.

The additional Site Collections will represent different departments generating the content, although they could easily be divided up into purposes, locations or any organizational division appropriate to the business. The key decision will be who should control access for publishing and reading the content, and represent that control appropriately. The Top-Level site of the specific Site Collection will provide navigation, resources and other tools for all related manuals in this particular Site Collection.

Regardless of organizational divisions, every Site Collection Top-Level Site will use the Enterprise Wiki Site Template.


3) Create the Wiki Subsites

Since we will be building an Employee Manual, we will place this site within an HR Site Collection as a subsite as this manual is typically generated by HR. By separating the entire manual into its own site, we can control individual chapters by Wiki Libraries and each section will be a Wiki Page within the appropriate chapter Wiki Library. This will provide a quick and simple navigation control for our sections within the chapter, and also for each chapter for the manual.

When the subsite for our manual is created from the Enterprise Wiki Site Template, a default library called Pages will be created. This Library, although associated with the default Wiki Pages normally generated when a Wiki Library is created, is actually a publishing page library with the Enterprise Wiki Page Publishing Page attached to it as well as a Project Page and Redirect Page. This default library will be used to hold the Table of Contents page for the entire manual, plus additional pages such as a How-To-Use guide and other tools and information.

Because we created separate Site Collections to divide management for the manuals, as we create new manuals we can create additional subsites to represent each manual. This also allows manual-specific control over the content through Site-Based security, and if the security requires such, a manual-based Site that is shared by more than one department can be made in a different Site Collection to represent this control.

Additional resource libraries, such as storage for forms, printable documents, collaboration resources and tools, will be generated either at the subsite level or at the Top-Level site, depending on how globally available these resources need to be.


4) Create the Wiki Libraries

For each chapter, we create a Wiki Library. This will automatically generate the Home.aspx and "How To Use This Wiki".aspx pages. The Home.aspx page automatically created will become the Chapter Table of Contents, and each section will be created as a Wiki Page as needed. We should keep the How To page for additional reference and instruction on collaborating through Wikis, although this information may also be consolidated into a User Guide for the manual.

There is no need to create additional Wiki Libraries in subsites beyond the required chapter, but the Top-Level Site in the Site Collection may have additional Wiki Libraries, including ones related to using and navigating content.

Naming Conventions for each Library should represent the organization naming, but the Title properties can reflect the individual chapter titles as well. This will provide a fast and easy way to generate navigation in the Quick Launch bar based on the chapters, but the generation of the Table of Contents will be handled differently.


5) Create the Wiki Pages

Since each Wiki Library will be a chapter, each Wiki Page in the Wiki Library will represent sections. This structure will also support multi-tiered structures that have many subsections per section but keep all related section information on the same page. Navigation within a section page presents additional configuration requirements.

Naming Conventions should also be applied as they are for the chapter libraries. Page names will be simpler and use text/HTML in the document itself to represent the complex naming, such as the section and subsection divisions and names. Unlike the chapter Libraries however, the order of pages will be controlled by views in some cases for navigation.


Analysis


We find that our logical infrastructure is quite simple and no additional configurations per Site Collection, Site, Library or Page has been discussed. However, the need to configure our infrastructure further is certainly evident, as such things as navigation, version control, content approval and other web content management features.

Also, the focus thus far has been on the Employee Manual subsite and its content, but attention to the divisional/departmental Top-Level Site and the root Site Collection must also be given to create a more usable structure since this will not be an additional Site Collection attached to the standard collaboration Web Application.

Object in the Architecture Purpose for Division
Site Collection by Department/Division Separates Ownership of Content by natural boundaries
Creates Shareable Ownership of Content
Supports individual backup/restore for Content
Top-Level Site of Site Collection Department/Division Creates central navigation for all manuals in Site Collection
Provides centralized tools for all manual subsites
Contains additional, non-Wiki content (forms, tracking, discussions)
Controls shared resources (templates, web parts)
Pages Library in Manual Subsite Controls Table of Contents for All Manuals
Subsite in Department/Division Site Collection Represents each different manual for separated management
Organizes sections of manual into simpler groups
Creates simple navigation management for content
Library in Manual Subsite Separates Manual Chapters
Creates automatic navigation
Separates Management of individual Chapters
Pages Library in Manual Subsite Controls Table of Contents for Manual Chapters
Provides additional content related to manual (how-to's)
Pages in Chapter Libraries Separates Chapter Sections
Supports Subsections in each Section

Additional Configurations


Within the manual subsite there will be additional configurations that will be set to take advantage of the collaboration features along with the Wiki features for SharePoint. Wiki Libraries normally use Simple Versioning since the changes to the Wiki pages would all be major ones. However, for drafting and approval control, the Wiki Libraries will have additional settings, including:

  • Enforced Check-Out for editing control
  • Comprehensive Versioning for drafting
  • Draft Item Security set for Approve to limit change visibility
  • Content Approval to control publishing
  • Custom metadata to indicate Chapter and Section
  • Custom Views to sort and show content based on Chapters, Sections, or other metadata

Wiki Libraries also suffer from some specific limitations to make using the collaboration features a bit simpler, such as not using folders, not allowing list templates and not allowing the attaching of or displaying content types. With SharePoint 2010, such limitations also include limiting custom columns from being displayed on the web page. However, the custom columns can be used in other ways, as we will discuss later.

Also, changes made to the navigation displays such as through the Quick Launch or Wiki Pages will also need to be configured.

Observation

Understandably, there is a higher level of complexity that simply creating an Enterprise Wiki site with numerous Wiki Libraries. Most of these additional configurations do not have to be applied although they will support a publishing system for the Wiki Pages. For the Employee Handbook manual subsite, the logical architecture along with the collaboration settings and Wiki-based features would be enough. But to continue to make the infrastructure useful, additional roles related to the Site Collections and Top-Level Sites also need to be defined.