Cast your mind back if you will to chilly February, amid the growing crescendo/death spiral of pre-election communications. Neil and his team were finishing off the new corporate website, having shunned friends and family for weekends on end. A member of the senior management team came bounding back from a cross government meeting where they had been shown this, and, in a nutshell, they wanted one too.

The brief was helpfully loose: make it easier for the media to access the information they needed via simple link in the bottom of a press notice, without generating a load of extra work for Press Officers. From the Digital team’s perspective, we wanted to increase visibility of our YouTube and Flickr content for media, ensuring that these channels get promoted in every news release. Oh, and the kicker: make something technology independent, that could survive the imminent move from WordPress to SiteCore, without incurring external costs. So we set out to develop something based largely in client-side technologies (i.e. Javascript and CSS) which usefully aggregated corporate announcements, multimedia output and press office contacts for mainstream media and bloggers in a single place – frankly, more of a technical and design challenge than a strategic one, but a fun one nonetheless.

There were half a dozen or so information sources to play with*:

• Press Releases, ministerial speeches (RSS feed)
• Tweets from corporate accounts (RSS feeds)
• Videos on YouTube (RSS feed with multimedia enclosures)
• Flickr photos (API)
• Podcasts on SoundCloud (added by the team later, again, RSS feed)
• Contact details for Press Officers & key facts on policies (static text)
• Email alerts for media to sign up to via GovDelivery

*We also had a plan to add a couple of extras which were built but not yet used. Case studies published elsewhere online were to be tagged using a corporate Delicious account and imported into the newsroom using the RSS feed for the tag. Urgent statements or rebuttals put out by a Press Officer out of hours sometimes aren’t issued as Press Notices in the normal way, so we set up a private Tumblr site to which these could be emailed, which could be embedded or imported into the Newsroom, again via RSS.

The primary tool in our arsenal was the wonderous Feed2JS, which takes an RSS feed and gives you a snippet of Javascript to embed which will render it for you in HTML. It’s free and awesome (and you can even self-host it if you want). This little tool helps single-handedly render the majority of the Newsroom content, the code snippet tweaked slightly to ensure the <noscript> alternative ensures the site degrades fairly gracefully for non-Javascript enabled browsers.

I also developed a couple of code snippets to render the content of a Flickr account or set as an RSS, HTML or Javascript snippet, and likewise with YouTube – feel free to grab the code from those links if that kind of thing is of use to you.

• Version 0.1 (click the image to enlarge) was a good proof of concept, built in an empty page template on our old WordPress site. But there was too much to take in for a notoriously lazy audience.
• Version 0.2 was an improvement, splitting the content into more manageable chunks with a natty Apple-style navigation bar and some concertina sections done in Javascript – but it still felt hard to differentiate the content types on the page
• Version 0.3 was almost there, introducing some nice little icons for the different content types, using CSS to help visually distinguish the lists, and losing the unnecessary mission statement with some DOM-rewriting to save valuable pixels for this audience. And then we moved to SiteCore and purdah struck, so…
• …Version 1.0, which you can now see in all its glory transferred the code into a new CMS and migrated across a stylesheet. The team added SoundCloud podcasts using its RSS feed, in the same way as the other media types.

Early feedback on the prototype from journalists was positive, the Press Office got a nice-looking tool which required literally zero additional work beyond emailing over their contact list, and Neil got one of his much-loved quick wins – and within SiteCore too. Props for this one to Rhys and Ian in the BIS Digital Communications team.

Photo credit: Victoria Peckham

Related posts:

1. A Load of Cobblers: my tumblog on the favourite tools I use
2. Minding the shop
3. The Audacity of Growth

In the words of Directgov:

A public appointment is an appointment to the board of a public body or to a government committee. Around 18,500 men and women hold a public appointment.

The public bodies involved are quite important, including health trusts, museum boards and regulators, some demanding specialist skills in law or social work, but many requiring general common sense and broad experience. So it’s important that the people who fill these posts are of the right calibre and reflect the diversity of our society.

The Cabinet Office has recently revamped its Public Appointments system, and you can now sign up to sophisticated email alerts about public appointments vacancies you might be interested in. As a publisher of vacancies, the central system also has an excellent API, enabling you to extract data feeds from the vacancy database to republish on your own site. There’s even some RDFa in the output should you wish to use that to mark-up the vacancy descriptions.

I’ve just created and added a dead simple RSS feed for the BIS-related public appointments to our homepage. But anyone can grab the code and set it up to generate their own feed, or indeed re-publish the vacancy data far and wide in any format compliant with its licence, in order to help spread the word about the interesting and varied positions available.

Hurrah for open data and APIs, and above all, hurrah to the Cabinet Office for building one in this case. Thanks chaps.

Related posts:

1. Civil Service jobs, your way
2. Version 1.1
3. Hold the front page

