Intranet CMS compare and contrast

I’ve been reminiscing over my time working on the Justice intranet and it got me thinking about the differences between the hoops and obstacles that I used to have to put up with compared to some of the standard issue features of using WordPress as a CMS today.

It’s been with great joy that I have witnessed government departments and other bodies choosing WordPress as the CMS for their websites and intranets. I am filled with glee when they pick a supplier from the Government Cloudstore for their hosting. Why? Because I spent years working on an intranet in a very restrictive framework, backed by very expensive IT contracts. My older blog posts are filled with gripes about not being able to use PHP or a database, and tales of 60K quotes from IT suppliers to flick a switch on our Google Search Appliance to allow it talk to another internal database.

Happily, I’m in a different world now, where people have more sense than money. This blog post is not a plug for WordPress, but rather a stroll down Memory Lane with a *compare and contrast* of how things used to (still do?) work at MoJ using a combination of manual Dreamweaver publishing and RedDot CMS, with the intranets that I am developing now. Aside from the main benefits of an open source CMS, here are some of the time-saving, money-saving differences that stick out for me…

New stories

BEFORE: We managed our news stories separately from the *static* intranet page content, in a clunky Red Dot CMS, which, like most things back then, pushed the developers to their limits in terms of dealing with the limited technology. We managed to build a system to allow editors to add news stories with featured images, thumbnails and galleries, featured on the homepage, with monthly archives.

We’d often source photos from press office shots from a flip camera or from various campaign graphics that had been developed in-house. Intranet editors would then have to prepare photos and images using a graphics package (Fireworks, which I still love), creating different sizes for use across the intranet as a feature photo or thumbnail, and getting the file format correct and the exact dimensions as required for each of the different image placements. The intranet was designed before *responsive* and *mobile first* were around, and also for a pretty standard desktop viewport across the organisation.

But it took effort and time to add an image and to create the page and make sure it was listed in the monthly archive. News stories with galleries of photos soon became few and far between because the effort required to resize and crop images for, let’s say, a 12 photo gallery, and upload them and attach them to a news story, would be considerable. And with less and less staff dedicated to do the job, the functionality that we spent days developing, didn’t get used.

Publishers had to rely on developers to manually update the monthly calendar listings at the change of every month, and year.

And I never managed to get images to appear in search results.

AFTER: Title. Body copy. Featured image. Publish.

Working with images in WordPress is a doddle. In its simplest form, you just drag and drop from your local copy to the media library. Images are automatically resized for use across the intranet. You can crop, resize and rotate images directly within WordPress so there is no need for the expense of graphic packages, not to mention the appalling process of actually getting a bit of software installed on your PC. Bulk uploads are easy. As are creating a gallery or a carousel. It takes minutes. Thumbnail images appear wherever the page is listed across the site.

Archive listings come as standard. As do images in search results 🙂

Broken link checker

BEFORE: The only way to do a comprehensive check for broken links was to run a manual scan of the whole local copy of the intranet in Dreamweaver. To do an absolute complete scan you’d have to download all the news stories (managed in a separate Red Dot CMS) locally too. And there could be 3 new news stories a day? The scan took hours on the super-fast laptops. As an alternative to this, we relied on reports that I had configured in Google Analytics to capture broken links, reporting the previous day.

AFTER: We use the Broken Links Checker plugin that runs behind the scenes and sends email alerts to individual publishers with details of their problem page. There’s no overhead in time wasted by the central team doing manual scans. The link checker also checks external links, so when you have to publish a link to the Cabinet Office website, which inevitably changes 10 minutes later, staff will see a greyed out link with a line through it until editors can get the *final final* link to the document with yet another version number.

Working with other editors

BEFORE: If you happened to be working on the same page as someone else, then it was pot luck who saved and overwrote the file. I myself was guilty of completely trashing a morning of developer’s work – sorry Matt! We did try to implement Dreamweaver file-locking for individual publishers, but it was such a palaver that we turned it off and I guess to this day, if you try to edit letter A of the A to Z, it will still be locked by Geoff.

