Archive for 'coi'
One of the most prominent WordPress installs in the UK is under new management: Nick Jones, formerly Director of Interactive Services at the (now doomed) COI, has been appointed Head of Digital for the (now merged) Downing Street / Cabinet Office operation. He replaces former Tory staffer Rishi Saha, who quit government for a PR job based in Dubai.
New Media Age reports:
As head of digital for the Prime Minister’s office and Cabinet Office, Jones will oversee all digital communications, including the Number 10 and Cabinet Office websites. He will also continue with his COI duties.
Both sites have, of course, been redesigned in the last 12 months: the former staying on WordPress, the latter moving to Drupal late last year. We've also had a number of WP-based microsites from the Cabinet Office crew. So they know their open source on that team, as does Nick, so there are grounds for optimism... although of course, the next six months will (in theory) see departments' independent web presences being run down, in favour of the (ahem) bespoke unified presence. But I don't want to prod that particular hornet's nest again quite yet.
It's interesting to see a civil servant taking up the role, following on from the political appointment of Rishi Saha: and given the imminent shake-up in government comms, not just online, it's unquestionably the right thing to do. We need someone in that position of key influence who understands government as a whole - not technology, not politics - and there's no questioning Nick's experience in that regard.
Good luck, Nick. It's a job which, publicly, can be more about limiting criticism than earning praise. But there's no more influential role in digital government. Use it well, sir.
There's a huge amount of information to digest in COI's 'Reporting on progress: government websites 2009-10', published this morning. It lists, for virtually every government department, an assessment of staff numbers, staff and non-staff spending, page views and unique users, and where available, outcomes of user surveys, and assessments of accessibility and standards compliance.
Inevitably, there are some scarily large numbers contained within. For example:
- BusinessLink, one of government's three super-sites, quotes a £35,000,000 spend on 'non-staff costs' - accounting for 27% of the total spend as outlined in the report.
- There's no hint of the super-sites approach leading to economies of scale. BusinessLink, Directgov and NHS Choices spent £4m, £5m and £6m respectively on 'design and build', way beyond the biggest-spending ministerial departments (FCO and DH).
- HMRC appears to have 111 people working at least half their time on its hmrc.gov.uk website, costing £7,500,000.
- Across all departments quoted in the report, we appear to be paying £23,840,000 per year for web hosting.
However, despite COI's best efforts, I'm still not convinced that the numbers are directly comparable. On hosting, for example, many departments quote £0 - but I'm pretty sure they're paying for it somewhere. I'm not aware of too many departmental sites built on Blogger, WordPress.com or Geocities.
Some of the most encouraging news comes from the customer satisfaction reports from certain sites - although it's a pity these numbers only cover half the departments in the study, with HMRC and BusinessLink being obvious omissions. The much-derided Transport Direct claims to have 1.2 million unique users in the average month, with a net customer satisfaction rate of +84%, scoring particularly highly for ease-of-use and design (!). DFID scores +79, Directgov scores +73, as does the MOD.
Other departments, sadly, don't fare so well. DWP and Transport both show negative numbers for net customer satisfaction: -8% and -1% respectively, with very high %s of people finding 'none of what I wanted'. I'm wondering if those measures are fair on them, though? - it seems odd with Transport Direct and (I'm guessing) JobCentrePlus, now a major part of Directgov, doing so well. And it must be a bit embarrassing for COI to rank so low in their own study, on an area where they are tasked with setting best practice (12% net satisfaction).
Like it or not, the raw traffic numbers are likely to be the main source of amusement. Predictably, the super-sites come top on all measures; but there's a suspiciously strong showing for The National Archives, whose opsi.gov.uk site appears to be claiming to have more than 1m unique users every month. Again, BusinessLink's numbers stand out, reporting much lower traffic levels than their fellow super-sites. There's also wide variety in the number of page views per visitor, and monthly visits per unique user, which might merit further investigation.
As with any dataset, it's a mixed picture. The biggest questions, I think, are over the £23m hosting bill - and that's unquestionably an understatement, when you consider the number of departments who quoted zero for hosting; and the value-for-money of BusinessLink.
But as with any dataset, there's a huge risk of misinterpretation of its contents - and I wouldn't necessarily guarantee that any of the above analysis is either true or fair. Data is good at asking questions, but rarely gives clear answers.
There's a press release from the Cabinet Office; but to be honest, I wouldn't bother with it.
Disclaimer: I do web stuff for lots of different bits of government. Many of the departments named above are past or present clients.
Out of the blue last week, I got a call from COI: was I available for an immediate, rapid turnaround WordPress job? I was a bit startled, and detail was lacking; but since this was precisely the kind of rapid-response thinking I've been trying to foster around WordPress for a couple of years, I couldn't really say no.
As it turned out, the project in question was the Coalition Programme for Government: and the mission was to build a commentable version of it, by the next morning. COI's initial proposal was to use Steph's Commentariat as a base; but given the document's structure, it didn't feel like a good fit. Plus to be honest, I knew I'd be more comfortable working with my own code, as opposed to unpicking Steph's - and time was too tight.
The theme came together fairly quickly, helped in no small part by the source document's fairly plain design - which I basically mimicked, with a couple of tweaks for better web usability. Extracting the text from the supplied PDF was excruciating, as you'd expect. But by the time I got to bed at about 2.30am, having barely left the keyboard since lunchtime, the site was ready, and my part of the work was basically done. It went live at 9:30 the next - well, technically the same - morning.
Now... I'm going to skip over the next bit, because I'm not the right person to tell the story. Suffice to say, people came in their many tens of thousands. And although measures had been taken to handle the expected load, the platform wasn't ready for quite that volume of interest.
But now, a couple of days older and wiser, the site has been re-enabled: and the comments are starting to come in. This in itself presents some interesting challenges: the document is, by its very nature, more party-political than most, and the comments will be too. The civil service's usual get-out clause - about the government being democratically elected, on the basis of its manifesto (singular) - doesn't really work this time. Thankfully, applying the moderation policy is someone else's problem.
Of course it'd be nicer if things had gone perfectly smoothly on launch day. To some extent, we've missed the boat in terms of the immediate wave of interest; but arguably, the comments might be more considered, with the benefit of a weekend to reflect and cool off. (Well, not 'cool off' given the mini-heatwave, but you know what I mean.)
And regardless of what went wrong, there's still a great story to tell, in terms of what went right. An interactive document, designed and coded from scratch, and delivered by bedtime. That's why we love WordPress.
The biggest surprise about the transition to the new coalition administration is how few surprises there actually were. A quick tour of the departmental websites reveals, for the most part, the exact same websites that were there before - albeit a little lighter on content, and with new faces in the About Us section. It's all gone commendably smoothly.
But one or two departments have taken advantage of the situation to revamp their web presences: and it's been our pleasure to assist with one of these already - with more, perhaps, to follow.
In the run-up to Polling Day, we were asked by COI to provide cover for any 'emergency' web building which might result from the arrival of a new administration. Steria provided a hosting environment, with WordPress MU pre-installed; and I worked with Zed1's Mike Little to develop a theme which could be deployed and managed centrally, ideally very rapidly - but still be easily customisable for each individual site which used it.
In the end, there weren't any major Machinery of Government changes which required it: but Defra recognised the opportunity, and are using it as a base on which to start rebuilding their corporate website. They've worked with Puffbox on a few WordPress-based microsites already this year, so it's familiar territory for them - and in truth, I think it's been coming for a while.
The theme is fairly plain, sober and generic: inevitably, given that we had literally no idea who might need to use it, or how. There's a rather nice homepage carousel, managed via the WP media library; a widget-ised sidebar and 'fat footer'; plus special page menus at the top and bottom. It makes for quite a nice little site: certainly enough to get things started.
But whilst the design itself might not win awards, the behind-the-scenes stuff is pretty smart. We've enabled WordPress's 'custom header' functionality on the theme: users simply need to create a graphic of predefined dimensions, upload it into WP, and it'll be used as a full-width banner across the top (with the search form and - optionally - department name overlaid). In Defra's case, they've gone for a fairly plain black logo on white; but it could have been a lot more creative if they'd wanted. When we've tried this in test, we've found it can produce quite dramatically different 'feels' to the theme.
And then there's the colour palette. The theme's style.css file avoids defining most of the colours used on the page. Instead, there's an options page in the WordPress backend, where you can enter the colours to be used for specific page elements: links, the 'blobs' in the sidebar and 'fat footer', and so on. These are saved in the database table of options for that specific blog only; and the custom CSS gets added to the top of each page as it gets generated. (It's effectively an evolution of the work I did for BIS on Science & Society, but it takes the concept to a whole new level, and opens up all sorts of possibilities.)
But of course, the most significant aspect is the centrally managed hosting environment, and the official recognition of WordPress as a suitable tool for the job. Precisely what I've been proposing on these pages for ages. And you know what? I think it actually worked.
I've seen a few ripples of excitement at the news that ABCe is to act 'as a sole third party to independently validate the figures generated by an audit of government websites, in the largest project of its kind to date', with 'COI [to] publish comprehensive figures on the cost quality and use of government websites by June 2010'. Not exactly a surprise though, as this was in the COI document on Improving Government Online, published in March.
The exciting part, I suppose, is the fact that the figures are to be published. I wonder how. If Sir Tim really is to lead a push to make government publish its raw data, wouldn't this make an excellent 'best practice example'?
I wrote the other week about 'the implications of free': how the widespread availability of high-quality technology changed the rules when it comes to project management. Another example struck me today, around COI's ongoing consultation on improving government websites.
There's a lengthy section on measuring website usage, with detailed proposals around the new requirement for website auditing, kicking in imminently with the aim of ensuring that 'the rules for measuring the number of Unique User/Browsers, Page Impressions, Visits and Visit Duration have been implemented correctly'. Government websites' data will be audited twice a year, at a minimum cost of £1,740 per audit.
So what's the alternative in the post-free world? How about a centrally managed, mandatory, open-source web analytics package - like Piwik?
- It wouldn't stop departments running their own analytics packages, if they so desired. Not that many would want or need to.
- Implementation of appropriate standards - statistical, technical, privacy, transparency, etc - could be guaranteed by experts at the centre.
- Lower overall cost: in terms of purchase, ongoing licensing & support, and of course, auditing.
- Freedom to tailor it to particular government requirements, if any.
I must say at this point, I've got no direct experience of Piwik myself: but the demo looks great, and it's used by people I respect - such as Sourceforge and MySociety (eg TheyWorkForYou). Plus, as TWFY demonstrates, you can use Piwik alongside other tracking methods: they seem to have two others on the page too. It's still at version 0.something, but they're pledging to hit v1.0 'in 2009'. (Actually, can any of the MySociety gang share their experiences?)
Instead, where will the COI guidance leave us? Website owners will face a financial penalty (admittedly a relatively modest one) if they aren't using a 2-star rated ABCe Associate Subscriber. And how many of these 'recommended' analytics tools are open source, do you think?
We need to increase the pace. We want to ensure that we continue to use the best possible solutions for public services at the best value for money; and that we pay a fair price for what we have to buy. We want to share and re-use what the taxpayer has already purchased across the public sector – not just to avoid paying twice, but to reduce risks and to drive common, joined up solutions to the common needs of government. We want to encourage innovation and innovators - inside Government by encouraging open source thinking, and outside Government by helping to develop a vibrant market. We want to give leadership to the IT industry and to the wider economy to benefit from the information we generate and the software we develop in Government.
I'd be grateful if COI would consider this as Puffbox Ltd's contribution to the consultation exercise. Thank you.
I'm in the early stages of spec'ing up a new site build. The client helpfully provided a wireframe sketch of the homepage, which included - deep breath - a news ticker. And for the first time in living memory, I haven't recoiled in horror. In fact, I'm quite happy to give it to them.
Previously, my response would have been to open up a cost-vs-benefit discussion. In my experience, people (arguably the less web-literate?) like to see tickers, but they don't actually ever use them. So is it worth me programming a function nobody really wants, just so you can pretend to be the BBC? Maybe, maybe not. Generally speaking, the ticker idea soon falls off the mockups.
Suddenly, any approach based on cost-benefit analyses goes out the window. The cost is virtually zero, so if there's any potential benefit to be derived from doing something, the test is passed. That doesn't mean we should throw everything at any given project; but it does mean we might as well drop it in, and see if it works.
For me, this is the challenge of the Open Source Era for big corporate clients like government. Procurement and project management processes have been built up to handle projects costing millions. We spend huge amounts of money ensuring that we don't waste all the money. But what if the cost of the job is zero, or something close to it?
This is why I'm bit perplexed by COI's new WordPress-based consultation on Improving Government Websites. There's a huge section on measuring costs: they're suggesting you might/should report an associated cost against each of nearly 200 activities. But how can you put a cost against something like (for example) RSS feeds in a WordPress build, when they're built-in, in numerous different ways, whether you like it or not?
The final version of COI's browser testing guidelines have emerged, and it's simply wonderful to see a shorter, tighter, more standards-centric document than the draft I reviewed back in September. In fact, looking down my bullet-list of specific recommended changes, all of them seem to have gone into the final document. Cool.
The revised document is based on the principle of a 'testing matrix', showing 'must test' and 'should test' for versions of each leading browser, on Windows, Mac and Linux. Effectively it's a direct lift from the BBC's Browser Support Standards document (which, for the record, I highlighted in my response). You're advised to review your matrix at every major website redevelopment, or at least every two years; and to publish your matrix on your site, within a 'help' or 'accessibility' section.
It includes a forceful statement in support of web standards in the very first paragraph, backed up by a full page on the subject (paras 17-24). But the 2% rule remains: 'Browsers used by 2% or more of your users must be tested, and any issues resolved', as does the insistence that you support Mac and Linux even if they don't reach the 2% threshold. (And thankfully, the contradictory references on this have been removed.) There's even a proper section on mobile devices - although I'd probably have made specific reference to the iPhone / iPod Touch; sadly though, nothing about games consoles.
And - hooray! - there's a black-and-white statement that things don't have to be pixel-perfect, killing off the draft's notion of 'semi-supported':
There may be minor differences in the way that the website is displayed. The intent is not that it should be pixel perfect across browsers, but that a user of a particular browser does not notice anything appears wrong.
Quite simply, the final version is just so much better than the original draft. It stands as a great example of the benefits of opening these things up to the wider community. Who's this Obama fella anyway?
Timely, given the release of Google Chrome, and the reopening of the Browser Wars: COI has just issued a consultation document, five months in gestation, on browser standards for public sector websites. Its 15 pages can essentially be boiled down to the following, based on an intriguing 2% rule of thumb:
17. Browsers used by 2% or more of your users must be supported.
18. Operating systems used by 2% or more of your users must be supported (although it rather undermines itself later on, demanding support for Mac and Linux).
19. The two most popular browsers on each supported operating system must be supported.
20. Browsers and operating systems used by less than 2% of your users may be semi-supported. This means that the content and navigation works but the website might not display correctly.
Like it or not then, we're obliged to ensure the content, functionality and display all work 'as intended' on IE6 - although there's no precise definition of what 'as intended' means. One would hope for a pragmatic (ie not 'pixel perfect') approach. And it sounds like bad news for Opera, whose user base is highly unlikely to pass the 2% threshold, or hold the no2 ranking on any one OS.
There's an all too predictable write-up in The Register; Andrew Orlowski opens with the statement that 'a firestorm is brewing', and quotes 'experts' who say 'taxpayers will be forced to change their browsing habits and computer setup to accommodate the guidelines.' I disagree with the first part, and I'm not sure I see the second as a bad thing. It's entirely appropriate for government to advise people on suitable behaviour where their body's health is concerned... why not also their PC?
Orlowski quotes Bruce Lawson of the Web Standards Project - and, as Orlowski neglects to point out, a Web Evangelist for Opera - who apparently said something along the lines of 'designers should conform to commonly agreed basic standards, rather than browser idiosyncrasies.' (Shame it's not a direct quote.)
Philosophically, I can't argue with that point. But pragmatically, it can't work. The browsers are here, on the ground already; and Utopia it ain't. You can't tell people unable to use your site with IE6 that 'hey, it's not our fault Microsoft didn't buy into web standards seven years ago.' And whilst the latest browser releases are getting closer to standards compliance, the current IE6 market share of 25% clearly shows (as does the 66% of people hitting COI's own site) that it'll take a l-o-n-g time for everyone to upgrade accordingly.
Deep down, I want COI to take a stand on IE6. As I wrote (coincidentally) the other week: development would undoubtedly be quicker, easier and most importantly, cheaper for the taxpayer. A friendly 'government health warning' could advise you to upgrade, for this and other good reasons. Others have already set the precedent. But I know such a brave step isn't likely.
If anyone from COI is reading this, please consider the following to be my contribution to the consultation process:
- There's an inherent problem with the 2% thing. You don't have to support a browser unless 2% of your own unique users are using it; but if the site doesn't support them, they won't be able to use the site anyway. Catch-2%, you might say. Whilst I see the value in the '2% of your specific user base' rule, it may have to be a global assessment of market share.
- Keep the geeks on board by including an explicit note about web standards, welcoming the progress towards better standards compliance... but acknowledging the reality of current usage levels, particularly as regards IE6.
- Terms like 'look as intended' or 'major/minor maintenance release' are too vague to be meaningful. Similarly, there are problems with the get-out clause for beta versions (para 27), especially now Google (with its perpetual betas) is in the game.
- There's no recognition of emerging scenarios like the iPhone or Nintendo Wii (over 1m sold in UK). I accept I may be an 'edge case' here, but as video becomes increasingly important to the web experience, I find myself using the Wii - and specifically, the big telly in the living room - to browse the web.
- You simply can't make an exception for Linux (para 32), or indeed the Mac (para 35). Either the 2% rule stands, or it doesn't. Grant one exception, and you'll have countless others making an equally strong case.
- If you're specifying operating systems, you might as well go the whole way, and specify particular browsers and versions. This isn't as impossible as it sounds: the BBC does it. There's a strong case for the simply 'contracting out' the testing process to the BBC, and adopting their rules as the gov-wide standard. They are subject to the same accessibility obligations as any government site.
I'm pinching myself. Wednesday, 08:30am: Justin Kerr-Stevens makes a request via OPSI's Public Sector Information Unlocking Service. A couple of dozen people sign up to say 'good idea'. A few people (me included) add some more substantial comments. Fast forward two days to Friday, 12:32pm: COI publishes details of RSS feeds for (virtually) every Cabinet-level government department.
I say 'virtually' every Cabinet-level department: the exceptions are the Scotland, Wales and Northern Ireland Offices. I can't see an RSS feed on the Scotland Office site; the NIO site's feed is curious to say the least, showing just one update since Christmas (which clearly isn't right). But the Wales Office is happily pumping out beautiful RSS. Puffbox and WordPress may have had something to do with that.
Update: I'm told they were on the site somewhere, just not obvious. Even knowing that now, I still can't find where they were. And if you can't find them, they might as well not be there. Next steps, please: an entry in the site's primary navigation, nicer URLs, and auto-discovery tags on each department's homepage.