Review: Google Wave An Experimental Ride

In view of my post yesterday, I thought that I would copy in this review of Google Wave from Tech web who abstracted it from Information Week - well worth a read in full.

To paraphrase Edwin Starr: Wave -- what is it good for?

The answer: A little of everything.

Almost nothing else Google has created has generated as much interest, and as much confusion, as Wave. Just describing it to others forces you to pick your words carefully -- it's not e-mail, or instant messaging, or a Web chat system, or a message board, or a collaborative-document system, but a hybrid of many features from all of those things.

"Experimental" is the most encompassing word for Wave, in the positive and negative senses of the word. Mitch Wagner believes Wave is one of Google's "concept car" creations -- a showcase for a slew of technologies that will eventually be repackaged in other forms. The most crucial being Wave's native protocol, which in theory can be implemented by anyone who wants to write a client or server for it.

In this article I'm going to walk through Wave as it embodies the aspects of a number of other things we should all be familiar with: e-mail, wikis, blogs, instant messaging, online collaboration apps, and many more. In some cases it substitutes quite ably for the item in question; sometimes, it's short of the mark (and not just because the other guy you want to involve in what you're doing doesn't yet have a Wave account).

E-mail 

If Wave has been described as any one thing, it's as an e-mail killer -- a way to take the inbox/message/threaded-discussion metaphor and push it into an entirely new realm. In many ways, at first glance, Wave does resemble an e-mail client of sorts: there's an inbox, there are folders, and the messages resemble e-mail messages organized into discussion threads.

