Here’s a fact: intranets don’t have to be crazy-complicated. Intranets are fundamentally about sharing simple information, which is not as hard as some people make it out to be. As simple as this is, most organizations either have no intranet, or a smattering of HTML pages someone threw together with Front Page that no one looks at.
In working with companies on their intranets, I’m confronted by the fact that there are fundamentally two types (genres?) of information:
Permanent and temporal.
Reference and announcement.
Eternal and time-sensitive.
Groomed and discarded.
Wiki-ish and blog-ish.
Pages and posts.
Pages and posts — that brings us back to a couple of posts about the concepts of posts vs. pages:
I’m not going to re-hash those arguments here, but I recommend you go read them, as they really touch on an important point: some pages on an intranet are eternal, and some are temporal.
- An announcement of an upcoming potluck — temporal
- The mission statement — eternal
- Information about a news article involving the company — temporal
- A procedure explaining how to apply for a new ID card — eternal
Now, this is a bold statement, but think that 95% of information on an intranet would fit into these two groups. Something is either an announcement, or it’s a reference page of some kind. Sure, there are other types — a discussion space type, for instance — but a lot of companies could fit almost everything into these two groups.
The most common phrase I hear about companies and their intranets is: “Our intranet is a mess.” The next most common phrase: “We just need a list of announcements somewhere…” So, they need a blog, essentially. And, invariably, they need a smattering of static pages as well.
Going back to that post mentioned above about the Wikipedia coverage of Hurricane Ivan:
With Wikipedia, you’re not seeing a series of posted items. You’re seeing a single body of information, continually updated and groomed. Thus, the basic information stays right where it’s easy to see. Wikis are more “speak to me like I know nothing” information, rather than “tell me the very latest nuance” information.
The ideal is really a combination of both — keep the basic (wiki-ish) information right there, and have a sidebar of the latest (blog-ish) information as it comes in.
So, we need a platform that allows groups to have blog-ish stuff, and wiki-ish stuff. What fits? Three platforms jump to mind:
Yes, I know there are many more, but these are at the lowest end of the scale in terms of complexity and the highest end of the scale in terms of applicability — remember, we’re trying to be simple here.
WordPress is great, and crazy hackable, but it suffers from what I’ve always considered a huge limitation: lack of the ability to have more than one blog. This is something that Movable Type has done from the start, and I’ve always taken it for granted.
One of the most common requirements for a company intranet is that different organizational units have their own “spaces.” Every department needs a sub-site all their own. It strikes me that this would be hard with WordPress, although with all the custom plugins and development, perhaps there’s something I’m missing.
Another problem with WordPress is that it’s bound to PHP. More on this below.
Google Sites is really fantastic. Blend uses Google Apps for Domains, and so we get Google Sites with it. I tried it out and was somewhat blown away by what appears to be an arrow shot directly at Sharepoint. Additionally, it’s built with the concept of multiple sub-sites in mind — they even provide tagging tools to organize sites. Your company could have hundreds and hundreds of Google Sites, and you could search for any sites tagged with “Human Resources,” for instance.
But, we all know Google Sites has perhaps a fatal flaw: you don’t own it. Your stuff is housed on Google’s servers, and this is just out of the question for a lot of companies.
Which brings us to Movable Type, which I think is the real winner here. First, it handles the posts/pages thing well, you can set up multiple blogs and allow individual permissions to each, and then there’s the biggest benefit of all: MT is a data push system — basically a big code generator. It’s written in Perl, but will effectively publish to anything.
A lot of companies are bound to .Net. It’s not their fault, but they’re Windows shops and all their stuff is in .Net. It’s in this environment where I think Movable Type would really shine because it can generate ASP.Net Web forms.
Gadgetopia uses MT to generate PHP files — why couldn’t it generate Web forms? Remember that it would just need to generate the Web form — all of the pages it generated could extend from the same code-behind.
This way, everyone consuming your intranet stays solidly in the world of .Net. All your hard-fought Windows user controls could still be in the pages (using Builderoo or some other tools, you could even get user controls embedded in posts), and you could use all of the other .Net integration goodness that the rest of your company runs on.
And this brings me back to my original point: there is a huge number of organizations out there for which a copy of Movable Type and a well-designed template would be an utterly massive improvement on their ability to share information.
I have built two intranets now using a mid-range CMS — it cost both companies about $40,000 in software alone. Looking back, I’m struck that they’re not doing much more or less than they could do with a copy of Movable Type.
This may sound simplistic, but take your organization and a single installation of Movable Type. Give every department their own blog, in which they can manage posts, pages, and media files (have you seen MT 4 yet? It does supporting files quite well).
Suddenly, every department has a simple announcement list (with RSS, even), and the ability to create whatever reference pages they need. This would solve a huge number of issues for the majority of companies struggling with their intranets.
Sure, there are higher-level functions that MT wouldn’t do well — things like a company directory, or a repository of policies and procedures. But in my experience, this stuff is often done in the main CMS anyway. The company directory is probably better served out of Active Directory, and policies and procedures are becoming more specialized with DITA and Docbook and other methodologies.
And of course, we could sit here all day and make up scenarios that would embarrass our humble little blogging platform, but that still doesn’t help the organization I consulted with two weeks ago. Even after multiple tries, their intranet is such a mess that they’ve given up and just they now post announcements to the bulletin board in the hallway and hope people see them.
Movable Type certainly wouldn’t solve all their problems, but it would solve most of them, and involve less pushpins.
- Read my first book: Web Content Management: Systems, Features, and Best Practices
- Read my second book: Real World Content Modeling: A Field Guide to CMS Features and Architecture
- Subscribe to updates from my next book: The Web Project Guide
- Subscribe to my twice-monthly newsletter about CMS: Squirrel Notes
- Follow me on Twitter, where I announce new posts: @gadgetopia
- Send me an email — I'd love to talk: firstname.lastname@example.org