Recently, I’ve been involved in a project to ensure our consultations support RDFa markup, to make them indexable and reusable by third parties, including Directgov. Without duplicating the quite accessible and useful COI guidance, I thought I’d summarise here the process involved from the perspective of implementing the standard with minimal prior knowledge of the whys and wherefores.

Why bother?

As of Jan 1st 2010, it’s now a mandatory requirement for government sites. But more importantly than that, it’s a Jolly Good Idea to provide a low-maintenance way of enabling other systems and services to grab a list of consultations from your site, and identify the important metadata about them, including the closing date and how to respond. Short term, it will make services like TellThemWhatYouThink and Directgov more useful, but in terms of the bigger picture, it will expose the opportunity to get involved with policymaking to a wider audience, and reduce the hassle for those who are already part of our regular stakeholder group (by making possible new services such as auto email alerts, RSS feeds, cross-government updates and so on).

What’s involved?

RDFa offers a simple way to add meaningful information to existing web pages, which can be extracted easily by software (as opposed to hit-and-miss ‘scraping’ of regular web pages). As a lay person, I’d say there are three key principles which I can articulate:

1. Be unobtrusive and minimalistic: taking this approach lets you add extra items to pages which aren’t seen by regular browsing visitors, but which are accessible to software robots looking for them. It’s also not ‘an extra thing’ to maintain and serve like an RSS feed, so reduces risk, in theory.
2. Offer clean data: through being consistent in how data about the consultation is described, the idea is that RDFa helps to extract very clean information about the consultation – for example, an unambiguous closing date, a response email address, an exact postcode, all in formats which can then be used in other ways (plotted on a map, listed on a calendar, turned into a mailform on a website etc)
3. Extend existing conventions: the most complicated aspect of implementing this particular specification is that the authors have gone out of their way to find existing wheels rather than reinvent their own. So they use Dublin Core metadata to describe authors and organisations; vCard to describe response contact information; plus nods to DBPedia and FOAF (Friend Of A Friend) to support these major semantic web initiatives. Only for the  gaps where specific consultation information needs to be marked up is there a new standard introduced, using the namespace (prefix) argot.

In a nutshell, the process involves tweaking the template for your consultation pages, adding extra metadata elements and attributes. This is only as easy or hard as your CMS makes it. It’s important that it’s right though – even a few ‘broken bits’ could render the page useless to a software robot trying to extract data from it.

How to do it

Read the COI guidance (and give it to your developer), which is the most comprehensive guide, with useful illustrated examples. There’s also a worked up HTML page showing how this works, and of course you’re welcome to look at ours (which I *think* are right, based on feedback from the gurus).

As an example (but again, you should read the official guidance) I found I needed to work through the following:

• ensure we have a single page per per consultation
• amend the DOCTYPE, if you’re using something like the standard XHTML strict/transitional version. Needs to tell requesters of the page that it contains RDFa
• add some attributes to the <html> element, highlighting the namespaces (vocabularies) you’re referencing in the document
• add Dublin Core metadata elements/attributes to your page <head> element if they’re not there already
• ensure we have a wrapper <div> around the consultation information which again references the namespaces (vocabularies) you’re using. This also identifies the name of the organisation publishing the document
• add some Dublin Core metadata attributes as <spans> within this <div> identifying this as a consultation
• add some Dublin Core attributes to key bits of the HTML, such as the consultation title, start date, closing date and description, marking these as such – and in the case of dates, ensuring there’s a machine-readable data format value in the attribute. Also add a unique identifier – a reference number – to each consultation (not something we’d done routinely before)
• ensure the contact details for responses is carefully structured using vCard format, with separate ‘Full Name’, ‘Street Address’, ‘Locality’ and ‘Post Code’ elements, suitably marked-up with attributes. Since vCard doesn’t cover the specific case of a consultation with an email reply address, for example, these elements are marked up with the new argot: namespace attributes
• add Dublin Core-based attributes describing the file attachments – the consultation document itself, and any related ones such as appendices or Impact Assessments

UPDATE: in retrospect, it was foolish to attempt a blog post about code without some code examples. I’ve tried and failed to find a half-decent code syntax highlighter plugin for WordPress, but the following couple of screenshots hopefully illustrate the before and after situations for the contact information part of a consultation:

Before, plain HTML:

After, with RDFa added (and marked up more semantically as a list item within the consultation metadata)

What help is available?

I worked from the examples given in the COI guidance and the pioneers in this at the Ministry of Justice. The COI Digigov team are your allies in helping to implement this, and should be able to answer queries and/or direct you to sources of further implementation advice and support.

In terms of online tools, you can see whether your RDFa is visible to suitably-equipped applications using Mark Birbeck’s tool or bookmarklet, if you prefer (and he should know; he invented RDFa).

Good luck!

P.S. If you Know About This Stuff and feel I’m giving duff advice here, please drop me a line in the comments or via the contact form and I’ll correct. Thanks.

Related posts:

1. What standards and legal requirements do government websites need to take account of?
2. Adventures in social consultation
3. Civil Service jobs, your way

