Force Left Nav To at least 200 Pixels wide
Force Body To at least 500 Pixels high
SharePoint MindsharpBlogs > Timothy Calunod > Posts > Configuring Wiki-based Collaboration

 Single Post

Dec 08
Published: December 08, 2011 20:12 PM by  Timothy Calunod

Hello!

We are in the middle of an examination of using Wiki-based collaboration features to create a functional organization manual. In this scenario, we are creating an Employee Handbook for Human Resources entirely in a Wiki-based solution. In my first post, we examined Wiki-based features such as Sites, Libraries and Pages, as well as comparing and contrasting Wiki Pages from other types of SharePoint web pages. In my second post, we examined the logical structure that would be assembled and configured to support our manual, as well as specific uses applied to each Site Collection, Site, Library and Page. Here in the third post, we will continue this discussion, focusing on how the structures within the Web Application can enhance the Wiki-based manual and other related sites.

Content: Top-Level Site of Department

In our Employee Handbook scenario, we placed the manual under the HR Site Collection and had the Employee Handbook created as its own subsite, populated with Wiki Libraries representing the chapters of the manual. The Top-Level Site, however, would not be the storage location for any of the manuals in Wiki format. The main reason we separated the manual in its own site was:

  • To take advantage of automatic and controlled navigation
  • To managed each chapter as a separate set of documents
  • To separate security control per manual
  • To separate collaboration work from other manuals

The benefits would create a simple package while still taking advantage of several areas, including:

  • Site Collection features useful for the Wiki-based publishing
  • Workflows, Content Types and Web Parts
  • Automatic security isolation from other departments
  • Centralized collaboration work and tools
  • Centralized navigation for other manuals in the department
  • SharePoint context-level search for the Site Collection manuals

The above reasons are generally the application of the Top-Level Site architecture used here, so that other, less manual-specific tools and functions can be separated from the manual collaboration and viewing itself. Thus, to enhance our department-driven Site Collection collaboration, we would create in the Top-Level Site:

  • A Wiki Library for an FAQ as well as general guidelines and tips for collaboration
  • A discussion board for a departmental forum for ideas and changes
  • A commentary page for the departmental information
  • Navigation tools for all manuals in the department
  • A centralized Style Library, Document Library and Image Library
  • A master forms and printing manual library for printing the entire manual and forms related to the manual
  • A change update announcements list to broadcast important changes
  • A help and guidance guide for specific manuals and how to access, use, search and print documentation

WikiWebTLSCInteractive

Interactive sections, such as an update and announcements summary page, as well as a simple comment wall for exchanges and feedback, can also provide additional functionality for the site.

We can construct this Top-Level Site as an application focused on making access to these manuals much simpler, more streamlined and consistent, and still provide additional tools and resources for the manual creators to generate, update and publish the manuals as needed.

Configurations for Top-Level Site:

  • Controlling Global Navigation to hide all manual subsites to prevent overcrowding
  • Controlling Current Navigation to display important libraries such as forms, how-to’s and references
  • Creating Site Columns for Chapter and Section metadata on the content Wiki pages
  • Activating the Publishing Infrastructure feature to take advantage of Look and Feel controls
  • Limiting the Site Template and Page Layout templates for manual subsites
  • SharePoint Groups to represent Manual Creators either by manual or by role
  • Navigation tool for viewing and accessing manual content subsites

WikiWebTLSCContent

Content: Top-Level Site of Documentation Site Collections

For the Top-Level Site of the entire Wiki Documentation Web Application, the Site acts more like a resource center as well as a navigation tool for accessing individual department Site Collections, or specific Manuals of high interest. While there may be additional subsites beneath the Top-Level site to control resources, a single site holding all the necessary content in Document and Asset Libraries would suffice for our need. Since the majority of the content will be outside of this Site Collection, many of the external hyperlink references will be done using standard hyperlink inserts instead of Wiki Links.

Standard Resources may include:

  • An Organization Style Guide for specifics when creating documentation
  • Legal information to be included or considered when developing content
  • Organizational Chart and Job Role or Job Description Information
  • Master Templates and Forms used for the organization
  • Employee Directory and other contact information

WikiWebTLSCRootContent

Configurations for Root Top-Level Site:

  • Modify Current Navigation to represent key resources and content
  • Use content targeting to control access to Resources
  • Define centralized libraries for organizational guides and tools
  • Define centralized libraries for templates and masters
  • Provide access matrix, legal information and other organizational references

Observation

The two Top-Level Sites – the Root Site Collection and the Departmental Site Collection – offers many communication and collaboration options that can grow from simply being Enterprise Wikis, but can also be used as Team Sites. However, the Root Top-Level Site requires much less configuration and dependency on the Enterprise Wiki while the Departmental Site Collection benefits from Wikis for additional FAQ and Guidance documentation while limiting the need for a complete Team Site in this scenario. Thus it would seem that using Enterprise Wikis can still be a great benefit and also provide the degree and flexibility of control needed to complete our organizational manuals.

Now that our infrastructure is in place, the specific work on the Wiki Pages can be handled. In my next post, we will examine how the Wiki Pages and Web Content can come together to provide a sensible and useful content generation tool.



 Comments

No comment(s) to show

 Add Comment

* Required Field
Your Name *
Your Blog Url
Message Subject *
Message Body *