To recap, the concept of open sourcing government is essentially about allowing third parties (citizens, companies, non-profits, etc.,) direct access via APIs to government data, so:

that individuals, communities and businesses are able to interact with government web applications in ways that are useful to them.
5 principles for Govt 2.0

The UK Cabinet Office released a report in June last year that looked at what this would mean for their public management system. The economic impact alone, as the report makes clear, had the potential to make a significant contribution:

2006 figures from the Office of Fair Trading that estimate that improved availability of information to re-users could double the direct market value of public sector information to £1.1 billion per year.
The value of government information

The Princeton paper authors, however, seem to be going some way further, calling for the US federal government to reduce the role it plays in presenting online information to citizens. The authors argue that the key role for federal agencies should be opening up their data, rather than building websites that provide a platform (and by inference, not a particularly good one) and a filter for people to access the information.

Their premise is an attractive one. That government

should focus on creating a simple, reliable and publicly accessible infrastructure that “exposes” the underlying data. [... The Government should] require that federal websites themselves use the same open systems for accessing the underlying data as they make available to the public at large.
Government Data and the Invisible Hand, p1.

Effectively, this means that government agencies could focus their attention (and taxpayer dollars) on the quality and accessibility of the information, and not on the presentation level. It’s a compelling proposition, particularly when you consider the current state of the namespace (in any jurisdiction, really).

The authors argue that the market, in the form of these third parties developing applications that reuse the government data, will drive economies of innovation and accessibility that are beyond anything that government itself could hope to provide. They list some of these advanced features:

• advanced search
• RSS feeds
• links to information sources
• mashups with other data sources
• discussion forums and wikis
• data visualization
• automated content and topic analysis
• collaborative filtering and crowdsourcing analysis

It is worth pointing out that some of these advanced features are already part of the namespace here; albeit with mixed success. Advanced search, RSS feeds, and wikis are all essential elements of the .govt.nz space.

There are a couple of concerns that I have. The authors acknowledge that in some case there will be no private actor willing to step forward and create a compelling website based on the data. The notion that government makes all information accessible, irrespective of it’s apparent value, is a fundamental one. Abrogating that responsibility to third parties seems fraught with potential to disadvantage some sections of the community. Mike W leaves a comprehensive comment to this effect on Ed Felten’s blog (one of the authors of the paper).

As an aside, ensuring that people can access a government data set via a visualization (like EveryBlock, for example) using a screenreader can be done, but it is hard work…

More of a concern, however, is the notion that we can either continue to try to build usable websites or simply outsource innovation in the namespace. I don’t see, as the authors apparently do, that the two are mutually exclusive. Indeed, there is an argument that government should retain and build more capability for innovation, rather than adopt practices that would encourage this sort of activity to atrophy.

Those concerns aside, however, what the authors of the paper are proposing is both an effective and efficient approach to transformed government. We should be seriously considering the same here in New Zealand.

Photo: kool_skatcat

Despite the evidence and regular predictions about the central role that mobile devices will play in the future of the web, public sector agencies (most of them anyway) have yet to recognize this and build or adapt their existing sites to accomodate these users.

One obvious reason is that public sector agencies’ investment cycles are a lot longer than twelve months and that we will start to see mobile-friendly sites developed increasingly over then next 36 months. That may be the case, but it points at what I believe is the fundamental problem with the .govt.nz domain space: that the management of government websites is mostly considered to be a technical function.

These are not, however, technical issues. The technology has been developed, is already widely used and understood. It is a question of business managers understanding how they can use these tools to better achieve their outcomes.

One possibility

Let me give you an example. We know that the telephone is New Zealander’s preferred means of interacting with government. We also know that it is the channel that causes the most grief for customers (and hence materially impacts upon the agency’s customer satisfaction ratings).

Yet how many government websites offer real-time interaction via the web, using instant messaging, for example? None that I am aware of (happy to be contradicted, point to examples in the comments).

Think about the advantages. You still have people in the ‘holding pattern,’ waiting to interact with a human being, but staff can see the nature of the query/complaint and make a judgement about moving it up or down in the queue.

You can also track contact drop outs against the logged query/complaint and garner much more data about the effectiveness of the interactions, because it can all be stored and – more importantly, given the volume of data we are talking about, searched.

