The digital brief was, on the face of it, not massively exciting – it’s a long document, covering 88 recommendations, with a small but informed audience of policy, media and stakeholder visitors – many of whom will go through the whole document in detail almost however we publish it.

But this kind of document does set an interesting challenge for online presentation – it’s really as close as policy documents get to a faceted classification in information design terms, with responses to each recommendation organised by theme, by audience affected, and by the Departments who are leading on each – and with lots of embedded links to other initiatives. The policy team, though tight on resource, are interested in following the comment and discussion around each of the recommendations.

So it’s also a natural fit for WordPress, where the Themes are defined as WordPress categories, and we use WordPress tags to indicate audience and lead department. Commenting is built-in, as is the facility for tag and category descriptions, which provide a space for useful ‘virtual chapter’ overviews. By offering the ability to cut the document up in so many ways, it provides a variety of accessible entry points for different audiences, which is promising raw material for digital engagement outreach, for example to student communities or the third sector.

It’s not going to win any design awards – it’s intentionally quite neutral and clean with just some simple colour-coding – but I think it’s an unusual and potentially helpful approach to enable readers to get into a document of this kind through different routes. It’s also been a good training exercise for the team – props to Alistair Reid for getting his head around the anatomy of WordPress in barely a week, and doing rather more cut-and-paste than is strictly healthy.

Related posts on this blog

5 comments on “Unleashing a Government response”

It kinda goes without saying… but that’s a nice job you lot have done there. If that’s Alastair’s first crack at coding a theme – that’s a pretty spectacular start. And don’t worry, we all start with copy-and-paste.

One trick you might also want to throw into the mix is WordPress’s little-known ability to combine tags and queries in URL query strings? For example:

which – guess what! – filters by both category and tag. You’ll need to be quite careful with the syntax of combined queries like that: it only seems to work that way round.

I’m not even sure this is an official feature; it certainly doesn’t fight for attention in the documentation. But it could be very useful in sites with multi-layered taxonomies, such as yours – maybe to power some kind of ajax-y menu system? Tell Alastair to get that into phase 2. 🙂

Thanks Simon – some neat tricks there. One thing I hit my head against a bit was trying to take the same approach to tags that I can categories. For example, showing the number of items tagged with a particular tag on the archive page for that tag. Is that possible? Similarly, we found some oddities like the count of items within a category being inaccurate.

Still, it’s remarkable just how much you can do, and how easily, without needing to write much of your own code…

Yes, it would be nice to have had more comments on that doc – but I don’t regret the effort put into it. It was a valuable training exercise for the team, helping to increase our capacity to develop these kinds of sites on a lower-profile project; it also helped push the boundaries of WordPress slightly and gave us a neutral theme we can reuse easily in the future (in fact, we’re just about to). Sometimes there’s value in refining the process, as well as chasing the outcome.

There is a learning too about what kind of documents work best in this format. Sometimes open-ended consultations don’t work as well as documents with more specific content which people can respond to – but not always. Sometimes documents with a clear and focussed audience work better than those with a broader mix – but not always. I don’t think we (or anyone else) is quite able to predict which kind of documents work best in commentable form online.

And there’s the luck factor. In this case, the announcement had to compete with a busy news day, we had technical gremlins (which we’re fixing), and we didn’t have the capacity to promote it properly on launch day (which we’re also trying to avoid happening again).

Not a rebuke at all – just me being my usual blunt self. It was merely an observation that us tech bods sometimes have a tendency to let what is technically possible get ahead of what the end user is likely to need / want and sometimes this can inadvertently damage the endeavour. I think we have to be constantly mindful that just because we can doesn’t always mean we should.