Why I’m going dark for purdah

When the General Election is called, and government enters the pre-election phase known as purdah, I’m going to suspend my personal blogging and tweeting at least until the results are announced.

Why? In a word, it’s too risky.

This will be the first election with really active social media. Last time around, Whitehall Webby (2007) was still a glint in the virtual eye, along with Facebook (2006) and Twitter (2007). Even Guido had been going less than a year (Sept 2004) only just outdone by Tom Watson – one of Parliament’s earliest blogging MPs (2003).

Now, things are different. The political blogosphere is enormous, connected and credible. Mainstream media figures blog and tweet alongside their primary channels, and use those new sources for stories and feedback. And like millions of others, including hundreds if not thousands of British civil servants and a number of old university friends now running for Parliament, I’m blogging and blathering in a variety of other social media.

Mainstream journalists covering my Department’s issues, politicians of all parties and party workers are amongst the 1,200 people who follow me on Twitter (along with a sprinkling of some exotic young ladies from Las Vegas who seem really keen to meet me). And I simply don’t know who’s reading this, which is generally where much of the fun comes in.

But elections (and, I’ve learned, reshuffles) are different: the rules on civil service behaviour are stricter, the scrutiny is much more intense, and the knives are sharper. Frankly, in a climate of pressure on civil service headcount, it would be unwise to stray too far from the pinstriped fold during this particular period at least.

It’s likely the Cabinet Office will be issuing updated guidance this year to help people in my position to stay on the right side of the rules, so watch that space. But personally and pragmatically, I’m not sure any rules will be enough to keep individuals truly safe given the nature and norms of media coverage of bloggers and tweeters currently. Pretty much any personal comment on a public service, a media figure or government initiative or public reply to a politician or even a colleague is going to be susceptible to selective reporting out of context or misattribution as an official or professional view. Sad but, I think, true. Safer simply to go mute.

For me, it should be an enjoyable break. I suspect there’ll be plenty of work to do on the other side

Be Brave

Photo credit: Sharon O’Dea

Well, that’s another UK Gov Web Barcamp wrapped up, and #ukgc10 was a corker, not least thanks to the sterling efforts of Dave Briggs to organise the thing, and the generosity of Google in hosting us.

It still impresses me that 120-odd people from all over the country would want to give up their Saturday to talk about government, technology, data and engagement. But it seems we still do.

A little local difficulty meant I missed the morning sessions, unfortunately, but still had a great time in my former colleague Kim’s session on social media for internal communications, Stefan Czerniawski’s session on improving transactional services online,  and Simon Dickson’s obligatory salon on WordPress (lots of practical questions and note-taking; we’ve clearly moved on from when WordPress was a just a wow new technology).

I jointly did a session with Anthony Zacharzewski and Paul Clarke on persuading politicians and bureaucrats of the value of digital engagement in a climate of cuts. I loved Anthony’s take on the language issues at stake, and his segmentation of the evidence which persuades political and administrative masters, which was bang on the money. My own slides are here:

In a nutshell, I suggested three approaches to making the case:

• Making digital engagement just part of the process of policymaking, not a special set of ‘innovative’ tools to be piloted
• Explaining the changing digital world and the digital engagement activity we do in terms of the real-world impact it has on our own people, our stakeholders, our customers and our costs (a tough one for policy-led environments)
• Pointing to the good company we’re in, not just the wide range of public sector examples of the use of these tools, but also the private sector application of them for customer service and business development

My bottom line was: this is a time to be brave, and argue the case for digital engagement in government as a driver of more efficient and effective policymaking and ministerial engagement – as well as a more cost effective route to service delivery.

Adding RDFa to a consultation

Recently, I’ve been involved in a project to ensure our consultations support RDFa markup, to make them indexable and reusable by third parties, including Directgov. Without duplicating the quite accessible and useful COI guidance, I thought I’d summarise here the process involved from the perspective of implementing the standard with minimal prior knowledge of the whys and wherefores.

Why bother?

As of Jan 1st 2010, it’s now a mandatory requirement for government sites. But more importantly than that, it’s a Jolly Good Idea to provide a low-maintenance way of enabling other systems and services to grab a list of consultations from your site, and identify the important metadata about them, including the closing date and how to respond. Short term, it will make services like TellThemWhatYouThink and Directgov more useful, but in terms of the bigger picture, it will expose the opportunity to get involved with policymaking to a wider audience, and reduce the hassle for those who are already part of our regular stakeholder group (by making possible new services such as auto email alerts, RSS feeds, cross-government updates and so on).