Now to really add public value, you could have the customer service representative tag the data as it is entered during the exchange, for example applying microformats to describe attributes like location and time, which would effectively create a rich dataset for the agency — and for any enterprising third parties, much like Adrian Holovaty’s EveryBlock.

The solution

The first couple of aspects of the scenario above are pedestrian in both conception and execution. The notion of introducing semantics to the process has the potential to transform the agency’s interaction with its publics.

As I suggested above, the lack of coordinated and strategic development of the namespace is because what are essentially communications issues are decided by technologists.

A small part of the solution is wresting back control of the way our agencies interact with their publics; the greater challenge is to understand the technology sufficiently to effectively engage with management and the technologists in these discussions. Otherwise we will be doomed to keep arriving just in time for the ribbon cutting…

Photo: Waponi

This week saw another incremental shift as I published the first of these social media releases (SMR) with commenting enabled. Most of you will no doubt be wondering why I have buried the lead (SSC has a blog?), but I figure that there are plenty of other capable people to spread the word.

In any event, IABC has now taken up the leadership of the Social Media Release and, as I will continue to contribute a public sector perspective to the process, I thought that it might be helpful to share some observations about the the impact for SSC of issuing semantic media releases over the past 12 months.

How effective is it?

Naturally, it depends upon where you draw the bottom line: media pick-up, comments, saves to social sites, there are any number of valid approaches to the issue. In most of these cases, however, these releases would have to be judged abject failures.

Another way of making the same point: at the launch I was chatting with a journalist, and I asked him if there was any value in the SMR for him. He stared blankly back. Figuring that I was talking passed him, I tried a more practical tack. Was he finding the del.icio.us links helpful? The reply? What’s delicious?.

Now that doesn’t mean that the del.icio.us links are a waste of time. There are currently six people who have at least a passing interest in what is being bookmarked, it just so happens that none of them work in the local media…

On the other hand, a couple of hours after the portal launch SMR went out, I issued this traditional release about changes to the ICT branch. The result? See for yourself.

Is it worth the candle?

Marking up your releases semantically does impose an overhead. Is that a justified use of resource? I would argue yes. Journalists here may be slow to pick up on the new format, but with every release, you are making an investment in the future capability of the namespace.

If all government news releases were marked up using this format, the newzealand.govt.nz search tool could return search results for all news items restricted to a certain geographic area, or about specific topics, within timeframes etc. These results could in turn be parsed into news feeds for local or topic specific sites (including those outside the .govt.nz domain), thus creating far more public value than an individual agency release buried on its site.

Another point that I have made in the past is that public sector communicators can’t afford to think of metrics solely in terms of media. They are a primary audience, but we have a responsibility to ensure that these news releases are discoverable and accessible by the widest possible constituency.

Conclusion

Whether or not hRelease makes it to a draft microformat stage is really an academic issue for me. I will continue to mark up the releases as semantically as possible and to argue for others to do the same. Yes, you should cover the basics and write sharp, factual and informative news releases. The question you should also be asking yourself is, why don’t I spend at least as much time ensuring that the release is as well crafted semantically as it is grammatically. That just is the reality of communicating in the age of the Internet.

Of course, this is not limited to the public sector but, given our obligation to make information available and to keep it available as outlined in the Policy for Government Held Information, we are in a particularly invidious position.

One of the obvious ways to address this content crush is tagging. However, I can’t help feel that this is only part of the answer to the problem or, less optimistically, at best a short term solution.

With only 600 odd items in my delicious account, I already feel a sense of dread at the cognitive overload when I look through my list of tags trying to locate a page saved a couple of months ago. Looking at Hamish’s bookmarks renders me dumb with equal parts awe and despair.

The Answer

As I suggested in 5 Principles for Govt 2.0, the answer is Search. Or, in Jon Udell’s far more elegant phrase,

we’re in the midst of a long transition from container-based to query-based storage and retrieval
Tagging and Foldering.

An important point to qualify here is that the term long transition shouldn’t be taken to imply a process that is either leisurely or painless; in government, we can rest assured it will be neither.

I should also point out that, for the government namespace, the demand side search issue has already been solved. The new search on newzealand.govt.nz is frighteningly good (if you are a content owner in this namespace, just search your domain and you will see why it is frightening — everything you have posted in now surfacable).

