Public Appointments by RSS

In the words of Directgov:

A public appointment is an appointment to the board of a public body or to a government committee. Around 18,500 men and women hold a public appointment.

The public bodies involved are quite important, including health trusts, museum boards and regulators, some demanding specialist skills in law or social work, but many requiring general common sense and broad experience. So it’s important that the people who fill these posts are of the right calibre and reflect the diversity of our society.

The Cabinet Office has recently revamped its Public Appointments system, and you can now sign up to sophisticated email alerts about public appointments vacancies you might be interested in. As a publisher of vacancies, the central system also has an excellent API, enabling you to extract data feeds from the vacancy database to republish on your own site. There’s even some RDFa in the output should you wish to use that to mark-up the vacancy descriptions.

I’ve just created and added a dead simple RSS feed for the BIS-related public appointments to our homepage. But anyone can grab the code and set it up to generate their own feed, or indeed re-publish the vacancy data far and wide in any format compliant with its licence, in order to help spread the word about the interesting and varied positions available.

Hurrah for open data and APIs, and above all, hurrah to the Cabinet Office for building one in this case. Thanks chaps.

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.

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.

The Audacity of Growth

If there’s one thing Barack Obama taught us about the power of digital by the manner of his election, it’s that email still counts (and, for that matter, still works when you’re in government). For a while, I’ve been determined to focus more on how we use email as a corporate communication channel, particularly in the context of needing to justify why establishing new websites often isn’t a good idea.

We launched a project at work today that’s hopefully a step in the right direction: a kind of souped-up landing page for our new strategy for supporting economic growth, Going for Growth.

We’re probably not alone in having a few big policy themes which embrace a multitude of announcements, speeches and initiatives. The challenge for digital communications – well, for all communications, I suppose – is bringing these big themes out in ways our audiences can understand, and not losing the wood for the trees. Even on our own small interim site, thematic information is scattered across press releases, speeches and policy pages, making it hard to explain the drivers of policy, the history or the direction it’s going in.

This time, the initial request was for a new ‘portal’ but it quickly became clear that an aggregator would be a better fit for the content, audience and the commissioning team, who would be moving on to other things after delivery. So the page we built is designed to:

1. Collate the content about support for economic growth on our site in a single place, making it more easily accessible to media and stakeholders
2. Curate relevant content from other parts of government, demonstrating the cross-government nature of the policy, and hopefully engaging other government departments with communicating it in partnership with us (more later on that)
3. Explain the vision and origins of a somewhat abstract strategic policy, as well as the progress to date and the future direction in an accessible way
4. Engage audiences using channels which enable us to build up a community around this content

Our corporate site is WordPress-based (for now) but the page template itself is really little more than a shell. What’s interesting is what Wordpress makes possible through its flexible RSS-with-everything approach and knock-yourself-out unrestricted approach to templating. But the interesting stuff happens elsewhere.

• The document itself is hosted on Scribd and embedded on a page, offering a pleasant browsing experience without the hassle of building a full HTML version. The PDF is of course downloadable too, for committed readers. There’s a video on YouTube (two in fact), press releases on NDS and the archive film of the livestreamed launch via Number 10’s provider. (And a bit of live tweeting around the launch itself, if you count that).
• We’re making liberal use of Feed2JS to help render an RSS feed as a list, comprising items across our site tagged in WordPress with ‘growth’.
• More interestingly perhaps, we’re using the social bookmarking service Delicious (as pioneered by Puffbox for the Governance of Britain site) to collect relevant announcements elsewhere in government via our corporate Delicious account, again tagged with ‘growth’. The RSS feed of these bookmarks then powers a little list on the page, enabling us to keep this content fresh easily, without needing to manually edit the page each time – it’s just a bookmarking job.
• In order to make better use of GovDelivery, a service we used previously just for powering email alerts to changed pages, we asked the team to set up one of their widgets – copying an idea done elegantly by the Highways Agency. These widgets offer a handy, embeddable version of items from an RSS feed (in our case, Piped-together) of Growth news from BIS and elsewhere, with built-in email subscription to topics from across our site. In principle then, these widgets offer a window into what Government is doing to support growth beyond a single Department and in a format which any Department or stakeholder could pick up and use for minimal effort. For instance, Number 10 kindly picked it up as part of their coverage of the launch:

