This is silly, it doesn't account for the many, many axes of communication.
* 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.
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).
Tough to say without trying it, but I think this has the potential to be a very flexible format and therefore potentially cover more use cases than you are giving it credit for.
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.
What is "flexibility" from a technical point of view is "ambiguity" from a social point of view. Is the conversation real-time or only potentially real-time? IM is a real-time conversation, like two people speaking. E-mail is not. A single protocol and interface for both means people will be constantly confused about each other's intentions. I like the idea of combining and persisting all communications about a single topic, but in the screenshots it looks like all Wave messages look the same. "Draft" mode vs. keystroke mode provides a clue, but what if I don't see the message arrive? What if I have a real-time conversation with somebody, and then five minutes after it ends, one of us posts another message? We have to add some kind of comment indicating whether it is intended as a continuation of the previous conversation, the beginning of a new real-time conversation, or a one-off message (with the sender perhaps not available to chat at the moment.)
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 follow your logic at all. I frequently have essentially real-time conversations via email. If someone steps away the conversation doesn't 'end' it just reverts to a slower pace. Gmail with its conversation-oriented view is already closer to an IM flow than most traditional email clients.
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.
I have real-time conversations via email, too. The difference is in the expectations of the participants. It's subtle and social. I wouldn't just walk away from a fast-running IM conversation to go to lunch without saying something to let the other person know I was going to be gone for a while. That would be rude. Doubly so on the phone. You don't just hang up on somebody in the middle of a conversation unless you're pissed at them. Email is different. Nobody thinks it's weird or rude if you disappear from an email conversation for ten minutes. After sending an email, you can even walk away from your computer and not check your email again for hours, unless the content of your message indicated otherwise.
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.
Your conversational partners are substantially more polite than mine :)
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 think wave is an indicator of something profound about what our computing and networking infrastructure is good for. It's good for us to collaborate on digital content. It's not so good for us to cooperate without that 3rd digital object -- directly with each other. For that to happen, we need to revamp the entire interface, so it's not a total perception and attention sink. We need to be able to interact with the world and other people in the world, and have computing as only a side channel or an augmentation.
Excellent break-down of the usage patterns of Email and IM. One thing that you hint at is persistence. While we all have the ability to log IMs, email exists as much for archival purposes as it does momentary communication.
The simplest way I can put the Email/IM dichotomy is: it is file vs stream.
Good call, that's yet another axis of communication. I actually had all that written down for a blog post I was going to get around to making (with diagrams & graphics and everything).
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.
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.
Meh, not going to argue with you over a product neither of us have ever used. You're right, I took stronger than needed stances, and it's most likely that this will be a very cool technology. I am just pointing out that all-in-one tools don't really solve communication problems, and that there is a ton to consider when talking about how information is presented, stored, and discussed between people.
Didn't RSS readers solve a problem by aggregating disparate streams? Granted, the problem is a lot bigger here. Instead of aggregating/organizing lots of sources using only 2 protocols, you are trying to do the same for many protocols and many models. But I suspect this is why it would be a big win -- the users find this daunting as well!
all-in-one does solve the problem of moving a conversation between all the different and incompatible existing systems. seamless integration is a huge win.
This was the biggest takeaway for me too. It's a way of easily moving data from just about any communication system to just about any other communication system.
Do you think it will really be seamless? That's where almost all of these types of all-in-one deals fail for me. They are completely seamless if you want to play by the rules they set and the interfaces they build. When you want to break out of that mold they're not really so seamless anymore. I know it's an open protocol and blah blah but I'm not sure I want to spend all this time making a screwdriver into a hammer when I already have a perfectly fine hammer.
The demo video isn't even up yet, and some people are already calling it the future of communication. This looks like one of Google's narrow-minded tactic to sideline Bing's news today.
What are you talking about? Google IO is going on, you expected them to just sit around and have a big circle chat about Bing? If anything, Microsoft is trying to sideline Google. Big companies compete for the spotlight, get over it.
Wave is not just a singular tool, it is also a communication protocol. There is no single way to use 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 think Twitter and Facebook are the key here. I think that those two sites and others are crying out for a unification of all of these axes of communications. Right now, your blog, your Twitter stream, your photo streams, the dozen different Facebook things, emails to friends -- unifying all of these in a way which lets the user navigate instantly to an appropriate level of detail, appropriate level of sign-off, and/or the appropriate kind of communications would be fantastic.
jzellman, eweaver, and I sat around one night last summer and made a grid of these things, for others like twitter, newsgroups, etc. Looking at it, it had holes in it, and we half-joked that all someone needed to do was pick some unfulfilled combination of communication axis, and they'd have another startup.
It's a new medium for communication. If it works, people will use it in new unexpected ways; if it doesn't, people won't use it. But there is a lot of excitement about new forms of real-time communication: twitter, recent friendfeed functionality, etc - so they may hit it right.
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.
A couple of important communication axes: Receivers (number, type and level of privacy), Context (threads, or more generally things like being embedded in something like Facebook).
1. For this to take off, other providers would have to implement the Wave API/protocol. Other providers like Microsoft, Yahoo, Facebook, etc. Just as today everybody is running SMTP servers.
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.
According to the lead developer, Lars Rasmussen, Google plans to open source the lion's share of their code. In addition, corporations can host their Wave servers. These will be interoperable with any other Wave service provider.
The web is getting really exciting again! I mean, it always has been, but these open protocols, open platforms, and general openness has really got me smiling :)
I'm glad somebody is excited. Not to be a downer, but I'm personnaly seeing copy-cat evolution, not revolution. The new toys just aren't going to change the way I work and play.
It's in Google's interests, as the king of Internet companies, to be at the forefront of whatever "the future of the Internet" is. I think to imply they crafted Wave specifically with advertising potential in mind is unnecessarily cynical.
Even if I agree somewhat with your feelings about xml, I think I prefer something like xml over (a sample) of:
RFC 1939 POP3 protocol Updated by RFC 2449
RFC 2449 POP3 Extension Mechanism
RFC 822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES Obsoleted by RFC 2822
RFC 2822 Internet Message Format
RFC 2045 MIME Part One: Format of Internet Message Bodies Updated by RFC 2231
RFC 2046 MIME Part Two: Media Types
RFC 2047 MIME Part Three: Message Header Extensions for Non-ASCII Text Updated by RFC 2231
RFC 2183 The Content-Disposition Header Field Updated by RFC 2231
RFC 2231 MIME Parameter Value and Encoded Word Extensions: Character Sets,...
RFC 2387 The MIME Multipart/Related Content-type
RFC 3462 The MIME Multipart/Report Content-type
RFC 2111 Content-ID and Message-ID Uniform Resource Locators
RFC 2632 S/MIME Version 3 Certificate Handling
RFC 2633 S/MIME Version 3 Message Specification
RFC 2821 Simple Mail Transfer Protocol
"The Google Wave Federation Protocol is an open extension to XMPP core [RFC3920] protocol..."
(From the first paragraph of the draft spec.)
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.
I think there is room for something like AMQP. Most people use libraries to process XMPP anyway, so a binary format wouldn't be a huge change (except, perhaps, in performance).
Yeah, me too, but writing a bi-directional wrapper for JSON or the even better future thing might be non-trivial -- unless the protocol gets ugly and uglier.
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.
This could be revolutionary, however email is the way it is because that's just how we've communicated as a species for eons, all the way from letters to tablets to cave paintings. You think carefully about your message, create something representing it, and share it. It seems like Wave is essentially condensing that process into one step, more like a conversation. I'm not sure everyone will welcome that.
It seems to be acting like a lot of communication tools at once. If there's some way to partition the usage up somehow then it's like a combination of several quality tools in the one place with the option to let the borders blur.
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.
So, the new thing they did is that they combined Chat and Wiki and then threw some API for mashing up. Made it pretty and Ajaxy. Well, mmm, Ok. I guess many people will like it.
combined Chat and Wiki and then threw some API for mashing up. Made it pretty and Ajaxy.
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.
I think it'd be more Googly if they got rid of the avatars, drop shadows, funky buttons and rounded corners (seriously, looks like someone barfed web 2.0 all over a screen) and ditched the 3 pane system, so clicking on a thread switched you over to the conversation itself rather than having the convo in a pane on the same page.
My understanding is that this is just 'a' waves client, just as there are a bunch of quite different applications that let you use Twitter or GMail in a variety of different ways.
Yeah. The playback feature alone is a very difficult feature to successfully implement.
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.
Just hide the levels of complexity, but make it easier for the user to delve into what they want.
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.
If you don't think the idea of merging private, public, synchronous, and asynchronous communication into a cohesive unit is exciting, then I don't know what you would find exciting.
Maybe I want to keep my private and public conversations distinct, or my synchronous and asynchronous communications distinct. Doesn't it follow that I'd want specialized tools for each?
I agree, context is important, and humans are better at separating context if it's "physically" separated, eg. a different site or window.
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.
Back in my day, we didn't have any of these fancy real-time-mashups. If you wanted to mash up, you'd show up at the person's front door, pull out a map, and point at things.
Wonder what we'll be saying down the road...."in my day, we didn't have these fancy neuron teleporters. If you wanted to mash up, you'd use Twitter or Google Wave." Some young hacker would look up, scratch his head, ask, "What's Google?"
Be sure you actually understand the limitations to the existing solutions and what benefits convergence such as Google Wave may offer before you dismiss it out of hand.
The merger of email, IM, and twitter into a new messaging system has tremendous potential.
Yes, I do, but maybe it's just me but I don't feel uncomfortable when emails, IMs, and other means of communication are separated. Blended experience isn't always a good thing. For example, for me it's much easier to maintain my Flickr and Twitter accounts independently rather than having both my photos and my status updates inside Facebook. To me these are two distinctive task and to have them in separate browser tabs feels more natural. I'm afraid the notion of wave just got to many concepts thrown into.
I would say that it's just to early to tell. Perhaps when I try it out it will replace everything else.
And that it has Google behind it, not AOL. AOL wasn't able to keep up with the innovation and so they fell behind, especially as the walls to the full Internet crashed down and AOL's walled-garden approach became outdated.
I was never a big user of IM or any real time communications (not even phone) so I don't think I would use it much for that.
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.
http://wavesandbox.com/ is where people are getting developer accounts from the Google I/O Conference. You may directly navigate to it and add yourself to a waitlist too, if you're not registered at the Google I/O Conference.
I guess I'm not hip or social enough to get it. It's like a glorified e-mail/IM client with avatars and social networking stuff, and a bunch of other things super glued to it? Seems like it might be too ambitious. Maybe there's a good idea in there somewhere but, looking at the tools/sites I use now, I can't imagine why I would want to use this instead. I certainly don't want to waste my time duplicating my efforts on more than one site/service/whatever. Looks like there might be a decent barrier of entry too just figuring out how all these parts work with each other and how you can modify them to work the way you want them to.
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...
Well, if you're going to try to reinvent email you've got a better chance at making whitelists useful.
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.
There are almost nothing new about this project - the big idea is "lets put all out services together" under new buzzword with the same proven strategy - "we will host and monetize your data" and "we published an APIs, you wll code it out".
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.
So something ambitious is going to be built ontop of complete junk and by forcing the HTTP protocol to handle shit it wasn't meant for. Wonderful. Fucking wonderful.
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??
Erm, I was talking about the web-end. I didn't realize there was a separate protocol for it but in any case, XMPP is heavy because it uses XML (which is also somewhat junk).
Google Wave actually looks nothing like your product whatsoever.
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.
* 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).