Low Value Content is Destroying Your Website? I don't think so.

Is low value content the problem with intranets? I am not sure it is or not. In blog post by Gerry McGovern over at CMSwire, Low Value Content is Destroying Your Website, has some interesting information.

Most data and content that we create is next to useless. Nobody will ever be interested in looking at it again.

He also mentions that the corporate intranet is a dumping ground for company information because companies have no clear standard of where to put this stuff. Well, where does he suggest it go? In my 10 years of developing intranet sites, the reason the data exists is because someone needs it. It may be a loss leader in hits, but there is still a need.

I would rather see a bunch of infrequently used pages exist on the intranet rather than some word doc sitting on someones hard-drive or worse yet, lost forever when an employee is termed.

This seems to me to be one of the best use cases for social networking, specifically the wiki. It gives employees a place to quickly and easily empty their brains and get back on with the task at hand. The other upside, is for you GTD readers, it helps make mind like water!

Disconnected CMS

Today, I launched a new piece of the puzzle in our intranet, a Content Management System. Yes, I know, we are way behind the times... We have been using a home grown CMS for our external website for years now, but the intranet (i.e. the ugly step sister up till last year) has had it's static content authored in Front Page since the inception.

It took so long to get a CMS into the fray due to the huge amount of work it would take to implement a traditional CMS system that includes page templates and the like. So we created a "disconnected CMS."

This system consists of two parts, a ASP.NET administration tool that allows authors to create content and a JavaScript function that uses AJAX to asynchronously request the data to be displayed on the page.

The administration site is secured by content groups or categories. Each author, which we have about 40, will be given one or more content groups for their sites. These groups can contain multiple pieces of content and multiple authors. Authors are restricted to only the content groups they are a member of. Any changes to the content are stored in a SQL server and versioned (with optional comments) so that authors can review and revert back to older content if needed.

The JavaScript function takes in the GUID of the content item and returns back the HTML string that represents the content. The AJAX call is done via the Prototype framework which allows multiple async calls on each page.

This system should greatly reduce the number of times a day I get requests to publish Front Page content and allows authors to update their websites over time to the new system.

I should have some hard data on usage in the next month or so to determine if this solution can really scale like I think it will.