Mike Bracken on GDS structure and the power of precedents

Computer Weekly have posted an interview with Mike Bracken: a fairly chatty (and somewhat predictable) getting-to-know-you piece, but with a few interesting snippets.
He reflects on the problems with the e-petitions relaunch:

For example, with e-petitions, no-one could predict just how fast that demand would go up. Consequently we learnt a lot about scaling and applications within the government estate. We reacted literally within an hour to sort out [the site crashing]. If someone else is doing that for you, you don’t learn. Managing a contract is a distinct skill but actually managing the service is different.

Was it really so unpredictable? Ah well, never mind. There’s also some detail about the structure of the nascent Government Digital Service:

The five areas of GDS will include DirectGov, which will be the most prominent constituent; identity assurance, which will identify people consuming government services; BetaGov, headed up by Tom Loosemore and formerly known as the AlphaGov team building a prototype for a single government website; digital engagement; and the innovation team.

Total headcount within the GDS will be ‘up to 200’, but the budget across those five areas has ‘yet to be finalised’. (Incidentally: it was confirmed in a PQ issued today that the GDS budget for 2011-12 would be £22.3 million.)
Mike also makes a point about the need to set precedents, a point I’ve made here numerous times in the past:

Launching successful products and pointing at them as examples of what can be done will be key. One can do lots of formal learning, but the simple way to build that culture of expertise is take people on a journey with you, which also means failing and learning on the way.

I’ve learned from my own experience that this is really the only way to take organisations with you. Find a modestly-sized but reasonably high-profile project, whose manager buys into the need for change. Make a success of that one, whatever it takes; then sell everything else you’re planning on the back of it.
The argument of ‘well, it was good enough for X’ is pretty primitive; but it works better than anything else I’ve ever tried. I’ve found few teams who really cared about ‘the journey’: most are only really interested in knowing the (approximate) destination, and seeing some evidence that you know the route.

How we could all benefit from Betagov's accessibility work

Accessibility is the subject of the latest post on the Government Digital Service blog: having had their fingers burned in the ‘alphagov’ phase of work, by consciously ignoring the subject, it’s clear they want to be seen to make it a priority into the beta phase.
Léonie Watson writes:

Tom Loosemore has said: “… we want to make the most easy to use, accessible government website there has ever been”. Those of you who know something about web development on this scale will understand what a challenge that is. Those of you who know me will also recognise it’s a goal I thoroughly believe in. So, what are we doing to achieve that goal? Simply put, we’re planning accessibility in from the outset and documenting the accessibility steps we take throughout the website’s lifetime.

I’ve posted a comment on her article, which I’ll reproduce here for the record. You’ll instantly note a common theme with my recent inflammatory post about departmental publishing.

As you’ve noted, accessibility is very hard to get right: you’re conceding that you might not even score a ‘perfect 10’, even though you’re ‘planning [it] in from the outset’. And as [previous commenter] Keith says, for small organisations, it’s prohibitively expensive to even buy the rulebook, before you even begin to implement the rules.
If government is hiring experts, consulting widely with users, and (hopefully) delivering exemplary results, it seems like a tragic waste for the benefits to be locked into a single website.
Wouldn’t it be fantastic if one of the outputs from your work were to be a reusable, customisable front-end theme for an open-source, widely-used publishing platform, like WordPress or Drupal? You could enforce certain ‘must have’ accessibility practices in the page templates, whilst still giving people plenty of scope to make it look and feel like their own site – via a parent/child theme arrangement, or a ‘theme options’ screen.
You could then release that theme publicly – giving web developers everywhere a robust base on which to build their sites. Imagine all those common accessibility headaches being solved, before the first line of custom code is written.
(I’m not suggesting this would solve all problems instantly, of course. And there’s still plenty of scope to cause all sorts of new problems in, say, a child theme’s CSS. But you’d certainly be giving people one heck of a head start.)
The fact is, very few organisations have any real motivation to get accessibility right. But Government has a moral obligation to do so. And you’re spending our taxes to do it… so I’d argue we all have a right to enjoy the fruits of that labour. Central and local government, public and private sector.
Issuing a list of rules seems a very old-fashioned way to encourage / enforce good practice. You have an opportunity here, to do something much smarter than that.

 