A quick one – today at work we’re launching ‘Unleashing Aspiration’: the Government’s response to the review of access to the professions, which was led by Rt Hon Alan Milburn MP and reported last year.

The digital brief was, on the face of it, not massively exciting – it’s a long document, covering 88 recommendations, with a small but informed audience of policy, media and stakeholder visitors – many of whom will go through the whole document in detail almost however we publish it.

But this kind of document does set an interesting challenge for online presentation – it’s really as close as policy documents get to a faceted classification in information design terms, with responses to each recommendation organised by theme, by audience affected, and by the Departments who are leading on each – and with lots of embedded links to other initiatives. The policy team, though tight on resource, are interested in following the comment and discussion around each of the recommendations.

So it’s also a natural fit for WordPress, where the Themes are defined as WordPress categories, and we use WordPress tags to indicate audience and lead department. Commenting is built-in, as is the facility for tag and category descriptions, which provide a space for useful ‘virtual chapter’ overviews. By offering the ability to cut the document up in so many ways, it provides a variety of accessible entry points for different audiences, which is promising raw material for digital engagement outreach, for example to student communities or the third sector.

It’s not going to win any design awards – it’s intentionally quite neutral and clean with just some simple colour-coding – but I think it’s an unusual and potentially helpful approach to enable readers to get into a document of this kind through different routes. It’s also been a good training exercise for the team – props to Alistair Reid for getting his head around the anatomy of WordPress in barely a week, and doing rather more cut-and-paste than is strictly healthy.

Related posts:

1. Unpacking the world of digital in government
2. The Audacity of Growth
3. Government information in the 21st century

I was never a born project manager. I didn’t have the organisational skills, the discipline or indeed a sufficient dislike of my colleagues to want to inflict upon them the highlight reports, gantt charts and benefits realisation plans needed for Proper Projects. But in my fairly brief stint as formal Project Manager, I did have one knack, and that was getting on quite well with developers. I can only think that the reason for this was that I can relate to the work they do, have an idea of what is easy and what is hard, and respect the elegance of the craft – because I dabble in code myself.

My ears pricked up when Alistair pointed me to Mercedes Bunz of The Guardian asking: ‘Will journalists of the future need to know how to code?’:

Up until now, as a journalist you worked with information, researching facts and figures which then you passed on to the reader. However, in a digital world there are more platforms you can use to convey that information – think of maps or mobile applications, augmented reality. And to be able to do that you will have know how to code.

I think it’s an interesting thesis, even if the scenario of journalists learning Python to develop their own Google-esque apps is pretty hardcore. But I don’t think it just applies to journalists – almost regardless of your role, I think it’s worth learning a bit of code, especially if your academic training has been in hand-wavy social sciences like me.