These design analogies are probably quite deliberate. Most people have trouble working with something that presents absolutely no parallels to what they know and worth with -- and if there's one environment that even most non-technical people are familiar with, it's an e-mail client (be it Outlook or Google's own Gmail). Others have superficially compared Wave to "Microsoft Outlook / Lotus Notes on steroids," since Outlook (especially in conjunction with Microsoft Exchange) sports a great deal more than just mail: contact management, calendaring, note-taking, etc.

Because Wave is an invitation-only protocol -- at least in its current incarnation -- that makes it a good deal more secure than e-mail. Conversations are only possible among trusted peers. What's not present is a sense that Wave can be transitional -- e.g., you can't take your existing e-mail and slurp it up into Wave. Maybe this isn't so bad, since it further underscores the difference between the two, and since Wave itself is not at this time intended to eclipse other, more broadly accepted things.

Perhaps Google's stance with such things is that they will provide just enough API-level functionality to allow other people to mortar over those gaps. Example: a third-party bot allows people to be automatically notified by e-mail when changes are made to a given conversation. A good idea, but it's something that belongs in Wave by default -- especially this early on in Wave's evolution.


Discussion Boards 

Another commonplace metaphor Wave emulates is that of a threaded discussion board or USENET group. Unlike the former, though, all Wave discussions are inherently moderated to some degree: people can only participate in a discussion on your explicit invitation. Unlike the latter, though, simply having a Web browser isn't enough: the other person also needs to have a Wave account.

One thing Wave adds to the discussion-board metaphor that isn't available -- and which adds to many other aspects of using Wave, too -- is the "playback" command. With this, you can see how messages were added, changed, or deleted as if you were pressing the play / fast-forward / rewind buttons on a VCR or DVR. It's an interesting way to see how a given thread has evolved over time, and what directions the conversation may have taken.

Unfortunately, some other things common to message boards are just plain missing. You can't prune and graft message threads, for instance; the only thing remotely close to this is the ability to copy a given message into a whole new wave.

So, again, a lot of what Wave offers is a little too specific to its current incarnation to serve as a substitute for other services. But from what we've seen, the goal isn't so much to substitute for those things as to present analogs to them as ways to allow people to acclimate themselves to the Wave way of doing things.

Wikis / Note-Taking 

Another example of this kind of analogous functionality: the way a wave can be used, sort of, as a wiki. Not in the sense that Wave supports wiki-style formatting, but in the more general sense: as a freeform repository for information that can be updated quickly by all participants.

The biggest downside of using Wave as a wiki is the lack of versioning as we have come to know it in Wiki-land. I mentioned how the "replay" function works with conversations, and it has the same function -- and the same limitations -- when dealing with a conversation that's being used as a generic information store. There's no diff function, as one might find in even the most rudimentary wiki tools. The only way around this right now is to rope in tools from the outside (e.g., a Web site where you can cut and paste to perform a UNIX-like diff on the texts in question), but that defeats the point of using Wave in the first place, where all the tools should be right in front of you.

One thing Wave's formatting does bring to wiki-style information management is an inherent sense of organization to conversations about a given piece of material. Anyone who's attempted to participate in the "Talk" page for a Wikipedia article quickly understands how difficult it can be to follow or keep track of discussions, as the format for such things is an ad-hoc creation that is not really enforced by the wiki software itself. Wave discussions fall into their native format automatically, so both document and discussion are consistent.

Wave also allows multimedia (at least, a subset of common multimedia types) to be inserted directly into conversations. This allows for that much greater a breadth of material to be included, not just plain text or HTML. Note that some document types may be interpreted strangely within the context of a wave: a "classic" Word 97-2003 document, for instance, shows up with the proper icon, but a .DOCX or .ODF document shows up as a .ZIP archive. Experiment before you embed.

Instant Messaging 

Many people had plenty of experience with instant messaging even before things like Google Talk ever appeared, but between that and things like Facebook's chat function the concept of an in-browser instant messenger has become familiar territory. Wave isn't a substitute for other instant messaging apps -- e.g., AIM -- but more like a parallel venue for real-time discussion.

Like instant messaging, wave discussions are logged as they happen, and the other person's typing can register on your own screen in real time. Unlike instant messaging, though, you're not obliged to respond only to the last thing someone posted -- or, rather, you can comment contextually on previous posts without the conversation derailing itself. If you and your friends in the discussion have a habit of jumping around or engaging in several parallel discussions at once, using Wave to hold that kind of talk imposes order that would be next to impossible to find through a typical chat client.

...But What Is It, Really? 

When Wave first premiered, it was widely rumored that it would replace or eclipse any number of other, existing systems and services. E-mail, mainly: Wave has a high degree of built-in security, while e-mail is natively about as secure as sending a postcard written in pencil.

The more people were able to work with it, however, the clearer it became that Wave wasn't intended as a replacement for many things -- and now it's clear that it might not even be intended as an adjunct to them, either. Instead, it's entirely possible that Wave is being used as one of two things.

The first is the "concept car" analogy I mentioned earlier: it's a demonstration of a whole group of different Web 2.0 (and possibly Web 3.0) technologies that could be broken out on their own and put to use in any number of contexts.

The second is a little trickier: Wave is an extended experiment in application interaction -- a way to take many common user interface metaphors (e-mail, discussion groups, IMs, etc.) and re-implement them in new ways. Most of us are so familiar with the concept of e-mail that any thinking about the way it's put together tends to stop right there: there's an inbox, a spam trap, a list of unread messages, etc. Wave's ingenuity is in taking the outward metaphors of many things we take for granted and combining functionality among things that, on first glance, might not seem to play well with each other.

A programmer friend of mine described Wave as "a research project in human-computer interaction." It makes sense: by creating something a great many people will want to try out in an enthusiastic if also provisional way, Google can figure out which parts of the protocol -- both on the backend and in the implementation -- are worth developing, and which parts are best left as add-ons by third parties or discarded entirely. And Google's long made a name for itself as a company that creates things that are experimental by their very nature, with their years-long beta cycles.

Because Wave is so amorphous, many things are missing, and many of those omissions are almost certainly by design. One is a way to migrate to Wave -- for instance, a tool that would let you take your existing e-mail store and convert it into a set of Wave conversations. No such thing exists right now. Not just because no one's written it, but because Wave itself is a moving target, and so migrating to it would be pointless. The protocol could be nothing like what it is now by the time people other than Google start using it. (In theory one could build Wave servers that run in parallel to one's existing e-mail system, create gateways between the two, and then incrementally migrate the functionality of the latter into the former -- but again, why do that when you don't know what you're really migrating to in the first place?)

