August 7, 2009
What Works: The Web Way vs. The Wave Way
Google Wave is an impressive set of technologies, the kind of stunningly slick application that literally makes developers stand up and cheer. I've played with the Google Wave test sandbox a bit, and while it's definitely too complex to live up to the "this will replace email!" hype that greeted its launch, it certainly has some cool features. So the big question is whether Wave will succeed as overall in becoming a popular standard for communications on the web, because Google has made an admirable investment in documenting the underlying platform and making it open enough for others to build on and extend. I think the answer is no, and the reason is because the Wave way is not compatible with the Web way.
What do I mean by "the Web way"? Well, if we look at the history of new technologies being adopted to extend web sites and enhance communications, we see a few trends emerge:
- Upgrades to the web are incremental. Instead of requiring a complete overhaul of your technical infrastructure, or radical changes to existing behaviors, the web tech that wins is usually the sort of thing that can be adopted piecemeal, integrated as needed or as a normal part of updating one's websites or applications.
- Understanding new tech needs to be a weekend-sized problem. For a lot of web developers, long before they start integrating a new protocol or platform into their work, they hack together a rough demo over a long weekend to make sure they truly grasp how it works. And a weekend-scale implementation on a personal site usually translates roughly into a 90-day implementation cycle in a business context, which is a reasonably approachable project size. (In tech, three days in personal effort often translates to three months of corporate effort.)
- There has to be value before everybody has upgraded. This is basically a corollary to Metcalfe's Law. While we know networks increase in value as they add more nodes, the nature of web tech is that, in order to be worthwhile, it has to provide value even if the people on the other end haven't upgraded their software or web browsers or clients or servers. Otherwise you're shouting into an empty room.
- You have to be able to understand and explain it. Duh.
Now, if we take a look at some examples of what has worked, we can see how various successful technologies have displayed these traits. One great example is feeds. When RSS feeds were new, it was easy to understand their potential immediately, and since I was working at a newspaper at the time, I just spent an afternoon understanding the format and hacking together a quick feed of headlines that anybody could subscribe to. If nobody had adopted feedreaders yet, that was no problem, since there was no cost to just having the feed sit there with no subscribers — the "nobody's upgraded" problem would only result in me having wasted a few hours.
Ajax had a similar adoption pattern. It took a little bit more time to comprehend, but not much more than an afternoon, and the development effort required for adding Ajax enhancements to an application started as a weekend-scale project and has only gone down over time. Following the principles of progressive enhancement, well-designed implementations performed just fine on older browsers or systems that couldn't handle the new features. And most sites that have added Ajax features have done so by adding the requirements as a checklist item in the course of normal ongoing updates, not as standalone efforts to migrate to a new technology.
![]()
This brings us to Wave. Wave offers excellent opportunities to extend its core features and to add richness to its "wavelets", and I have no criticisms over its utility as a developer platform that third parties can build upon. But the fundamental Wave protocols are, I fear, a bit too complex to ever be fully and correctly implemented by anyone other than Google. Interoperability is likely to be a challenge that plagues the platform for its entire existence. In short: It's likely that nobody will ever build a fully-compatible clone of Wave that competes with Google's own implementation.
Why is that true? Let's look at what's built in to Wave:
- Powerful realtime collaboration features
- Unlimited versioning of content
- Built around robust XMPP protocol
- Combines chat, document editing, and message threading — wikis + blogs + comments + IM
- Delivered as a very polished rich user interface
Each of these is a very compelling experience. But a lot of developers' reactions to seeing them was not just "I can't wait to use that!" but also "I want to add that one feature to my own existing application!". And that's where it gets tough. Let's take a look at Joe Gregorio's list of the protocols that power Wave. (Joe works at Google, but made this list before he was working on Wave. I appreciate his research and openness on this topic, and presenting his work here is a tribute to what makes Wave great, not a criticism of his effort.)
- Federation (XMPP)
- The robot protocol (JSONRPC)
- The gadget API (OpenSocial)
- The wave embed API (Javascript)
- The client-server protocol (As defined by GWT)
That's a lotta stuff! XMPP alone is a bear to implement, let alone to deploy at large scale. (I can't think of anyone outside of Google, Earthlink and LiveJournal who have deployed XMPP to millions of users.) But if you wanted to make another application that truly interoperates with all that Wave can do, combining all of these pieces would just be the starting point.
And people aren't looking for a replacement for email, or instant messaging, or blogs, or wikis. Those tools all work great for their intended purposes, and whatever technology augments them will likely offer a different combination of persistence and immediacy than those systems. Right now, Wave evokes all of them without being its own distinctive thing. Which means it's most useful in providing reference implementations of particular new features.
If a developer wants one of the compelling individual features of Wave, like near-realtime collaboration, they're more likely to use something like (wait for it...) Pushbutton technologies. The infrastructure afforded by the components of the Pushbutton Platform comes nowhere near the richness and polish displayed by Google Wave. Pushbutton isn't even designed to offer the benefits demonstrated by Wave. But to its credit, Pushbutton displays nowhere near the complexity of Wave in its interoperability requirements. More importantly, integrating Pushbutton features into a website or application isn't a monolithic process of building dozens of cutting-edge features, but rather can be deployed incrementally by even non-expert webmasters.
In this context, it might help to think of Pushbutton tech as a "micro-Wave". As Gina Trapani said in mentioning Google Reader's support for PubSubHubBub:
Huh-wha? you ask. Yeah, I know. It's no Google Wave. But that's what makes this exciting. This kind of small Pushbutton implementation is how real web pages will easily use existing technology to notify one another of new updates. The Google Reader/FriendFeed integration is just the first tiny step in what will be a broad deployment of realtime-enabled sites. These sites and services will let one another know when they have new data to share without the sucky inefficiencies of polling. Check out how fast FriendFeed updates when you share an item in Google Reader in the video above.
In short, it's almost zero latency.
Why is this clearly "inferior" technology going to win? Well, as just one example, XMPP is way too complicated for any normal human to deploy. Whereas if you're reading this, you probably already have access to a regular HTTP web server that could talk to a Pushbutton hub. In fact, the only two backers I know who have worked extensively with XMPP are Brad Fitzpatrick and Artur Bergman, who co-created Djabberd. And they are both excited about PubSubHubBub. Realistically, someone like Yahoo might try to do all of this, and inevitably one or two open source projects will try to lash together open implementations of each of these pieces to make a kind of FrankenWave application. There are probably already one or two teams working on the inevitable "Enterprise Wave Server" platforms as well, though I haven't heard about them myself. These efforts may succeed, but that doesn't mean they'll ever be robust enough that people will trust them for communicating on the web.
More to the point, I'm a regular blogger who knows a little bit about scripting on a normal web server. I can poke around the documentation and add a few tweaks to my RSS feed (or, in my case, do nothing and have Feedburner automatically handle it for me), and all of a sudden my blog's feed is part of the Pushbutton web, ready for others to build on. I literally wouldn't even know where to start with the Wave developer documentation if I wanted to integrate it with my site or any of the little apps I like to hack on during a long weekend. What seems more realistic — that someone will figure out a way to incrementally build on top of realtime feeds to enable Wave-like experiences, or that all this talk of Waves, wavelets and blips is going to suddenly become easy to understand.
In short, web-way tech like feeds, Ajax and Pushbutton win because people who make good sites and applications have a place to start with it. Does this mean we get fancy realtime simultaneous editing right away, now that Pushbutton exists? Nope. In fact, Wave might even get the early jump on those kinds of features for web apps, simply because it's pioneered that part of the user experience. But Wave only runs to its full potential on the most cutting-edge web browsers. And there may only be a dozen companies in the world with the in-house expertise to clone the entire complement of technologies underlying Wave in order to make a full-fledged competitor. Worse, the monolithic nature of the Wave experience means it will even be a challenge to make a full-fledged open source competitor to the official Google service.
I hope that Wave succeeds, because I love to see ambition and innovation rewarded. But I think it's mostly likely that Wave's success will be in inspiring people to create similarly compelling experiences by adding incremental enhancements to their existing sites. That's how the web's always advanced in the past.
Related Reading:
- The Pushbutton Web: Realtime Becomes Real
- The Pushbutton Web now in Google Reader (from Smarterware)
- My keynote session on Pushbutton, which will be at the upcoming Web 2.0 Expo in New York City.
2 TrackBacks
More great responses to some recent posts to recap, along with an interview I did a few weeks ago that seems to be pretty timely.... Read More
Twitter's API has spawned over 50,000 applications that connect to it, taking the promise of fertile APIs we first saw with Flickr half a decade... Read More
36 Comments
Leave a comment
- Earlier: Preconceived Notions and The Web As Water
- Next: On Fail
Thanks for this realistic perspective and analysis of Google Wave.
I don't have a lot of XMPP experience, is it really that daunting to implement?
Seems like there is a huge opportunity for someone to create an enterprise class Google Wave Server implementation that enterprise IT can adopt?
I strongly feel the success of Wave will be completely on the backs of the development community to explore, understand, innovate, and ultimately create solutions / tools that specific industries and audiences can understand and embrace.
We have to find specific ways to deploy and keep very simple for the masses.
I tried to get XMPP going once and there is a steep learning tax to pay.
I think Anil's point is that pubsubhubbub and webhooks are things you can add to a web application quickly, whereas wave integration is a whole new theoretical tangle.
Are you seriously saying that Google Wave is going to fail because it is going to be too hard to re-implement?
They have already released their protocol implementation as open source. So, the open source community should be able to modify it, clone it, and fork it however they want. They also have a free open source implementation that Google uses as a way to test for interoperability.
Google Wave's protocols aren't that terribly difficult. xmpp.org, for instance, lists 24 different server implementations (http://xmpp.org/software/servers.shtml), and there are *hundreds* of clients. In comparison to protocols like LDAP, Kerberos, TLS, etc. the protocols Google is using for this aren't even close to difficult.
Furthermore, I find it funny that you chose to compare this to something like RSS. RSS uptake is fairly low. Most normal people just don't "get it".
I'm not trying to say that Google Wave is going to replace email, or that it is the next killer thing in communication; however, I think it is going to have a *much* larger uptake than you are predicting.
You might have to implement all that stuff to run your own wave server, but not to add it to your blog.
Think about YouTube, you don't have to build a streaming video server in order to post a video on your blog, you just embed theirs. It's pretty much the same thing.
Even writing a wave "plugin" to support a new type of content is done with web-style api's, again, you don't need to reimplement (or even understand) the whole wave server infrastructure. You just need to write an ajax-style script that turns a chunk of xml data into another chunk of presentable html. The wave server (running at Google or wherever your wave host is) will handle all the heavy lifting of editing.
At least that's the promise. If all this works smoothly in the real world, I think it could be huge.
I think that what it is most important from google wave it is not the technology behind it, or how easy others would be able to replicate it. Neither its realtimeness. But rather the new way it will force us to think how we communicate on internet.
It is that concept of media integration between IM, mails, wiki, VoIP calls, and everything that we currently use to share or communicate, into just one consistent cohesive "wave" abstraction.
Think of that. Just being able to have this article, and this comment, and the other comments, and links to the article that I could send to friends, and IM chats about it, to have all that tied together, with context, stored for later reads or new chats/talks/edits or whatever. That is mindblowing
Thanks
The web is too big and what we do everyday on the web - not sure how wave would be able to support all those things easily.
Guess it might immediately support e-mail, IM, Orkut etc... but until developers develop super cool and simple to use applications on it, people won't be able to embrace it very effectively.
It would be interesting to see how google can implement it's search engine and advertising platforms based on wave concept.
I think that what it is most important from google wave it is not the technology behind it, or how easy others would be able to replicate it. Neither its realtimeness. But rather the new way it will force us to think how we communicate on internet.
It is that concept of media integration between IM, mails, wiki, VoIP calls, and everything that we currently use to share or communicate, into just one consistent cohesive "wave" abstraction.
Think of that. Just being able to have this article, and this comment, and the other comments, and links to the article that I could send to friends, and IM chats about it, to have all that tied together, with context, stored for later reads or new chats/talks/edits or whatever. That is mindblowing
Thanks
I see what you're saying, and to some extent, I agree. But overall, I think you're just underestimating the reality of how technology builds over time.
Look at the car for parallels.
The earliest cars were funky, strange designs, that hacking around on could really screw things up. Only the nerdiest of nerds would venture to mess around.
As the technology solidified around cars like the Model A, it was stable and easy for people to take things apart, learn, then put them back together.
For what? 40 years? car tech improved and increased in complexity, but generally was still able to be Shade Tree Mechaniced.
But today's cars are nearly impossible for mere mortals to do anything more than gas up and top off the windshield washer fluid.
As Web tech gets more complicated and as society relies more and more on this tech there WILL be a tipping point where mere mortals aren't able to hack around for a weekend. To deny this feels like yelling at the whippersnappers to get off their lawn.
Funny, I have a hard time believing Google Wave *won't* replace email.
The amusing thing is that reading this reminded me of my experience with Motion and Action Streams in Movable Type 4. I am not a programmer or a web guy, but I happily blogged for years with MT 3. MT4 seemed much more complicated/black boxy and much harder to theme/tweak using the default templates... and then Motion and Action Streams looked really cool, but the documentation sucked and they didn't fit into that weekend rule... I couldn't figure them out and even some of my geekier friends were stumped. My guess is Google Wave is an order of magnitude more complex than something like Motion and useful application of the technology for most of us mid-level bloggers will be years away.
Speaking for myself, I find email really frustrating for a lot of purposes.
And the question is not whether people are looking for a replacement for their existing technologies, but how they will respond to the new alternative that arrives.
@jake.communityguy.com pretty echoed my own thoughts. The complexity of Wave may cause a slow initial uptake, and will be limited to hugely intelligent nerds with way too much time on their hands. They will then build tools, frameworks, and interfaces for mere mortals like myself to more easily implement Wave technologies.
After all, isn't that what happened with PHP? It started as a toolkit to ease use of a much more sophisticated technology, and it significantly lowered the bar for entry for building dynamic websites.
Same goes for jQuery (and all the other javascript frameworks). I spent about a month in 2005 writing a browser-based image-cropping app with a draggable, re-sizable crop box. I wrote it in pure javascript, and spent many hair-pulling days trying to make it work in IE6 (!!!) and Firefox. Nowadays, there are dozens of jQuery plug-ins that will accomplish the same thing in 3-4 lines of code.
If Wave is as awesome as the demo led everyone to believe, the early adopters will build things to abstract away the complexity, and then we'll be off to the races.
I understand your point, but at the same time I feel that the web is due for change in a lot of ways.
Small incremental updates were only to compensate for what the web lacked, I think as HTML5 grows in adoption we'll start to see far more complex web applications thus something like Wave will be necessary.
For the current state of the web it may sound unnecessary but in the long term I think it will provide a lot of benefit.
And about this line
"...people aren't looking for a replacement for email, or instant messaging..."
I must differ, I'm sick of e-mail and instant messaging right now (I usually use Facebook to communicate with friends) I think Wave will fix that.
htylim says: "I think that what it is most important from google wave it is not the technology behind it...rather the new way it will force us to think how we communicate on internet."
I have to say I agree with htylim on this point: I’ve recently finished a series of articles that illustrate how this change in communication will manifest. The framework is termed “Social Tesseracting”:
“In _Social Tesseracting_: Part 1, we learnt that:
1. Dimensionality defines working concepts of reality.
2. Theoretically, dimensionality can also expand to define a spectrum of nascent social actions.
3. These particular social actions encompass communication trends defined by synthetic interactions.
4. Synthetic interactions create social froth that can be produced geophysically or geolocatively. Both connection types depend on relevant electronic gesturing.
5. This mix of synthetic interactions and electronic gesturing provokes a descriptive framework of this aggregated sodality. This framework is termed Social Tesseracting.
6. In order to adequately formulate Social Tesseracting, contemporary theorists need to extend “valid” reality definitions based currently on the endpoint of the geophysical.”
...an extract of one of these communication-changing social tesseractions/markers:
“e) Information Deformation: akin to process centering, this Social Tesseraction involves a shift in the very definition of information: ‘Information may be defined as the characteristics of the output of a process, these being informative about the process and the input. This discipline independent definition may be applied to all domains, from physics to epistemology.’
These deformed systems of data are constantly in flux and available for perpetual revision. Examples include:
* cloud-based applications
* constantly transliterated google waves.
Users are able to simultaneously modify, update and adapt their input in real time. This type of liminal practice results in a deformation of current information architectures. Although traditional information construction may be flexible over time, it still demands unitary data snapshots for knowledge formation. Deforming such data in real time acts to fundamentally alter meaning production. Socially structured input is the keystone of such a dynamic, perpetually fluctuating system.
Here the notion of Social Froth takes on a new level of importance: information becomes a constantly shifting construct with variable endpoints. Rewiring information in such a way radically changes its cohesive nature. This in turn effects:
* authorship
* politics
* communication and media
* education
* book publishing and academia [think: the perpetuation of potentially obsolete content systems]
* the scientific method
* disciplines dependent on referential instruction [think: History or Commerce].”
…and…
“g) Decline of Silo Ghettos: as information deformation impacts knowledge formation, there’s an increasing need to provide social tesseractors with comprehensive dimensional engagement. This type of borderless interaction deforms monostreams into cross-channelled productions. Social tesseracts assist in addressing the somewhat restrictive walled garden approach to software and platform production [think: the frustration levels encountered whilst experiencing the locked door syndrome].
Google Wave is one system that removes such constraints and allows users to input directly into previously distinct arenas. Other instances of interoperable systems that require the reorientation of Information Silos:
* augmented applications that encourage a pairing of geolocative and geophysical needs.
* bridging software that links previously disparate platforms together [think: IRC-to-Second Life Chat Bridge]“.
The series can be accessed here:
http://arsvirtuafoundation.org/research/2009/03/01/_social-tesseracting_-part-1/
Regards,
@netwurker [Mez Breeze]
Google's notorious for creating brilliant frameworks, toolkits, etc., that are so brilliant no one can figure out quite how to put them to use. Your point is well taken. It remains to be seen what'll happen, but you're right to point out that when the learning curve on any new technology is too steep, or just steep enough that the ends don't clearly justify the means, its days are numbered.
While I usually like what you have to say Anil, this time I couldn't disagree more.
First, there's no need for developers to use the entire stack of protocols to work with wave. Most likely people will build extensions (such as bots) that will interface with just one aspect of wave, through just one protocol.
It's great that Google have made it all open and accessible, but that doesn't mean you have to use all of it.
Many existing tools from other places can probably be easily ported with javascript and open social. That in itself should create a good ecosystem to start with.
Second, while most people probably aren't looking for a replacement to email, many definitely need one but just don't realize it.
Any team that is widely spread geographically or telecommutes uses multiple collaboration tools. That creates a new problem - keeping up with the conversations as they happen in so many places. Bringing even part of that together into one place would be just great.
This is a problem that we're having right now in my startup. We're using google apps anyway, so we're used to the idea of hosted email etc. But we also use other tools like wikis and skype, and I just can't wait for wave to be released so we can try to switch over.
Google is very good at making complex things, then making them simple for users. In a nutshell, that's what software development is all about. Wave may be a complex system with tons of features, but by the time it launches, I'm confident Google will have a simple marketing plan to get the general population to buy into it.
For the development community, Google has a number of avenues (some already implemented, some stated in the preview video, and others that are surely to come). For instance, they can make an easy, integrated abstraction layer with Windows services and Linux packages. Along the same lines, good API documentation, a full-featured SDK, and tons of code samples will go a long way. Lastly, their higher-level plugin system for their client implementation makes weekend-warrior hacking a reality.
I find this account short-sighted, as if http is the only acceptable protocol, that interfaces trump platforms, and that the software driving innovation comes from people who can barely tweak their RSS feeds. Accuse me of building a straw-man, but none of those premises are true.
It is interesting how much you stress the labor and learning curve of the developer vs. the end user's when critiquing Google Wave. RSS's adoption failure was due to a nearly universal poor user experience for consumption and discovery. However, Wave appears to be an accretive approach from the end user perspective, enhancing existing channels with real-time capabilities.
As for XMPP implementations, there are many sites who have wrapped and abstracted the complexity within their API stack, including drop.io, OMGPOP, and even Twitter's private "firehose". For one-off communications, yes, WebHooks and PubSubHubBub type solutions work great for basic web based callback mechanisms, but they aren't an extensible framework. We need both, just as we need JQery and Javascript, Rails and Ruby, etc.
This is a very thoughtful post which had clearly spurred a good conversation. I wanted to add my voice to those who made the point that the audience that matters are the users.
While I don't want to diminish the complexity of the implementation (not least because I haven't a clue about those technologies), I found the overall package extremely compelling. I can't wait to use it !
If there is an audience, the developers will follow. Look at the iPhone, despite all the grumbling, the uptake by developers has been unprecedented.
Also, starting the argument with "this will replace email" is a red herring. It doesn't have to replace anything. It just has to be great.
If it's possible to predict if Wave (or any other technology) will be a major success then it probably isn't radical enough to make a big difference (and vice versa).
So far we don't even know if folks will stick with many existing application such as blogging or social networks for long periods. When I was younger I listened to, and bought, a lot of music. For me, and many others it passed. Sitting at a computer for hours each day is an odd thing for humans to do. Long term I reckon it won't last.
Embedding works too - Anil.
The first part of this article expresses some general truths about success factors of new system deployment which I feel are worth reflecting on - regardless of their applicability to Wave.
Great constructive criticism - thanks for the writeup!
Meebo comes to mind for scaling xmpp/jabber as well - across their platform they service 45+ mm who use it http://www.quantcast.com/p-93vmRJG_BQlqo
Cheers!
I can't argue from what this costs developers. As a potential user, I like the idea of Wave. The way things are done today, there's very little integration of things. Take Twitter. To upload photo to share, you must use a separate non-Twitter site. So bringing that and more together in Wave is very exciting to me.
I think it will excite many other people too.
That said, if Wave winds up with a MySapce/FaceBook-size "usership," wouldn't that be an impetus for devs to tackle the difficult work needed to extend Wave?
... or in other words: Keep It Simple, Stupid (KISS).
alternatively, it *is* possible Google could provide the necessary incentive / adoption groundswell by implementing Wave-let apps & Wave support for it's most popular properties (YouTube, Gmail, Maps, iGoogle, etc). with anywhere from 100-500m+ users on those misc services, I'm pretty sure there would be *plenty* of motivation for lots of developers to pile into this Volkswagen bus of Geek Complexity.
(and let's just remember: the Windows API was no paragon of virtue to the Altar of Simplicity, but that didn't stop BillG from driving it onto 100s of millions of PCs... never underestimate the monopolistic ambitionof a powerful incumbent ;)
Anil, Nice article. Google Wave is more technology driven rather than customer driven so it's hard seeing it going mainstream or extending beyond early adaptors anytime soon if at all. It is fantastic to see this type of innovation and I believe that Google are doing all the right things (i.e. open protocols, open source wave server implementations) to push it along the adoption curve but there is a huge amount of friction to overcome starting with the technology stack. I totally agree that Google Wave will spur incremental, wave-like enhancements to the tools we use today.
Excellent Article! - I very much agree, that the simplest only survives on the web - and if a product tries to introduce too many new technologies, it will not be successful in a broad way - and do we really need all this to achieve the new communication paradigm?
> Do we really need a new protocol? - A simple http real-time streaming extension does the same -
> Do we really need a heavy, XML based application run on the client side? - The same can be achieved by a simpler form of Ajax, or even AJAH (HTML and JavaScript, streaming) -
The basic concepts of Colayer are almost identical to Google Wave, but Colayer runs on Web Technologies: See: Colayer and Google Wave, especially the Interview
Email is broken beyond repair.
All that needs to happen is for developers to create gateways between Wave and existing widespread technologies, especially email and IM. If done well, that will take care of the "everybody has to upgrade before it's useful" problem.
I think the issue is a different from the web, which has experienced huge leaps in content, browsing software, etc. You're right, that was incremental, but it's because the upgrade/switching costs were always small. You reaped more benefit by upgrading with very little tradeoff.
That hasn't been the development of e-mail. It's grown barely at all since it was invented, showing that it's not on the same incremental trajectory as the web.
Our communications growth has stagnated because of this, and now new forms are developing to replace it (Twitter, Facebook, Wave). It's because upgrading e-mail always involved high switching costs with little benefit. Even now a ton of different e-mail clients don't properly render HTML.
So Wave is necessarily an attempt to leap forward, because incrementalism has failed in this case.
Dashing insights Anil. :) Your 'Web way' analogy is profound. On similar lines but on a different level, in my blog, I have tried to analyze why Google Wave is not a pure web based application, as they claim ...
Hi,
I have created my response here .
/daniel
I'm not sure e-mail (or Facebook, or twitter for that matter) replaced any existing technology per se, more then they suited a need better then the incumbent were. Wave might, e.g., solve the issue of having too many social platforms to control, and not enough tools to separate contexts rather then service.
Regarding implementation (not being a coder it's hard for me to say, but) I was under the impression that modularity was what allowed you to tweak one bit you understood without making all the rest fall to pieces. Provided Google gives away enough code to inspire aspiring hackers.
— Bertil Hatt
couple of things:
first, thanks for dashing (no pun intended, really) my hopes of going to graduate school. this post, combined with your most recent on all of the change that's coming/has come to the .gov sites pretty much encompasses the core of what i had envisioned my imaginary dissertation to be. seriously, 3 different people all sent me to read your post as they've come to know my obsession with google wave, .gov websites, and most of all... user adoption of said communication tools.
second, you make a good point here: _"And people aren't looking for a replacement for email, or instant messaging, or blogs, or wikis..."_ but... while people might not be looking for a replacement for these things individually, i believe there is a problem to be solved here that does combine all of these mediums. in fact, i'd say finding the right all-in-one technical solution/medium for business communication has been a problem my colleagues and i have come up against every day of my working life since college. there are tools galore out there in the world, but none appear to be perfectly cohesive. honestly, google wave appears to be so from the outset, BUT, no matter how much cool stuff your magic new tool offers, and no matter that it might solve everyone of your communication challenges... it's nothing unless it achieves a critical mass of user adoption. so, what's the tipping point in terms of user adoption? the answer is probably pretty simple, but entirely different depending on the user group... anyhoo, all this makes me think!
thanks for this write up. i enjoyed it very much.
I am quite agree with your point of view.
Just read my post about Google Wave: Google Wave: more a collaboration tool than a communication tool.
Google Wave is currently more a kind of prototype which features could/would be included into next communication tools. At this point, Wave shows the way next tools may take.
Thanks for the article and your review. I have mentioned it on my own article, which is a roundup of early Google Wave reviews:
http://googlewavesucks.com/post/206311509/early-reviews-google-wave-sucks
Collaboration Review - Google Wave & TWIP: http://bit.ly/3viosc