1. It helps you think about how everyday processes work: there’s nothing like building your own applications to make you think  logically about how people behave online, and the hidden sophistication of seemingly simple systems like cash machines or website subscription services.
2. It’s good for your attention to detail and organisational skills: you can be sloppy about how you capitalise words or use punctuation in the real world, but the world of code makes you a more organised, consistent person (n.b. those who know me will laugh at this hubris)
3. It gives you an insight into why websites work the way they do, and why they break: as a webbie or even just a web user, coding for yourself helps you understand the anatomy of websites, the technologies which come together to deliver them, and gives you some explanations for why they’re ‘being a bit funny today’.
4. It lets you translate ideas into prototypes: talk is cheap, but if you can turn it into a prototype, you’re already a step ahead – and you can refine your thinking as you build it and get feedback on something tangible, rather than just a brainwave.
5. It opens up a new world of lifehacks you can build for yourself: whether it’s a way to backup your Twitter account or a to-do list application that actually reflects how you work, being able to write bits of code to save yourself time is neat.
6. It’s a social* thing: fifteen years ago, I was getting little applications on computer magazine cover disks, and receiving letters back from all over the world via the school register. Now, when I release code I get feedback instantly, along with help, suggestions and improvements, and feel part of something energetic and positive. (n.b. I say ‘social’, but not necessarily family friendly. I’m still squaring that circle
7. It’s creative and relaxing: I don’t actually get paid to code, so for me there’s something relaxing and challenging in sitting down of an evening to make a new tool or improve something.
8. It’s good for the career: maybe a bit obvious, but even a small amount of coding capability (real; not just puffed-up for CV purposes) helps you do your job, and get noticed for doing it, generally without antagonising your colleagues. Frankly, bosses like clever bits of digital innovation: it’s worked for me in pretty much every job I’ve ever had, particularly the non-digital ones.

It’s worth putting two caveats on that list of benefits:

1. Know your limits: the old cliche ‘a little knowledge is a dangerous thing’ is a double-edged sword when it comes to coding. If you believe it, then you’ll never start learning anything. But if you ignore it, you’ll find yourself in dangerous territory (exposed to hackers, losing friends’ data, costing yourself money etc). Strike a balance between the courage to learn, and the humility to ask for help or say you don’t know.
2. It’s a long way to the summit: ‘coding’ as I’m describing it here is a shorthand for knowledge of a whole range of technologies – all of which are changing over time – which you’ll find you want to develop at least some familiarity with. Of course, you can do some things with just a little practice and knowledge, but unless you focus very narrowly, I don’t think you ever reach a plateau of knowledge – there’s always an infinite amount more to know and potentially keep up with. You’ll be learning forever.

I hear the other side of it, of course: do what you’re good at, and leave the heavy lifting to the professionals, like you would car maintenance or central heating. I think that view gets too much unthinking acceptance, for the reasons above and more. Be proud to be a jack-of-all-trades, master-of-none, I say.

No related posts.

If there’s one thing Barack Obama taught us about the power of digital by the manner of his election, it’s that email still counts (and, for that matter, still works when you’re in government). For a while, I’ve been determined to focus more on how we use email as a corporate communication channel, particularly in the context of needing to justify why establishing new websites often isn’t a good idea.

We launched a project at work today that’s hopefully a step in the right direction: a kind of souped-up landing page for our new strategy for supporting economic growth, Going for Growth.

We’re probably not alone in having a few big policy themes which embrace a multitude of announcements, speeches and initiatives. The challenge for digital communications – well, for all communications, I suppose – is bringing these big themes out in ways our audiences can understand, and not losing the wood for the trees. Even on our own small interim site, thematic information is scattered across press releases, speeches and policy pages, making it hard to explain the drivers of policy, the history or the direction it’s going in.

This time, the initial request was for a new ‘portal’ but it quickly became clear that an aggregator would be a better fit for the content, audience and the commissioning team, who would be moving on to other things after delivery. So the page we built is designed to:

1. Collate the content about support for economic growth on our site in a single place, making it more easily accessible to media and stakeholders
2. Curate relevant content from other parts of government, demonstrating the cross-government nature of the policy, and hopefully engaging other government departments with communicating it in partnership with us (more later on that)
3. Explain the vision and origins of a somewhat abstract strategic policy, as well as the progress to date and the future direction in an accessible way
4. Engage audiences using channels which enable us to build up a community around this content

Our corporate site is WordPress-based (for now) but the page template itself is really little more than a shell. What’s interesting is what WordPress makes possible through its flexible RSS-with-everything approach and knock-yourself-out unrestricted approach to templating. But the interesting stuff happens elsewhere.

• The document itself is hosted on Scribd and embedded on a page, offering a pleasant browsing experience without the hassle of building a full HTML version. The PDF is of course downloadable too, for committed readers. There’s a video on YouTube (two in fact), press releases on NDS and the archive film of the livestreamed launch via Number 10′s provider. (And a bit of live tweeting around the launch itself, if you count that).
• We’re making liberal use of Feed2JS to help render an RSS feed as a list, comprising items across our site tagged in WordPress with ‘growth’.
• More interestingly perhaps, we’re using the social bookmarking service Delicious (as pioneered by Puffbox for the Governance of Britain site) to collect relevant announcements elsewhere in government via our corporate Delicious account, again tagged with ‘growth’. The RSS feed of these bookmarks then powers a little list on the page, enabling us to keep this content fresh easily, without needing to manually edit the page each time – it’s just a bookmarking job.
• In order to make better use of GovDelivery, a service we used previously just for powering email alerts to changed pages, we asked the team to set up one of their widgets – copying an idea done elegantly by the Highways Agency. These widgets offer a handy, embeddable version of items from an RSS feed (in our case, Piped-together) of Growth news from BIS and elsewhere, with built-in email subscription to topics from across our site. In principle then, these widgets offer a window into what Government is doing to support growth beyond a single Department and in a format which any Department or stakeholder could pick up and use for minimal effort. For instance, Number 10 kindly picked it up as part of their coverage of the launch:

The site was still put together, in-house (kudos for this project to Jenny, Michael, David and Rhys), fairly rapidly to meet a moving target, and there’s still plenty of work for us to do. The list of email subscriptions offered to you via the widget still needs tidying up; we still haven’t quite provided the killer resource for media that I’d hoped to I think; and though it’s less of a nightmare than an independent microsite to manage, it’s still likely to be headache to migrate across to a new CMS.

But we’ll keep tweaking, and with this low-cost patchwork of tools, hopefully we’ll nudge closer over time towards the goal of a truly engaging, useful and workable channel for policy news.

Related posts:

1. Version 1.1
2. Civil Service jobs, your way
3. A Load of Cobblers: my tumblog on the favourite tools I use

In my line of work, keeping track of the threads is half the battle. At work, we have (for now) three corporate sites, a sandbox, a development environment, and more. We have social media channels – some corporately-managed, many managed by external agencies in support of our campaigns – and an active stakeholder and media community who like to talk to us and about us, along with ten busy ministers.

We’re also expected to respond quickly to news stories which break in the media on the issues we cover, as well as be responsive to our colleagues in the Press Office, including helping them to monitor and evaluate the reach of their material online.

So ever since some nice chaps from the Foreign & Commonwealth Office blew me away with an internal dashboard they had developed for this purpose, I’ve been keen to set up something similar. Something which I can have open all day and which lets me see quickly if our sites are up, what’s hot on them right now, who’s sending us traffic, and what we’re putting out there in terms of news releases, tweets and multimedia.

I’ve stolen their idea pretty much wholesale, tweaked it slightly towards social media, and come up with this (click to open a larger version):

1. Site availability: we have Pingdom monitoring set up watching our various domains to measure their uptime, and this box uses its API to tell us what’s up and what’s down. Green is good.

2. Popular content: Google Analytics has a little-known API and the excellent GAPI PHP library to help you access it. In more or less real time, this box lists the top 30 pages on the site today. There’s a lot more to the API, which I might write about another time.

3. Top referers: if there’s a spike in traffic, chances are somebody important has linked to us – this shows a list of the top 20 referers today, again powered by Google Analytics.

4. Search engine keywords: More Google Analytics goodness, this shows the top 20 keywords people entered into Google recently which sent them to our site.

5. Custom Site Search keywords: Slightly squiffy this, as the Great Google haven’t quite sorted out their own technology, but in principle this shows the popular search terms people have used within our own site search (which is powered by a Google Custom Search, covering all our key domains).

6. News Releases we’ve issued: using the RSS feed of our news releases which we retrieve via COI’s News Distribution Service, this lets me keep track of what press releases have gone out recently, to help cross check against popular pages on the site and to help us know when to press the button on digital activity in support of them.

7. Social media output: powered by the RSS feed of our FriendFeed account plus some PHP jiggery-pokery, this is maybe the box I find most useful. At a glance I can see new YouTube videos we’ve posted (in red), Flickr sets (navy), and corporate tweets (gold). The aqua boxes show me what agencies are putting out there as part of our marketing campaigns.

8. Replies and mentions: it’s useful to see what people find re-tweetable and how they respond to tweets from @bisgovuk – this box runs off the RSS feed from a Twitter search.

9. News coverage: Not enough for full social media monitoring of course, but for those reports which do mention the Department by name, this RSS feed from Google News Search provides a helpful list, right next to the news releases which they often refer to.

10. Blog coverage: Often a surprisingly different focus from the mainstream media mentions, this box runs off an RSS feed of Google Blog Search results.

11. Our issues in the news: Believe it or not there’s a world beyond our doors, and this aggregated feed (a bundle of RSS feeds from sections of BBC News online relevant to our policy areas, gathered together and shared out again via Google Reader) helps me keep track of the big stories.

So there you are. I’ve been refining and tweaking it while I road test it over the last few weeks. It’s surprisingly simple (around 500 lines of PHP all told) but helps me get on with more interesting things while keeping half an eye on the shop I’m supposed to be minding. And there’s a hint of geek cool in there too. Whatever gets you through the day, eh?

n.b. This code was developed in my own time, using my own resources and information, and is not Crown Copyright. I’m happy to offer anyone who wants one (including my employer) a royalty-free, non-exclusive licence to use it, bearing in mind it’s early code and I can’t provide much in the way of support – for now, just leave a comment or drop me a line if you’d like a copy.

Related posts:

1. A Load of Cobblers: my tumblog on the favourite tools I use
2. Civil Service jobs, your way
3. Introducing inboxlistening: follow the online conversation by email

Just a quick one to flag for readers who get my stuff by RSS that I’ve got a parallel tumblog alongside this main blog, which I use to post up quick reviews of tools that I like for web work. I’ve called it A Load Of Cobblers, to celebrate the spirit and practice of cobbled-together webbery, made from many individual pieces.

I’ve just posted a few new bits and pieces on there:

• Feed2JS: a simple Javascript-based way to show an RSS feed on a site
• Page Saver: a Firefox plugin to take a screenshot of the whole page, not just the visible portion
• 7 favourite digital engagement tools: from my presentation at ConnectedGeneration back in September

There’s also stuff about the email newsletter software Campaign Monitor, Flash video players and how to get a feed of comments on your Flickr photos.

Coming up in the near future are likely to be snippets on Google Analytics’ API and the GAPI PHP library, the uptime service Pingdom, and Flickr open-source-licensed search tool, Compfight.

Related posts:

1. Not what ships are for
2. Newsroom: the backstory
3. Hold the front page

Photo credit: ilse

Last week, Stephen Hale wrote a great piece on how to say no to new websites in the nicest possible way. I quite agree with him, and his analysis that most of the time, people say ‘I want a new website’ when they really mean that they want their issue or campaign to be communicated effectively online.

So when yesterday, Social Media Today directed us to Build Channel, or why Microsites are a Bad Idea, I started wondering: what makes people ask for microsites in the first place?

There are a bunch of reasons, good and bad:

• Identity: people want their thing to have its own name online, with a nice URL to use in marketing, and its own distinctive look and feel – which may or may not be justified
• Measurability: they want to be able to tell how well their site works and get regular, good stats on traffic, referrers and search keywords for their project specifically
• Flexibility: they want more latitude than the normal corporate site allows, maybe using more space for video or displaying an RSS feed – and the corporate templates or CMS can’t handle it
• Distance: their thing is a partnership or an independent organisation and they want to show it’s at arms length from the mother ship
• Timing: it’s a short-term or urgent project, so it’s more cost-effective to set it up separately and take it down again afterwards than to make changes to the functionality and templates of a big platform
• SEO: (a rare one) people believe that a separate microsite will rank higher in search engines for the desired keywords or brand name
• Ego: (a rather more common one): people want to say ‘that’s mine’ and enter it for awards
• Hassle: getting it onto a corporate site can involve headaches, bureaucracy and compromise in many organisations; it’s easier to go it alone and build from scratch direct with an agency

I’ll put my hand up to setting up microsites for these reasons and others – and yet I also agree with the ‘build channel, not microsites’ logic. It’s self-evident that a big channel can send more traffic, be more cost-effective, and be a better long-term bet in terms of SEO and brand, if it’s an effective one.

So what makes an effective channel, and by implication, what does it need to offer to head off the calls for microsites?

• It’s not about strong corporate branding: or at least, it’s not about a rigid corporate visual identity across the site. Cbeebies, BBC Weather and BBC News manage to have some pretty radically different templates, but work within the umbrella channel brand. A good channel has a common purpose and personality, where the organisation’s style and proposition shows through the design and language of its various sites.

• It’s not about a monster CMS: I just don’t think a single CMS can ever quite stretch to cover all the needs a big organisation has – no, not even WordPress. So it’s better to choose the right tool for each job, using small (interoperable) parts, loosely joined with embedded code, APIs, RSS feeds or whatever it takes to link your content pages to your blogs, your email newsletter to your video hosting provider. More generally, a strong channel is integrated: with other corporate channels, with social media channels, with related and interesting content, and with other sources of evaluation. Flexible but specialised tools, well-integrated with each other is crucial to demonstrating why a new microsite is a second-best option: if you find yourself saying ‘it’s not possible to do that on our CMS’, then you’re fighting a battle you will (and probably deserve to) lose.
• It’s about stickiness: microsites build an audience from scratch, and generally try and keep them engaged for the length of the marketing campaign. That’s an expensive and inefficient way to do it. A good channel has segmented email lists and alerts, RSS feeds, good use of Twitter, good SEO, and strong partnerships within and beyond the organisation. It helps promote the new launch initially, and builds awareness and engagement with the organisation’s customers in related areas, and can sustain it for months or years, not just a few weeks.
• It’s about ownership: it’s human nature to want some control over the shop window, and to feel frustrated when your special project is forced into a standard template or told it can’t have the kind of functionality you see on blogs all over the web because the corporate site can’t do it. A strong channel gives internal clients a sense that they own their piece of the channel, and that within some sensible boundaries, it’s theirs to take in whatever direction they like.
• It’s about the package: it’s not enough to say ‘You have to’. There are good reasons why – with the limitations of big CMSes and the needs of individual projects – people want special functionality, custom templates or personalised analytics. The challenge for people like me then is to put together such a helpful, flexible, compelling package of design, functionality, promotion, integration and analytics that nobody in their right mind would want to go it alone and build a microsite. Because why would they?

Related posts:

1. What machines think people do: a basic primer on web analytics
2. Going where the people are
3. Hold the front page

In a previous life, I once wrote:

Fundamentally, evaluation should be about measuring performance objectively in order to make improvements:

• measuring: involves a process for collecting, recording and sharing data, perhaps from a number of sources, or of different types
• performance: how successful the activity has been, which means how well it met its objectives, budget and timeframe – including unintended outcomes or side-effects
• objectively: trying to overcome natural personal and psychological inclinations to look on the bright side, remember ‘peaks’ or anecdotes,and try to consider every aspect of the activity fairly and in proportion
• in order to make improvements: not just evaluating for its own sake, but with the aim of making it better in future, through refining techniques or developing individuals

Source: Connecting with Communities: a good practice guide to outreach, CLG (2006)

I still think there’s something in that definition, and it came to mind when someone challenged me to write an intro to web analytics – a field awash with data and trends where it’s more important than anywhere to ask yourself: why?

So why analyse?

Before you analyse, ask yourself two questions: What is my site for? and What do I want to achieve by analysing? The answer to the first question will help you work out what kind of measures are worth paying attention to; the latter will help you be clear on what the numbers really mean for you. It’s important, because analytics can help you do all kinds of things:

To track progress towards a goal. Web analytics can help you benchmark and track trends over time to see how your site is performing: if the purpose of your website is to sell things, how well are you doing that? If it’s to build a community, are people coming back? If it’s to build an easy-to-use web app, do people get beyond the front page? It’s an obvious point, but not all goals are the same, so Good for one site is Bad for another.

To compare approaches.Web analytics are all about comparisons. Analytics can help you see if site A or site B send you more traffic; whether a particular piece of link text works better or worse than the one you tried last month, and whether people are more interested in your blog posts on Kerry Katona or Kefalonia.

To assess the value of what you’re doing. Return on investment is a dirty phrase, but the bottom line is that analytics can give you some of the raw materials for a story about what you achieve for the effort and money you invest in your site. But it’s the story and the insight into why people visit and what they do when whey come that’s really interesting.

To kill failure. Some sites or sections or campaigns flop for one reason or another. Analytics can tell you which ones they are, so you can try something else instead.

What do analytics look like?

Broadly-defined, I’d say there are four main kinds of analytics:

1. Server side: these are based on the big log files stored by the server your website is hosted on, which adds a line each time a web browser requests something from it. It stores information about the machine address, the page or image requested, and what the requesting machine’s operating system and web browser is, all in a line something like:
   123.123.123.123 - - [26/Apr/2000:00:23:48 -0400] "GET /pics/wpaper.gif HTTP/1.0" 200 6248 "http://www.jafsoft.com/asctortf/" "Mozilla/4.05 (Macintosh; I; PPC)"
2. Client-side: these are stats collected using a service like Google Analytics or SpeedTrap, which uses a bit of javascript code in each page of a website to detect information about the page itself and the visitor’s machine. The tools are often able to provide quite a bit of detail – even sometimes providing ‘heat maps’ showing which parts of the page are most clicked on – but don’t record anything if the machine visiting the site has javascript turned off (and a few percent still do).
3. Trackers & counters: particularly on the social web, you’ll find lots of services which track how many times something has been played, favourited, commented on or clicked through to. From comments on YouTube videos, views of a Flickr photo to clicks on a shortened bit.ly link from Twitter, all of these provide help to answer the ‘how many?’ question
4. Panels & data-crunchers: some services can tell you how popular your site is without even asking you. Well, they claim to. Tools like Alexa track the websites visited by people who install a certain toolbar, or are paid to be members of a certain panel, while services like Hitwise use data from internet service providers to track which websites are visited by their customers – and fascinatingly, what the demographic and consumer profile is of those people. Whether these numbers mean anything depends a lot on the profile of their sample, and whether they reflect visitors to your site – if you’re a big consumer site, there’s a chance they will. At the very least, they’ll give you some comparisons in terms of rank order and traffic volumes for some of those kinds of sites.

What to look for

Trends: the absolute number of visitors or pages is usually less interesting than the trend over time. Are more people coming than last month? Are weekends always low, or is it something we did? Trends help you establish whether a change or campaign consistently has a positive or negative effect.

Journeys: when people come to your site, they move about. It’s a common fallacy to assume people visit the homepage, click on an item from the main menu, then an item from that page, then the next page, and then view your detailed page. But analytics often show the reality of people who land from a search engine deep within your site, unaware of your homepage. The journey tools within Google Analytics can help you spot where people give up and go elsewhere, so you can take action to make the journey smoother and keep the traffic (if that’s what your site’s about).

High & low stories: the high and low points can tell you some interesting stories in themselves – what made a particular blog post twice as popular as the norm? And was it bad timing or bad content maybe that made that other post sink like a stone?

Surprises: analytics are full of surprises, like the geographic origin of visitors (plenty of UK consumers read US sites, and vice versa), or the screen resolutions on which people are reading your site. Have a large cohort of iPhone readers browsing your site on a 320×480 screen? Consider tweaking your stylesheet.

What to look at

Hits v Pages v Visits v Uniques. A hit is request for a single part of a web page, like an image or a stylesheet – so isn’t a great measure, as a page with lots of pictures and associated files can have a lot of hits for very few actual people visiting. Pages is a better measure, more comparable to measures used in traditional media given the correlation with the number of times an advert is displayed, for example. A visit gets closer to the concept of ‘how many real people visited the website’, looking at the number of times someone came along to the site and viewed a set of pages in a single session. Finally, ‘unique visitors’ tries to de-duplicate visits from the same person or machine, to give a cleaner measure of the number of different people who came to the site. I generally find unique visitors the most valuable number, as it gives me a sense of the real human audience for the content.

Time on page. By seeing how long it takes, on average, for someone to move from page to page within your site, analytics work out the average time spent on each page and on the site as a whole per visit. It’s an interesting measure which can give you an indication of whether you content is properly being properly read or just skimmed. If your aim is engagement and your time-on-page is just a few seconds on average, there may be a problem – a longer time-on-page is generally thought better for most sites.

Bounces. A special case for visits are so called ‘bounces’ where a visitor visits only a single page on your site. Perhaps they come to the home page, realise you’re not for them, and click back to the Google search results. Or perhaps they land on the in-depth article they were looking for, and need to look no further. A lower bounce rate is generally thought better.

Conversions. Some of the more complex functionality in Google Analytics lets you define goals and ‘funnels’ to analyse how people move through your site towards a defined sales objective – maybe downloading a document, completing a multi-page form or clicking the ‘buy’ button.  Non-transactional government sites often don’t look as hard at this measure, but that’s not to say they shouldn’t. A lot of websites are created simply to look good or get lots of readers, but establishing some more stretching objectives like getting visitors to sign up to a newsletter, subscribe to an RSS feed or complete a form to join a ‘supporters’ scheme is more likely to show the value of the web longer-term in mobilising support and engagement from otherwise passing trade.

Referrers. Blimey, where did all those people come from? Referrer information tells you which site the visitor was on when they clicked on a link to your site. Looking at the list of sites which refer traffic to you can often open your eyes to unexpected organisations or individuals who found your content interesting and chose to link to you. ‘Direct entry’ generally means someone typed your URL in themselves or, in these days of desktop Twitter clients like TweetDeck, that they came to your site from a source outside of their main web browser. Many referrals are likely to come from search results pages which, in these days of Google dominance, are most useful in that they give you…

Keywords that people typed into the search engine in order to find the link to your site. These give you a sense of the popularity of different phrases used to describe your content, as well as some of the most amusing and surprising insights into your analytics – at time of writing this site, for example, is on the first page of results in Google for the phrase ‘sell stuff‘.

Browser stats. In making design choices about your site, browser stats can tell you what proportion of visitors used outdated browsers (such as Internet Explorer 6) and therefore do or don’t need catering for, as well as the screen resolutions they have, which can inform what kind of layout you go for – often very useful when combatting the oft-quoted stipulation that government sites need to work for the sizable minority of visitors on 800×600 browsers. They’re a minority, but they’re not as sizable as the folks browsing your postage stamp pages at 1600×1200.

Social stats

Social media tools and platforms introduce a new dynamic. On the whole, you don’t get the richness of traditional web analytics (though some platforms such as Ning let you plug in Google Analytics code if you pay a bit extra). But on the flip side, your analytics are much more public, which introduces its own interesting dynamics of ‘popular content’ and feeds the ego.

• Views of videos, pictures or presentations are probably the most straightforward, along with click throughs of link services like bit.ly (tip: take any bit.ly link e.g. http://bit.ly/3zfftT and add /info/ in the middle to see the public stats on that link – e.g. http://bit.ly/info/3zfftT). [UPDATE: And as Robin says in the comments below, it's worth mentioning the stats built into Feedburner, which lets you track the otherwise untrackable activities of people who come to your content via your RSS feed and never actually visit the site itself]
• Comments are the next notch up, showing who has engaged with the content to the extent of responding to it, e.g. @replying to a Tweet
• Shares in the form of bookmarks on services like Delicious, Digg or StumbleUpon or re-tweets on Twitter indicate people who liked or felt inspired to spread your content to their own networks or save it for later. Ditto for starring/favouriting items.
• Embeds and responses in the form of inbound links to your site (which you can pick up by searching for link:http://blog.helpfultechnology.com on Google or Google Blogsearch or using services like BackType) are maybe the highest form of engagement, where people are moved to respond – hopefully positively – to your content.

Measuring social media stats is both easy (they’re often public, and pretty straightforward) and hard (they’re spread over lots of sites, and can overlap or tell conflicting stories). Tools like PostRank (h/t Treepixie) are emerging to help disentangle the mess, and put these stats alongside your own site’s web analytics.

What analytics don’t tell you

With so much information, it’s easy to assume that’s the whole story, but of course it isn’t. Web analytics tell you what machines think people do, not why they do it, or even who they really are. Beware of treating one-off spikes and troughs as trends or significant patterns – maybe Google just tweaked their algorithm that day, or your site went down for an hour without you noticing. It’s also hard to assess the true extent of engagement from hard stats alone, and that’s often better done from a deeper sense of what people who come to your site say in the comments and do when they send you enquiries and feedback forms. Above all, be careful of attributing cause and effect to the stories you see in the stats: use the flexibility of stats to compare alternative approaches before deciding that you’ve been doing it wrong. See what norms you can glean from tools like Alexa or Hitwise if they’re appropriate to your audience, or informally from friends and colleagues if like me you operate on a smaller scale. And remember that stats can’t tell you much about the who and why – so consider using an old-fashioned visitor survey or subscriber questionnaire (or even just a blog post asking people to tell you a bit about themselves in the comments) to understand the visitor profile of your readers and what they want when they get there. More about that in another post, I suspect.

Congratulations for getting this far – you can be sure I’ll be watching the time on page carefully to see if you read it properly

Related posts:

1. Why do people want microsites?
2. Going where the people are
3. A Load of Cobblers: my tumblog on the favourite tools I use