As part of the upcoming session I am presenting at SharePoint Saturday in Brisbane I have put together short series of 3 article to support what I shall be covering in my presentation.
- The first article presents some fundamental concepts and makes the business case for document format conversions.
- In this article I shall highlight the pros and cons of corporate wikis in Sharepoint and why so many of them fail to deliver the expected outcome.
- In the final article I shall look at some of the SharePoint technologies and 3rd party solutions which might be exploited to convert or render documents to different formats.
The Good the Bad and the Ugly of SharePoint Wikis
In any largish organisation, important (but I guess sometimes boring) stuff is often hidden deep within heavy tomes of policy documents. In search of information, users have to first find the right document and yes I know search can help here but don't get me started on search configuration. The number of SharePoint deployments I have seen where search is deployed just as it come right OOTB beggars belief. Organisations spend thousands on SharePoint licenses and don't do some basic tweaks on the search engine that would enhance the user experience immeasurably and would only take a day or so to implement. I said don't get me started!
Search usually serves up the document and then it's up to the user to find the right page or section and even with a table of contents this task in a 300 pager is still time consuming. The end result is that too often user's just give up or don't even try in the first place.
In an attempt to improve things many organisations have seen the potential of moving key information products on line. Wiki's are the answer, surely. With a wiki we can serve up nice bite size chucks of information and we can make information access sprightly and agile. We can cross link between articles, we can empower users who know their stuff to make regular updates (subject to good governance of course). Hell we can even encourage constructive feedback and reward both authors and commentators alike.
And we don't need to stop at the boring corporate policy stuff either! Let's use wikis to transform tacit knowledge into explicit knowledge, you know the kind of stuff:
"Well the manual says do it this way but my experience has been that if you do, you'll cross thread the flange bolt widget thingy and so for me this works…"
Imagine the power of that, your own little stack overflow!
Wiki's, what's not to like?
Not so fast. Some of the things that make wiki's so powerful can also be a double edged sword. What if the method to avoid cross threading the flange bolt thingy is actually very dangerous? And what if someone ends up getting hurt because they followed that piece of tacit knowledge which has now been made explicit? Who's to blame?
So there is a balance to be struck and once again that comes down to good governance.
Even if we are risk averse and switch off decentralised and un-moderated feedback then there are still a few things that wiki's don't do so well. For instance, wouldn't it be cool if they could self-cross-reference i.e. scan the content and stitch stuff together with hyperlinks. Yes, I know some products do this but Sharepoint doesn't, at least not OOTB.
And I wouldn't mind a self-generating TOC, you know like what you get with Wikipedia. And wiki syntax, that's another thing to learn and … drone on, drone on.
So wikis are not perfect but surely they are better than the alternative of wading through 300 page documents. I would say yes except that wikis are flat and tend to want to be contextually free standing. Whereas documents (in the traditional sense) are not flat, they are very structured and hierarchical. They consists of sections and paragraphs and sub-paragraphs etc. and all if this means that the information is presented is within a context and this context is usually missing when the same information is presented in a flat article.
Actually, what many organisations actually want is not a wiki at all but rather a wiki/document hybrid which might come under the header of Structured Authoring. That's a blog article in its own right which I shall leave for another day.
Ok, the reason that most organisations who come up with the idea to wiki-ise their corporate documents fail is because the end user experience is poor. I think SharePoint is the most wonderful collaboration platform in the world but as a wiki authoring platform it sucks. There, I've said it, and with that bang goes any prospect of future employment offers from Redmond!
What makes it suck? Well too often content authors have to resort to editing HTML because the layout is screwed or something went wrong when they pasted in a reference or some such. And when you want to insert images you can't copy and paste, oh no. First you have to upload the image file somewhere and then grab the URL and then resize the image and hope that it looks ok.
This would not be so bad if content authors only ever had this way of producing stuff but in reality they have been spoilt with the Word. For years they have honed skills known only to professional Word-smiths and now we are saying to these people:
"Wait, that great stuff you've been doing in Word for the past 20 years, for the good of the company we now what you ditch these life skills and produce stuff using this crappy little text editor thing on a web page"
I think we should get real and recognise that this is a battle you will never win.
I'm sure that there will be people out there saying that if that's what the organisation needs then content authors should just get with the programme. The problem is that they just won't get with the programme. No amount of persuasion, cajoling or even threats will work. They will just delay, swerve and dodge knowing that this is a war of attrition and they just have to hang in there until you see the error of your ways.
And do you know what, they're right. Content authorship should be an efficient, creative and even a pleasurable exercise. When you are constantly constrained by the technology then creativity is sapped and the once pleasant task is replaced with dread. Hardly a positive outcome then.
So what's the answer?
Well, I don't know if it's the answer but I can provide an answer. My answer is a simple one. Don't make it the problem of the content authors, instead make it a technology problem. Find a way to let authors continue to use the tools they love (Word for the most part) and have technology take on the job of transforming their labours into a format that is better suited for information consumers such as a wiki article.
I came to this shocking realisation a couple of years ago when trying to wiki-ise a set of best practice guides for a large mining and exploration company. The project failed because of user uptake or rather because of the lack of it. Everyone agreed that this was the right thing to do but when it came to actually doing it, well nobody actually did it!
Once the penny had dropped and I realised that I was approaching the problem from entirely the wrong angle then things started to fall into place. What was needed was a way to take Word documents and automatically convert them to SharePoint wiki pages. Surely someone must have a solution for that. Well actually there weren't many solutions to be found and so I ended up building my own called Word to Wiki which is part of the Kaboodle Renditions suite and is my company's best-selling product.
If you read the first article in this series you will have heard me go on about Above, Below and Beyond the line and how that I believe that thinking of information as being separate from the deliver channel is a sound approach so long as it is backed up with good governance and good technology.
In the final part of this 3-part series I'll take a look at the technology which can be used to support this idea.