Eye of an elephant

My post last week on apps for elephants has prompted some interesting discussion.  Steph Gray had some eminently sensible practical thoughts on how government could balance the need to adapt to changing demands with the need to support openness and flexibility:

Of course Government should be developing smartphone apps (though probably not iPhone exclusively) as part of communication strategies to reach mobile audiences, and building on the ‘start simple’ approaches above. Frankly, it’s embarrassing to still be spending such large sums on direct mail to businesses, for example.

But government shouldn’t be a monopoly provider, crowding out commercial or voluntary alternatives, and it should probably focus on the areas with strong social benefit but limited commercial opportunity.

Even more interestingly, Dave Briggs has argued, in effect, that we might be discussing the right issue, but that we started with the wrong question.  I think he’s on to something important here: the apps issue is a special case of a much more general question, and there is a real risk that the apps bit (particularly if apps is interpreted as being just about iphones) gets in the way.

The government is strongly committed to the transparent availability of data.  Its central public facing website has published an API which allows third parties to build their own variants if they want to or, more probably, to incorporate particular parts of it in their own services. So in effect the model we are moving towards is one where material is generated and can be published at a much more atomic level, making the scope of publication and the range of potential publishers into questions which are separate from the availability of the underlying material. That separation creates four broad options:

  1. government is a unique user interface provider
  2. government is a privileged user interface provider
  3. government is an unprivileged user interface provider
  4. government is only a provider of data and transactions and does not provide a user interface at all.

Traditionally, government – and all other organisations – have been in the first category. Government has been a  monopoly provider of its own services and the monopoly gateway to its own data.  The current shift is to somewhere between the second and the third.  Even with the application of the data transparency principles, though, I am not sure that we get all the way to the third.  The apps question is essentially a question about the fourth option: for at least some devices and services, should government exclude itself from providing the service directly at all?  But that isn’t inherently a question about apps at all, and in turn splits between a pragmatic approach (some markets are too small for government to be justified in serving them) and a more principled one (there is a better outcome if government avoids the risk of crowding out nimble innovators).

My instinctive view remains that government cannot abdicate the responsibility for user interfaces, whether online or in any other channel.  It has a responsibility to make sure that they exist, that they are usable, that they are accurate and up to date and that they are where citizens and services users expect to find them. The possible paradox is that government has no means of discharging that responsibility in an option four world, even if it were the case that the absence of the elephant led to a flowering of innovation and a better set of solutions.

It is clear though that we are leaving the option one world behind and that what we are seeing is some unresolved tension between options two and three, much of which is about finding ways of giving confidence and safety to the mice without hobbling the elephant altogether.  Or perhaps is about looking for ways of being confident that the collective contribution of the mice will fill any gap created by the absence of the elephant.  As Steph points out in his comment on Dave’s post, third party providers have not yet shown eagerness even for apparently attractive opportunities, and it is far from clear that there is a commercial model yet established which will come anywhere close to creating a substitute for government’s own efforts.  That may mean that we need smarter business models or it may mean that we need to be better about bringing skills and dynamism into government.  And undoubtedly it is about better understanding of what customers want and need and about better understanding how to translate that into effective service design.  The elephant has not always been very good at that – but the mice have something to learn here too.

More generally, the elephant needs to create space for the mice. But that doesn’t give a mouse the right to require the elephant to be silent. It would be well worth thinking more systematically about how option three might be made to work, but we shouldn’t assume that’s just a step towards option four. And in the meantime, Steph’s five points are not a bad place to start making it all work:

  1. Establish standards, and good practice (COI already has something, but it needs updating: http://coi.gov.uk/guidance.php?page=319)
  2. Expect strategies (demand that new mobile projects can demonstrate an audience, a business case, an evaluation process etc)
  3. Mandate open source data/APIs (so the wider ecosystem can kick in where there’s a desire to do so; and get your licensing straight)
  4. Control costs (itemise spending on mobile web/apps, count traffic properly, publish it all)
  5. Start simple (optimise web for mobile devices, use SMS, integrate mobile with regular web platforms, build standards-compliant online services)


  1. As long as the call and movement for open data propels itself along a tipping point will eventually be reached.

    That will likely happen when the then current perceived best practice dictates that Enterprise level software dumps data out to data stores as a matter of practice (or if we are serious about this and want to put the knuckledusters on – a matter of contractual obligation from Jan 1).

    At that stage Gov UIs at 3) will be consuming their own data with everyone else from 4).

    APIs and data will cease to be a by-product, they are the Main Thing.

Comments are closed.