A Case for Movable Type as your Intranet

By Deane Barker on March 30, 2008

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.

Comments (3)

James Robertson says:

I’m all for keeping intranet technology simple, but I think this misses the point.

I’ve identified four fundamental purposes for an intranet:

  • content

  • communication

  • collaboration

  • activity

I would see a lightweight publishing solution such as Movable Type as being a pretty good fit for the communication component, but perhaps not the rest.

The content aspect needs to be supported by decentralised authoring, and MT just doesn’t do this in a scalable way.

The collaboration aspect pretty much always needs to be supported by additional software, whether it’s wikis or SharePoint.

The activity aspect is the big gap, as it is for most intranets. If the intranet is just a “place for reading stuff”, it won’t succeed. Instead, it also needs to be a “place for doing stuff”, and this obviously isn’t MT.

In summary, we need to take a broader view of intranets, if they are to be valuable and used. This doesn’t necessarily mean more complex (or more expensive!) software, but it does mean we need to be careful about not getting trapped in one particular box.

PS. you can read an earlier article describing was then the “three purposes of an intranet” here:


Cheers, James

Deane says:

James, I’m going to argue a couple points –

This scenario is targeted at the myriad companies that have nothing at all to work with – maybe I should have been more clear about that.

While I agree with your idea of the intranet being a place to “do stuff,” there are countless organizations that can’t even manage a list of announcements. These organizations lose sight of their most basic need (communication), bite off more than they can chew when planning and building something, and never get back to the first thing they needed out of an intranet in the first place.

Additionally, the concept of “doing stuff” is often not at all connected to a CMS anyway. When was the last time you changed your investment plan allocations within the bounds of a CMS? The tons of little mini-apps that exist on the average intranet are often custom-coded, so they exist apart from the CMS anyway.

We’re getting into a larger question here of just what an intranet consists of. Is it a single thing that is served by your CMS? Or is it a broad survey of resources within the bounds of your companies network? I pick the latter, which means that any CMS is only part of any intranet solution – one cog in a much larger machine.

From this perspective, you’re right – Movable Type would just handle one piece of the puzzle. But it’s an important piece. It’s usually the first thing people think of when they think “intranet,” it’s invariably the biggest bang for the buck that provides the most benefit for the least investment, and will often end up being the springboard on which they build the “activity” intranet you speak of.

Ian Stalvies says:

I think MT can still be useful as part of the puzzle for large companies, reason being it’s LIGHTWEIGHT. Quite a few places I’ve seen combine a massive, cumbersome CMS with an obsessively centralised intranet policy – often meaning a hideous publishing process through different environments and layers of bureaucracy. Apps like SP can of course get around this with the right policy, but too often the dedication just isn’t there (ie, they throw Sharepoint up “as is” leading to massive link lists ...)

“Collaboration” is an interesting topic, internally this seems to be a buzzword mirroring “Web 2.0” in the outside world ... dazzling technology, but what is it REALLY used for? Great potential users are stuff like voting systems on ideas, or SP connecting project elements (tasks, calendars etc ...) to the user’s everyday tools. But again, sometimes this stuff is just thrown up there with the idea that staff will just ... em ... “collaborate” via blogs and wikis, without a purpose. Cheers :o)