As an example, when I wanted to pull up the Government Held Information Policy, I searched the SSC site using the, what I thought, obvious terms: “government held information” “policy framework” and finally (I am a lazy typist) I went for the whole phrase. Result? Nothing on the first page of the three searches. An advanced search on newzealand.govt.nz, using the phrase “government held information” restricted to “ssc.govt.nz” and, bingo! straight there.

Supply Side Search

The real issue for government is not the search tool. It is preparing the content for search — making it discoverable. This is where we will have to reinvent business processes and essentially apply a new model to the creation and publication of government held information.

However, until we have XML editors installed across government, and we continue to rely on the thoroughly broken model of trying to convert Word documents to valid HTML, then we will need to pay far more attention to these supply side techniques.

So, in the meantime, we need to focus on:

• semantic markup
• seo
• folksonomies, and last but most importantly
• validate your pages.

All these techniques will address the symptoms, but to get to the heart of the issue will require a more fundamental and profound change.

Conclusion

The exponential growth in the amount of content on government websites should be viewed as an opportunity to transform the namespace by creating social and economic value. There isn’t much point talking about the long tail if it is squashed under a fat rump of poorly marked up, irrelevant and dated or superseded content…

Photo: singleframe.

Before you begin downloading, installing and customising, take a look at the principles for public sector social media, these will give you a pretty good overview of the operating framework for any social media platform in government.

The blog

I am an unabashed fan of WordPress. Why? Firstly, because it is open source. The philosophy of open source software is, I believe, a natural fit for the public sector. It also has an amazing support network, and an array of functionality that is without equal. And it is dead simple to setup and run.

You will need to install it on a server: the current version requires PHP version 4.2 or greater and MySQL version 4.0 or greater. Talk to your IT people about what you are currently running, or are paying a provider for.

Support tools

The basics

Once you have installed it you, or someone you contract, will need to theme it, ie., give it an appropriate look and feel. Even if you don’t do this yourself, you will want, from time-to-time, to tweak the way the site looks, and this is where these tools will come in handy.

If possible, run Firefox as your web browser. Not only because it renders pages accurately, but because – like WordPress – there are a range of incredibly useful tools that have been developed for it, including a few that will make working with your theme so much easier. Firebug and the Web Developer Toolbar are two extensions that I would recommend you install to help you run your blog effectively and to the requisite web standards.

If all this is starting to sound like too much hard work, it’s not really. While it is not necessary to understand HTML as WordPress has a solid wysiwyg editor, if you are interested in social media then it would be a good idea to get your head around it.

As well as the basics, you will also require a little more social functionality:

• a web statistic package, like AW Stats
• an RSS feed statistics analyzer
• Plugins for subscriptions, tagging and bookmarking (I use subscribe2, simpletags and sociable, respectively)

For the monster list of WordPress plugins, see this Mashable post: WordPress God.

Images

You should think about the judicious use of images in your posts: they definitely can add to the post and will make the blog a lot more approachable and usable (particularly for those who read your posts via RSS).

You will need some sort of image editing software to resize, crop and/or tidy up your images. I use Photoshop, but apparently the GIMP is just as good (and free).

Networking tools

Of course, running a blog is not just about posting to your pre-determined schedule. It is just as much about the way you interact with other bloggers and commenters in your niche. Track other blogs that are also in your field of interest, leave comments and post in response to their posts: be part of the conversation. To do this, you will need some of these tools.

RSS

Without RSS, you are doomed. It’s that simple. You will need an RSS aggregator (either a desktop client or a web-based one like Google Reader) to track blogs and to follow comments. Yes, you could do it all through laboriously visiting each site in your Favourites, but you would be clinically insane after a couple of weeks…

Collect feeds of all the blogs that you read or monitor, search results from the various blog search tools that help you track what is being said about your agency and you can access it all from one interface. Genius.

Comment tracking

You also need a tool to keep track of the comments you leave on other blogs. Again, you don’t want to have to keep randomly returning to the post page to see if anyone has responded to one of your comments. Tools like co.mments make it easy for you to follow all your comments from one spot. Naturally, you can subscribe to a feed from your account page so this just shows up in your RSS reader as well.

Bookmarking

