This is the second in a good intentioned series of blogs detailing my experiences and uses of the tool. The first blog, SharePoint 101, provided some context and a ‘fictional use-case’ which the following blog is based on.
To date, I have used the wiki function of SharePoint in 4 different organizations. I would rate only the last one as being successful and being able to deliver the communication value that I seek. I will dispense with defining what a wiki is, how to edit them and other entry-level knowledge needs. This knowledge is very important but is beyond this blog just as defining good documentation is beyond the scope of this blog.
Unfortunately documentation is a waste of time… until the moment you need it and so determined how you will need the documentation and work backwards. Part of working backwards is to recognize that terms like wikis scare most people away. As a result, I prefer the term Desk Reference. It is a hardy and old fashion term that conjures up images of a trusty 3″ binder full of policies and procedures. So, we can now tell the “don’t change nothing!” co-worker that this is a Desk Reference, not one of those fancy-dancy wikis, by Jove!
Key Terms and Structures
A SharePoint wiki library is composed of webpages. But what to name the pages? To start, do not use spaces but use “-” or “_” instead; SharePoint will strip out the spaces and sometimes they give you the dreaded “%20%” error – so better to avoid spaces from the start. Next, set up a naming convention for the types of pages you be using.
Because I have screwed up enough Desk References, I have come up with what I think is a really good standard set of conventions for Desk Reference pages. Generally these pages are broken into the following:
- HOW-TO pages (the subject of this blog)
- DESK-REFERENCE Standards
- INFRA pages (the next blog)
- WISDOM, template and other page types (a future blog)
There are more to a good desk reference than just the pages, but that is still more future blogs (I may be writing for a while).
HOW-TO Pages – Overview
Based on the fictional budget management site, the clients using this site will need to know how to do specific activities. As an aside, Desk Reference pages should be part of a multi-channel strategy to communicate with one’s clients. Myself, I use the ‘HOW-TO’ pages as a reference in emails, as an audio-visual aid in conference calls and meetings and then linked within the actual tools. The format of a ‘HOW-TO’ page is as follows:
- “How-To”-[SUBJECT NAME]: Used to describe how to perform a business process. These pages described to my clients how to do things for specific budget activity.
- For example, let’s say that the budget activity involved:
- Set up a unique activity code
- Providing a narrative for that code
- Providing costs associated with the code
- Allocating the costs across the organization and
- Running a reporting on all of the above
- The possible HOW-To Names could include:
- HOW-TO_BUDGET-CONTEXT: a context page detailing why the budget activity is needed, the authority and any rules of engagement.
- HOW-TO_NEW-CODE: an instruction page of how to create a new code.
- HOW-TO_NARRATIVE, HOW-TO_COST, HOW-TO_ALLOCATE, and HOW-TO_REPORT pages detail specific steps for each of these functions.
HOW-TO Page Standard Format
Consistency is key in writing procedure manuals. The user has to be able to expect a format and then not to be surprised afterwards. To this end, I strive to use the following conventions:
At the top of the wiki page, I like to provide a set of links or bread crumbs such as the following example from fictional budget management site. Some standards used include:
- Home – takes the user to the main desk reference page
- Planning Cycle Overview – Returns the user to the theme area, in this case an overview of the budget planning cycle
- Go to Tool – A bold/italic leap to the relative tool, in this case, a SharePoint list
- <<< Back or Forward >>> – The previous (<<<) or next step (>>>)
- Note the eye-catching graphic and context for the desk-reference-fatigued user
Just the Facts
The body of the HOW-TO page includes a very abbreviated overview of what needs to be done. Ideally this is so an experienced user can get a quick refresher without having to read the full-page.
Suitably detailed instructions are provided to walk the user through the task at hand. More detailed than the Just the Facts section but less detailed than what is found in some of the pages in the Quick Links section
The last section provides additional reading links for those need more information or research. In the following example, links are provided for definition of the fields used in the business case narrative SharePoint list, the ‘INFRA-‘ definition of the header list (see next blog) as well as how to request a new code and the data dictionary entries (a future blog).