What’s involved?

RDFa offers a simple way to add meaningful information to existing web pages, which can be extracted easily by software (as opposed to hit-and-miss ’scraping’ of regular web pages). As a lay person, I’d say there are three key principles which I can articulate:

1. Be unobtrusive and minimalistic: taking this approach lets you add extra items to pages which aren’t seen by regular browsing visitors, but which are accessible to software robots looking for them. It’s also not ‘an extra thing’ to maintain and serve like an RSS feed, so reduces risk, in theory.
2. Offer clean data: through being consistent in how data about the consultation is described, the idea is that RDFa helps to extract very clean information about the consultation – for example, an unambiguous closing date, a response email address, an exact postcode, all in formats which can then be used in other ways (plotted on a map, listed on a calendar, turned into a mailform on a website etc)
3. Extend existing conventions: the most complicated aspect of implementing this particular specification is that the authors have gone out of their way to find existing wheels rather than reinvent their own. So they use Dublin Core metadata to describe authors and organisations; vCard to describe response contact information; plus nods to DBPedia and FOAF (Friend Of A Friend) to support these major semantic web initiatives. Only for the  gaps where specific consultation information needs to be marked up is there a new standard introduced, using the namespace (prefix) argot.

In a nutshell, the process involves tweaking the template for your consultation pages, adding extra metadata elements and attributes. This is only as easy or hard as your CMS makes it. It’s important that it’s right though – even a few ‘broken bits’ could render the page useless to a software robot trying to extract data from it.

How to do it

Read the COI guidance (and give it to your developer), which is the most comprehensive guide, with useful illustrated examples. There’s also a worked up HTML page showing how this works, and of course you’re welcome to look at ours (which I *think* are right, based on feedback from the gurus).

As an example (but again, you should read the official guidance) I found I needed to work through the following:

• ensure we have a single page per per consultation
• amend the DOCTYPE, if you’re using something like the standard XHTML strict/transitional version. Needs to tell requesters of the page that it contains RDFa
• add some attributes to the <html> element, highlighting the namespaces (vocabularies) you’re referencing in the document
• add Dublin Core metadata elements/attributes to your page <head> element if they’re not there already
• ensure we have a wrapper <div> around the consultation information which again references the namespaces (vocabularies) you’re using. This also identifies the name of the organisation publishing the document
• add some Dublin Core metadata attributes as <spans> within this <div> identifying this as a consultation
• add some Dublin Core attributes to key bits of the HTML, such as the consultation title, start date, closing date and description, marking these as such – and in the case of dates, ensuring there’s a machine-readable data format value in the attribute. Also add a unique identifier – a reference number – to each consultation (not something we’d done routinely before)
• ensure the contact details for responses is carefully structured using vCard format, with separate ‘Full Name’, ‘Street Address’, ‘Locality’ and ‘Post Code’ elements, suitably marked-up with attributes. Since vCard doesn’t cover the specific case of a consultation with an email reply address, for example, these elements are marked up with the new argot: namespace attributes
• add Dublin Core-based attributes describing the file attachments – the consultation document itself, and any related ones such as appendices or Impact Assessments

UPDATE: in retrospect, it was foolish to attempt a blog post about code without some code examples. I’ve tried and failed to find a half-decent code syntax highlighter plugin for WordPress, but the following couple of screenshots hopefully illustrate the before and after situations for the contact information part of a consultation:

Before, plain HTML:

After, with RDFa added (and marked up more semantically as a list item within the consultation metadata)

What help is available?

I worked from the examples given in the COI guidance and the pioneers in this at the Ministry of Justice. The COI Digigov team are your allies in helping to implement this, and should be able to answer queries and/or direct you to sources of further implementation advice and support.

In terms of online tools, you can see whether your RDFa is visible to suitably-equipped applications using Mark Birbeck’s tool or bookmarklet, if you prefer (and he should know; he invented RDFa).

Good luck!

P.S. If you Know About This Stuff and feel I’m giving duff advice here, please drop me a line in the comments or via the contact form and I’ll correct. Thanks.