Bespoke builds and broader benefits


In which Simon makes the case for the ‘government machine’ (in the diagram above), for government departments to publish fairly basic written information about their work, to be built on something which already exists, instead of being built ‘from the ground up’. If you haven’t already, do read Neil’s piece… then Stephen Hale’s piece about the Department of Health’s new approach… then read on. And do please note the line about ‘Seriously, this isn’t about WordPress.’
It won’t entirely surprise you to learn that, when Neil Williams’s blog post about government web publishing in the world of a Single Domain popped up in my feeds, the first thing I did was press control-F, and search for ‘wordpress’. And hooray, multiple mentions! Well, yes, but.
Some background, for those who need it: Neil is head of digital comms at BIS, currently ‘on loan’ to the Government Digital Service team, to lead the work exploring how government departments fit into the grand Lane Fox / Loosemore / Alphagov vision. A ‘hidden gem‘, Tom Loosemore calls him – which seems a bit harsh, as Neil has been quite the trailblazer in his work at BIS, not least with his own web consolidation project. It’s hard to think of anyone better placed to take up this role.
With that track record, it’s happily predictable to see Neil reserving a specific place for WordPress (and the like). More generally, the vision – as illustrated in the diagram reproduced above – is sound, with the right things in the right places. There’s so much to welcome in it. But there’s one line, describing an ‘irreducible core‘, which stopped me in my tracks:

a bespoke box of tricks we’ll be building from the ground up to meet the publishing needs most government organisations have in common, and the information needs ‘specialist’ audiences most commonly have of government.

Here’s my question for the GDS team: why bespoke? why ‘from the ground up’?
It’s a decision which requires justification. ‘Bespoke’ invariably costs more and takes longer. It will increase the risks, and reduce the potential rewards. It would also seem to be directly in breach of the commitment Francis Maude made in June 2010, to build departmental websites ‘wherever possible using open source software’. Were all the various open source publishing platforms given due consideration? Was it found to be literally impossible to use any of them, even as a basis for development?
Let’s assume WordPress and Drupal, the two most obvious open source candidates, were properly considered, as required by the Minister. Let’s assume contributions were sought from people familiar with the products in question, and just as importantly, the well-established communities around them. Both are perfectly capable of delivering the multi-view, multi-post type, common taxonomy-based output described in the ‘multistorey’ diagram. Both are widely used and widely understood. So why might they have been rejected?
Did the team spot security or performance issues? If so, wouldn’t the more responsible, more open-source-minded approach be to fix those issues? Then we’d all see direct benefits – on our own personal or company websites – from the expert insight of those hired by our government. If things are wrong with such widely-used technologies, whether inside or outside government, it’s already government’s problem.
Or were there particular functions which weren’t available ‘out of the box’? If so, is it conceivable that someone else might have needed the same functions? Local government, perhaps – for which the GDS team has ‘no plans or remit‘. We’re seeing plenty of take-up of WordPress and Drupal in local government land too. They have very similar needs and obligations as regards news and policy publication, consultations, documents, data, petitions, biographies of elected representatives, cross-cutting themes, and so on. Why not make it easy, and cheap, for them to share in the fruits of your labours?
But I think it goes wider than different tiers of government. Government is under a moral obligation to think about how its spending of our taxes could benefit not just itself, but all of us too.
Even if this project’s bespoke code is eventually open-sourced, the level of knowledge required to unpick the useful bits will be well beyond most potential users. Given that it’ll probably be in Ruby or Python, whose combined market share is below 1%, it won’t be much use ‘out of the box’ to most websites. A plugin uploaded to the WordPress repository, or a module added to Drupal’s library, would be instantly available to millions, and infinitely easier to find, install and maintain. (Well, certainly in the former case anyway.)
I can’t help thinking of the example of the BBC’s custom Glow javascript library, which does simplified DOM manipulation (a bit like jQuery), event handling (a bit like jQuery), animations (a bit like jQuery), etc, proudly open-sourced two years ago. It appears to have attracted a grand total of 3 non-BBC contributors. Its second version, incompatible with the first, remains stuck at the beta-1 release of June 2010. Its Twitter account died about the same time; and its mailing list isn’t exactly high-traffic. I’m not convinced it ever ‘unlock[ed] extraordinary value out there in the network‘. Proof, surely, that open-sourcing your own stuff isn’t the same as pitching in with everyone else.
Seriously, this isn’t about WordPress – although that’s unquestionably where the Whitehall web teams’ desire path leads. It’s not really even about open source software. It’s about government’s obligation to the citizens and businesses which fund it. It’s about engaging with existing communities, instead of trying to create your own. Acknowledging people’s right to access and make use of the data – erm, sorry, the code – whose creation they funded. Any of that sound familiar?
There’s so much right about the picture Neil paints. And maybe I’m reading too much into a single line. But the idea of building yet another bespoke CMS to meet Whitehall’s supposedly-unique requirements seems to be three to five years out of date. And it didn’t work too well, three to five years ago. Or three to five years before that. Or…

