I've been building websites for 18 years. Roughly half of that as a full-time civil servant; and a good chunk of the rest as a government specialist. I was Whitehall's full-time web worker; and for the first five years of my career, the management chain either didn't know or didn't care what I was doing. I took full advantage.
Over time, managers decided it was something they should probably take an interest in. So too did the management consultancies. Progress ground to a halt. These were the dark days of government web development. Getting things done from the inside was becoming impossible; so I moved outside, and soon found myself re-energised by the flourishing open source movement.
I began blogging in early 2006. I tried to offer opinions and insight on stuff I thought I knew a bit about - which, broadly speaking, was 'new media' (ha!) and its effect on the businesses of news and politics/government. I could see there was something genuinely exciting in this new technology, and this seemed as good a way as any for me to gain some experience with it.
By this point, I'd been in the web business for a decade. I had pretty clear ideas about what I thought worked, and what didn't. The blog wasn't intended as a campaign for cheaper, faster, better web development - but that's what I believed in, so it's no surprise to see it coming through time and again.
I wrote frankly about new government websites, new policy announcements and new staff appointments. And because nobody else was doing so, at all, my blog picked up a following. Some liked it: and I began to receive tip-offs, sometimes from remarkably senior levels of government. Some didn't like it: and well-meaning individuals would regularly take me aside for 'a quiet word', to say that so-and-so had read my piece about X and wasn't happy.
Of course, if that was meant to put me off, it had the opposite effect.
I began to feel an obligation to blog. Numerous times I found myself firing up the PC, well after midnight, to post about something I'd seen or heard. I owed it to - to what? My audience? The cause? It was academic. This was what I did. I monitored those RSS feeds, I crawled Hansard, I dug through lengthy PDFs so you didn't have to. Whoever you were.
I justified my occasional moaning from the sidelines - to myself at least - with the thought that I wasn't just highlighting problems; I was advocating a solution, based on transparency, engagement and open-source. But these were quite vague, nebulous concepts at the time... so I often chose, quite deliberately, to frame those principles in terms of one particular engagement channel (blogs) and one particular open-source project (WordPress). This absolutely wasn't to exclude other channels and other technologies: but I found that better and more useful conversations arose when we talked about specifics.
Now look where we are.
Government departments' profligate spending on websites has been eliminated. The main communication channel for this radical transformation of public services has been a blog - hosted on wordpress.com initially, soon to move to a centralised WordPress multisite install. It's all built on open source, using open standards, and all posted on Github. New code is pushed live daily.
So it's no wonder that the postings on Puffbox.com have slowed to a trickle. Although I can't take much credit for it, this is pretty much where I hoped we'd get to. I don't really need to make the case for it any more.
Can't help but mention the sites.usa.gov project being run by the US General Services Administration, offering 'a shared service to help agencies focus on creating great content rather than on building systems to deliver that content'. No charge initially, but looks likely in due course. And yes, of course it's running on WordPress.
By providing agencies with a content management tool that is up-to-date, supports open content, is secure, compliant and hosted, we can help government agencies meet the goals of the Digital Strategy: to enable the American people to access high-quality digital government information and services anywhere, anytime, on any device. You concentrate on carrying-out your mission and engaging with citizens, we do the infrastructure lift.
Can't argue with that. Nor would you expect me to, having advocated precisely such an approach for at least four years.
We're proud to announce that Facetious, a plugin we've been working on for quite some time, has now been released in the official WordPress repository. And we'd like to thank the UK taxpayer for his/her assistance in writing it.
We do a lot of work for government departments, and on several recent projects, there's been a requirement for an 'advanced' or 'faceted' search form. This allows you to search by post type, by keyword, by taxonomy, and by month - all together. You can see it on the Government Olympic Communication site, for example, where we let you search its video library (post type) by keyword, and/or theme, department, nation/region, video quality, or month of upload.
We did something similar for the Commission on Devolution in Wales; and it's a key feature of another site due to go live in the next month or so.
We're in good company, by the way: you'll see a very similar search form on GovUK's Inside Government pages, for example.
It became immediately obvious that we could write the code as a plugin, for instant reuse on any WordPress site. We called it Facetious, because it had the word 'facet' in it. And in keeping with our open source principles - not to mention the fact that the development work had been funded by government departments - we decided we would release it publicly in the official WordPress plugin repository.
Out of the box, it provides an enhanced 'search form' widget, which you can drop into any WordPress sidebar. If you want to add a customised form into your own post templates, we've made that easy too: it's all detailed in the plugin's readme file.
Facetious isn't a 'search engine' per se: it's just a simple way to construct complex multi-dimensional queries. The results are gathered using WordPress's built-in search function, which doesn't try to be anything too clever. If you're looking for smarter search results, you'll need a different plugin. (Maybe Relevanssi or something.)
Oh, there's one more thing.
Search URLs in WordPress are the platform's last unpretty 'permalink'. Nobody wants to see
?s=keyword in their address bar; and it isn't possible to cache query-string URLs using something like WP Super Cache. So we've created a new permalink structure for searches as part of Facetious, and your search URL now looks like
/search/keyword/ - or
/search/month/201302/keyword/whatever/category/uncategorized/. This will be applied to any search: not just those submitted via a Facetious form.
If you want to give it a try on your own WordPress site, just go to Plugins in the admin area, and search for it. If you're a developer, and you'd like to help us improve Facetious, it's also on Github. Pull requests welcome.
My thanks to Nick H, Nick S and Sara P for letting us experiment on their sites over the past few months: and to John Blackbourn, for doing such a fantastic job turning my hacky code into a plugin to be proud of.
Someone, somewhere is apparently interested in Puffbox's relationship with the Wales Office. Interested enough to dig beyond the lengthy blog posts I've written here on the subject. Interested enough to lodge an FOI request, asking for publication of all invoices and correspondence from May to December 2012.
The result was published this week on the Wales Office website - ironically enough, on the FOI Disclosure Log I built for them. It consists of 132 pages of painstakingly redacted emails - although given that Puffbox Ltd is one person, redaction doesn't exactly cover my tracks! - plus a single invoice, for £130 ex VAT, for a copywriting job.
Of course, I have no way of knowing who it was who lodged the request, or what he/she hoped to find. If you're reading this, please feel free to get in touch directly: I don't believe I have anything to hide.
There can be few more blatant symbols of internet-powered globalisation than the appearance of 'Black Friday' sales in the UK. Personally, I've never let concerns about cultural sustainability stop me saving a few quid. Two years ago I bought my first-generation iPad on Black Friday, saving £30 if I remember rightly: Apple are rarely generous with discounts, and it wasn't an opportunity I wanted to miss.
I've had a reluctant eye on Amazon's Kindle Fire for some time. I played with one in our local Tesco a while back, but wasn't immediately sold on its user interface. As time has gone on, it's become obvious that Amazon's market power would ensure it was a success. We're also starting to see it listed as a 'must work on' device in project briefs. But with Silk, its 'revolutionary cloud-accelerated web browser', it's yet another potential point of failure for your web design.
So when I saw it in a Black Friday sale for £99 as opposed to £129, I gave in and bought one on the company account. For testing purposes you understand. It arrived at the weekend.
The first thing to strike you isn't the size; it's the weight. Because it's that bit smaller than an iPad, you're expecting it to weigh a good bit less. But it doesn't. I haven't got the scales out, but it feels like it weighs the same as my iPad - and yet you're meant to hold it in one hand, not two. It's good and solid, though, and doesn't feel as plasticky as you fear it might, for (in my case) the sub-£100 price tag.
Instantly you're struck by the quality of the screen. It isn't jaw-dropping; but you can't help noticing that Amazon have chosen particularly lightweight fonts for the interface, showing off its increased resolution. The use of white-on-black doesn't do any harm there, either.
One of the Kindle's selling points is the fact that Amazon will configure it for you, before it arrives. I opted not to do that; I was intrigued to see the registration process, step by step. And it was a bit of a shock to be hit instantly by a screen demanding credit card details. Yes, it was possible to skip this step; but only until I went to the device's on-board App Store, and tried to download a (free) app. No go, until I signed up for one-click purchasing: which, of course, requires me to register a credit card. It felt aggressively commercial, probably too aggressive.
The App Store itself is a real disappointment. As an Android veteran, I knew the apps I wanted... and I found about half of them. I've managed to find the ones I really need: Twitter, Flipboard, TuneIn Radio, iPlayer, a couple of news apps. The remainder can probably be covered by the mobile interfaces of certain websites: but it's deeply frustrating when you know that Android-compatible apps are available, but you aren't permitted to have them.
And then there's Silk. All we ask from a web browser is that it renders HTML as you'd expect. Basics first, please, innovations later. But Silk has one glaring problem: web fonts. We've waited literally years for web browsers to catch up with font-face delivery of custom fonts; and just when you think it's safe to start using them, along comes the Kindle Fire.
It doesn't not handle web fonts: but it definitely seems to have a problem with fonts delivered from third-party sites such as Google Web Fonts or Typekit (confirmed in a tweet I received from the Typekit guys at the weekend). And whilst it might seem like a small thing, it can be enough to completely ruin a design you've painstakingly put together.
I think I expected something very different from the Kindle Fire. I thought I was buying an Android tablet, which happened to include an e-reader function. In fact, it's an e-reader which happens to run some tablet apps as a fortunate bi-product.
Nowhere is this more obvious than the main user interface. Turn on your Kindle Fire, and you're confronted not by an Android 'desktop', but an iTunes-esque coverflow interface which treats apps in the same way it treats books. As a usage metaphor, it's entirely reasonable for (the products formerly known as) albums or books, where in the offline world, you'd run your thumb along items on a shelf to find the one you want. But apps just don't work like that, never have, and never will.
It also lacks certain things that we'd probably expect a 'proper' tablet to include, such as a camera (or two). But the Kindle Fire just isn't a proper tablet... and it seems to go out of its way not to be. I've tried to use it as a 'proper' tablet like I've used my iPad for the past two years, and it's an unsatisfying experience. But maybe that's my mistake.
The Kindle Fire will succeed. For roughly a third the price of an iPad, you get a device that's maybe half as good, so it's not a bad deal. But it isn't great as a tablet; and although I'm no expert, I think I'd probably prefer to consume e-books on a 'proper' e-ink device, like a standard Kindle.
Someone close to me has asked for a tablet to call her own, as a Christmas present. It was nearly going to be a Kindle Fire. It won't be now.
Regular readers will know the pivotal role played by the Wales Office in recent gov-web history. In 2007, they took the then-radical step of moving their corporate web presence into an open-source web publishing platform, namely WordPress. Nobody died. A point was proven. From there, to Downing Street, to Defra, to Transport, to Health... etc etc.
We started out with two completely separate 'single site' installs: WordPress MU didn't seem quite stable enough. But since 2010, they've been running a WordPress 3.x multisite - containing both their English and Welsh language sites, archived copies of their complete pre-2010 content, and more recently, the (bilingual) Commission on Devolution in Wales site. All fairly modest in traffic terms, but punching far above their weight (and pricetag) in terms of functionality.
For some time, we've been trying to perusade the Wales Office team to change hosting provider. Getting any serious systems admin work done - including, I'm ashamed to admit, WordPress upgrades - was almost impossible with the legacy hosting company. The market price for hosting had crashed, but their hosting bill hadn't. And to be quite blunt, they were getting a minimal level of service.
Our first step, early this summer, was to liberate the DNS. As with a lot of websites, the domain name info was held by the hosting company. Two eggs in the one basket. By taking the DNS to a third party, it gave us the freedom to move the sites at a time of our choosing - and the hosting company couldn't really do anything about it. Would they have been deliberately obstructive? Probably not, no moreso than usual. But 'usual' was precisely why we wanted to move.
Step two was to buy some new hosting space. And courtesy of GCloud (v1), this part was unexpectedly straightforward. In CatN, we found a hosting provider offering an appropriate level of service, with the kind of access and support we expected, for a tiny fraction of the cost.
Step three was migration. Assisted by regular partner-in-crime John Blackbourn, we did a number of dry runs, zipping up the entire WordPress installation - database and uploaded files - and transferring it to its new home. Not as straightforward as it probably sounds, given the relative inaccessibility of the incumbent server... but we found a way. One or two rules may have been broken, at least in spirit, along the way. And I'm very glad I'm on an unlimited broadband contract.
Today was step four. We implemented a content freeze at 9am, migrated everything one last time.... and by lunchtime, we had everything up and running at CatN. At 2.30pm, the DNS changes began - some by us, some done on our behalf. (Thanks again to you-know-who-you-are.) With some having very low TTLs, we could see the changes starting to kick in almost immediately. With others, we had to wait an hour or two. But by 4 o'clock, it was done. And with the freeze unfrozen, there was even time for a new press release before going-home time.
No downtime, and no loss of data. Massive performance improvements, at massive cost savings. At long last, a fully up-to-date install. And best of all? If we hadn't told them we were doing it, I doubt they'd even have noticed it happening.
If you have any interest in the Directgov->GovUK transition, you are hereby ordered to make a cuppa and read this by veteran (sorry!) e-government blogger Alan Mather for a bit of historical perspective.
It's long but it's important. This isn't the first time a new unified government website has made big promises. Some things are different this time; much, though, isn't. 'Some will take what I say below as an attack on GDS,' he acknowledges; 'that's far from what it is, it's an attempt to look ahead and see what is coming that will trip it up and so allow action to be taken to avoid the trouble.'
In a post on the (then) Alphagov blog in April last year about design principles:
Given it has 3.5% UK market share and Microsoft are trying to persuade everyone to shift off it, we assumed IE6 is dead (actually, we were a tad ruder than that).
The blog post was illustrated by a photograph showing design principles scribbled on cards, and stuck around the room (which was in the old COI headquarters of Hercules House). See that 'IE6' one disappearing off the top? There's a very good reason why the photo is cropped precisely there. Clue: four letters, begins with F.
I think this is a well-intentioned mistake. Gov.uk is a clean slate, a rare opportunity to force people to upgrade, for their own good. GDS is a future-oriented operation, charged with leading a revolution in the delivery of public services. Oh - and cutting costs, too. Ask any web developer about the cost, in terms of both person hours and opportunity cost, of supporting IE6.
This effective endorsement of the continued use of an 11 year old browser is entirely contradictory to that mission. Sure, they'd take some flak for it. But it would be an opportunity to promote the message of 'Government’s preferred online security advice channel', GetSafeOnline, which states quite categorically: 'Always ensure that you are running the latest version of your chosen browser.'
I feel somewhat obliged to highlight the latest blog post by Stephen Hale, head of digital at the Dept of Health. As regular readers will know, Stephen switched the department's web publishing strategy over to WordPress just over a year ago, and he's written subsequently about the joy of making such a move.
The countdown is now well and truly 'on' for government's move to its new bespoke web platform: in less than a week, Directgov and BusinessLink will have been switched off. Government departments' corporate sites will make the transition over the next few months: initially as 'islands', but reaching a critical mass 'in around February', according to the Inside Inside Government blog. A post on another Health blog quoted a completion date of April - and that certainly tallies with conversations I've had.
All of which leaves Stephen in reflective mood.
In DH, since we switched our main content management tool for dh.gov.uk to WordPress, we’ve expanded the range of people who can publish DH content. We’ve been able to do this because it’s now dead easy for people to do it. WordPress removes complexity for the editor – form relates to function pretty well.
As a result the digital team spend much less time publishing than we once did, and less time training and supporting editors. So we are able to focus more of our effort on ambitious uses of digital for health and care, and our policy engagement work.
- which is exactly the message I have been pushing around Whitehall for several years. How great to see it reflected back on a *.gov.uk website.
Stephen's post closes:
I’m expecting [with] the publishing tools for the Inside Government bits of GOV.UK ... our editors won’t need a manual and a training course to do their jobs. From what I’ve seen, it’s looking good.
Is it just me, or is that a veiled threat?
Reported by the Telegraph today:
Those applying via computer or mobile phone for services ranging from tax credits, fishing licences and passports will be asked to choose from a list of familiar log-ins to prove their identity... Under the proposals, members of the public will be able to use log-ins from “trusted” organisations, chosen to appeal to as wide a demographic as possible, to access Government services grouped together on a single website called Gov.uk... A user logging onto the site by phone would be asked to choose to select from a logo from one of the trusted brands, such as Facebook.
Two days ago, on the blog of email newsletter service MailChimp:
[We were convinced] that adding social login buttons to our app were essential to improving our depressing failure rate... I was shocked to see that just 3.4% of the people that visited the login page actually used Facebook or Twitter to log in.
Even a 3.4% drop in failures is worth having them there, right? Maybe not... Do you want to have your users’ login credentials stored in a third-party service? Do you want your brand closely associated with other brands, over which you have no control? Do you want to add additional confusion about login methods on your app? Is it worth it? Nope, it’s not to us.
Of course, the MailChimp position is slightly undermined by the use, immediately below this very blog post, of 'Sign in with Facebook' and 'Sign in with Twitter' buttons on their comment form. They argue in the comment thread that commenting is a very different user scenario; and it's a view I have some sympathy with.