Two years ago, I discovered the JavaScript InfoVis Toolkit, a really cool library for doing visualizations in Javascript, like force-directed graphs, hypertree, treemaps, sunbursts, and more. Since then, I've been looking for an excuse to use the library in conjunction with a Google API, and after our latest API release, I found the perfect use.

A few weeks ago, we released a new feature in the data and robot APIs: threads. This feature means that developers can render threaded waves in alternative clients and export waves to other formats while retaining their true structure. It also means that I can finally use the InfoVis Toolkit, in order to visualize the threads in a wave as a structured tree.

To create the visualization, I started with the code for the Inbox Checker sample, a Python App Engine app that asks a user to authenticate (via OAuth), and then shows them their inbox and any wave they click on. I modified that app to output JSON instead of HTML for each wave, and I piped that JSON into the SpaceTree class from the toolkit.

Here's an side-by-side example of how a wave might look like in the client, and what it looks like as a SpaceTree:

You can try the app out for yourself here: Wave Visualizer. After granting access to the app, you can click each of the waves in your inbox and browse the tree for it. As you mouse over each blip, you'll see a snippet of the content of the blip in the tooltip. When you click on a blip, you'll be taken to that exact blip in the Wave client, utilizing our other new feature: blip linking.
(You can also try out the "Timeline" view, which shows the sequence of blips over time, using the Google Visualization API).

This app shows off one of my favorite features of Wave - flexibly structured conversations. Some waves are very flat long trees, and others are wide and deeply nested, and they are all made possible by the Wave conversation model. And now, thanks to the new Wave data APIs, apps like this are possible.

Enjoy playing around with the visualizer, and if you have any questions about building apps like it, stop by the Wave API forum and let us know!

Posted by Pamela Fox, Developer Relations

As part of my Google I/O talk on "Anatomy of a Great Extension", I talked about the optimal look & feel for Wave gadgets. On one hand, if your Wave gadget is based off an existing website, like the 6Rounds gadget, then we recommend mimicing the UI of your website inside the gadget, so that your existing users feel like they're using an extension of your website into Wave. On the other hand, if your Wave gadget is independent and designed purely for Wave, like many extensions in the gallery, then we suggest mimicing the UI of the Google Wave client itself, so that users feel like the gadgets fit inside their environment, and so that waves with multiple independent gadgets look cohesive. To make that easier for developers, we've introduced a new feature to the Wave Gadgets API, the wave.ui library, which makes it easy to turn your gadget elements into wave-styled elements.

For example, you might start with an anchor with some javascript onclick behavior:

<a id="button" href="javascript:void(0)" onclick="doIt()">Do Cool Stuff!</a>

You can then call makeButton and pass in the anchor element:

<script>
wave.ui.makeButton(document.getElementById("button"));
</script>

And, presto, your button will be wave-styled like this:

The wave.ui library also offers the loadCss, makeDialog, and makeFrame methods, and will expand to include additional methods as needed by developers.

For examples of gadgets using the new wave.ui library, check out the Flammard bible bot, which uses makeFrame for a multi-tabbed interface, or the Google Maps gadget, which uses makeDialog for a welcome screen and makeButton for the info window buttons.

As usual, please let us know in the forum how you're using this feature and if you have any questions.

Enjoy wave-styling!

Posted by Pamela Fox, Developer Relations

Hilbrand Bouwkamp is an independent internet developer/trainer/presenter specialized in RIA, GWT and Android. He has been following GWT and Wave since it's first release and has created two open source libraries related to GWT and Wave: cobogw and cobogwave.This blogpost is about the cobogwave library.

As soon as Google Wave was released and I had an account, I wanted to write a Wave Gadget. I believe Gadgets are one of the strengths of Wave because they let you add a structured component to an unstructured communication flow to make things more efficient. For example, a simple date picker Gadget can be added to an event-planning wave, and instead of people having to go to a separate site and communicate their date preferences manually, they can do the date-selection in the wave, and all of the information is stored in a single place. There are many situations like this where gadgets can add structure and keep related information together.

Since the Google Wave client itself is build with GWT (Google Web Toolkit), I thought it to be natural to write a Gadget with GWT. To do that, I needed to wrap the Wave Gadgets JavaScript API with my own GWT JSNI wrapper. Like other GWT gadget developers, I wrote my own wrapper - but I wanted to do it in a way that other developers could benefit from. So, I made sure that my wrapper included all of the Wave Gadgets API functionality, I wrote documentation for it, and I open-sourced it under the Apache 2 license as the cobogwave library. Now, other developers can skip the wrapper-writing step and simply focus on writing their gadget.

The cobogwave library makes it very easy to build gadgets for Wave. Just like the iGoogle GWT Gadgets API library, it defines a Needs interface: NeedsWave. By implementing the interface, you can make your gadget code Wave-enabled. Or, you can simply extend the WaveGadget class for the same effect.