I have posted before about the importance of social bookmarking tools like del.icio.us for public affairs and these tools are equally as important when you begin to blog. Not just for syndicating links to your blog, but for tracking how your posts are being bookmarked by others. Open an account and start bookmarking your posts, this allows you to discover more about your readers and their content preferences.

SEO

Public sector communicators often overlook the importance of search engine optimisation, probably because in the .govt.nz namespace we are already pulling quite hefty page ranks. There are, however, some techniques that you may want to consider to ensure that your posts are well indexed and easily discoverable. There are also some pitfalls you may want to avoid.

Conclusion

This should get you started. I am sure there is stuff that I have missed — feel free to add your suggestions in the comments. What this should give you is a (hopefully not too daunting) feel for exactly what is involved in running a public sector blog. As I have said before, the easiest way to tackle this is incrementally; launch it as an internal tool, iron out all the bugs and then you will be ready to take it to the world.

Photo: eshm

The review proposes a simple vision:

that citizens, consumers and government can create, reuse and distribute information in ways that add maximum value.
p.20

The authors then go on to propose a three point strategy to enable government to make the most of the opportunities afforded by unlocking its information. They suggest government:

• welcomes and engages with users and operators of user-generated sites in pursuit of common social and economic objectives;
• supplies potential re-users with the public sector information they, when they need it, in a way that maximizes the long-term benefits for all citizens; and
• protects the public interest by preparing citizens for a world of plentiful (and sometimes unreliable) information, and helps excluded groups take advantage.

In the post on the principles of Govt 2.0, I discussed the importance of this practice, ‘open sourcing government.’ But before we (here in New Zealand, or any other jurisdictions for that matter) are in a position to transform the .govt.nz namespace into one that actively encourages this sort of value transfer, we need to look at how we are making the information available in the first place.

Data web

The use and re-use of government information is predicated on the ability to find the right information at the right time, and for it to be made available in a way that enables people and/or machines to access and, where necessary, manipulate it. The review has an interesting counter example of this:

‘I got in touch with the Stern report team, because I wanted to republish it in a format that people could easily read and discuss on the internet. I couldn’t make the person at the other end of the phone line understand why I didn’t want the report in 600 page PDF format. So I said I wanted to be able to read it on my phone. He told me to get a better phone.’
p. 19

The irony of this review only being available as a PDF aside, this anecdote illustrates a classic public sector myopia around the publishing process: “We’ve put it on the web, we’re done.” When what is really called for is a vision of the publishing process as a value chain that begins when agency information is being marked up for publication.

However, this requires a revolution in the thinking that we bring to the management of government information. Everything that we publish becomes viewed as a potential resource for the public and private sectors to consume, syndicate, mashup and reinvent for social and economic benefit.

A local example is Statistics New Zealand, who have just launched a programme to make their data available to businesses.

The Cabinet Office review cites 2006 figures from the Office of Fair Trading that estimate that improved availability of information to re-users could double the direct market value of public sector information to £1.1 billion per year (another pdf).

Unlocking some of this value is the challenge before us. Microformats and semantic markup in general are a good first step, and another compelling reason why public sector communicators should be familiar with HTML. It is our job to describe and champion this value chain within our agencies.

Conclusion

Mor Naaman, in his post The Emerging-Semantics Web (”The Semantic Web is Dead”), points out that most people will be unwilling to mark their pages up semantically therefore what we will see emerge is a ‘bottom-up’ semantic web built from lightweight solutions like microformats and Flickr machine tags. This is probably the case, and a good reminder that web standards are not an end in themselves.

It should also remind us that as public servants we have an additional responsibility to ensure that the information that we publish – in addition to being accessible by all – can be re-used by people and businesses to generate social and economic value.

Photo: dltq

The first thing that occurred to me as I began writing the post was that there isn’t much point trying to optimize your pages for search engine spiders unless they are also optimized for all the other User agents, ie., web browsers, handheld devices, screen readers, content aggregators and syndicators etc. In short, SEO is a subset of a wider field of optimization, and an understanding of web standards, particularly HTML, should precede that conversation.

This got me thinking about the level of understanding of HTML among public relations/affairs professionals. After all, it is our job to advise our employers or clients on how to best communicate using the various channels that use the Internet, so surely we should have at least a basic understanding of these media?