Another and far bigger issue: Right now, the only version of Wave is Google's Wave. If Wave is meant to be an open protocol that can be implemented by any number of people, either on the client or server side, it'll have to exist in multiple independent implementations before it can be considered any kind of protocol or platform to use in a production sense.

The last word on Wave for now would seem to be that it's aptly named. It's a moving target, and whatever its final incarnation -- if there is one -- it's likely to only resemble what we have now in the most distant way.

For Further Reading 

Is Wave A 'Concept Car' For Google?

Enterprise 2.0: Google Wave, A Solution Seeking A Problem?

Google Buys AppJet To Power Wave

The psychology of Google Wave and a sceptic won over

Innovation: The psychology of Google Wave - tech - 09 October 2009 - New Scientist

I was reading this article and then tweeted an article by Chris Brogan on how he had started to like Google Wave and was using it to help him on managing a project that he is working on with a colleague.

I also think that it would be useful to do a brain storm style exercise when the team are distributed throughout the organisation or for example when bad weather sets in (as I type this it has started to snow again)
 I think that this is probably what I'd want to use it for - however the major problem and I hope that Google sort it out is to allow people to use say their work e-mail addresses to use rather than if you aren't already signed up to a Google account.

It will be interesting to see if this forms part of the Google Apps Premier edition where as I see it you pay $50 a year or £33 in the UK. A colleague was telling me that her husbands company (Jaguar Land Rover and is advertised as a user on Googles site) has already signed up - a few teething difficulties but generally ok. Google Wave might be a useful add on as part of the collaborative element of the site especially for small businesses.

However what about the 600 pound gorilla companies with all their legacy systems - will they for example start to put pressure on Microsoft to develop something similar for Sharepoint 20XX. Or will frustrated people use skunk fund monies to sign up a few users because their IT department can't deliver. £33 isn't a lot.

I looked back through some of my old reader feeds and came upon the article in the New Scientist - not a publication given to hyperbole as I wondered how this might change the way we communicate if it was in wave format as I find that e-mail tends to be more formal an electronic version of memos that I used to send to my boss. My wife tends to say that some of my messages tend to be stream of consciousness which lends itself more to a Wave style conversation.

Two of the features of Wave that are likely to alter how people communicate are related to time: it allows users to see others typing live, even if they later delete that text; and a "replay" function plays back the complex tangle of interactions that produced a wave.

Past research has shown that the real-time, synchronous, nature of instant messaging (IM) encourages an informal tone, says Susan Herring, who researches the convergence of computer communication platforms at Indiana University in Bloomington. "It invokes face-to-face communication and encourages people to use conversational strategies," she explains.

Seeing live typing may accentuate that effect, but Wave can also be asynchronous, like email. "We won't see the difference between the two types of communication disappear," says Herring. "More elaborate messages are still possible, but when the other person is online you will be drawn to a more informal style." The pace and style of communicating with Wave will be more varied than with email.

The replay button I think can be useful as it gives you a way of seeing what the other correspondee was thinking about a little earlier and gives more of a sense of the conversation.

The problem that this article doesn't address is the culture of the organisation and whether it encourages more free wheeling conversation and whether in working in a project group you would address say the project leader in a more relaxed format.  I consider that people will tend to use the more relaxed style amongst their peers. I've found by experience and across cultures that people express more individual opinions and brainstorm more openly when a senior member of the team isn't present. I'd also find this useful if I was in a small informal community of practice and wanted a quick tool to work on a dialogue on an issue if I didn't have any internal forums that could be quickly set up.

