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…
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.
And I never managed to get images to appear in search results.
AFTER: Title. Body copy. Featured image. Publish.
Broken link checker
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
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
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.
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.
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…