Uncovering the meaning of Google Wave for publishers

Elsewhere on this blog are posts describing the Hack Day events that we hold here at the Guardian to encourage team members to try things outside of their normal working practice. In this post I will outline the second main program we have called DevLabs and, more specifically, some thoughts on Google Wave that came out of it.

(For more about Wave see Lisa van Gelder's overview on the Guardian's Technology blog)

Whereas on a Hack Day there are twenty four hours to attack the problem and the goal is a working demo, even if it is hanging together with duct tape, a DevLab is a more considered beast. The concept is similar, to examine something outside of the normal working scope, but the time-scales and outcomes are different.

The DevLab process is basically a simple one. A proposal is made to the departmental management team, in this case what is a Google Wave and how, if at all, is it relevant for us as a company. Once approved the developers are taken completely out of the standard development process for five days.

This period is to be spent on investigation. There is no requirement for a working product that can be released or even demoed. Rather the outcome is understanding, and for this understanding to be spread throughout the team.

A presentation is provided by the participants, during which there may be a demonstration and examples, but as stated above these need not be something which is useful for the company, but simply just to illustrate points.

Following this demonstration the other team members are invited to peer review the work. The best peer review, judged by the participants and by the departmental managers, receives half of the monetary grant awarded for the DevLab.

Why have a DevLab program? Really this is a cost effective way of having a research program and who better than those working on the site to investigate new technologies that may affect it. We understand the platform in a way that an external party would not.

These programs are not an investigation purely into the Wave for investigations sake, for example, but the participants should have in the back of their minds the Guardian throughout the investigation. And the result is the whole team moves forward. We may not use the outcomes immediately, but if we need that knowledge we have a starting point.

The first DevLab looked at Android development. As the Android now becomes more popular that knowledge becomes more and more relevant – it's not that we apply it every day, but when (if) the time comes we are prepared!

So what of the Google Wave

This is one of the most blogged and discussed things out there at the moment. Every angle has been dissected almost to exhaustion. What I'd like to add is some of the ways it may be of use to us as a publisher of online content.

Firstly, lets deal with the problems.

The first problem we have is browser compatibility. It's OK having all that frontend Wave technology but it won't work in IE6. Monday through Friday a site like ours will receive a higher than you'd imagine quantity of IE6 visitors. Any Wave like functionality added to guardian.co.uk would have to be able to be applied to older browsers.

The second big issue with using Wave in a publishing context is that of user permissions. Obviously Wave is in beta. And Wave is not intended in it's current form for a publishing model. However it is an open protocol so it is valid to examine how it may be used in contexts outside that of peer to peer communication.

Unless you have a Wave account you can't see a Wave. This seems obvious and valid until it is you consider the embed model. Waves can be embedded on any web page. This is a part of the Wave specification. So we can in effect stick a Wave right into the heart of guardian.co.uk. However unless you were signed into your Wave account you can't even see it. Only a blank page. There is the notion of public Waves. Type show:public into the Wave search box and a huge amount of Waves return. But I believe that you still need to be signed in to see these.

If you are signed in you can not only see it, but edit it also. So in effect we have instant publication – very exciting – but not very practical considering the media injunctions that get banded about these days!

An important idea at the forefront of contemporary online news is mutualization. It is possible to imagine a scenario whereby a Wave provides an implementation of this. Consider a breaking news story where many people can quickly update a Wave in real-time, in collaboration, with photos, documents etc. and this Wave can either (a) Just appear on the site as the content is added or (b) Go through a sub editing process first. But this editing is also in real-time, so the delay between event and report is incredibly short.

This is similar to Twitter reporting, but many times more powerful given the scope for longer and richer reporting.

These in the field reporters need not be in the direct employ of the guardian, they could be trusted sources, or a new tier of trusted commenter, like article commenting but on a new level – providing in page content as opposed to user comments.

This feels more powerful than the Twitter model – a more detailed stream. With some form of prioritisation rather than simply a fire-hose. Stream ordering is an interesting concept. Is it relevant or even desirable? Could users be ranked – top ranked users get their posts displayed accordingly – even if they are out of sequence? Is the sequence more important?

But, even with the addition of user roles, there are many problems that would need to be overcome – consider the, currently prescient, issue of legal take down. Given that the Wave allows playback how do you remove all instances of a legally challenged post? Given the nature of the Wave itself – an XML document residing on multiple servers that each have a list of actions stored alongside that allows the recreation of that document in linear sequence – how do you manage removal of the post? From all servers?

Given the current model this would seem to be impossible, consequently this provides a difficult challenge for a publishing company. Would subs have to censor virtually anything that may become subject to a legal challenge and if so could we in effect publish anything this way?

Perhaps, given the possibilities of running your own Wave servers, we would have our own , internal server, perhaps in the cloud, over which we would have complete control. This may even be necessary for scalability.

Guardian.co.uk gets upwards oft thirty million unique users a month, with several times that in pages views. If we had a publicly visible Wave providing commentary on a breaking story on our front page how would it stand up? Multiple contributors, each with their own 'home' Wave provider, syncing multiple posts. I have not seen much debate yet about how this model manages to keep all nodes up to date across high numbers of participants.

The extensibility of Wave provides other areas where GU content may be delivered. Robots that respond to posts could drag in relevant articles via the open platform. There could also be a PubSubHubbub model where Waves periodically request the latest news and provide a discussion tool around these. We've hacked together this kind of idea already which you can see in more detail here.

It is possible to imagine such a talkboard style forum in existence, perhaps with a local focus, latest headlines, user generated photographs and maps, comments, longer blog style posts and so on, creating a rich community platform.

Spam, group mails, other email specific uses are not yet defined. This may be a good thing – it perhaps would be correct to not think of Wave as email – to try and keep an open frame of mind when considering it's use. Something like the fiver would take on a new hue if it was a Wave!

But it is the case that ad targeting, group mail, trend tracking, SEO and so on will all need to be applicable for universal acceptance. These are the meat and potatoes of today's commercial web, and it's commercial forces that may drive acceptance of Wave in the longer term.

No one seems to have a succinct definition, and it's uses are potentially broader than simply a communication standard. Perhaps the Wave is best thought of as a new document type. This document lives on the Wave server and has a corresponding set of actions that generated it's current state. This document could be replicated, branched, delivered in a number of mediums, updating in real time all the time.

The uses of this document should not be confused with the Google Wave UI, which has issues discussed fully elsewhere. But a more specific goal will lead to better user interaction, focusing the power of the Wave onto these specific uses is perhaps the future model? Above and beyond simply an email / Twitter killer.

How we, and others, as a publishing house respond to this will certainly be very interesting. It is very early days as of yet, but the Wave may be a technology that embeds deeper into the fabric than Twitter, Facebook and so on ever could.

I hope this provides an overview of what we were trying to achieve in our DevLab. While we tried out as many aspects of the current Wave provision as we had time for, the most exciting outcome for me was the discussions that arose during the presentation, from techies, from product managers and so on. These many, differing, points of view really added to our collective understanding of where we might go with this in the future.