If you have a number of you in the organisation and you have access to Google Wave why not try it on a small and relatively unimportant project either to project management or to brainstorm an issue and see how you find it.

Great questions at the end of a major project or bid

Thank you to Matthew Homann at the non billable hour for capturing some of the great questions that you should try to capture at the end of every project.

I have made some alterations in respect of my own experiences but direct quotes via Matthew are in italics. 

These are as follows:-

• What was the outcome of this project?
  
• What was good for our client about the outcome of this project?
• What were the areas of improvement for myself and the team
• What was the best part of the project? 
• What was the biggest pinch point in delivering this project?
• What new abilities or knowledge have we learned from doing this project? (though see my point later in this post.)
  
• What do we wish we had known when we started this project?
  
• Briefly what were the 3 lessons of this project that other colleagues need to know?  (I suggest taking 5 good lessons and 5 areas for improvement. - but don't make that an inflexible rule)

The important element to do is not to just file it away as part of some closed file but to share it  - this could either be via a blog but ideally with a wiki style approach - so that people can add additional comments especially if you are doing a number of projects for the same client and want to capture points say about a clients preferences or key areas of concern or praise expressed on an issue.

I think though that it time is pressing then you can use these four steps which tries to cover all the points earlier - but still does not obviate the need to capture these in a electronically searchable format.

• What were our intended results?
• What were our actual results?
• What caused our results?
• What will we sustain/improve?

Interestingly though this article neglects the need for people to carry out a before taking action review which covers the following points that people should ideally carry out before carrying out a major project and to some extent a bid

 This might then deliver an answer before the need to say - what things did we wish we had known before starting.

• What are our intended results and measures?
  
• What challenges can we anticipate?
  
• What did we/others learn in similar situations? (hence searching a wiki)
  
• What do we think will make the biggest difference to success ?
  

Blogs made simple

A question that I've been asked from time to time - is what is a blog and how can I use it.
Here is a useful You Tube video from the excellent Commoncraft (hat tip also to Doug Cornelius at KM Space - congrats on your new arrival).



A number of organisations now use blogs within the enterprise setting and as I posted last year the new Microsoft Sharepoint Server software 2007 has blogs as well as wikis inbuilt. I can imagine blogs being used for a variety of things - working on a project, working with a virtual team as well as utilising it for in house communities of practice. I've also discussed utilising them as a means of capturing lessons at the end of a project. I'm also placing a link in to a post I made last September on this subject so if you'd like to be encouraged then click on the link below

Thoughts on the uses for an internal blog

One firm that I worked with started to get experts in a particular field blogging and they enhanced their profile in the firm because they started to write a blog and the viral marketing effect took over and more people in their group subscribed to their blog as a source of knowledge that captured the human element.

It would be interesting to find out some innovative ways that blogs have been used within enterprises, but also for people to start to think laterally how this might be used in their enterprise.

An old article revisited on wikis

I am a big fan of Commoncraft who do excellent small movies to explain technology to dummies like myself. I was browsing through some of my old posts and as I was asked about a wiki - thought that I would repost this useful video of what is a wiki.



I'm a big fan of wikis to use on small scale projects and feel that they can assist with the creation of a high performance workplace by improving communication and also because as I have cited before, these will be part of the IT plumbing. The main issue for me that it isn't that the plumbing is there people have to be shown how to use it but also understand some of the more advanced functionality to get the benefit.

I was talking to an old colleague the other day and he advised me that he was talking to an IT manager who had found by accident that younger employees where using a wiki that was hosted externally to the organisation because the firm had not allowed them to trial an in house wiki. By encouraging people to link people start networking internally and can aid each other as well as tapping in to and learning new knowledge.

Anyway I hope that if you haven't used a wiki, this will encourage you to try. If enough people reply then maybe there is someway we could trial a wiki on a KM subject or anything else that takes your fancy.

The Google way to innovation

I was reading the New York Times online over the weekend and was reading an article about the Google Way for innovation.

Like the classic example of 3M - Google's engineers are encouraged to take 20 percent of their time to work on something company-related that interests them personally. This means that if you have a great idea, you always have time to run with it.

As I've discovered in my past people work harder if it is something that they are passionate about and are given time to do so. However, the article highlights the concept of the 'grouplet' when say something that you want to work on isn't say a new product or is something that is going to produce change that affects other departments. The article then mentions that these grouplets have no budget and they have no authority to decision make - but what they do have is a group of people who are looking to convince their organisation that this is an idea worth pursuing.

Say for example that you are looking to introduce a new working process or working on delivering a wiki as a means of delivering on a project. - then say a wiki grouplet might be a good idea and using people other than management as a means of selling the idea by giving talks to say a staff meeting or by holding brown bag lunches where people just drop in from the canteen to find out whats going on and putting their views in to the process.

The article extends the concept just to look at other areas such as a customer satisfaction fixit grouplet or even a grouplet to look at say ways that we can make a small improvement by losing a piece of bureaucracy.

Or my favorite: the Customer Happiness Fixit, when we fix all those little things that bug our users and make them sad — for example, when the hotkeys aren’t just right on mobile phones. Many of these events come with special T-shirts and gifts to reward the engineers who take a little time out to work on them.

The concept could be extended to be part of the new arrival induction process and people were encouraged to get involved with a grouplet. It helps with the induction process in my view and also starts to get people involved in the social networks that they need to cultivate them - but also you should be set this as a target as part of your appraisal process.

This of course can be a way to spread stories about the organisation but also by bringing in new views, then you can start to get new ideas looking at a problem. I'm not suggesting that there should be an anarchic situation and the grouplets need guidance to make sure they are aligned with the company interest.

Having a lot of people who are self-organising can be powerfully positive or negative, and not every idea is a good one. Therefore, all grouplets should be 'registered' with an organisers and that they should meet at least monthly to ensure that there aren't two grouplets doing the same work or doing work that is at cross purposes with the other.

Passionate people doing things that they are self interested in and supported by their peers can be a powerful combination in helping your company not only to innovate but also to ensure that it's internal processes are dynamic.

About to start a project - do you use prospective hindsight

One of the ideas, that I worked on was a variant of that well known practice within knowledge management of carrying out an after action review to gather the lessons and knowledge from every major project. The area that I looked at was going to be a before action review. The aim was two fold - one was to gather some of the participants  thoughts on the project and to tap in to their tacit knowledge. The other was to stop projects failing which they tend to do at regular intervals. I wanted people to bring their experiences to the table and to contribute any reservations or benefits before the team set off down the road so to speak.

There is an interesting article within the Harvard Business Review for September 2007 which highlights work done in the 1980's by Mitchell, Russo et al which discovered that 'prospective hindsight - imagining an event that has already happened increases the reasons for future outcomes by up to 30%. 

Gary Klein has utilised this research to suggest a pre-mortem approach to projects, which is used to identify risks - and asks team members to imagine that the project has failed spectacularly.  

Project members then write down independently every reason that they can think for the failure. Then team members are asked to read one item from their list (bit surprising this one as people depending on the culture of the firm will probably read out the one that is the least politically sensitive). 

It was interesting to read how this had been used to tap into a participants tacit knowledge and the groups social network to solve a potential project stopping issue.

It is interesting that Klein concludes as I did in my proposal - in that project team members then feel valued for their intelligence, experience and that other team members can learn valuable lessons from them. 

Also by examining problems at the start it also acclimatises people to look for early signs of trouble in the project and hopefully avoid the need for a painful after action review where people are too busy avoiding blame that useful knowledge doesn't get discovered and used for the benefit of the organisation.