---
title: "Exploring Web 2.0 Possibilities in a SharePoint-Endorsed Environment"
date: 2008-05-28
description: "$( document ).ready(function() { // Handler for .ready() called. $("
canonical_url: https://idratherbewriting.com/2008/05/28/exploring-web-20-possibilities-in-a-sharepoint-endorsed-environment/
---
# Exploring Web 2.0 Possibilities in a SharePoint-Endorsed Environment
For a long time, I've wanted to take my documentation into web 2.0 territory and enable user interaction and feedback, but I've been hampered by tools. Around some people, just saying the word "tool" brings up immediate negative responses. For example, when I [interviewed Scott Abel about social networks](https://idratherbewriting.com/2008/04/12/podcast-social-networking-and-the-value-of-user-communities-for-technical-communicators/) and asked him about Ning, he didn't want to discuss Ning because for him — and many others — tools are merely a selection of wrenches in a hardware store aisle. You figure out what you need first, and then you pick your tool.

I don't think anyone who is eager to implement web 2.0 interactivity into their documentation can be so indifferent with tools. This is because there are no good web 2.0 tools for documentation. Right now everything's a hack. You have to cobble together a solution from various things and try to make it work. 

The question of tools plays an even larger part for writers who are subject to IT policies about what they can and can't install. Even if you have free reign to use whatever authoring tool you want on your computer, many web 2.0 tools are database driven and require server components. Many infrastructure departments are particular about what you can and can't install on their servers, assuming they give you space to install anything at all.

Last month I was dealing with these tool obstacles when a guy at a WordPress blogger dinner suggested that I work with the tools and platforms already endorsed by my company. Seems obvious, I know, but when you're a WordPress devotee, considering any other tool for blogging seems blasphemous.

At my organization, the closest Web 2.0 tool we have is SharePoint 2007, or MOSS 2007, to be more accurate. Although SharePoint has a bad rap, the latest version is actually quite innovative, and includes blog, wiki, and RSS functionality. That said, the complexity of SharePoint's code makes it a hard beast to tame.

I'm still in the process of testing my prototype, but I've learned a few things about SharePoint that may be useful to others.

### With SharePoint, Blogs Make More Sense Than Wikis

The blog and wiki features in SharePoint are extremely close cousins. The source code for both a wiki page and a blog post function the same, so you can easily move your content from one format to another by copying the source code of a wiki page into the source code of a blog post. The source code consists of a lot of DIV tags referencing external styles with unrecognizable classes. And everything is unavoidably structured with inline styles.

SharePoint wikis and blogs do have some differences:

- The wiki automatically keeps revision history and shows incoming links.

- Any columns you add to your wiki appear exposed to the reader's view.

- Wikis lack a master wiki template that you can modify to change all wiki pages.

- The blog displays the writer's name and timestamp below the post and offers a permalink.

- The blog allows you to aggregate the posts in categories, and then see the latest posts in that category.

- The blog provides a comment field below the post, and includes a view that shows all comments.

- The blog allows you to attach a workflow to the comments field.

- Wiki pages are individual aspx pages, whereas blog posts are contained in a database somewhere.