GWT developers are accustomed to work with handlers, so the cobogwave library provides much of its functionality via handlers. For example, you can register for the ModeChangeEvent to be notified when the user changes from playback to edit mode, ParticipantUpdateEvent when a new user is added or removed to the wave, and StateUpdateEvent when the gadget receives a new state. The cobogwave library also has support for experimental functionallity in the Wave Gadget library, like the Wave UI Widgets Button, Frame and Dialog.

Recently, I was involved in the latest release of the gadgets support in the Google API Libraries for GWT. In the new version, it's much easier to implement RPC calls to your own server, and this method also works for Wave Gadgets.

Here's a sampling of diverse range of gadgets that developers have built using the cobogwave library:

• Shortyz: Lets you solve crosswords together in a wave - ported from Android code.
• MindMap: Lets you create an interactive mindmap, and favorite nodes up or down.
• Karma: Lets participants in a Wave rate each other.
  
• Pongy: Lets you play the classic game "Pong" with a fellow Wave user. (This last gadget was written by me to showcase the highly interactive possibilities of Wave.)

To start building your own Wave Gadgets with GWT, visit the cobogwave project page and to keep informed on updates, follow me on Twitter.

Posted by Hilbrand Bouwkamp, Community Developer

When I heard that Australia was going to have its very own PyCon, I knew I wanted to give a talk. While working on the with the Wave APIs over the last year, I've gotten to the point where I'm using the Python client library on a daily basis, and I've learnt a lot about Python from our library. I wanted to give a talk that would be interesting both to Wave API developers and to Python developers and would force me to dig deeper into the depths of our client library.

So, I presented a talk called "Wave Robots API: Behind the Scenes", with the goal of showing how we used Python to abstract on top of our HTTP API. I started with an overview of Google Wave and a quick look at Wave's core technology — the conversation model and operational transformation algorithm — so that everyone in the room would be comfortable with me talking about blips, wavelets, operations, and the like. Then I went deep into the robots API, explaining the JSON-RPC protocol between the Wave server and robots, and showing how the Python client library serializes the JSON into Python objects, how it lets developers register for events, and how it signs outgoing requests using OAuth. I then explained how we designed the client library to be hosting-provider-agnostic, and live demoed a robot that I created using the Django framework on a slicehost node. I finished with a summary of the most important features of the client library — versioning, automation, authentication, flexibility, and being Pythonic.

But, hey, if all that sounds interesting to you, you don't have to read about it -- you can watch it! Check out the video here, and the slides here. If you have any questions after watching, just head over to our Google Wave API forum.

Posted by Pamela Fox, Developer Relations

David Crane is an external Wave developer, involved in the development of the Debatewise extension. We've invited him to post on this blog to share his vision for an open source project.

A few months ago, the Google Wave team open-sourced the code underlying Forum Botty, the robot that is powering the Wave API forum. We want to continue developing this code base into a powerful and generic extension for running forums in wave, and we're hoping that other developers like you will join us in this project.

Google Wave offers a number of benefits over traditional forum software, with just its native functionality. However, by incorporating some of the tried-and-tested features from forums into a robot, we could turn Google Wave into the ultimate platform for forum-based discussion.

A forum could be a killer app for Wave. It’s a tool that people already use in huge numbers for specific purposes, are used to keeping separate to their email, and will dip in and out of as required. Wave is similar enough for them to jump in quickly and different enough for them to get, and be hooked by, the benefits. A forum removes the need for people to find things to use Wave for and means they could use it even if none of their friends did. Wave could enhance and improve upon some of the most important features of a forum and through acclimatisation, will encourage them to use it for a world of other purposes.

There are three specific areas we believe need developing

Goal: Allow people to coalesce around a subject of their choosing and help them find Waves of interest
Tasks: Group waves around subject areas. List the following alongside each Wave title: the total number of blips in the wave (including read/unread), total number of views, date/time of last post and who made the post. Later add ways of rating, sorting and categorising the Wave.

Goal: Encourage and reward participation in the conversations
Tasks: Add karma mechanisms, applause and trophies so Waves, blips and users can be rated. Incorporate tiered participation levels and privileges (eg StackOverflow).

Goal: Develop trust mechanisms so people can determine who to rely upon or ignore
Tasks: Link waves with Google Profiles (or other profiles), display the user’s trophy cabinet, list all posts by user and their ranking in the community

We’re looking for Python, Java and Javascript developers, QA testers and anyone with an interest in forum software, community building and online discussion. All software will be licensed under Apache 2.0, the same open source licence that Google Wave uses.

This project is organised by Debatewise.org, a non-profit debating web site whose goal is to be the Wikipedia of debate. Anyone can create a debate on any subject they like and anyone can edit and strengthen that debate. In this way and over time the debates become stronger, more definitive and an ever-greater resource for anyone looking to make up their mind.

If you're interested in joining the project, please wave me at dh.crane@googlewave.com.

Posted by David Crane, Debatewise