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.
The date for transition from Directgov to GovUK is fast approaching, and we now have a sight of the homepage which will greet visitors on opening day. And as GDS head of design Ben Terrett acknowledges, 'it’s significantly different from any of the other homepages we’ve released so far'.
Back in April last year, when a small group of people were starting to think about an alpha for GOV.UK, the expression “Google is the homepage” was coined... People often misunderstood this to mean we thought the homepage should look like Google. We compounded this problem by making the homepage look like Google.
A brief review of previous iterations shows just how deeply that thinking went. Note in particular the one with a Google Maps aerial photo being used as a zero-effort equivalent of Google's 'doodles'.
This isn't the only instance of 'inspiration → implementation' in the GovUK design, by the way. When Ben was appointed, he wrote on the GDS blog:
In many ways the problem is similar to problem [Jock] Kinnear [sic] and [Margaret] Calvert faced when designing the road signs in the 60′s. Kinnear and Calvert proposed one consistent system. One designed with the clarity of information as it’s [sic] goal. From then on Britain had a solution that became the definitive standard and was copied around the world... Sound familiar? Swap signage systems for websites. Swap vehicle traffic for online traffic. That’s a challenge no designer could resist.
Six months later, which typeface did they choose as the new design's base? (New) Transport, Margaret Calvert's digital-friendly update of said 1960s road sign work. Well, I suppose that's one way to meet said challenge. But I digress.
Instead of trying to emulate Google, they've switched to more of a signposting strategy - which looks more like (very) old-school Yahoo. (Or indeed, Directgov.) A bold decision, which almost feels like a backward step... but a decision based on evidence. It all leads to a fascinating conclusion, which Ben describes as follows.
The people who visit the homepage do so because they are lost. They’re not on the right page, and they’re not comfortable using search, so they go to the homepage to try and help them find what they’re looking for.
Or, if I might dare to paraphrase, your own on-site search isn't worth worrying too much about. If they're going to be comfortable doing with the concept of searching, they'll almost certainly have come to you from Google (65% of traffic) anyway. (All the more reason, I'd say, for using Google Custom Search or the paid-for Site Search.)
The move also coincides with the removal of one of my favourite features of previous iterations: search suggestions as you type. When done well, it's an invaluable navigation tool in itself: and in fact, I'm now finding myself expecting to be offered search suggestions, when I start typing into the Search box of any large-scale site.
But it may not be gone for good:
I look forward to reading that forthcoming blog post. (Update: now published.)
Rumours of the demise of RSS seem to come in waves. We're in the midst of another one just now, with moves by Twitter and Google (in the form of Feedburner) seemingly calling its future into question.
Before I began to bore everyone with the wonders of WordPress, I used to bore people with the wonders of RSS. In fact, it was WordPress's handling of RSS feeds which initially won my heart. Feeds are now so ingrained in my daily life, I don't even think about it any more. But the reality is, RSS reading (per se) didn't catch on.
That isn't so say that it's a dead technology though, far from it. Five years ago, I suggested Facebook 'might actually be the app which brings RSS to the masses'. Not too far off, as it turned out. I wonder how many people receive Facebook updates, or automated tweets, or email newsletters, which are really just renderings of an RSS feed?
And so to a little project I've been working on, in conjunction with leading Lib Dem blogger Mark Pack.
Its successor is the new Lib Dem Widget, a curated collection of current political content and links, which - like its predecessor - can be added to any website with a single line of code.
We pull in details of the latest party news item, the latest YouTube video, plus a collection of other interesting bits from around the web, and render it in a nicely style-guide-compliant 'skyscraper', which should drop seamlessly into any website sidebar. And yes, of course, it's (mostly) driven by RSS feeds.
You won't be surprised to learn we built it with WordPress: but it's a rather unusual use case. The widget runs as a theme, giving us easy access to:
- WP's built-in feed-fetching;
- its various caching options - including, but not limited to WP Super Cache; and
- its oEmbed calls, for easy inclusion of the YouTube clip.
In effect, it's the 'homepage' of a one-page site... but a site with no actual content of its own.
To give things a visual lift, we also 'code scrape' the various linked pages, looking for details of thumbnail images. Facebook's OpenGraph meta tags are now in fairly widespread use, so there's a healthy chance that we'll see an
og:image in the HTML header - and if so, we'll use that.
Writing code which will work on any website - regardless of sidebar width, existing CSS styles etc - has been quite a challenge. The markup ends up pretty ugly, with everything included 'inline', just to be sure. And even then, I'm not sure we've sorted out every possible use case... but that's what beta testing is there for.