Steph Gray

10 things Alpha.gov.uk gets wrong (Part 1)

In Blog

People have been very nice about Alpha.gov.uk, the new prototype of the single domain for government since its launch last week. Simon Dickson, a man who pulls few punches, highlighted ten things Alphagov gets right. I agree with all of them, and having seen glimpses of the project as it developed, it’s a remarkable, important and innovative way to approach a really knotty problem.

But it’s a long way from perfect, and the emerging consensus that This Is The Way Things Should Be Done troubles me a little. So with my tongue slightly in cheek, here’s Part 1 of my starter for 10 on What Alpha.gov.uk Is Doing Wrong…

alphagov in IE6

1. Focus on unicorns, not IE6

Paul Annett-Baker (who I met briefly) is a formidable creative talent to have on the team. His Dribbbling was one of the most fascinating and consistent strands of public engagement, sharing snippets of his design thinking along the way. Now, I appreciate that IE6 is a dying browser, but people in public and third sector organisations around the country are still stuck with it. It was the right call not to constrain functionality in order to achieve cross-browser consistency, but to be honest, for my little projects I find making a design functionally usable (if not pretty) in IE6 is often matter of a couple of hours’ work at the most. It’s nice that we have well-drawn unicorns, but it’s a shame that SpAds and senior civil servants around Whitehall are presumably looking at Alphagov and thinking “this looks awful, where’s the Serco version?”.

2. Accessibility

This was a heated debate a few weeks back, as part of which I backed up the Alphagov team’s justification for not aiming to deliver an accessible output. It was right not to claim to tick a box for the sake of ticking a box, and the intelligence of the Alphagov team is such that I’m pretty sure they appreciate the importance and complexity of delivering accessible digital tools – and this is just a vision, a prototype. But it’s stimulus for public feedback so restricting access is a problem, and the implication (if not the intention) of the statement was that accessibility was a feature to be prioritised and downgraded, rather than a hygiene factor like security or resilience or maintainability. The bottom line is that the site is still more accessible than many public sector digital tools in production (SharePoint, anyone?), but the project lost friends here, when it didn’t need to. The Unicorn symptom, maybe.

3. Shrink the padding, goddamit

My main screen is a 22 inch 2048 x 1152 monitor. On it, I can see a grand total of one line of the first paragraph of text on the BIS corporate homepage. The vast acres of white space feel relaxing and unexpected on a government web property, but the scrolling you have to do around alphagov gets annoying quickly (especially with an odd horizontal scrolling bug I get in Firefox). Sure, people scroll, but they scan too and needless scrolling makes it harder to make those snap judgements and orient yourself on landing pages.

4. So many content types, so few civil servants

With an all-star cast of developers and content folks, a subset of content, and a blank technology slate on which to build it all, it’s nice that Alphagov has built content pages that look and work differently from each other: from bank holidays to reporting a stolen car. Directgov and Business Link pages all look drearily similar, but then they’re trying to be a platform that civil servants across government can use to publish content on a huge range of topics. Quite possibly, too many, and with too much uniformity.

But at production scale, and with more normal people behind the keyboard, there surely needs to be a manageable range of template types which are used to publish content, or else the simple task of updating and maintaining the site content will become unjustifiably laborious, right?

5. Terse like a road sign

One of the more subtle but important parts of the Alphagov project has been the content strategy and editorial work done. Directgov and Business Link turned impenetrable jargon into tautological blurb, which helped, but not much. Alphagov cuts out unnecessary words, emphasises what’s important and gets you to dates, facts, rules etc quicker. Thank heavens for that.

Except, terseness isn’t all you want. Take the page on whether you need a car seat for your child: it’s clear and definitive. But there’s nowhere to go to find out more, to see pictures of what these types of seats look like in shops, or to find help from your local council on finding a seat that fits your car and show you how (mine has a great service to do just that). It’s a topic crying out for pictures, how-to videos, related links. And I suspect that if you’re wondering about maternity leave, there’s more you’d find useful than these two undefined bullet points.

Cut the pointless words, fine, but don’t lose the opportunity the web affords to enable visitors to drill down if they want to, and link off to more helpful stuff on the same topic.

…On which note: that’s it for part of 1 of What Alphagov Does Wrong. Tune in for part 2 shortly… 😉

Update: Part 2 is now up

Get notified of new blog posts by email

#

May 18, 2011

Comments

Re: Content types and terse like a signpost

Alphagov tries to demonstrate that not all content is equal, and so can and should be treated differently – as a content type, and by design and visual cues. But yes, in production, it’s important to not bewilder content producers or end users. with an excess.

Similarly, many user’s needs can be answered in a ‘to the point’ fashion -with a table of rates or a set of bullet points, rather than expecting users to wade through a lot of information. But signposts to related and deeper content are, of course, important. I hope future iterations will experiment with leveraging metadata and concepts of relatedness to provide the experience that Steph suggests. One idea might to be make linkages between content for citizens, businesses and professionals

Taking this post in a slightly skewed direction, I’d like to pose that websites are like cars.

Even with all the automated production, it still takes hard yakka to produce something excellent. Then, there’s no planning for personal preference. And most importantly, both depreciate like billy-o as soon as they are launched.

Is this post an indication that the shine is already wearing off Alphagov? That user expectations have moved on quicker than developers can hit keys? Is it just the nature of the beast that today’s Alphagov becomes tomorrow’s Directgov?

Well, no, because Alphagov is a proof-of-concept. Not a launched service.

But the debate about development still stands in the sense that one of the questions this project needs to answer is whether an ‘agile’ approach to development can work with something of the scale and importance of THE government web platform?

Where sites like Alphagov ought not to suffer depreciation is by being built never to be finished. You keep bringing it back to the shop to tune. Regularly. After every lap, even.

But can that approach to building and sustaining a single government web platform work in this environment once the weight of managers, public users, content, politics and history get added on?

Maybe. If the single government web platform that sprouts where Alphagov was does manage it, it will be a true game-changer. Achieving Mini rather than DeLorean status.

At present it’s not clear where it all goes from here.

That depends entirely on the context. I don’t think a best man’s speech that runs: “He drinks, used to shag her sister, but is actually all right” would exactly have them rolling in the aisles.

Re: accessibility You make good points, but the team certainly do “get it” which shows in the quality of their code. As you say it’s a lot better than found elsewhere. It could be said that putting the POUR principles of accessibility (perceivable; operable; understandable; robust) was difficult in an alpha prototype. E.g. was there enough time to design new (and innovative) interfaces accessible to every concievable input method in the time allowed? That would have been very very tough.

In the end they took an uncomfortable, but brave and understandable approach. The proof will be in the pudding as the saying goes.

You’ll know better than most that accessibility is a spectrum not a benchmark. My point really was that – while Alphagov’s accessibility at a technical level is actually pretty good, and probably baked into the front-end coding habits of the team – in hindsight, it wasn’t a great idea to give the impression that “we’ve decided not to try and be accessible for this alpha”. It made the team sound like they think accessibility itself is a bolt-on, when in fact, they know and demonstrated that it isn’t (but fiddling to meet an arbitrary accessibility level checklist would be).

Digital inclusion & digital engagement

ConsultationXML goes open source

The Coalition: what now for digital?