My Compromise with SharePoint -- What Works and What Doesn't

by Tom Johnson on Jun 23, 2008
categories: technical-writing • web-design

In a previous post, I mentioned my desire to use SharePoint as a help authoring platform because it provides a Web 2.0 experience that is company-sanctioned. SharePoint not only has blogs, wikis, and RSS feeds, but also integrates with Active Directory, Outlook 2007, and has integrated search across all content.

However, the more I tried to use SharePoint as a help authoring tool, the more problems I ran into. SharePoint doesn't handle role-based content very well. For example, if you have administrators and regular users, it's not easy to create two versions of the same help material. SharePoint does have audience targeting, but only if your audience is already tagged with roles in Active Directory (and if active directory is integrated with SharePoint).

Additionally, SharePoint doesn't single source well. For example, if you have to create several role-based guides, you're in for a challenge. You can create views in SharePoint where all content shows, and then copy that content into Word. But then you have to reformat much of it, add cross-references, index entries, a table of contents, headers and footers, sub-lists, and other formatting.

Formatting the content in SharePoint itself is also a kluge. SharePoint's wikis are primitive. They don't allow comments. And if you add metadata to sort the wiki pages into different views, the metadata (columns) appear to the user.

SharePoint's blog posts give you a comments field below the post, but it still looks too blog-like. You lose out on the table of contents navigation pane on the left. You can't quickly navigate through an outline of content. However you try arranging the help topics, it just doesn't look like help. Users are a bit perplexed and don't immediately know how to use the system.

Even more important, though, almost no one comments on help topics. As much as I'd like to web-2.0-ize my help, it's not the same as a personal blog on the web. People at companies simply aren't inclined to comment on help, so going out of my way to add commenting features below each topic is like adding engravings in sidewalk cracks -- sure it may look nice, but no one has a use for it or cares much.

I didn't renounce SharePoint altogether. I'm still using the web space to organize my content and the blog to communicate information to users. So I've made a compromise. First, I customized the SharePoint site to look like a sharp looking website rather than a SharePoint site. The default help URL in my application takes users to a SharePoint landing page, where they can choose their help deliverable -- online help, quick reference guide, user manual, or video. All my help content is hosted on SharePoint, so I can publish and update it whenever I need to.

Finally, I'm still tracking visitors to the help. Because of the integration with Active Directory, I can see the names and departments of everyone who visits the help. And they can subscribe to RSS feeds and email alerts for the blog. (Now if I can just teach them how to pull RSS feeds into Outlook 2007 ... )

I'm not saying SharePoint can't be used as a help authoring tool, but it's more suited to knowledge base situations, where you have hundreds of topics and you're not expected to format them out into any printable guides.

And I'm also not discounting the value of Web 2.0. In some situations, such as promoting an application on the web, more interactive help topics in the form of blogs or wikis might be powerful. But inside the firewall, people often just want to do their jobs.

I returned to Flare for my core help authoring tasks. Let me just say that in doing so, I felt a sigh of relief. Flare provides the feature set for help authoring that I need -- conditional tagging, multiple outputs, modifiable skins, hotspots, advanced styles, etc. Despite its quirks, it works.

The way I see it, I'm taking the best of both worlds and combining them.