Intranets (The Bane of Corporate IT)

As a developer, I’ve had to personally implement at least one Intranet for a large organisation, and have been privy to the details that have gone into the implementation of several others. It seems that there’s a big batch of common functionality that goes into each and every one of them. It also seems like every company of decent size on the planet has one. So why do most of them suck ass? Well, I don’t have the answer to that question, but I know of at least one or two (massive understatement alert) articles on the web that go into this issue in depth. All I can offer is my own insight.

First off, realize that the individuals you are most likely going to be directly dealing with as a developer are decidedly non-technical (think, Communications Department). Their main goal is usually to provide interesting and relevant content to a large number of users. Remember that part about the content. You’ll most likely receive requests for all kinds of little features, but (as I’ve said before) content is what really matters. If the publishers of content can’t do their jobs efficiently, you’re in trouble. One thing you’ll come to learn, is that it’s quite hard to find or develop a solution that makes publishing and managing simple content entry easy. This is often lost in all the features of “Enterprise” CMS packages. (I’m pointing directly at you, Microsoft CMS).

Secondly, don’t forget about stats. At some point, whether it’s in an initial RFP, or several months down the road after implementation, somebody will ask for stats. Luckily, this one is easy. Every web server keeps a detailed log of every request made to it, so all you have to do is hook up a stats program that will make the information all pretty like. Do yourself a favor, and at least make sure that your web server is actually keeping these logs. That way, you can retrofit a stats package on later, when this feature is actually requested.

Next, think about search. There are actually more than a few CMS packages that don’t include this relatively useful (massive understatement alert) functionality by default. If you find yourself in this sorry situation, have no fear. Just think Lucene. It’s a Java technology (also available in a .NET version) that allows you to quite easily create a customized search solution for your particular situation. You can use it to index files, or you can base it off of an existing object model (like with Microsoft’s CMS). It’s quite easy to use, from a development standpoint, and will most likely provide results that are better than a package you might pay for.

Very importantly, you must realize that most users will write or receive content written in Microsoft Word. This means, that they will expect to be able to cut content from Word, and paste it as is into the CMS interface and just be done with it. This opens up a whole bunch of fun issues, (like what happens to images and charts). It’s hard to balance having this functionality with maintaining a good, consistent look and feel. I don’t have an easy answer to this one, unfortunately. Just be aware of it.

And lastly (at least for now), be wary of situations where the technology is actually chosen for you before you start development, without any input from yourself. This likely means that, sadly, the points I’ve mentioned above were not considered very well. It also means that a salesperson likely already sold a solution to somebody before they fully understood what was needed. This happens a fair amount of the time. Good luck with that.

That’s all I can think of right now, although there’s probably more.