Stay current with the latest in tech comm
Keep current with the latest trends in technical communication by subscribing to the I'd Rather Be Writing newsletter. 5,000+ subscribers

Stitcher radio

Search results

Upcoming event:
I'm giving an API documentation workshop in San Francisco, California, on November 19, 2019. Check it out on EventBrite and register today to receive a $100 early bird discount.

SharePoint Wikis: Both Liberating and Frustrating

by Tom Johnson on May 17, 2008 • 0 Comments
categories: technical-writingwikis

Lately I've been converting my documentation over to a SharePoint wiki and have had days where I felt totally liberated and others where I wanted to go into my Control Panel and remove every Microsoft product I have installed on my computer.


Here's what I find liberating. Most wikis can easily degenerate into a chaotic disaster, with links nested on pages pointing to other links on other pages, with no clear sense of where you are or how deep the wiki goes. One writer at Doc Train told me her company's wiki was an "unmitigated disaster."

With SharePoint, you can get around this chaos by adding columns on wiki pages. The columns are similar to metadata fields for the page. You can add a drop-down box requiring the user to select a category for the wiki page, and the role, and any other ways you want to classify the wiki page.

Then you use SharePoint's sorting and grouping functions to create various views for your wiki. These views use the columns/metadata fields to sort your pages by category, by role, or other methods. This is liberating because it allows you to impose order on what might otherwise become chaotic.


Unfortunately, the columns/metadata fields appear to each reader who views the wiki page. They aren't hidden behind the scenes, only visible when you edit the page. I tried modifying the stylesheet to add "display:none" for what I presumed was the style for the column fields, but this ends up making the wiki page disappear when editing the content.

It's also quite difficult to pinpoint the styles in a SharePoint wiki because many elements are nested in about 17,000 tables and have a class applied at the end. I've stopped trying to fight this monster. It has consumed me for the past two days without a solution.

Another problem is that while you can classify wiki pages into categories and then group the content by these categories, you can't actually change how the categories are arranged. They're sorted alphabetically -- that's it. So although I wanted to have my "Introduction" category at the top, I now have to resort to either numerical prefaces ("1. Introduction") or change the title to something like "A Basic Introduction."

I could expand on plenty of other frustrations here (such as no discussion page or comments field on wiki pages, no export ability, bloated and obtuse wiki code, no info on wikis in the help), but I'll save those for another day. I am still convinced that, as Lawrence Liu states, despite SharePoint's limitations with wikis, overall the SharePoint 2007 platform provides a mix of integrated collaborative tools that together are superior to one standalone best-of-breed product.

Liu writes:

As I stated quick emphatically during my "SharePoint Collaboration and Community Tools" session at the European SharePoint Conference last Tuesday, the wiki functionality in WSS 3.0 was not designed to compete directly with best-of-breed wiki products like SocialText, but rather, it's the integration of a plethora of collaboration and community features that make WSS 3.0 and MOSS 2007 best of breed as a whole.

I'm not just stopping at the wiki. I plan to also add a blog, feature request page, bug submission feature, and other interactive tools to solicit information from users.

follow us in feedly