The site was still put together, in-house (kudos for this project to Jenny, Michael, David and Rhys), fairly rapidly to meet a moving target, and there’s still plenty of work for us to do. The list of email subscriptions offered to you via the widget still needs tidying up; we still haven’t quite provided the killer resource for media that I’d hoped to I think; and though it’s less of a nightmare than an independent microsite to manage, it’s still likely to be headache to migrate across to a new CMS.

But we’ll keep tweaking, and with this low-cost patchwork of tools, hopefully we’ll nudge closer over time towards the goal of a truly engaging, useful and workable channel for policy news.

Minding the shop

In my line of work, keeping track of the threads is half the battle. At work, we have (for now) three corporate sites, a sandbox, a development environment, and more. We have social media channels – some corporately-managed, many managed by external agencies in support of our campaigns – and an active stakeholder and media community who like to talk to us and about us, along with ten busy ministers.

We’re also expected to respond quickly to news stories which break in the media on the issues we cover, as well as be responsive to our colleagues in the Press Office, including helping them to monitor and evaluate the reach of their material online.

So ever since some nice chaps from the Foreign & Commonwealth Office blew me away with an internal dashboard they had developed for this purpose, I’ve been keen to set up something similar. Something which I can have open all day and which lets me see quickly if our sites are up, what’s hot on them right now, who’s sending us traffic, and what we’re putting out there in terms of news releases, tweets and multimedia.

I’ve stolen their idea pretty much wholesale, tweaked it slightly towards social media, and come up with this (click to open a larger version):

1. Site availability: we have Pingdom monitoring set up watching our various domains to measure their uptime, and this box uses its API to tell us what’s up and what’s down. Green is good.

2. Popular content: Google Analytics has a little-known API and the excellent GAPI PHP library to help you access it. In more or less real time, this box lists the top 30 pages on the site today. There’s a lot more to the API, which I might write about another time.

3. Top referers: if there’s a spike in traffic, chances are somebody important has linked to us – this shows a list of the top 20 referers today, again powered by Google Analytics.

4. Search engine keywords: More Google Analytics goodness, this shows the top 20 keywords people entered into Google recently which sent them to our site.

5. Custom Site Search keywords: Slightly squiffy this, as the Great Google haven’t quite sorted out their own technology, but in principle this shows the popular search terms people have used within our own site search (which is powered by a Google Custom Search, covering all our key domains).

6. News Releases we’ve issued: using the RSS feed of our news releases which we retrieve via COI’s News Distribution Service, this lets me keep track of what press releases have gone out recently, to help cross check against popular pages on the site and to help us know when to press the button on digital activity in support of them.

7. Social media output: powered by the RSS feed of our FriendFeed account plus some PHP jiggery-pokery, this is maybe the box I find most useful. At a glance I can see new YouTube videos we’ve posted (in red), Flickr sets (navy), and corporate tweets (gold). The aqua boxes show me what agencies are putting out there as part of our marketing campaigns.

8. Replies and mentions: it’s useful to see what people find re-tweetable and how they respond to tweets from @bisgovuk – this box runs off the RSS feed from a Twitter search.

9. News coverage: Not enough for full social media monitoring of course, but for those reports which do mention the Department by name, this RSS feed from Google News Search provides a helpful list, right next to the news releases which they often refer to.

10. Blog coverage: Often a surprisingly different focus from the mainstream media mentions, this box runs off an RSS feed of Google Blog Search results.

11. Our issues in the news: Believe it or not there’s a world beyond our doors, and this aggregated feed (a bundle of RSS feeds from sections of BBC News online relevant to our policy areas, gathered together and shared out again via Google Reader) helps me keep track of the big stories.

So there you are. I’ve been refining and tweaking it while I road test it over the last few weeks. It’s surprisingly simple (around 500 lines of PHP all told) but helps me get on with more interesting things while keeping half an eye on the shop I’m supposed to be minding. And there’s a hint of geek cool in there too. Whatever gets you through the day, eh?

n.b. This code was developed in my own time, using my own resources and information, and is not Crown Copyright. I’m happy to offer anyone who wants one (including my employer) a royalty-free, non-exclusive licence to use it, bearing in mind it’s early code and I can’t provide much in the way of support – for now, just leave a comment or drop me a line if you’d like a copy.