Maybe not. Two things happened this week that left me thinking that perhaps this is a naive or overly simplistic view…

First, I was in an agency presentation where a web development company were pitching to redevelop one of our websites. At one point, they showed us a slide where all the acronyms on the page were highlighted (this being a government site, they reasoned, you would want people to be able to understand the acronyms: fair point). However, when I asked how they intended to do this, they said with some javascript. I asked why they wouldn’t just use the acronym element? And, honestly, they just stared blankly at me. They had no idea what I was talking about.

Here is a hint. If you are presenting yourself as a subject matter expert, at least cover the basics.

Then a couple of days later, I saw that another social media release had been put out, and judging by the case study, it was a success. Which is great. However, if you view the source of the release, you will see that the quality of the HTML is, well, quite poor. Invalid, no doctype, full of deprecated markup and meaningless classes.

Why does this matter? The release looks fine in most browsers and none of the other bloggers of media seem to be complaining about the quality (or lack thereof) of the HTML.

It matters because if you are a practitioner of public affairs/relations and you are working in the online space, how can you claim to be a professional if you don’t understand the basic language of the medium? Would you employ a builder that couldn’t read the architect’s drawings?

It matters because valid, semantic markup is accessible to both people and machines. It is optimised for search engines, for browsers and for people, irrespective of how they choose to access or repurpose that information. That is presumably what the author of the case study was aiming for when he said:

So we opted to make the announcement as an SMR, optimizing it’s format for maximum success.
Geoff Livingstone

I don’t want to be overly critical, because I think that it is terrific that people are experimenting with the social media release. Indeed, compared to some of the earlier SMRs that I have looked at, this one is a marked improvement. What I do find amazing is that so much of what communicators are trying to achieve on the Internet is done without consideration of the standards that support this medium.

So, if we are going to have a microformatted social media release, hRelease, then we can start by issuing releases that are valid (x)HTML. Validation is not an end in itself, but it is a pretty good indicator of a disciplined approach, and if we want to be considered professionals, isn’t that something we should all aim for?

Conclusion

If you are going to specialize in online communications or public relations (in the public or private sectors), then you owe it to yourself, you agency and your clients to – as a minimum – be familiar with the HTML 4.01 and XHTML 1.0 specifications. The HTML 4.01 spec was published eight years ago: have you read it? Do you think you should?

[Media release for the Standards, again microformatted]

Fortunately – unless you have a burning desire – you don’t have to read the whole document. You can just use the audience page to read the sections that are relevant to your role type.

I would, however, recommend that you do read as much of the material as possible. The Internet is increasingly important as a delivery tool for content both in terms of government strategic direction and communications/public affairs practice. Understanding how the web works (and why standards are so important) is no different to understanding the printing process, or the media cycle. It is just part of our job.

If the whole web standards thing just leaves you cold, ask yourself this question: would it be considered acceptable to build a government office that had no wheelchair access? Or that was constructed from materials that were known to be of inferior quality? Or only allowed access to the wealthiest and those with the newest technologies?

Websites are no different. Taxpayers are paying for us to build them, so every New Zealander who wants to access the information or services on those sites should be able to do so. Irrespective of their physical location (and available bandwidth) and the technology they are using (assistive or otherwise).

This fundamental right to access is non-negotiable.

How did they fare? Poorly.

When I opened MSN the first thing I saw was a warning:

Additional plugins are required to display all media on this page. Install missing plugins now…

That is a great start: do I want to install something else onto my machine just to view your content? I don’t think so. As a consequence, a significant part of my screen was blank, so I can’t really give you an accurate assessment of the content that they are providing for their visitors — at least those that have the requisite plugins installed.

Both MSN and Yahoo!Xtra weigh in at a hefty page size: 364KB and 354KB, respectively. That means that for Kiwis accessing these pages using dialup, they are in for a wait of around 90 seconds for the pages to load. A minute and a half to load: make it my homepage? Sure, what else am I going to do with my time?

This is particularly ironic given Yahoo is partnering Telecom on this venture. As we have recently seen, New Zealander’s access to broadband is not a given.

Following my look at mobile access to government sites, I decided to put these portals to the same test. Surely the big corporates are far more aware of this stuff than the public sector and will be much better positioned to deliver content over the phone (especially when you consider how much Telecom have to gain)? In a word, no.