Unleashing a Government response

A quick one – today at work we’re launching ‘Unleashing Aspiration’: the Government’s response to the review of access to the professions, which was led by Rt Hon Alan Milburn MP and reported last year.

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.

Should you learn to code?

I was never a born project manager. I didn’t have the organisational skills, the discipline or indeed a sufficient dislike of my colleagues to want to inflict upon them the highlight reports, gantt charts and benefits realisation plans needed for Proper Projects. But in my fairly brief stint as formal Project Manager, I did have one knack, and that was getting on quite well with developers. I can only think that the reason for this was that I can relate to the work they do, have an idea of what is easy and what is hard, and respect the elegance of the craft – because I dabble in code myself.

My ears pricked up when Alistair pointed me to Mercedes Bunz of The Guardian asking: ‘Will journalists of the future need to know how to code?’:

Up until now, as a journalist you worked with information, researching facts and figures which then you passed on to the reader. However, in a digital world there are more platforms you can use to convey that information – think of maps or mobile applications, augmented reality. And to be able to do that you will have know how to code.

I think it’s an interesting thesis, even if the scenario of journalists learning Python to develop their own Google-esque apps is pretty hardcore. But I don’t think it just applies to journalists – almost regardless of your role, I think it’s worth learning a bit of code, especially if your academic training has been in hand-wavy social sciences like me.

1. It helps you think about how everyday processes work: there’s nothing like building your own applications to make you think  logically about how people behave online, and the hidden sophistication of seemingly simple systems like cash machines or website subscription services.
2. It’s good for your attention to detail and organisational skills: you can be sloppy about how you capitalise words or use punctuation in the real world, but the world of code makes you a more organised, consistent person (n.b. those who know me will laugh at this hubris)
3. It gives you an insight into why websites work the way they do, and why they break: as a webbie or even just a web user, coding for yourself helps you understand the anatomy of websites, the technologies which come together to deliver them, and gives you some explanations for why they’re ‘being a bit funny today’.
4. It lets you translate ideas into prototypes: talk is cheap, but if you can turn it into a prototype, you’re already a step ahead – and you can refine your thinking as you build it and get feedback on something tangible, rather than just a brainwave.
5. It opens up a new world of lifehacks you can build for yourself: whether it’s a way to backup your Twitter account or a to-do list application that actually reflects how you work, being able to write bits of code to save yourself time is neat.
6. It’s a social* thing: fifteen years ago, I was getting little applications on computer magazine cover disks, and receiving letters back from all over the world via the school register. Now, when I release code I get feedback instantly, along with help, suggestions and improvements, and feel part of something energetic and positive. (n.b. I say ’social’, but not necessarily family friendly. I’m still squaring that circle
7. It’s creative and relaxing: I don’t actually get paid to code, so for me there’s something relaxing and challenging in sitting down of an evening to make a new tool or improve something.
8. It’s good for the career: maybe a bit obvious, but even a small amount of coding capability (real; not just puffed-up for CV purposes) helps you do your job, and get noticed for doing it, generally without antagonising your colleagues. Frankly, bosses like clever bits of digital innovation: it’s worked for me in pretty much every job I’ve ever had, particularly the non-digital ones.

It’s worth putting two caveats on that list of benefits:

1. Know your limits: the old cliche ‘a little knowledge is a dangerous thing’ is a double-edged sword when it comes to coding. If you believe it, then you’ll never start learning anything. But if you ignore it, you’ll find yourself in dangerous territory (exposed to hackers, losing friends’ data, costing yourself money etc). Strike a balance between the courage to learn, and the humility to ask for help or say you don’t know.
2. It’s a long way to the summit: ‘coding’ as I’m describing it here is a shorthand for knowledge of a whole range of technologies – all of which are changing over time – which you’ll find you want to develop at least some familiarity with. Of course, you can do some things with just a little practice and knowledge, but unless you focus very narrowly, I don’t think you ever reach a plateau of knowledge – there’s always an infinite amount more to know and potentially keep up with. You’ll be learning forever.

I hear the other side of it, of course: do what you’re good at, and leave the heavy lifting to the professionals, like you would car maintenance or central heating. I think that view gets too much unthinking acceptance, for the reasons above and more. Be proud to be a jack-of-all-trades, master-of-none, I say.