Archive for June, 2009

The Waves are rolling in

June 7th, 2009  |  Published in Commentary

Ok, so as I’ve been at I/O 2009, I now have the luck to be a Wave Sandbox Account holder. Until now, most observations around my trial runs with the Wave Client revolve around minor bugs and annoyances (like not having any contacts to talk to with this shiny toy).

But then again, there is one new idea for a wave application/robot/gadget on my mind per day.

While I won’t find the time to implement them all, I might as well jot them down here and see how long it takes for them to be implemented by somebody:

Legacy System integration
Although there is a Twitter search bot, most other current systems are not yet integrated with the Wave Protocol. To make the Wave Client a true “one inbox to rule them all”, there are some obvious knots to be tied:
  • Email – sending messages to a Wave account via email, syncing your current email contacts with Wave contacts and sending out messages to non-wave users.
  • RSS/Atom – using a Wave Client as a feed reader: write a robot to take an RSS url or an OPML file and push new feed entries into the current Wave.
  • ICQ/AIM/MSN/Jabber – same as Email, but for all Instant Messenger Protocols
  • Twitter/Friendfeed/Backtype – write a robot to auto-post all conversation threads as wavelets that revolve around a certain hashtag/blog post/tweet/blip/URL: no matter if they are on a Movable Type, WordPress, Blogger blog; Twitter, Friendfeed, Facebook, or brightkyte. Take Backtype/IntenseDebate or Feedly as an example/inspiration.
WordPress Publishing Robot / Plugin
As some have pointed out the diffculties of SEO on a wave, I would just go the same route as the existing “Bloggy” robot: Publish a wave to an existing WordPress Blog.
Result: your custom look, a great interface for writing and edits and (possibly) a moderation panel for below-the-fold or even inline comments. I remember an experiment using YUI for displaying comments at a certain line withing a regular blog (and can’t find the damn link).
But then again, do we really need our own “view” on contents or discussions? Have our own logo, colors and fonts attached to a certain thought?
Let’s see in the next examples.

Wikipedia Editing powered by Wave
As with any Wiki, concurrent and simultanious editing is a bummer: In comes the Wave. If there is a Robot/API/Frontend for editing regular Wikipedia content, current contributors could swarm into a certain section or article and redo it based on previous discussions. The discussion around the artcle itself could be handled in a linked wave.
Although the notion of 25 people re-editing an article at the same time might make watching it “live” impossible, the replay-feature and the usable WYSIWYG editor can ease the influx of new contributors to the project while circumventing the challenges the other 95% face.

Additionally, while lots bemoan the chaos of a “traditional” wiki, especially the Wikimedia community has found the right means to organize around content creation.
With LiquidThreads never properly integrated into core Wikipedia, Wave as a protocol, frontend and delivery mechanism for discussion could become the engine of an even sharper growth of the content base.
And in case this approach (due to corporate sponsorship by Google) is not realized onsite, all contents could be ported into a mixture of Knol, Squidoo, Wikipedia, Mahalo and SearchWiki.

Realtime Answer Services
If there’s something you want to know that has only one answer, who/what do you ask? Google, Wolfram Alpha, your Twitter/Friendfeed/IM buddies?
How about a Wave Robot that dispatches the question in your blip to Aardvark, Twitter, Friendfeed, Wolfram, Bing, Wikipedia, Yahoo Answers and (depending on niche, services like Stackoverflow)?

Wave Edit/Update Handling
As a Wave client user, one thing about the realtime updates can make handling a large volume of waves impossible: minor updates.

Since logging into Wave for the first time, the test waves sent to all users have been edited several times: typos, formatting, wording etc.

The big question: Which of these updates is important enough for me to be notified about? And who decides this?

I’d suggest measuring the relevance of updates in a ratio of delta/length of blip. So, if you add a new blip to a wave, I get notified, but if you edit 5 characters of a 500 char text (1%), I won’t be pinged about it. As engineers, the Google guys should figure out the right ratio/percentage, but I’d like this as a setting for the client as well.

That’s it for now about the Wave.

The takeaway: With Waves, content is king. Whatever you write will be scanned, sliced, diced, enhanced and published allover the web. All in realtime.

Add your own ideas and comments below and follow the discussion: