I think the problem is that Wave is, fundamentally, a "Jack of All
Trades, Master of None" platform. It tries to replace e-mail, IM, and
office suite groupware and doesn't obviously lend itself to any one of
those tasks well enough to market itself.
Google could have probably mitigated that by working to clearly
demonstrate its usefulness in various use cases (eg. as a
collaborative brainstorming and writing tool), but I got the
impression they just said "Look at this cool thing we made! Help us
find uses for it!"
Wave as a protocol is still useful... it just may need a variety of
more specialized clients on top of it to really shine.
On Sep 4, 9:57 am, Alex <a...@realtyna.com> wrote:
"Jack of All Trades, Master of None". This is a common assumption.
What I agree on is it didn't meet expectations in in it current form
was not usable (just because seasoned users can use it in chrome
doesn't mean it is usable, seasoned geeks aren't always the best
judge), and was essentially always going to fail, because it was a a
rough diamond, and largely entwined in a subculture (firefly).
Although that was sort of an in joke that was really at the heart of
the issue. There isn't another Google product I can think of that
doesn't have in the name what it is for. The team were naive in
thinking that it would somehow magically find it way, and they should
have had help developing into a nieche implementation and directly
targeting a specific type of use. Only then can you build on that. A
wize person once said ther is no such things and the "mass market".
You have to start somewhere.
However Wave as a concept isn't so much a replacement email. it is
more significant than that, it is more on the level that the internet
is in relation to the telegram. But a lot needs to be worked out
first.
"Wave" should not be uttered outside circles developing wave service
or client. That isn't relevant to the user base. What is important is
it improves the way they do things. There need to be an intuition to
using it, but an enhancement as well.
Another reason why it failed is ironically it was limited by it own
freedom. It is typecast into a use which at worst is dubious because
of the limited Access Controll. However I also agree that just putting
a bunch of arbitrary AC setting could actually make things worse,
because you are potentially limiting how it might be used in the
future.
I had some really blue sky ideas public via proxy with publishing
agents, etc to try and provide a more ad hock approach to what wavelet
interaction actually means for a user. of course this is not a trivial
thing, it has to federate, and federate simply without without the
need for stipulation, and also it can't afford to be too slow for the
users. Also how much to do on trust? One the idea to speed thing up is
to have distributed agents, which would be a condition of publication
for that federation (there can only be one PvP agent added by whoever
creates the wave), in other words if someone doesn't include that
publishing agent they can still federate with that service (that uses
publishing agents), however the service doest have to publish it in
whatever form, nor has to take pride of place within the concept of
that wave service concept. Publishing agents allow wave to be
meaningful within a specific context. because users do actually have
certain exceptions within a specific context and it is not always free
for all. if a service provider, doesn't distribute in good faith, then
you can always decide not to federate with them. Publishing agent
versions could have a checksum. The original issuer may chose to
update and this will be distributed to replace the existing agent
version. Perhaps a more egalitarian or flexible way needs to be worked
out in some instances.
RPC is all well and good. But you may want to be able to distribute
something that will run as an agent for the wave in a sandbox
environment, it takes the weight off a single service provider, and is
faster for the participants.
How do you decide what form this would be distributed in. Well it
could be javascript after all this is exactly what web apps do to
distribute an "agent" of the app to the client (browser). So it is not
really that far removed to distrubute agent to wave providers.
Some agent don't need to be distributed such as "spelly", that is a
luxury or considered part of the interface. However the idea of
publishing agents is as above make sure interaction works as expected
for that context. This in itself will increase the use cases for wave,
and the inflexibility born out of freedom has definitely been a
stumbling block of wave.
I like to think that Wave hasn't failed, if it will survive as WiaB
and on Google Apps. It *will* survive on Google Apps, right?
I know these aren't simple things to achieve, but I think Wave failed
as a mass appeal tool is because
1. Nerds like me were raving about it, realizing its potential, but
users didn't get it. So, better marketing.
2. People thought it was some fancy IM with other stuff they didn't
get. Again, marketing.
3. Interface. While I didn't mind it, yes, it was a "programmer" UI.
4. It was out of reach.
4a. Put it into GMail and make it a default messaging system for
contacting other GMail users. Buzz was pretty bold with automatic
changes (yes, even when it resulted in lawsuits), so I think that
energy could have been used to propel Wave.
4b. Email compatibility. Transfer nested replies into text. Send an
email with full text of Wave posts.
5. Server availability. If I can't type "sudo apt-get wave-server",
it's not going to be the next email.
6. Client availability. If it's not in GMail, Outlook, and on my
BlackBerry, it's not an email replacement. (Yes, I know Google's
stance "we don't have time to develop for crappy BBOS browser", and I
agree with it. But rich-client are sadly not dead yet. Google is a web-
first company, but serious, email isn't.)
7. Twenty years back, email was a riot. Also, you could send an email
to *any* email address and it worked. Now, we have a huge information
overload, and channel overload. I have friends that check email once a
month, but are on facebook daily. It's a busy, highly competitive
market (for lack of a better word).
/blog
That said, I still trust that Wave (or a derivative) will succeed as
the next email, only it will take another decade.
Oh, and thanks to Google Wave team for all the hard work, and for
finishing the job with WiaB.
I know why I haven't used Wave more often -- I simply didn't have the
right contacts in. I remember sending invites, and getting only few
people register.
On Sep 7, 1:38 am, Stephan Sokolow <stephan.soko...@gmail.com> wrote:
> I think the problem is that Wave is, fundamentally, a "Jack of All
> Trades, Master of None" platform. It tries to replace e-mail, IM, and
> office suite groupware and doesn't obviously lend itself to any one of
> those tasks well enough to market itself.
> Google could have probably mitigated that by working to clearly
> demonstrate its usefulness in various use cases (eg. as a
> collaborative brainstorming and writing tool), but I got the
> impression they just said "Look at this cool thing we made! Help us
> find uses for it!"
> Wave as a protocol is still useful... it just may need a variety of
> more specialized clients on top of it to really shine.
> On Sep 4, 9:57 am, Alex <a...@realtyna.com> wrote:
> > I think the reason for failure of Google Wave are these :
On Tue, Sep 7, 2010 at 5:23 PM, x00 <dt01pqt...@yahoo.com> wrote: > There isn't another Google product I can think of that doesn't have in > the name what it is for.
Android isn't for androids (yet). Google Chrome isn't for making metal alloys. Picasa isn't for whatever a picasa is. ;-) They're all successful products. I don't think the name was Wave's undoing. And ...
On Wed, Sep 8, 2010 at 11:55 AM, Milan Brezovskı <analy...@gmail.com> wrote: > I like to think that Wave hasn't failed, if it will survive as WiaB > and on Google Apps.
Me too. :-) I'm looking forward to the Firefox of Wave.
I think it mainly failed because of missing integration into "oldschool" technologies.
These integration needs to be done in certain levels of depth. From adding views of a wave in blogs, cms and wiki software which is widely spread and has lots of different user scenarios. To replacing the background infrastructure with wave. think of wordpress or mediawiki with the same appearance on the front end but a wave-storage in the back end. also a mail and chat integration which gives users the possibility to view and edit waves in their "normal" clients would be helpful.
Problem with wave was just it was judged too soon.
It was primarily a protocol...yet only one interface for it was
judged, and only after a few months of being
public with nearly no advertising. I think expectations were simply
too high to get lots of users too soon.
And the name didnt help....Wave is a great name. But calling your web
client, the protocol itself, and threads within it all "Wave" is
confusing.
On Sep 9, 12:54 pm, t <accoun...@gmail.com> wrote:
> I think it mainly failed because of missing integration into "oldschool"
> technologies.
> These integration needs to be done in certain levels of depth.
> From adding views of a wave in blogs, cms and wiki software which is
> widely spread and has lots of different user scenarios.
> To replacing the background infrastructure with wave.
> think of wordpress or mediawiki with the same appearance on the front
> end but a wave-storage in the back end.
> also a mail and chat integration which gives users the possibility to
> view and edit waves in their "normal" clients would be helpful.