AFTER:

We have fancy locking for all editors so that two people can’t both work on the same page at the same time. And you can take control of a page if it’s still locked by someone who left the organisation. There is a revision history so you can go back in time to compare or restore previous versions. And if you delete a page, you don’t have to submit a request for change to restore from a backup and then wait; you restore from the trash.

Forms, surveys, polls

BEFORE: Adding a poll to the intranet was a major event. Someone had to code it up in confirmit, an external web survey service, and a developer would have to embed the poll into the news page. And then it had to be taken off again when voting was over.

Surveys always linked off to the external survey website and had to be created by the evaluation guy and only if we had enough credits available.

As far as online intranet forms go.. No PHP + No database = No online forms

AFTER: We use the GravityForms plugin for intranets that require forms. Editors can create their own forms using a simple visual interface, and add them to intranet pages. Or their own surveys or polls, for that matter. This is a premium plugin that we include as part of client projects, but would be covered by a GPC (government procurement card) purchase if you want to download your own. The plugin emails responses to a specified email recipient and also stores them in WordPress.

Workflow

BEFORE: I mentioned that we didn’t have file-locking on static content pages and there was certainly no workflow for static pages. But we did have workflow for the Red Dot news stories that required some editors to have their work approved before being published.

AFTER: Workflow isn’t a standard feature in WordPress, but we have used plugins for some of our clients to allow pages to be reviewed and approved before being published. To be honest, digital teams seem to be so small these days that CMS workflow is not something that we get asked for a lot. But for larger teams, or teams who need sign-off before publication, and especially for untrained, devolved intranet publishers, it’s a requirement.

Staff profiles

BEFORE: I don’t think we ever had a staff directory that was adequate. Staff always used to resort to looking up a phone number in their local Outlook email client. The online directory was never up to date. I don’t know what the official figures are, but I clocked at least a 6% staff turnover from our Google Analytics reports. That’s a lot of people to add and delete from the database, regularly. I think at most, at one point, we had 1 person responsible for this task. And then it fell into disrepair.

In fact, I don’t think I’ve ever worked on an intranet with a useful, functioning staff directory. I’ve seen them. I remember being wowed by Cheryl Lesser’s tour of the Thomson Reuters colleague finder a few years back. And it is my dream to create one for an intranet and to start playing around with social features.

AFTER: With the uptake of the GovIntranet WordPress theme it looks like I finally have the chance to work on a staff directory. With PHP and a database *raspberry*

It’s an intranet feature that is very close to my heart and one that I look forward to knuckling down with. Hmm, a GOV.UK-style people finder…

3 replies on “Intranet CMS compare and contrast”

YES! *high-fives Luke*

I read paragraph the introduction of this and then sat back in my chair with my arms in the air and shouted “YES!”

Paragraph two of this sums up exactly how I felt about corporate IT before I left it to work freelance. I’m really glad that the Government is embracing this way. I’ve seen so much business money wasted on licensing that could have been spent on development and people and R&D and doing anything-other-than-stuffing-the-pockets-of-big-shareholder-owned-software-companies.

Totally with you!

I’m really interested in how you’re trying to use WordPress here. I don’t think it works great as a CMS for an Intranet. But then, nothing I’ve some across seems to (OpenAtrium kinda comes closest but is a pain to set up).

Glad I found your blog today. Will follow with interest.

*High Five* and thanks! We’re getting good feedback from our clients, especially the editors and publishers who are finding it easy and productive to use WordPress as a CMS. One even described it as “completely yummy!”

This is excellent. I am baffled by the constant rebukes for platforms like wordpress (not secure, open source = rubbish, bla bla) what on earth is rubbish about a community of people around the world that can fix a bug before the big boys have even got round to issuing their contract?
🙂

Well done!