Experience the World’s first Google Wave SVG Editor Gadget

We were the first to let you know about Vidar Hokstad’s Google Wave Gadget Emulator. Vidar has taken it a step further and now offers a full blown SVG editor that works in Wave’s character-by-character” collaboration mode that we all fell in love with so much.

If you want to play with it right away, fire up the Google Wave Gadget Emulator, type in “svg-edit.xml” and hit the “load” button.

With so much hype related to Google Wave available everywhere, we thought it might be worth your time to share some more technical details, which might be too technical for some of you, and asked Vidar to give us a little bit of an insight.

Here we go:

Basically to write a Wave Gadget you need to put together an XML file describing it. The bulk of that XML file is HTML and JavaScript that gets loaded in it’s own frame. Within that frame it has access to a gadget and the Wave API. This APIs provide the gadget with a few simple methods to obtain participant information (not currently used by the SVG Editor) and to retrieve the current state and submit deltas to the state.

To adapt the SVG Editor Vidar started by stripping it down to its bare essentials. He removed some of the tools both to make it easier to work on and to make it fit in less space. He then had to make it both submit state and handle state updates. Luckily the editor was structured in a way that made this relatively easy.

When users add a new object in the editor, it calls separate methods to add and update the attributes of the nodes. When one participant is done creating an object the gadgets state is updated with a JSON string representing all the attributes.

Vidar had to make a few other changes to his code, such as creating a participant-unique ID for the SVG objects – the editor used to give ids like rect_45, path_46 etc. – now it gives id’s like svgob_2_56 where “2” is the id of a participant in the wave and “56” is just a counter that’s incremented for each new object that participant adds.

The remaining part was to let the gadget handle state updates. The Wave API provides callbacks that will be called when the state changes. This callback just had to iterate through the state and update the SVG objects from the provided JSON. Future enhancements would probably for starters be to add back more of the features from the original editor, and add load/save ability (post to a website/ load from a URL), and support for more “fancy” SVG features like gradients.

We’ve also asked Vidar about his opinion on Google Wave:

“I’m not interested in the “Wave will replace e-mail” meme. Personally I think that fundamentally misses the point. People still use e-mail for “instant” communications despite instant messaging. People use IM for long discussions that’d be better done over e-mail. People use e-mail for “voting” when both IM and other solutions would work better. And so on.

Communication is dictated more by social conventions than by tools, and the tools needs to bend to that.

Wave in it’s current form can take over some of the modes of communication that e-mail currently covers, but it raises a number of issues: Archival; ease of searching; ease of browsing; threading; sorting; quickly seeing order (e-mail: one glance; wave: playback…) and a sense of “immediacy” that may follow from the “see people typing” part (immediacy is often why people use e-mail for things suitable for IM: IM is seen as more disruptive and intrusive).

What interests me is that it creates a platform that people can build tools on. Gadgets. Robots. Servers with custom policies for archival, search etc. Nothing says that Googles Wave client will even remain the dominant one for long after launch. What’s disruptive is having an open, federated protocol for real-time collaborative document editing (where document is anything that can be represented as XML).”

Vidar has taken these thoughts further in his very interesting article “It’s new but not new“.