Last night Pamela Fox, from Google, gave a really good presentation on Wave Robots and the new Wave API. The session was full of gems. In this post I cover a few of them and include links to a live-wave of the presentation, a video recording of it and other resources.
The event went on for two hours (i.e., I took seven pages of notes) and we probably could have kept going. What made it work so well is that Pamela is a really good communicator, well versed with the technology and did a great job representing the thinking inside the Wave team. All of this amounted to well thought out answers for every question.
UPDATE: Pamela’s Response
Evidently, there already is a commercial implementation of a very different Wave UI by Novell called Novell Pulse. I don’t know any more about it than what their product page says (and what I read in some of these articles).
There was a lot of interesting in when will Wave support more sophisticated state management (labeling and branching, in source control terms). Evidently, there are plans for that but no specifics of when we’ll see those changes.
The interesting for me was to learn that at it works currently, Restore simply copies that state as the most current state. No information is cut out of the wave. In other words, if you simply open the Wave, you’ll start at the “restored” state, but if you replay it, you will see changes that took place after the restore operation.
Nothing but Wave
Pamela mentioned that the Wave team no longer uses Google Docs or Gmail.
Later, we came back to the issue of email and Wave and evidently there doesn’t seem to be a single view within the Wave team. There’s still a lot of brainstorming and competing approaches in the air.
Every Wavelet and every Blip has its own ID. This offers great possibilities for the future (e.g., linking to individual blips) but it also has a lot of scalability implications.
She mentioned “the OT algorithm.” Not knowing anything about it, I looked and found a bunch of references to the Operational Transformation algorithm (that I still have to check out myself).
Robots, Machines of Loving Grace **
Robots and Waves communicate via Jason, not XML.
The new API provides more event types that Robots can sign up to.
By default, Waves send Robots the Root, Self, Parent and Children blips. In the new API, you can also set the context to ALL (yeay, finally!). Evidently, they had a lot of requests for this.
You can also set filters. These are really event triggers defined by regular expressions. The server uses this to select which blips to send to the robot but it sends the whole blip (i.e., not the result of the regular expression as I first thought).
Operations include modify tags, reply, add participant (to blip), create wave and fetch wave.
It used to be that Robots could only be driven by Wave events. With Active API Robots be driven by internal or other events (e.g., CRON job, interactions with another application or service). This is a big deal.
Robots can proxy for users, although they cannot impersonate people. The example she gave was of a Twitter robot that renders tweets as blips and they look as if they came from the user. It shows the user’s avatar and Twitter handle. However, when you inspect the Robot’s profile, it is clear that this was posted by a robot in behalf of the Twitter users. This facility let’s Robots make the UI that much nicer and intuitive.
Pamela showed a couple of examples of integration between third party apps and Waves. She showed how Livenote converts text notes into Waves; another app lets you do that from IM. A neater and more practical example was of using Github’s post-commit hooks (i.e., webhooks!) to post back to a wave to keep track of commits.
She also showed a Chrome extension that she created that converts clips from a web page into a Wave with the highlighted text and the page’s URL. This is just a quick demo she put together at the hackathon (at the Hacker Dojo?), but it gets the idea across of what’s possible with web pages.
The Wave UI loads the browser’s DOM with lots and lots of objects, however many there are in a wave (and that can be a lot). The obvious side-effect of that is that it really slows the UI performance quite a bit. For example, I am on several public waves that are almost useless because they are so slow to render.
They have plans to “page” the objects to speed things up. This will also make the GUI more practical for mobile phones and other low bandwidth/performance platforms (e.g., IE right now is 12x slower than other browsers when it comes to rendering and manipulating waves).
Blip size is limited to 10MB (20MB?). If you have a blip bigger than that, the server refuses to let you do anything with the Wave. This happened to a Wave I was in. Pamela’s guess is that the Root blip got too big.
More business-oriented robots are on the way.
An App Store?
When she was talking about the Extension Gallery (it’s a hack), somebody asked about an App Store. “Never mention App Store,” was her first reaction.
Then she explained the difficulties presented by their current architecture where every participant in a Wave has an ID—doing this now would create significant scalability problems. They’re working on resolving it, though, because it is very important that they come up with a solution.
Besides the scalability issues, they want to do an App Store the “wavey” way and it’s still not clear what that looks like.
She also mentioned that it will be much easier to monetize Robots than Gadgets because the former don’t disclose their source code, whereas Gadgets are just XML markup, open to all to see.
Email (Oh, boy!)
This discussion was the most surprising to me.
Almost in passing, Pamela mentioned that the “they tried for a year to bring email inside of Wave.” I was really taken aback by this because it showed that the team really (really) believed that “Wave is what email would be if we were starting today.” It seems that they were so captured by this “XXI Email” paradigm that they failed to fully see (for a year, at least) the true potential of what they had built. Email is but one of the many modalities encapsulated by Wave and to invest a year of this team’s time on it seems like a real waste. I understand the motivation to hook Wave up with a very popular Gmail but it still strikes as a waste of effort.
Maybe it’s just me, but even now, there still doesn’t seem to be one clear direction/position for Wave vis-a-vis email.
UPDATE: Exporting from Wave to MS Word
One question that came up several times was about exporting form Wave and I just noticed a post in Timothy Brown’s blog: Exporting Material from Wave to MS Word 2007. I thought it made sense to add a link to it here.
Thanks for Making It Happen
It was organized by Lawrence Wong with the help of Robert Schwentker who also live-waved the event.
Here’s the Google Wave for this event.
Here’s are links to some related posts,
- Tools we use at Nearsoft to create a remote presence, including Google Wave
- My take on the significance of Google Wave as a game changer (it will help you understand why I was so shocked by the fact that the Wave team spent a whole year on email integration).
- Previous Google Wave Meetups in San Francisco and the South Bay
If You Are Still Reading…
Thanks! And if I missed/mangled anything, please point it out in the comments and I’ll incorporate it as an update. Or you can send me an email at [email protected]
Otherwise, please RT!