I was fortunate enough to receive an invitation into Google Wave shortly after the initial 100,000 invititations went out last month. Initially, I was a bit overwhelmed and did not really know where to begin or what to do. Bwana was kind enough to engage in a real-time wave with me, and show me around a bit. Afterwards, I began to see the potential. However, I think there are many reasons why Google Wave still is not ready for prime-time.
Lack of Access Control
Google Wave does not have any sort of access control for managing waves and wave participants:
- Anyone can be added to a wave by a participant in the wave.
- Any wave participant can add a bot to the wave (because bots are simply treated as participants).
- It is not possible to remove participants (except for bots) from a wave.
- Anyone can modify any part of the wave.
Here is what I think Google Wave needs to implement to resolve the access control issues:
- Allow the wave creator do add/remove any participant from a wave.
- Allow the wave creator to assign/modify the following permissions that can be set at the wave and participant level:
- Permission to add bots to the wave.
- Permission to invite other participants to the wave.
- Permission to remove participants from the wave.
- Read-only or read/write access to the wave.
- Permission to grant/modify each (or all) permissions for other participants and/or the entire wave.
Without access control, things can quickly get out of hand if you are trying to work on a collaborative project that is only intended for certain people. Even if you do manage to maintain control as to who has access to a wave, you may only want to allow certain people permission to perform certain functions.
Image Credit: Brandon Lowery
Poor Contact Management
When you click on the Manage contacts link in Google Wave, you are taken to Google Contacts. Unfortunately there is hardly any correlation between what you see in your Google Contacts and what you see in your Google Wave contact list. Although everyone in your Google Wave contacts list has a @googlewave.com “address” (it is not an email address although it looks like one), within Google Contacts you’ll see no addresses with googlewave.com.
If you want to remove someone from your Google Wave contacts, you have to remove them from your Google Contacts. This may not be something you want to do, as you may wish to keep them in your Google Contacts and remove them from your Google Wave contacts or vice versa. Either Google Wave needs its own contact management, or Google Contacts needs to incorporate functionality for managing Google Wave contacts.
Image Credit: Hannes Grobe
Lack of Groups
If you deal with multiple groups of people when you communicate via email, mailing lists are absolutely essential. Google Wave has no way to group your contacts together to build the equivalent of mailing lists. Without such a function, you have to manually add each and every participant you want on a wave. Not only is this a major inconvenience, but you may omit someone that needs to be a wave participant or add someone that should not be a participant.
Google Wave needs to implement groups. Perhaps it can be incorporated as part of the improved contact management I’ve suggested, or implemented as a separate feature. Regardless, it should also become a part of access control. That way access control can be set and modified at a wave, group, and participant level.
Image Credit: lumaxart
Lack of “Legacy Support”
You cannot expect someone to abandon a very well-established legacy technology (email) without providing reverse compatibility and legacy support. The world cannot and will not just drop email in favor of Google Wave without an interim solution that supports both technologies. The fact that Google Wave addresses do have the same appearance as email addresses does seem to indicate there may be plans to allow Google Wave accounts to receive email.
It is very inconvenient having to check communications from multiple sources rather than having it all in one place. This is the reason why I have all my email forwarded to one single Gmail account. I also take advantage of the Gmail feature that allows you to send email from other accounts.
Google Wave needs to incorporate features to allow users to send and receive email if it is to receive the kind of wide-scale adoption Google seems to believe it is capable of achieving. If I could just forward all of my email to my Google Wave account, receive all my communication in one place, and send emails from Google Wave as well, I would seriously consider using solely Google Wave.
Image Credit: ePublicist
Lack of Revision Control
Revision control is absolutely essential for working in a collaborative environment. The need eventually arises where it is necessary to revert to a previous version of a document. Wikis provide this capability as do a variety of software development source control solutions. Google Wave needs revision control.
Google Wave does have something resembling revision control with the Playback functionality. However, you can only see the progression of a wave from start to finish, and you cannot revert to any of the frames in between. It would appear that some of the plumbing is already there for revision control, it just needs to be implemented.
I’ve seen many situations in public waves where revision control was needed. Sometimes someone unwittingly adds a bot that overwrites the initial blip, wiping away hours of hard work in the blink of an eye. Someone may also intentionally sabotage a wave, removing a lot of valid and important information that must subsequently be manually recovered or rewritten.
It would be best to have revision control in Google Wave at a blip level, rather than at a wave level. One may wish to revert to a previous version of a blip within a wave, without losing the changes that have taken place within other blips and the rest of the wave.
Image Credit: VisualPharm
Final Thoughts
Google Wave is a good tool for communication and collaboration. It has many impressive features and capabilities. However, as you can see by the headings in this article, the problem is that it is lacking many key features for wide-scale adoption. Given that the current Google Wave is just a preview, it is likely that these missing features and others will eventually make it into the final product.
Pingback: Confluence: National Campus Office
Disagree — I think these things mis the point and are implemented in other technologies, like mailing lists, document sharing, etc. basically, Access control is trust-based and assumes that you trust the people who are invited to the wave. I'm not using wave yet (send me an invite, plz) but as I understand from the demo, the contacts are complete-as-you-type, so fine-grained contacts are not required. Since wave is a federated service, access control is also limited by keeping information internal. I do agree with the version control point, but I think that you could probably implement it with a bot, and it will probably be implement it that way easily. and as far as legacy support, I think what you want in an export option. the point of not being compatible with email is that you don't lose people in the process. Also, making this work with a bot, mailing list should be relatively simple.
http://danieltenner.com/posts/0012-google-wave….
I think you're right in that version control and email support can be
implemented via bots. I actually started trying to implement my own “Undo
Bot”, but did not succeed. It requires duplicating the entire wave
structure each time a blip is added/modified and storing it somewhere. It
was a bit more involved than I had initially anticipated, so I stopped
trying to develop it. Hopefully someone much smarter than me will figure it
out.
The contact management really needs work though as does access control. Let
me give you an example. Say you work together on a collaborative website
with 9 other people. All 10 of you are essentially contractors for the
website owner, and you get paid for content. The 10 of you write many waves
with secret information that is only to be shared between the 10 of you.
First of all, if you want to start a new wave with everyone in the group, it
is a major pain. You need to pick and choose the other 9 people and add
them to the wave. You may forget someone and they miss out on important
info. You may accidentally add someone you shouldn't have, and there's no
way you can remove them.
Another situation you may run into is that bad things can happen if someone
leaves the team. That person will remain on all the waves with everyone
else, and there's no way to remove him or her. Plus, without access
control, he or she can sabotage the waves, invite others that should not be
invited, make them public when they should not, etc…
Certainly using a hosted solution with the federated service would resolve
the access control issues, as you stated. But if anyone is to use Google
Wave as their client, I think it would be best if some of these features
were implemented, particularly for public waves.
Some of the public waves in Google Wave have been experiencing a lot of pain
due to the lack of access control. Because anyone can join and do anything
they want to the wave, bad things happen. Of course, even if they do not
implement access control, some form of revision control would alleviate some
the pain. It would at least allow reverting to a prior version before the
bad things happened.
Sorry, I have no more invites to give out. 🙁
So, I understood that you could export one part of your wave as another wave, I think that this would be a good solution for less-trusted individuals, but I see your point with access control. What would you suggest?
It would be great if Google Wave were to implement all the access features
mentioned in this article. But at a minimum, you need to be able to set
read-only/read-write permissions and the ability to remove people from a
wave. That would allow Wave users to moderate and remove any individuals
that are a nuisance with sabotage, graffiti, spam, etc. Combine that with
better contact management groups, and revision control, and you've got a
pretty solid real-time collaborative platform.
I still do believe that it needs a two-way interface with email, to gain
wide acceptance and usage. A lot of people will take the stance that “email
ain't broke so don't fix it.” It will take backward compatability for such
individuals to even consider using it.
It may not be necessary for someone like you or me that accepts, embraces,
and utilizes new technologies with little issue. Unfortunately, there are a
lot of folks out there that need to be eased into it. They require
facilitation with the transition in the form of “legacy support.” Besides,
it is difficult to deny that it would be very convenient to use email and
wave all in the same place.
Maybe they could just add an optional gmail inbox window to the wave page, this way all your messages are in one place and this seems like the most practical way to combine the two.
They could probably do a bit better than just bringing a gmail inbox into it (although that would be a start). I envision that [email protected] would actually behave as an email address. Emails could just appear in your inbox just as any other wave does, and you respond by adding response blips.
The big differences would be that of course there would be no real-time interaction, and you wouldn't be able to edit blips, only add new ones. I suppose some provisions can be made for editing blips. When the wave user modifies a blip, the email user could receive an email with the modifications. But of course, the email user will not be able to modify the wave.
I've also covered this topic and have a different point of view on it. You can see it here: http://www.seekomega.com/2009/09/still-some-rip…
Thanks for the link Mark. We do seem to share some of the same thoughts,
particularly on the lack of email integration. I think you're spot-on in
stating that lack of email integration is going to be a major roadblock for
mass adoption.
Actually I got to partially agree with both of you on this matter.. there are many things missing from GW but also we need to remember that its really in alpha stage…I'm not sure about the access control system cz it might beat the purpose of it..
Pingback: Linkwertig: Internetsperren, Google Calendar, Whitehouse.gov » netzwertig.com
I agree with everything you said about access control, which hopefully will be coming soon. I also agree with what you said about contact management. Google should also add a way to find people like you can on facebook, and through a privacy page, select which aspects of your profile such as name, address, image you want visible to people who are not yet one of your contacts.
I also don't like how when you view a public wave it goes into your inbox, even if you don't add yourself to it or reply in it. The best you can do is hide it in your trash but I did not realize this when I was playing around with it and now have a ton of waves I can't get rid of but only hide. I also accidentally left a reply on my profile settings page which I now am unable to delete.
Maybe they could just add an optional gmail inbox window to the wave page, this way all your messages are in one place
Pingback: My Tweets of October | Blogging & Technology | So You Want To Teach?
You're absolutely spot on. Lack of legacy support is a real killer from my perspective.
I've got my invite and am now twiddling my thumbs waiting for other people I know to get their wave invites. I have no interest in 'waving' people I don't know. In addition I want to email them from and receive emails in wave but have to move between services to do so.
My overall impression leads to a resounding fail for google at this point.
I don't know that I would call it a resounding fail. Afterall, it is just a
preview. Assuming that preview is the equivalent to what everyone else
calls “alpha”, it should eventually move into beta which should be much
better. When it does eventually get there, they will need to include
support for email in some fashion if they expect mass adoption.
The good news is that being a federated protocol, someone else may beat
Google to reverse compatibility and develop some kind of Wave client/service
that integrates both email and Wave.
I actually found this post after doing some work in Wave and being really frustrated once again with contact management. I will give you an example from my usage.
The first thing that really bothers me is that (like you mentioned) contact management users Google Contacts. This should be fine as I use it (and it syncs to mobile devices, etc). Great. Except, like you said, the fact that it lumps everyone together with no way to discern who is a Wave user and who is regular contact. I like that they're trying to integrate Wave participants as regular contacts, but they should create a group in GContacts and have everyone who is added in Wave automatically added to that group. For me that would facilitate the management of my thirty some odd Wave users from the sea of some 600 contacts.
A nit-picky point, but major usability issue is that when you click the + in the contacts pane, the focus doesn't automatically go to the input box. So you type into nothingness until you click. It's little, but really annoying.
Not being able to remove people really bothers me as well.
I thought when I saw the Playback feature demoed that while playing back, you could go back at any point to a previous version. I have had people really mess up the structure of a Wave (by accident, although maliciousness is possible too) and there is no way to go back.
I'd like to comment on the “Ping” feature. If you use this from within a Wave it makes a private blip between you and the person you pinged. The next time they log on (or if they are online) they get a pop-up. This is all great. The problem lies in the fact that you cannot delete these ping-related blips, even if they are empty. This is a source of major frustration for me as it often destroys the flow of collaborative documents.
Finally, the e-mail situation: why can't [email protected] be our Wave address (or, once federated, [email protected])? Barring this, at the VERY least, I think that e-mails to [email protected] become a new wave in the inbox with the contents of the e-mail, if the mailer is a Wave user, they are added as a participant. I don't even need any back-and-forth functionality to start. I just think this would be a great way of getting info from current systems into wave without having to copy paste. The other e-mail functionality, which I'm sure to come, can happen later.
Great post, well written, bang on, and very informative.
I'm right there with you Gordon. I think you're spot on with the annoyances
you mentioned, as well as the way email integration should work. Being able
to receive @googlwave.com would be perfect, because then I we can just
forward all mail to that address and have all communication happen in one
place.
email support isn't something big, its just done by adding a no edit permission, reply is available, the conversation way is available too, maybe support for HTML, therefore i think wave is ready. BUT Google won't do it this way, first they will use the wave interface in all their applications (Gmail, Docs, ..etc) so people get used to it then they would feel like home when they merge everything with wave 🙂
I agree completely and there are many more things missing besides: not being able to remove people from a wave, to delete a wave, editing large waves, not just making responses crashes it, search filters as buttons rather than as search keywords, making a wave unpublic after making it public…its just not ready for wide release yet. They risk ruining a really good idea by hyping it so quickly.
Pingback: Disruptive Conversations
I wrote an article with other ideas, including some hints related to what you mentioned, but going much further : http://spoirier.lautre.net/beyond-google-wave
But I don't agree with your claim: “Google Wave has no way to group your contacts together to build the equivalent of mailing lists”. Indeed, you can form the equivalent of a mailing list in the form of a single wave: you can then bring more news to the list by adding contents to the wave, with no need to create another wave.
You could build a wave with the group and just continually modify it.
However, if you're working in a collaborative group, it is unlikely you'll
only ever work on a single topic. If the entire subject matter changes, or
you're working on a new project with those folks, you would lose all the
work on the previous project if you were to use the same wave and overwrite
it with the new project/content.
OK I integrated your remark in my article. Now, as for my other ideas, what do you think ?
Your article is quite comprehensive indeed. My thoughts still remain very much the same on the topics I've discussed here.
For one, I think that email needs to be better integrated than what you've described. You are proposing that someone could be invited via email to a wave. However, in order to participate in the conversation they still need to join the wave. If they don't have a wave account (somewhere, assuming we are talking about a federated environment) yet, this is a big hassle.
It is a lot like if you get an email from someone sending you pictures posted on XYZ Picture Hosting service. However, if you want to see the pictures you need to sign up for an account. This is a major pain and a lot of people won't bother with it, so you will lose a lot of participants.
I think your idea of creating a “tsunami” for containing other waves for use within a group will work. It is definitely better than using a single wave and continually overwriting it. It would still be better to have group contact management, but the tsunami concept is a good workaround to use until Google (or someone else) implements better contact management.
You missed an essential point of my concept. Maybe I should insist that, in what I envision, email users could reply by accessing the wave by a simple click, with no need of any formality of wave account creation. I define this as another use (a marginal one, just for the transition to the end of email), of the very foundational feature of my project, which is that any user of any site of the federation could directly access and use all the other sites of the federation, with the illimited accumulation of possibilities every specific site can develop in itself, with no need to create more accounts. This is a very new feature as compared to the whole hassle of the web we are all used to bear as a fatality (creating as many accounts as you need to use independent services). But this usual hassle is not a fatality, since a general technical solution is possible as I explain, and can be directly developed (in fact, it is supposed to have already been done by the developers who previously worked on my project, but I'm afraid this code may not be good enough for reuse). This can first be used as another way to have conversations between users of different sites, but its usefulness can be much wider. As I explained in my article, this feature would also solve the currently pending dead-end of Wave, which is that any link to a public wave you would like to include on a web site of blog, pointing to a different host's than the visitor's provider, would not technically let them directly access it with their usual account.
I agree that Google Wave has poor contact management (especially as far as grouping is concerned). As far as access control is concerned, as must as I would like to see it implemented (it would be a great feature), it does not make Google Wave “not ready”. Email in its current form does not have access control. You can send the email to whoever you please. Furthermore, the nature of email does not allow you to remove participants. Yet all of this does not make email not ready for release. Revision control is the same thing.
In other words, while I must agree all the features you listed would be really helpful if they were implemented, but it does not make Google Wave any less “ready” for the public.
Your article is quite comprehensive indeed. My thoughts still remain very much the same on the topics I’ve discussed here.
For one, I think that email needs to be better integrated than what you’ve described. You are proposing that someone could be invited via email to a wave. However, in order to participate in the conversation they still need to join the wave. If they don’t have a wave account (somewhere, assuming we are talking about a federated environment) yet, this is a big hassle.
It is a lot like if you get an email from someone sending you pictures posted on XYZ Picture Hosting service. However, if you want to see the pictures you need to sign up for an account. This is a major pain and a lot of people won’t bother with it, so you will lose a lot of participants.
I think your idea of creating a “tsunami” for containing other waves for use within a group will work. It is definitely better than using a single wave and continually overwriting it. The tsunami concept is a good workaround to use until Google (or someone else) implements better contact management.
I agree with your suggestion, but your headline? Come on… Co-creation is the basis for a lot of software development. Google is putting a product out there and letting people test it out so they can do exactly what you are doing: identify its shortcomings so that Google can make it a better product. To that end, Google Wave clearly IS ready. The groundwork is set and now Wave is ready to be tested by early adopters who can help identify the features of the product that should change/be added/be removed.
A really great post, well written, bang on target and very informative. But it missed the MOST important point. Unless you sit here glued to it (like a really need another program like that), it doesn't announce the arrival of a new message. It needs something like the TweetDeck ping, maybe a sort of soft whooshing noise (since its a a wave), but something, ANYTHING, to let you know there's been some activity. Then with this MOST important point, and all the other irrelevancies you mention, its a 'Twitter Killer'. Why put up with all that meaningless crap in 140 characters or less, from anyone and his dog, when you can have meaningless crap from only those you decide in as many characters as the buffers will transmit. Which, by the way, something tells me is going to be its downfall. Buffering several hundred thousand messages is one thing. Buffering several gazillion keystrokes is quite something else. We shall see.
Yeah, lack of notification is another issue as well.
I wouldn't call Google Wave a “Twitter killer” though. Wave and Twitter
serve different purposes. Twitter is a poor communication tool for the
reasons you mentioned. If you want an open dialogue with someone, Twitter
is not the medium to use. You would probably use email or instant
messaging, or Wave.
Twitter is really more for sharing small bits information than it is
collaboration and communication. If Twitter ever dies, it won't be because
Google Wave killed it.
Just as long as something kills it… 8^)
Did you see the pole that Guy Kawasaki ran about, if they decided to charge for it, how much would people be prepared to pay? Do you know what 60%+ of the respondents said? They'd pay for it not to exist at all.
lol
No, I didn't see that. It still boggles me how and why it ever became such
a popular service.
All absolutely true, but as Google says, it's a PREVIEW, and can be BUGGY!
It's like alpha code. No-one expects it to be perfect.
Pingback: Connected Well » Novell Pulse Enables Inter-Company Collaboration via Google Wave
1 reason why your article is pointless – wave is in limited preview. Advanced new web technologies always go through a rough start, just go hit twitter right now and see if the servers are crashed to see what i mean. you're not doing anything productive about it, just whining about something you want to add, enjoying a ride on the google-bashing bandwagon (they're not Windows ME just yet, here), and enjoying some nice web traffic off of people's google wave searches because of your catchy “5 things” gimmick. sometimes numbered lists work, and sometimes you look like the MSN homepage.
I understand Google Wave is just a preview. It doesn't change the fact there are still some missing key features. That being said, Google Wave has come a long way since I wrote this article last October.
They have since added some group functionality as well as revision control, which is definitely a step in the right direction. They've also added email notifications, so that at least now there is one direction of legacy support. I have been using Google Wave to track progress with the Android on HTC project, and it has been great. Google Wave is excellent for use in specific collaborative projects.
1 reason why your article is pointless – wave is in limited preview. Advanced new web technologies always go through a rough start, just go hit twitter right now and see if the servers are crashed to see what i mean. you're not doing anything productive about it, just whining about something you want to add, enjoying a ride on the google-bashing bandwagon (they're not Windows ME just yet, here), and enjoying some nice web traffic off of people's google wave searches because of your catchy “5 things” gimmick. sometimes numbered lists work, and sometimes you look like the MSN homepage.
I understand Google Wave is just a preview. It doesn't change the fact there are still some missing key features. That being said, Google Wave has come a long way since I wrote this article last October.
They have since added some group functionality as well as revision control, which is definitely a step in the right direction. They've also added email notifications, so that at least now there is one direction of legacy support. I have been using Google Wave to track progress with the Android on HTC project, and it has been great. Google Wave is excellent for use in specific collaborative projects.
That is a good tip particularly to those new to the blogosphere.
Brief but vwry accurate information… Thanks for sharing this one.
A must read article!