Public services white paper promises GDS 'app store'

With all the tabloid shenanigans going on yesterday, you’d be forgiven for missing the publication of the new White Paper on Open Public Services – launched complete with a WordPress-based consultation site, developed by Harry Metcalfe’s DXW, with rather cheeky advertising in the source code.
It’s worth noting a couple of references to the Government Digital Service:

7.9 We want to shift the approach of government from ‘public services all in one place’ (focused on how departments want to deliver) to ‘government services wherever you are’ (open and distributed, available where citizens want to access them). To take this forward, the Government Digital Service (GDS) will have the authority across central government to co-ordinate all government digital activity, including encouraging the commissioning of the best user-centred digital services and information at lowest cost from the most appropriate provider. This commissioning process will identify those providers who are the most appropriate to provide content on a particular topic. For example, the Department for Education has already taken this approach in funding some of its parenting support services through the voluntary and community sector – these online services provide in-depth counselling and intensive support as well as information and guidance.
7.10 The GDS will develop a digital marketplace, opening up government data, information, applications and services to other organisations, including the provision of open application program interfaces for all suitable digital services. All suitable digital transactions and information services will be available for delivery through a newly created marketplace, with accredited partners, including charities, social enterprises, private companies and employee-led mutuals, all able to compete to offer high-quality digital services. In opening up this marketplace, the GDS will establish appropriate processes and consider a ‘quality mark’ to ensure that public trust in information and public sector delivery is maintained. This may go as far as including quality assurance of third-party applications.

Two concise paragraphs, but several interesting points in there.
The reference to ‘public services all in one place’ is a rather cheeky, and somewhat barbed reference to Directgov’s strapline, and is surely another nail in its coffin – well, in its current form anyway. I’m surprised to see the word ‘encourage’ for GDS’s role, as opposed to something stronger; and it’ll be intriguing to see how the trinity of best quality, lowest cost (note use of the superlative) and ‘most appropriate supplier’ plays out in practice.
The second paragraph puts some flesh on the bones of the ‘government app store’ notion. But the more I think about it, the more uneasy I get about the idea of QA’ing third-party applications. If an application hasn’t been approved, is it still permitted? Who exactly is doing the approving? Would the approval process become a bottle-neck?
I hate to bring it all back to WordPress (again), but it’s the best example I can personally think of, of a rapid, cheap and non-traditional solution being widely successful in government over the past few years. We – a word I use in the widest possible sense, covering myself and many other (rival?) suppliers – made our case, we delivered, and we didn’t let people down. The only approval we needed was the recommendation of the previous client.
We didn’t need no stinking badges. And if we’d have had to wait for delivery of our badges before being taken seriously, none of it would ever have happened.