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.
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.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.