Google wave interim report

I have used waves for a while now and I've had fun implementing robots and gadgets - event though nobody ever appreciated my brilliant JDebuggy so far ;-)

Now it's time for an interim report.

I honor the hard work that all the wave developers spent so far to create this product. To build a browser based realtime application that handles concurrent changes of potentially thousands of users is far from being an easy task. I've worked on a realtime GWT based callcenter client in the last years with a limited number of users (<1000 concurrent callcenter agents) and it was quite difficult to build a robust and reliable browser based application.
You have to deal with the persistent connection limit in IE (that might be the reason why wave is not available for IE right now), have to assure that the application state will be restored when the browser crashes or when the user reloads the page and other problems alike.

Despite of being appreciative of the good work of the involved developers - I think wave has a long way to go until it turns into a useful tool. This is why:

Google wave claim to be a potential combination or even replacement for email, blogging, twitter-like instant messaging services, word processors, photo sharing apps etc.
But I've the strong feeling that these particular services are successful, because they target a very specific problem and deliver an extremely simple to use solution.
People like to use Twitter because they can simply start to type and publish with a single click. Flickr has a specific UI for sharing and tagging photos and provides an API that is focussed on accessing photos.
Blogger is cool, because its focus is on creating and editing posts and lets you easily modify the page layout using a simple template mechanism and css for styling without messing around with the posts.
Google docs is very nice, because you have the subset of word processing power that will satisfy the needs of 90% of the usecases and lets you import and export into lots of document formats.
I could go on with the list, but I think you already got the point.

In contrast to these applications Google wave is a more generic approach.
If you know me, you may already know that I'm not a big fan of generic approaches.
You'll find generic design approaches a lot in software projects where unexperienced software architects come up with a idea like this: "Hey, I've a brilliant new generic approach for our API. We can do everything we want in the future without changing the API by simple passing in a generic Map of objects and get back a Map of objects!"
Of course it is cool and very impressive to have just a single-method API that lets you do fairly everything, BUT: you'll wipe out all the improvements that have been made in software languages over the last decades like compile time type checks, strong typing etc.

But that's a totally different story. Let's get back to Google wave.

In wave you'll find tons of potential usecases - and this makes me suspicious because of the reasons described above. But let's do a reality check for the most important ones:

Email

Everyone uses email, because it is the 21 century replacement for letters. Even though you can abuse emails for simply sending documents or photos, it is generally used as the way to send longer private letters to single or multiple persons.

The content is important and so I personally like plain text email and I hate html emails as they'll cause a lot of trouble because the email client may screw it up.

What about wave?
Right now waves are always styled (equivalent to html emails) and even worse: You are encouraged to add so called gadgets to your text. These gadgets are living pieces of software that may use a lot of javascript.
If you use wave to write an email like letter, you may not be amused that all participants (=recipients) can change the email you've sent. If you'll have a look at your text some days later, you may not recognize it as it might be totally changed by someone else.
You have the chance to use the "playback" feature that let's you go through every single revision, but it is very hard to find the changes made and this playback feature is of course only available in the wave client. If you would access the wave in an arbitrary text editor without playback feature, you'd have no chance to see the documents history.
So you are tied to the wave client to access the mail.
Another problem is that you'll see all the changes that someone is making in realtime. So the private character of an email is totally gone. There is a planned "draft" feature to enable you to type first and send later, but I'm concerned about how this will work out when many people are allowed to edit the document at the same time.

But I don't want to be fussy. Here are my suggestions that need to be implemented to improve the email capabilities of wave. I've already posted some of these suggestions to the wave sandbox, but here we go again:

• Permissions
  To keep the email feeling of being the owner of a document, wave needs to support a fine grained concept of access control. The permissions should directly modify the UI so that only the allowed actions will be accessible.
  You'll need the following permissions to be able to use wave as an email like application: 
• READ 
• EDIT 
• STYLE_TEXT 
• DELETE 
• ADD_GADGET
• REMOVE_GADGET
• ADD_PARTICIPANT 
• REMOVE_PARTICIPANT 
• ADD_ROBOT 
• REMOVE_ROBOT 
• CREATE_BLIP 
• DELETE_BLIP 
• CHANGE_PERMISSIONS 
• COPY_TO_NEW_WAVE 
• PRIVATE_REPLY
• CHANGE_TITLE

So if you'll use wave wave to write a plain text email to your best friend, you'll:

1. Create a new wave
2. Write the text (to write text before adding participants is the only way to avoid them to watch you while typing)
3. Add your friend as participant
4. Grant your friend the permissions to read and private reply. If you'll not grant the STYLE_TEXT permission, you friend should not be able to create a reply with styles text in it. As you'll not grant the EDIT permission your text will be untouched in the future.

Right now there are no such permissions in wave. And there is no way to add permissions on a participants level.

• Templates
  Of course it would be unacceptable to keep the user in charge of going through all these steps just to write an email. In wave you'll also need a way to create wave templates that will automatically add certain permissions to the participants and add certain robots.
  An email template would automatically add the spell checking robot and would grant the proper permissions to every participant added.
• Default permissions per contact
  Some contacts may have certain roles. So if you have a certain coworker to create shared documents, you automatically want to grant him the EDIT permission if he is being added to a wave. To find out if the permission per contact overweights the template permission set there needs to be a concept like GRANT, GRANT_ALWAYS, DENY, DENY_ALWAYS to calculate the resulting set of permissions per contact.

  
Word processor
When it comes to collaboration on a shared document this is one of the strengths of wave. You'll see the changes of the participants in realtime. It is not yet foreseeable how wave will relate to Google docs in long term.
There is currently no support for existing document formats and the text style capabilities are very limited. So right now it looks as if wave would end up somewhere in between docs and email.
Again here are some suggestions, how to improve wave to deliver a better user experience when it comes to document collaboration:

• Improved playback history
  Right now it is very hard to follow the changes made to a wave. You are able to step through the document history, but it is difficult to find the changes made in each revision. This can be improved:
  IntelliJ, Eclipse and latest dev build of Chrome search have it: Colored indicators in the scrollbar to jump directly to certain positions in the document. This would be extremely useful in conjunction with the playback feature: Mark the modified positions of the document and let the user directly jump to these positions to be able to track changes made in each step.
• Annotations
  Modified parts of the wave should be annotated. There are already proven ways to show annotations in OpenOffice and other office suits. A short-term improvement would be to display the author when hovering with the mouse over the text.
  Google docs offers a minimalistic but useful revision compare mode. If would be nice to have such a history view in wave to compare playback steps.
• Create as new doc
  Instead of being able to create a fresh wave from an existing one it would be very cool to be able to create a Google doc from a wave. So you could start brainstorming in wave and finishing the document in Google doc and don't need to implement a full blown word processor in wave.

I'll try to post my suggestions to the other usecases, but that's it for now. Just found an interesting post addressing similar issues:

http://jungleg.com/2009/06/04/googles-wave-doesnt-look-like-a-tsunami/