Neither had skip links, and both served up big irrelevant images. Yahoo! acknowledged this was a problem by including a message that told me:

Please upgrade to a more recent browser: Internet Explorer 7, FireFox 2 or Safari 1.2

My message back to them: Please upgrade to a more user-centric approach to web development.

I will, however, acknowledge that at least Yahoo! offers RSS feeds from their portal, which increases the utility of the site, sort of.

Conclusions

Looking at both sites really made me ask myself one question: why would you bother? If you want a portal, customise your Google homepage and build your own (you can even set it up to work on your phone).

These two offerings are for people who don’t understand the web, have incredibly low expectations about what sites should be delivering and have no physical or technological handicaps. Anyone else taken either for a spin and come up as disappointed?

Rather than just comment from the sidelines, I thought I would prepare and publish a media release as a hRelease, the proposed microformat for the social media release. I hesitate to call this a social media release because –being a government release– it doesn’t look like the templates that have been proposed. However, under the hood, it is very much an attempt (albeit preemptive — hRelease has not yet made it to ‘draft’ status yet) to publish a semantically enhanced media release.

So here it is: just off the shelf, the first New Zealand government hRelease: SSC signs all-of-govt deal for Google boxes.

The real departure from the examples that are already in the wild (one, two and three) is the detail in the markup. If you view the source of these pages, you will see that the content is just jammed into (for the most part) a ratmangle of nested tables, font tags and other cruft that severely undermines the principles of microformatting content in the first place.

Yes, the content should be usable by humans first. For public sector communicators, that means everyone. People using text readers because of vision impairments or people on 28k dialup in Taihape. The content should also be usable by machines, hence the microformatting. Publish it once at the authoritative source (your agency) and ensure that it can be syndicated and reused by whoever chooses to do so with minimum effort.

The Markup

I have tried to use existing microfomat properties and work from the elements for hRelease as outlined by Chris Heuer. It was also a given that the page would validate. The best way to see this is to look at the code:

1. <div class="hrelease">
2. <h2 class="headline"> SSC signs all...
3. <abbr class="dtreleased" title="20070227">February 27, 2007</abbr></span
4. <p>The <span class="fn org">State Services Commission</span> today...

You can see how the content is marked up so as to make it semantically rich. The heading is given the class headline, the agency is marked as "fn org", full name organisation etc, all of which makes the whole document much more usable — for people and for machines. This is critical for search. You could, for example only spider for hrelease results, or for contact details vcard. So within the hRelease, I have added my contact details as an hCard:

1. <p><div class="vcard">Contact:
2. <span class="fn">Jason Ryan</span><br / >
3. <span class="tel">
4. <span class="type">DDI</span>:
5. <span class="value">04 495 2850</span>...

Not only is this format more accessible to people and machines, it is actually usable. There is a Firefox extension that allows you to click on microformatted information in web pages and it will initiate application sequences. So, in the case of hCard, clicking on the microformat will open your address book (in Thunderbird or Outlook, say) and you can save all the information then and there. Geo formatted information will open Google Maps and show you exactly where the place or event is, hCalendar will open your calendar application and allow you to save the event. Pure genius. This functionality will be fully integrated into Firefox 3.

From here on in it gets a bit more opaque, so I should note that the rest of the markup is provisional only, until hRelease makes it to draft and some of the properties are specified.

I wanted to add resources, in this case an image, del.icio.us links and Technorati tags. I dropped the first two into a <div class="links">. A property for the image had already been described in the hCard spec, so that saved some improvisation.

The tags were another matter. I created a <div class="tags"> (I know, crazy eh?) on a best-guess basis, but I am happy to consider alternatives.

That is about the extent of it. Have a look at the release and, bearing in mind that it is a work in progress, let me know where I went wrong. Or just tell me if you think all the extra markup is a complete waste of time…

Updated 22/7/07

After reading this post from the Web Standards Group on the accessibility issues around abbreviations in microformats, I have reworked the code for the most recent e-government hRelease (on new search for newzealand.govt.nz). The dateline now looks like this:

1. <h3 class="dateline"><span class="dtreleased" title="20070717">July 17, 2007</span></h3>

While, not an ideal solution, it does make it more accessible for people using assistive technologies.