Google Wave Drips With Ambition. A New Communication Platform For A New Web.
techcrunch.com
techcrunch.com
* Push vs. Pull. Does the recipient have to ask to get incoming messages.
* Off the cuff vs. Official. How quickly is the communication written, how much thought goes into formal language & proofreading.
* Personal vs. Notification (this is a big problem for communication). Regular mail has fallen to this, 99% of mail is automated messages, both wanted and unwanted. Email is going the same direction. Phone never has moved very far that direction.
* Filtered vs. Raw. Computer filtered, or human filtered. Spam, autocategorization, etc.
And then it adds document problems to it:
* Collaborative vs. Sign off. Am I co-writing the document with somebody or is it a write-revise-signoff cycle?
* Controlled vs. AdHoc. How formal does the collaboration need to be. Does it make sense for us to both be editing things, or is internal consistency too important to allow concurrent edits?
Basically, just saying "screw email, it's a chat! With Widgets!" totally ignores what people use communication services for, and the varying levels of formality, proofreading, speed, style, and automation.
A quick rundown of communication protocols that exist:
Email: Delayed, Push for the most part, Filtered, lots of notifications
IM: Instant, Push, Raw, few notifications
Blog: Delayed, Pull, Filtered (RSS reader, you decide what to read), few notifications.
Waves: Instant, Push (?), Raw, notifications... maybe?
Basically, it fits in the IM category for the most part. Why would this replace my email to the boss containing a page of pros vs. cons on a new technology that we were going to adopt? Would this replace the automated quarterly emails from HR showing me my 401k balance (and does it do the job any better?).
Summary:
Very technologically cool, but I have no idea how it fits well into the framework of communication types, and adds anything that's not covered adequately with current communication methods.
A thought I have had was that twitter flourished because it was a different set of attributes from anything else that existed (along with other things of course).
The simplest way I can put the Email/IM dichotomy is: it is file vs stream.
Something I'd really like to see if a protocol that is designed for notifications to humans. Anywhere from "Your car is ready to be picked up" to "We charged your credit card for this product, for this month of server", etc, etc.
I think if it is built from the ground up as a notification protocol, we can avoid the crap emails that we filter based on regular expressions, and bulk mail, and recorded phone calls.
But, it'd be really hard to get any sort of traction on of course.
XMPP might be the answer, or maybe dialects on top of XMPP. (haven't looked too close to see what's possible).
http://xmpp.org/extensions/xep-0201.html (last updated Feb. of last year)
Wave is XMPP, with additional Google extensions for a variety of collaboration features. That is possible because the first letter in XMPP doesn't stand for "XML", it's the (annoying but common) "eXtensible", suggesting that domain-specific additions are not only accepted, they are encouraged.
As an example, I wouldn't want to turn writing the page of pros vs. cons to my boss into a big collaborative discussion. But once I write the big long list in draft mode and then send it off, it would probably be great if the boss and the whole team could have a conversation about the document in real-time and at various places in the document. It would sure be more manageable than the big email chains in outlook that I've got now.
Everything that is currently implicit in the mode of communication (email, IM, etc.) and in mode-specific indicators (IM status, etc.) will now have to be communicated explicitly. That seems like a big step backwards. Google Wave will do well if it usefully aggregates many different modes of communication, but if it attempts to unify them then it will be socially unworkable, a total flop.
I don't have email interactions or IM interactions, I have conversations. I frequently switch off an email chain to an IM or telephone or even in person. If wave lets me coordinate that all in one interface and let me access the same history and context from multiple locations it will be phenomenally useful for me.
In contrast, an IM that isn't a one-off message says, "If you're there and available, I would like to have a real-time chat with you." Each mode of communication sets different expectations. It's quite handy. If you unify everything into a single mode of communication, then you have to set expectations explicitly.
"Hi, Joe. Can you tell me XYZ? Please reply when you are available to have an interactive real-time conversation with me."
"Hi, Joe. Can you tell me XYZ? Please reply at your leisure. I may not be available immediately to discuss your reply but will respond at some point if I have further questions."
See the difference? Of course, the different modes of communication don't mean the same things to everybody. I expect every company and every group of friends has a slightly different IM culture, for instance.
It's not even remotely uncommon for people in my circle to leave an IM or even a group chat in the middle. We all have dozens of things going on at any given time and it's expected that, unless the conversation is Really Important it will take second fiddle to the emergency of the moment.
So for us all conversations implicitly fit into your second category unless pretty explicitly stated already.
I concede, however, that if your typical behavior doesn't fit this model already wave is likely to be somewhere between useless and actively frustrating.
I based what I wrote on the two articles that got posted to HN, and gave my initial impression.
You said "This is silly, it doesn't account for the many, many axes of communication".
Then you listed these axes without explaining how they weren't accounted for.
Then you reduced the product to "screw email, it's a chat! With Widgets!".
Then you listed out a bunch of existing products that actually don't account for all the axes of communication.
And then admitted towards the end of all that that you actually "have no idea how it fits well into the framework of communication types".
All without having ever used the product, or having any exposure to it besides reading two short articles about it.
If you watched the demo you would see that many of the issues you mentioned in your comment can be addressed simply by choosing to use wave in the manner that is appropriate for the specific communication's context. You are free to approach it as:
'Collaborative draft and then publish' 'off the cuff IM type conversations' 'Push type communication like email' 'Pull type conversation like a blog' * etc...
Its really hard to explain without seeing the demo. When they publish the video for the day 2 keynote you should definitely watch it: http://wave.google.com
I would just respond to your summary by saying that it does what existing communication types do already... but better... and throws in things like versioning (history and record/playback), collaboration, and concurrent modification for free.
I like Roman Jacobson's work on communication functions, which wikipedia used to have a slightly better description of: http://en.wikipedia.org/wiki/Roman_Jakobson
You are enumerating the current segmentation of the space, which is useful if you want to determine where the product stays, but these dimensions are not set in stone. For example Wikipedia is about off the cuff writing that evolves into an official document, collaboratively.
2. What does open-sourcing mean? Is Google open-sourcing their server-side code? Probably not, since it's tied to the Google architecture anyways. Implementing these APIs/protocols would be a significant expence for the other providers. Also, open-source or not, this would still be a Google-technology (controled by Google), and large corporations don't like to invest in other's technology.
3. Presumably Google would allow Gmail users to upgrade with a click, so they'd have a good amount of seed users. But still, most of my contacts are not @gmail.com, so the experience would be limited.
4. This probably includes email as a special case, eg. your Wave provider is still running SMTP servers and receiving email messages coming to your address (Wave address = email address) and placing them in your Wave inbox, and sending out emails per SMTP if the other side is not Wave enabled. This means painless upgrades in terms of "compatibility" for the user.
Correct me if I'm wrong, I've only skimmed the docs!
From http://www.waveprotocol.org/: our plan is to release an open source, production-quality, reference implementation of the Google Wave client and server
So it looks like they will release an example of server code, thought it probably won't be exactly what Google uses. Still, this should allow other people to copy that implementation and make their own servers relatively easily.
So many possibilities!
Which is where they make there money and why they are doing all these products.
It makes perfect sense.
looks like XMPP to me
I really hate XML
"The Google Wave Federation Protocol is an open extension to XMPP core [RFC3920] protocol..."
Whatever your feelings about XMPP, I challenge you to point to a standardized, interoperable protocol that you think would be a better fit. It may not be ideal, but it's extensible, already supported by a large number of clients and servers, and doesn't require starting from scratch when building interoperable software.
1. XMPP is verbose.
2. XMPP is inefficient for mobile networking.
3. A proprietary binary protocol would be more efficient for mobile devices.
4. The former Android xmppService API will diverge away from XMPP.
It'd be nice to be able to set the communication mode for instance - "this is asynchronous, like an email", and then you don't have to worry about the person you're writing to coming online while you're drafting something you want to word carefully. It sounds like they have something like that but I don't know what the granularity is like.
If it can do that you can have your cake and eat it to, and I'd be pretty keen to give it a go.
Hell, I'd be happy with email/chat/feed reader/blog interface as separate apps in the same page, just so I could get status info from everything in the same place that I do stuff. Being able to drag and drop things between them all has a fair bit of appeal as well.
It's probably a fine line between good integration and a huge shiny mess though.
I still prefer plain-text emails, though.
Don't fall in the trap of using word choice to make something sound insignificant. Having several people edit the same document in real-time without problems, clearly see when and who updated what, and quickly look at the document's history (honestly, sites like Wikipedia's history feature is just ugly and clunky) can't really be called a wiki.
The interface looks really busy from the screenshot and generally doesn't look like products Google usually makes (Chrome, Gmail have pretty clean interfaces, but maybe that's because I'm accustomed to them). If anything, I'm more interested in using the protocol and building a stripped-down version of it.
The possibilities of this product is mind boggling. But will the complexity and learning curve be a stumbling block in adoption? Even if the consumer product doesn't take off, I expect wave to be hit in companies where people need to collaborate frequently especially since they can host their own wave server and not worry about hosting data with google.
If they can make a web app that can let users unify their various notification/collaboration streams (Blogs, Twitter, Facebook, delicious, Flickr, IM, email...) then they have a winner. Especially if they can make a slick mobile version.
However, if you look at the Gmail+Gtalk use-case, the fact that all conversations that go through Google's Jabber servers are automatically indexed and searchable in Gmail alone is a killer feature (this also works if you use a desktop client like Adium, the point is, it makes sense to use Google as your IM provider for the indexing).
So the point is, keeping as many docs/conversations/etc in some centralized Google app may be worth it just for the search/indexing.
My final conclusion then is that other companies, in the long term, may have to implement Google-like search functionality (and storage), otherwise Google will suck up their application's users with search as a killer feature.
The merger of email, IM, and twitter into a new messaging system has tremendous potential.
I would say that it's just to early to tell. Perhaps when I try it out it will replace everything else.
The key difference being the openness of wave.
But I do like that they experiment with new forms of collaborative document editing. This has always been a big pain. I have thought about it quite a lot myself.
The really difficult thing about collaborative document editing is versioning. The more I think about it the more open questions accumulate.
I have my doubts that a tool that wants to be so many things at the same time can be a good enough collaborative document editing tool. For instance, how do I separate the content that is edited from the communcation _about_ that content? Maybe that becomes obvious when we can actually try it.
In Wave there is a distinction between editing text and attaching a reply or comment to the text.
Direct link: https://services.google.com/fb/forms/wavesignupfordev/
Come, Bring a Friend and let's discuss Google Wave over lunch.
Please use the following link: http://www.socializr.com/event/976099347 to RSVP.
Feel free to forward to anyone who might be interested.
I was wondering specifically about how would it effect development mailing lists - with wave plugins to look at patches / browse repositories / review code things could get pretty interesting.
Although with non-development mailing lists it could be interesting as long as you could optionally select the group of people to discuss the contents of the list.
I'm assuming sometimes it would be better to discuss the contents of the mailing list (or RSS feed) with a select few of your contacts. Discussing the content with all subscribers can be done already (although perhaps not as fluidly) with blog post comments etc...
the other contender would be linkedin due to the professional atitude they have towards social networking.
Even if your inbox (or whatever the wave equivalent is) could divide incoming waves based on whether they were from whitelisted contacts or from unknown contacts, it gets a lot more useful if people whitelist each other by default.
The same principle is about technology - put it all together XMPP + XML documents (for easy data extraction and indexing) (google docs) + version control (git) + wiki-style editing (wikipedia) + maps, of course + profiles (facebook) + feeds (twitter).
And it will probably work, because it is targeted for mobile devices (android) as clients which means instant and short messaging by definition.
Can we get a time machine and go back to the 80s and start all over again and build up a proper platform before the WWW becomes popular??
If you don't want to wait for Google Wave to see updates from everyone in real time, check it out.
We already have real-time updates. What we don't have is a system where every sort of update is treated in a single place. That's what Wave is.
If you want to advertise Browseology, do it with a post to the front page, and only advertise in other threads if it's relevant to the story. You're borderline spamming right now.