20 May 2011
Everybody who has had much to do with the development of government web services knows that there have been failures of imagination, failures of bravery, failures of technique and failures to seize opportunities – as well as successes in the teeth of opposition and incomprehension. Few have had the opportunity to start from scratch (though those who have have often made good use of that opportunity). So there are inevitably people who will look with envy at what the alpha gov team has achieved and, just as importantly, what it was given licence to achieve. Relly Annett-Baker caught that sense in her recent post:
The frustrating part is plenty of people before Alphagov could see the problems and probably a good few of the solutions too. They were not able to act on them (and many have privately told us of their struggles). And they probably feel like, well, like how everyone feels when the consultants waltz in and say exactly what you’ve been saying for the last however many months. We have been given the utopian blank slate that others have only dreamed was possible. To those people, I can only say this: we aren’t wasting the opportunity.
But everybody who has had much to do with the government web services also knows the complexity of forces which bear down on creativity and design choices, sometimes from undue caution but at least as often from the fact that genuinely contradictory pressures have to get reconciled.
That’s where it starts to get interesting, because Alpha gov is beginning to find itself in this territory. It has come under criticism for the choices it has made about accessibility, for compromising on its approach to UX and even for the amount of white space frivolously scattered about the site. To my mind much more interestingly, questions are also being raised about its scalability and extensibility. One commenter on alpha gov’s about page puts it this way:
It looks good. Vast improvement on Directgov. Alpha seems like a great way to test and design the public face of e-govt and I’m sure a lot of the comments you get will praise the big leap forward in usability on show here. I hesitate to say this, but that’s the easy bit. Does your remit with Alpha go as far as testing the other side of this – i.e the other end of the transactional processes, within the Departments? It’s just as important that that alpha provides Departments with the flexibility, functionality and autonomy they need to adapt and develop their products and online services quickly, as it is to make sure the public interface works well. I suspect this will be hard though – the barriers will be more cultural and political than technical.
Alpha gov is a proof of concept. But what concept has it proved? That there are more arresting and more user friendly ways of building a government navigation site? Definitely. That starting with what users actually want to do, and then helping them do it is a good and (in this context) radical approach? Assuredly. That this could replace Directgov or become the heart of the single government domain (whatever that is)? Well, no. Not because it is clear that it couldn’t do those things, but because that is not what it has been built to test.
So what, then, is this alpha? Is it an alpha gorilla, asserting dominance and superiority? Or is it alpha software, tentatively tiptoeing into the daylight for a short and critical life before being cast aside?
The name is supposed to connote the second. But because of all the doubts, uncertainties and insecurities described above, some will inevitably hear the first. Tom Loosemore is horrified by that possibility. I don’t have a scintilla of doubt in his good faith but objectively, as the marxists used to say, I think he may be wrong. The purpose of alpha gov is to challenge, to point fingers at the past and so, by implication, at those who have played parts in creating that past. The position it is aspiring to occupy is not some marginal piece of unimportant communication to a group nobody cares about, it is to be the new paradigm for the way the whole of government interacts with its citizens. It is to be the alpha gorilla, even if its chosen weapon is the alpha site. Aspirant alpha gorillas have to fight to establish their position. Some succeed, and dominate the pack (at least until the next aspirant comes along). Some fail, and are ejected. What we are seeing is the beginning of that fight.
I don’t think Tom and the alpha gov team need feel apologetic about that. But equally, I don’t think that most of those involved in creating the set of things alpha gov is there to challenge need to feel guilty or apologetic either. That’s because alpha gov is, in one important sense, a sleight of hand. It is proposing a technical solution to a supposedly technical problem. That’s good, but technology is not, fundamentally, the reason why the government’s web presence is as it is. The real problem is not technology but sociology. To the extent that the structure of government has been designed at all, it has been designed to be delivered in ways which can be managed. Government is not fragmented as an accident but as a way – for a long time the only possible way – of getting things done. One result of that, as I have argued before, is that there is no such thing as the government. The question then becomes, how in a world of rich and complicated public services, detailed legal frameworks (often highly specific to the service they regulate), every conceivable combination of personal characteristics and needs, and long tribal histories we can nevertheless make things better by deploying the new and more powerful tools we now have available.
From that perspective, the primary power of alpha gov is not as a solution, but as a catalyst. It does less to provide answers than those who built it might have hoped or thought. But it does very starkly pose a question and demand an answer. Who chooses to pick up that question and answer it may show who is the real alpha in the pack.
Things which caught my eye elsewhere on the web, rather a lot of them from the Alpha.gov.uk blog. This is only the second time ever that one of these posts has been so skewed to a single source (and is just as unintended and emergent as the first time). So the Alpha team get one of the highest accolades this blog can offer – all they need to do now is come up with a couple of aphorisms.
- It’s all about the nodes and what lives at them | Alpha.gov.uk team blog People are arriving from search engines looking to complete a specific task, so we decided to build an unashamedly flat, task-focused website to help people find the ‘quick do’ as we termed it.The assumption is that people are coming from a search engine, and for those who aren’t we provide an autocomplete search box with a more traditional search results page as a backup – again to get people straight to the answer as quickly as possible. It’s about the nodes not the network.
- Agile does work in government | Alpha.gov.uk team blog Just as there are trends in technology, there are fashions in project management and some feel that agile is poorly suited to government and is just a fad. One of the principle objectives for this project was to demonstrate that an agile approach can work.
- Broadly, the visual language of Alpha.gov.uk | Alpha.gov.uk team blog Search logs from existing Government sites show that over 90% of traffic is people arriving at deep links, typically coming from Google to a transaction page, wanting to complete their task and leave. From this perspective, the homepage is rarely seen and very little horizontal navigation around the site is necessary, at least in the citizen parts. The original concept was to keep the homepage simple, much like Google, but in the end we had to make a few concessions internally and we’re presenting a lead news story as a backdrop to the search, plus some news articles further down the page.
- Schneier on Security: Status Report: The Dishonest Minority The term “dishonest minority” is not a moral judgment; it simply describes the minority who does not follow societal norm. Since many societal norms are in fact immoral, sometimes the dishonest minority serves as a catalyst for social change. Societies without a reservoir of people who don’t follow the rules lack an important mechanism for societal evolution. Vibrant societies need a dishonest minority; if society makes its dishonest minority too small, it stifles dissent as well as common crime.
- Preaching to the unconverted « honestlyreal As with most difficult public policy issues, from asylum seekers to disability claimants to identity, there’s always an easy, quick answer that will get heads nodding in the pub and taxi. But which is almost always utterly, hopelessly, WRONG. Who wouldn’t like an easy answer to a hard question? To avoid any deeper thinking about the subject. Or acknowledgement of history, personal responsibility or sense of others? To gloss past the difficulties that arise when something that looks (from a huge distance) a tiny bit like a simple, familiar, backyard activity is attempted on a scale of tens of millions of people and transactions.
- Alphagov – in which we remove potential threats of leopards. | Rel.ly If you’re from a Government digital services background then you’ll be aware of Martha Lane Fox’s report on which our work is based. You’ll know the word radical was used. And so it is, in the scheme of Government work. Leaving aside the ‘how is it developed’ and ‘what technology are you using’ questions (which become part of the problem and explanation), the frustrating part is plenty of people before Alphagov could see the problems and probably a good few of the solutions too. They were not able to act on them (and many have privately told us of their struggles). And they probably feel like, well, like how everyone feels when the consultants waltz in and say exactly what you’ve been saying for the last however many months. We have been given the utopian blank slate that others have only dreamed was possible. To those people, I can only say this: we aren’t wasting the opportunity.
7 May 2011
This is how conversations work, or rather how one conversation played out on twitter this morning. Tricky subject, no right answer, constructive discussion.* But perhaps most important of all, those issues are being discussed in public for a government proof of concept which hasn’t yet even been launched. It is that which is more radical and, for the long term, more valuable than the issue at hand.
Update 8 May: And then 24 hours later, the same conversation restarted. The very things which make twitter a powerful and immediate communication channel also make it hard to see what has gone before and – I have even more forcibly realised – hard to transcribe and preserve. A few more tweets added below.
* It is the nature of twitter discussions that there was more to it than this, but from what I could see, this was the core thread of the conversation.
Update: The following day…
6 May 2011
Things which caught my eye elsewhere on the web
- If you started today, you would never build what we’ve got. You would build Alphagov.
- A few design rules for alpha.gov.uk | Alpha.gov.uk – team blog Back in February when we were kicking off the alpha project, we spent the first couple of weeks scouring search logs and analytics for the various central government websites; thinking about who our users were and generally discussing the kind of thing we were setting out to make.
‘User centred’ was always going to be one of the fundamentals of the project, but it’s a mutable concept so we wanted to set out more clearly what we were all about – to set out some rules to guide our thinking and to keep us honest.
- Executive Order–Streamlining Service Delivery and Improving Customer Service | The White House The public's expectations of the Government have continued to rise. The Government must keep pace with and even exceed those expectations. Government must also address the need to improve its services, not only to individuals, but also to private and Governmental entities to which the agency directly provides significant services. Government managers must learn from what is working in the private sector and apply these best practices to deliver services better, faster, and at lower cost. Such best practices include increasingly popular lower-cost, self-service options accessed by the Internet or mobile phone and improved processes that deliver services faster and more responsively, reducing the overall need for customer inquiries and complaints. The Federal Government has a responsibility to streamline and make more efficient its service delivery to better serve the public.
- Agile for communications « Sharon O’Dea In many, probably most, organisations, taking an agile approach to projects and campaigns outside of IT is going to mean a big cultural shift. The waterfall mindset is deeply ingrained in almost every project; changing that mindset so that stakeholders accept plans will constantly change isn’t going to be easy. It requires trust on the part of stakeholders and bean-counters, and getting that is going to require a hard selling job emphasising the rewards that come from reducing large-scale failure, and in some cases a big leap of faith.
- Against studying the Internet — Crooked Timber I’d like to see people who study the ‘Internet’ and ‘social media’ stop studying them, and instead start focusing on the role of causal mechanisms that might (or might not) be associated with specific technologies in explaining political outcomes, i.e. to start replacing technology names with mechanisms. This would, of course, require Real Research. But it seems to me more promising than the likely alternatives.
- Local Government by contract? « We Love Local Government ‘Government by contract’ assumes that the facts never change and that when they do it is possible to re-negotiate.
But politics is designed to produce disagreements and for those that govern to change their mind and respond to the feelings of the people they represent. A ten year contract, or budget cycle even, might be more efficient but it forgets that the facts might change, that the politicians might change and that stuff happens.
- Are your users S.T.U.P.I.D? – Boxes and Arrows: The design behind the design Effective intelligence obviously varies across situations. People are ingenious at figuring out things they really want, but the simplest task is insurmountable to the unmotivated. Both scenarios are solvable, but an application that makes the wrong assumptions about its users will fail.
- Fear of piloting | Blog Above all, we need to change a culture which sees changing course in the light of evidence as a sign of weakness.
- FT.com / FT Magazine – Why we’re all far too sure of ourselves The fact is that our political system simply does not take evidence seriously. If I had to suggest one single reason for that, it’s our love of certitude. Evidence is the way to reduce honest doubts. Stuffed on a fattening diet of certitude, who has room for doubt? And if we have no doubts, who needs evidence?
- 3 Tips On Scaling Agile Development At some point, adopting Agile development becomes an organizational change management exercise that has little do with Agile itself.
- Searching out jobseekers’ behaviour | Analysis | Recruiter Information sites, such as DirectGov and Wikipedia, achieved notable visibility due to relevant job-related content and credibility through links. By contrast, Hays lost 4% visibility, which saw it fall from position 11 to 27 in Greenlight’s league table.
- The public debt – why it’s different this time | Flip Chart Fairy Tales But over the longer term, if public finances are to be restored, the cost of delivering public services will need to come down. That will be the challenge of the next decade.
- Architecture Revisited « The Limber Lambda Due diligence, even if through up-front requirements specification and review was justified, however you look at it. The only way that interpretation of requirements could have been tackled efficiently in an agile setting in this case would have been if the product owner was uber-qualified—someone who knew the business backwards and who had a sufficient personal stake to take delivery personally. No such person existed.
4 May 2011
I went a couple of weeks ago to a fascinating discussion about the nature of service design, organised around a book published last year called This is Service Design Thinking. The two editors of the book were due to lead the session but were at the wrong ends of a skype three way video conference which stuttered into a dalekian half life without really quite making the breakthrough into comprehensibility. After various attempts to rewire, reconfigure and reboot, we gave up and had what turned into a good conversation among the dozen people round the table in London.
I wasn’t taking notes, so I am not even going to attempt to capture the range of the discussion. Instead I want to reflect on one of the topics we touched on and on some subsequent thoughts about the different positions of public and private sector and smaller and larger organisations.
The topic, slightly unexpectedly, was on the question of whether there was really any such thing as service design in the first place. Given the selection bias inherent in a group united round a book on the subject, that felt a little odd, but reflects the novelty and uncertainty of service design as a discipline. As the book brings out, perceptions of service design can strongly depend on the the starting discipline of the person doing the perceiving: anthropologists and marketing people tend to see the world rather differently. Several members of the group questioned whether service design was really user experience design talking itself up. I found that fascinating, because for me one of the attractions of the label is precisely to get away from questions of channel specificity: the service which needs to be designed is the complete set of interactions which take a customer securely, confidently and effectively from arrival to departure, treating that as a form of glorified interface design seems to slightly miss the point. That indeed points to one of my frustrations with my (very fast and superficial) reading of the book, that its case studies start too far in: the focus is very much on how design questions were answered rather than on how and why the questions were formulated – what was it that made the case study clients think that they wanted some service design in the first place? Interestingly, the one exception is the MyPolice case study (even allowing for my bias in its favour), which I suspect has a lot to do with being a self-generated project where service designers and product owners were the same people.
That mirrored the perception by some in the discussion that service design was a fine idea for small scale experiments in the voluntary sector, but wasn’t (or at least wasn’t yet) something which could be offered to a demanding commercial client interested only in immediate increases in sales. The sense seemed to be that it was too nebulous and unproven, and that clients overwhelmingly preferred to buy specific skills in the minimum necessary quantities rather than some more broadly based and perhaps more amorphous service (and worth noting that many of the participants were in the web consultancy business one way or another, with billable hours the only real currency).
There is a common perception in (and of) the public sector that we are constrained by process and caution, insulated from commercial pressures to be innovative and creative, and so compelled to lag behind the cutting edge of the private sector (a pattern perhaps illustrated by no fewer than three recent posts on public sector procurement, all very well worth reading). So it was fascinating for me to see a sort of reciprocal envy, from people in intensely commercial roles and organisations, who saw in the public and voluntary sectors a degree of freedom from very short term financial metrics which could allow more integrated and less hard edged approaches to flourish.
It was an interesting discussion, though not the one I had expected, based on a book which perhaps shares the power and fragility of the concept which is its subject. It is itself, very self-consciously, a piece of service design, using colour, symbols and layout to provide a much richer experience than any more conventional book. That added up to a splendid reminder of how much more powerful and engaging a book can be than any online substitute yet devised – and yet elements of the design self-consciousness were as irritating as others were inspiring. It all felt as though it was trying just a little too hard to be clever, and perhaps that is an indicator of a discipline with huge power and potential, but which has not quite reached the maturity and self-confidence to make best use of them.
3 May 2011
I have cracked the problem of government IT.
A few months ago, I argued that there is no such thing as the government. Now, in a further breakthrough, I have realised that there is no such thing as IT either. Putting those two thoughts together leads unavoidably to the conclusion that the problem of government IT is not what it appears to be.
The prompt for this realisation is last month’s report from the Institute for Government, System Error, bravely subtitled, ‘Fixing the flaws in government IT’. The first thing to say about it is that it is an excellent piece of work, setting out very clearly some of the problems which beset large IT projects and how those problems would be better avoided, not by sticking ever more rigidly to formal processes which are themselves root causes of the problems, but by switching to radically different approaches to developing and delivering projects.
But the second thing to say about it is that it is deeply flawed in ways which stem from perceiving all of this to be an IT problem in the first place. Grouping issues together because there is a technology dimension is not wrong, but nor is it the only approach and, I would argue very strongly, it is not the most useful approach to addressing the problems the report is seeking to solve. The conclusion I draw from the report’s own arguments is that seeing this as being about fixing the flaws in government IT is itself one of those flaws.
I claim no originality for this thought. I came into the world of e-government just a report was being completed on making government IT projects work better, in response to a perception that too many were failing. Although the report was called Successful IT, its very first page stated firmly that:
Our most important message is that thinking in terms of ‘IT projects’ is itself a primary source of problems. Delivering IT is only ever part of the implementation of new, more effective, ways of working. The IT has to fit closely, for example, with the demands of the public and the new working practices needed to produce the desired changes. Achieving this requires a clear vision of the context in which IT is being implemented.
A change of approach is needed. Rather than think of IT projects, the public sector needs to think in terms of projects to change the way Government works, of which new IT is an important part. Our recommendations aim to achieve this change.
I don’t for a moment suppose that the authors of System Error would disagree with any of this, but it doesn’t seem to be a central theme of their own thinking.
Instead, they focus on two basic concepts:
- platform which is essentially about the commoditisation of as much as possible, reinforced by common standards and functions across government; and
- agile which is about how new systems and services are developed (and so by almost necessary implication, things which are not commodities).
Their analysis of each of them is powerful and persuasive, but I think in the end takes them to some unhelpful conclusions because of a perception that the two are linked by being part of something called IT. Slightly oddly, the report contains within it the seeds of a very different – and to my mind much more powerful – understanding of both problems and solutions than it in fact draws from the evidence.
The body of the report opens with a strong attack on traditional waterfall approaches, particularly for the kinds of problems governments often find themselves needing to deal with:
Government is frequently tasked with tackling ‘wicked issues’, such as reducing child poverty or combating antisocial behaviour, where no one can be certain what the best solution is. For these kinds of complex problems, the best way to determine what works can often be to experiment, learn and improve as you go in an evolutionary approach. However, government IT has rarely supported this iterative and exploratory style of developing solutions. When uncertainty is high, ‘locking down’ solutions is exactly the wrong approach and virtually guarantees that a sub-optimal solution will be developed. (p28)
With equal fervour, the following chapter describes a very different approach:
Compared with traditional tools and methods, agile offers a fundamentally different approach to tackling business problems. Where the traditional approach favours complete solutions developed in a linear fashion, agile encourages a modular approach using short iterations to learn and adapt. Instead of trying to lock down requirements and minimise changes up-front, agile encourages continuous experimentation, improvement and reprioritisation. The approach to user involvement also differs fundamentally. The traditional approach favours heavy user engagement up-front to determine and lock down detailed specifications and at the end to test the final product. In contrast, agile embeds users in the process for the duration of the project, making them an integral part of the development team rather than a constituency to be consulted. (p31)
That’s an approach which certainly started off as a method for software development, but that’s not to say that’s the most helpful way to think about it in this context. The message I get from the report is that IT is too separate from the business and needs to get closer to it. That’s not wrong, and if it were the only available option, it would be well worth doing. But at one level, all that’s doing is moving from the picture on the left below to the one on the right.
That’s not a bad change to make, but it doesn’t look very exciting, and it isn’t – and in both versions, both agile and platform stay firmly in the IT circles.
I am increasingly of the view that those pictures embody an unhelpful model of how organisations and services actually work – and obscure a fundamental division of labour within the IT function to boot. Neither ‘agile’ nor ‘platform’ happens in isolation in the IT organisation, or rather they do, but that’s a problem to be addressed, not a state of affairs to be emulated. Instead, those words each describes part of what, typically, happens across the organisation. Some of it is about continuing to do what the organisation does, in a repeatable and stable way, and some of it is about finding new and better ways of doing those things, or indeed of doing different things altogether. Treating agile and platform as things which end at the boundary of something called IT reinforces a compartmentalised view more likely to exacerbate problems than to solve them.
It is also true that agile and platform are less distinct than the report argues. The idea of using commodity tools, services and platforms to create agile, radical and distinctive applications is hardly novel or distinctive. That is, after all, a way of describing the internet and the services which run across it, which is all not as new-fangled as it used to be.
A better approach is to recognise that stable things and innovative things both need to belong to the organisation as a whole – or rather to the users of the organisation’s services – rather than artificially to something called IT or something else called business. The crucial point, though, is in their relative positioning. There is a strong case for activities designed to change what is done being agile; there is no case for those projects being focused on, still less driven by, IT change. That is wholly consistent with the agile philosophy, which emphasises user stories and engagement and participation from every relevant interest, but is less consistent with some of what seems to get labelled agile practice.
So I think we need a picture much more like the one below. IT is still there, as it should be: it is a skilled and professional discipline with an essential contribution to make, but it is only one element of thinking about system changes. Both what is standardised and commoditised and what is customised need to be more comprehensive in scope, though their relative balance probably should be different.
So by all means, let us have commoditised platforms and let the provision, support and reliable operation of them be an IT service to the wider organisation. Even there though, we need to be careful about the life cycle of a commodity. Email and web access are commodities, but does that doesn’t necessarily make getting stuck with a ten year old email client and IE6 an attractive place to be. Government has a web CMS platform which was intended to be a commodity, but is locked inflexibly into a world before social media. And even the most commoditised of basic internal services can suffer if their development is approached in any less agile a way than any other project, with a particular risk of being optimised for specialist rather than more general users.
But when we get beyond commodities, the picture gets very different. I don’t think the authors of the IfG report see change as being purely about IT; quite clearly they do not. But the language of the report repeatedly gets trapped in making ‘IT’ and ‘not-IT’ the key organising categories:
The principles of the agile approach can be applied to almost any IT project and could also be considered for non-IT related applications. (p47)
Though that is almost immediately followed by:
Agile may have originated as a software development tool, but many of its principles can be used much more widely. Projects should be modular, iterative, responsive to change and have users at the core. (p47)
Much of its comes from the fact that at least to start with, agile is about software development, without ever being about IT. The principles it embodies can indeed be applied much more widely, in ways which themselves have a huge impact on the nature of the project. Indeed, I would go so far as to say that the application of agile principles is inconsistent with the concept of an IT project.
So it is not possible to make change management work better in government as long as the challenge is expressed as being about fixing IT or about distinguishing IT and non-IT projects. The power – and the threat – of agile is that it undermines sequential professional silos. From what I have seen of it, it is not inherently more difficult, but it is undoubtedly very different, and like any new approach adaptation and adoption need to be taken seriously. Particularly for large and cumbersome organisations, such as are occasionally found in the public sector, there is a real risk that agile becomes a trendy label for doing waterfall in fortnightly drops.
So by all means, let’s talk about platform, agile, commodities and customisation – but let’s not squeeze them under a heading of IT where they do not fit. Once we break free of that last critical element of the waterfall mindset, we can think seriously about how to do all this better.
That still leaves, of course, the question of how best to apply agile approaches, and indeed whether they can be made to work at scale in government at all. That’s an important debate, the subject of a flurry of recent blog posts, but it’s too big a question to come to late in a long post. So that’s a topic to return to, but one where I will be arguing that agile gives us our best hope of reconciling the challenges of large scale change in public services with efficient and effective delivery.
28 April 2011
When I was 17, my first proper paid job was in the public library just down the road from the Elephant and Castle. It was the first time I had come across large print books. They had their own section, and there was a huge demand for them. But though it was much more intensely used, the selection was much more limited, partly because they served only a fairly small proportion of the library’s users, but partly of course because only a very narrow range of titles was produced in the first place. They looked very boring and very distinctive – no money was wasted on design or on attracting readers, the covers were just slabs of colour, and they stood out at fifty paces.
That was a long time ago.
A few months ago, I got a kindle, slightly accidentally – I hadn’t thought I wanted one. To my surprise, it has more or less instantly become my preferred means of reading book-length texts. There are several reasons for that, but this post isn’t yet another kindle-groupie breathless review, so I am going to focus on just one feature which, from what I have seen, had got relatively little attention.
You can adjust the size of the text.
The kindle destroys the concept of a large print book, because it’s not the book which has a print size any more, it’s the reader (in both senses, the device and its user).
That instantly means that I can adjust my kindle to a size which is comfortable for me, which is bigger than most publishers’ default, though much smaller than large print. That’s a really useful feature for me as an individual. But it also has much wider implications. It means that there is no reason why every book should not be available for every reader, it means that there isn’t a highly constrained choice of books for people with weaker sight, and it means that the arbitrary, binary, and stigmatising divide between ordinary books and the large print list goes away.
All of that makes the kindle a lovely example of technology which changes the context in which it operates.
Most of the borrowers of large print books all those years ago were elderly ladies. I doubt that their successors of today are high on the target list for Amazon’s marketing of the kindle. But their successors of tomorrow could find that an almost accidental characteristic of easy technological flexibility brings a segregated service and segregated customers into the mainstream.
26 April 2011
My strong recommendation for this evening’s entertainment is to watch a documentary about nuclear waste in Finland – it’s on More 4 at 10pm and will be available on the Channel 4 website for a while after that (and north American readers can find dates of cinema showings here). It’s much more interesting than it might sound.
I happened to see it a few months ago, when it did a brief run in obscure cinemas, and wrote about it then:
The Finns are digging a very big hole in which to store their nuclear waste. They won’t finish filling it up while any of us is still alive, but once it is full, they plan to fill in the hole and keep the waste secure for 100,000 years. To put it mildly, that raises some interesting questions.
Those questions include how to communicate over thousands of generations, how to approach decision making for issues of such moment, and whether secrecy may be a better gift to the future than openness.
Since I assume readers of this blog have a fairly strong interest in public strategy and decision making, I can recommend it even if you think you have no particular interest in apparently recondite issues of nuclear waste management. My earlier blog post has more about all that and the film has a trailer, though it’s not the greatest come on in film history:
18 April 2011
Things which caught my eye elsewhere on the web
- Fast Path to a Great UX – Increased Exposure Hours For more than 20 years, we’ve known that teams spending time watching users, can see improvements. Yet we still see many teams with regular user research programs that produce complicated, unusable products. We couldn’t understand why, until now. Each team member has to be exposed directly to the users themselves. Teams that have dedicated user research professionals, who watch the users, then in turn, report the results through documents or videos, don’t deliver the same benefits. It’s from the direct exposure to the users that we see the improvements in the design. Over the years, there has been plenty of debate over how many participants are enough for a study. It turns out we were looking in the wrong direction. When you focus on the hours of exposure, the number of participants disappears as an important discussion. We found 2 hours of direct exposure with one participant could be as valuable (if not more valuable) than eight participants at 15-minutes each. The two hours with that one participant, seeing the detailed subtleties and nuances of their interactions with the design, can drive a tremendous amount of actionable value to the team, when done well.
- Premise: Asking the wrong question about Data.gov Open data policy matters because it reduces barriers to people with bright ideas from creating goods and services that make the world a bit better, either socially or economically. It really is as simple as that.Data.gov and all its’ domestic and international spinoffs suceed only in so far as they help the frustrated innovators or researchers to get what they need quickly and easily, so that people in the future don’t have to break the law by ‘stealing’ their own parliamentary transcripts data, as the first TheyWorkForYou volunteers had to. [...]
The open data community should shake off its guilt about not producing data for direct consumption by end users – power station managers don’t feel guilty about not producing iPods. Instead we should be proud of and fiercely focussed on enabling the next generation of entrepreneurs and story tellers to do their mass-market magic.
- Light Blue Touchpaper » Blog Archive » Pico: no more passwords! Passwords are no longer acceptable as a security mechanism. The arrogant security people ask users that passwords be memorable, unguessable, high entropy, all different and never written down. With the proliferation of the number of passwords and the ever-increasing brute-force capabilities of modern computers, passwords of adequate strength are too complicated for human memory, especially when one must remember dozens of them. The above demands cannot all be satisfied simultaneously. Users are right to be pissed off.
- A clash of networks and institutions | LabourList.org 2.0.2 | LabourList.org When things work well networks and institutions can be balance with one another: one serves as venture capital, the other as insurance. One exploits the present, the other builds for the long-term. The ideal is to balance the creative energy of networks with the long-term logic of powerful institutions. What this means is that networks are at their best when they not only disrupt present injustices but when they quickly move to build institutions around more just and democratic alternatives. It’s easier to organise a protest -even a large one -than to build a new economy, democracy, or society.
- Happy Birthday Rewired State | Helpful Technology As a fair weather coder, I understand the desire to code for fun – and I think Tim Davies’ app to render Select Committee minutes in the style of restoration comedy was pretty much squarely in that camp. As a former government digital insider, I also understand the impatience that the great ideas and talent don’t make a bigger impact on online public services. It’s one of the tensions of the open data movement more generally, that putting more raw data out there hasn’t yet produced more industrial-strength solutions with major commercial or social benefits. But that doesn’t mean that it won’t.
- Third National Hack the Government Day « Julia’s Blog I attended the third National Hack the Government day, which, contrary to some early reactions from friends and colleagues, is not some shady underground movement where people try and break things, but an energetic session where people with a combination of coding skill, curiosity and a general wish to make things work better get together and see what they can do with government data. Its run by Rewired State and todays session was at Kings Place –home of the Guardian. Notes follow on most of the presentations (apologies if I missed you out, or got your name wrong (or just didn’t get your name….) –blame my scribbled note taking or the fact I simply couldn’t get my head around what you had done!) Full details and links to all the material available should be published on the Rewired State website.
- Light Blue Touchpaper » Blog Archive » Can we Fix Federated Authentication? Using one service to authenticate the users of another is an old dream but a terrible tar-pit. Recently it has become a game of pass-the-parcel: your newspaper authenticates you via your social networking site, which wants you to recover lost passwords by email, while your email provider wants to use your mobile phone and your phone company depends on your email account. The certification authorities on which online trust relies are open to coercion by governments – which would like us to use ID cards but are hopeless at making systems work. No-one even wants to answer the phone to help out a customer in distress. But as we move to a world of mobile wallets, in which your phone contains your credit cards and even your driving license, we’ll need a sound foundation that’s resilient to fraud and error, and usable by everyone. Where might this foundation be? I argue that there could be a quite surprising answer.
- BBC – dot.Rory: Technology for all ages The ideas being piloted here were similar to those I’d seen at Microsoft’s research laboratory – they all involved abandoning the traditional computer and keyboard in favour of what are called natural user interfaces. Touch, talk, and motion look like becoming the ways we interact with computers in future – often without realising that the computer is there at all.When technology firms design new products, they look to early adopters for ideas and approval – the elderly are shut out of the process. Yet across today’s technology industry, the most successful new products are those which are easier to use. So the Surrey academics and their elderly collaborators could be helping to shape the gadgets of the future.
14 April 2011
This apparently ordinary station on the Berlin U-Bahn is remarkable for two reasons, one visible and one not visible at all.
The first is fairly apparent. The typeface of the station name and the brown tiles give a clue, though the full splendour of the orange ceiling doesn’t really come across in the picture. This is the 1970s in unabashed glory.
The second reason is not apparent at all. It is that as well as being an underground station, this is also a nuclear shelter. In the concourse above and in the tunnels, massive doors are ready to swing into place. Just by the ticket machines, a small discreet door in the wall leads to interlocking steel doors, a decontamination area, and then a warren of rooms and passages providing everything necessary to keep three and a half thousand people safe for two weeks, before emerging into the post-nuclear dawn. Trains were to be parked at the platforms to provide extra space, with bunk beds four high on the platform itself.
It is extraordinary, impressive – and a complete folly. It formed part of a civil defence network for Berlin which in total provided 20,000 places for two million inhabitants. It was a gesture, not a defence system.
From our omniscient viewpoint 35 years on, it is easy to ask why on earth anybody thought this was a good or necessary idea. It’s fairly clear that it was a gesture, but a gesture to whom, signifying what?
Of course it didn’t look like that at the time. It never does.
This is a particularly stark example, partly because of the speed with which the perceived threat of the cold war dissipated. But it is very far from being unique. Options may be appraised, costs and benefits assessed, future proofing added and gold plating removed, but still solutions emerge from the paradigm within which they were created. Perhaps it was once obvious that the building of a new station should be seen as an opportunity to build a shelter as well.
None of us will make exactly that mistake, of course. But we are no more immune to follies of policy and delivery than our predecessors were. The difference is only that ours are not yet visible to us: it will be apparent in a few decades – perhaps sooner – where we are going wrong. That’s not much good of course: if we are going to fail, much better to fail early, in time to do something else instead.
If the only problem with the Pankstrasse shelter were that we can now marvel in its pointlessness, there would be little point in worrying about it. There is a strong case for saying, though, that this is a folly which could have been avoided; that the problem was not the absence of information but its interpretation. Knowing (or thinking) that provides no guarantee that we can do better, but it does suggest that innovation by simple extrapolation may not be the best way of designing policies for the long term.
They still test the doors which seal the tunnels once a year. And the ceiling is still orange.