Dumb Gadgets

Over the past few days I’ve talked about the process of converting my puzzle site from a webapp into a Google Gadget. A few twists and turns aside, the centerpiece of the effort was eliminating the page reloads that I’d used to navigate between puzzles, and editing my markup slightly to created a gadget XML spec from my existing HTML code. This seems to have been the Right Way to do things, but today I want to look at a different issue: “What’s the fastest, dumbest way to convert an existing web site into a Google Gadget?”

Content Type

Google makes two “Content Types” available for the Content tags of their XML Gadget specifications. The html type is the one I’ve been working with this week; it offers better integration with the Gadget’s host environment (e.g. iGoogle), and seems to better represent “the spirit of the thing”. The url type, on the other hand, allows you to write gadgets that treat the host environment like any other IFRAME. This approach is much faster.

Example

Here is the complete source code for a puzzle gadget (based on my puzzle site) that uses the url Content Type:

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
  <ModulePrefs title="Calcudoku (Quick/Dirty)"/>
  <Content type="url" view="home,canvas" href="http://www.mlsite.net/neknek/play.php"/>
</Module>

Here is what it looks like in the “home” view:

Not so good. Fortunately, here is what it looks like in the “canvas” view:

Explanation

The XML is pretty self-explanatory; the only bit of cuteness involves the view parameter of the Content tag, which is assigned the value "home,canvas". This means that the single Content section will be displayed in both the “home” and “canvas” views.

Other than that, pretty simple: “Create an IFRAME, point it at this URL, and there is no step 3.”

Pros and Cons

This approach has some costs and benefits. Briefly:

Pros

• 5 lines of code
• 5 minutes to figure out and write
• only one codebase to maintain

Cons

• “home” view looks awful
• no organic navigation to “canvas” view (visitor must use the host’s left-hand menu)
• gadget won’t be able to use any OpenSocial features
• gadget won’t “feel” right

The first two “cons” could be addressed with a small, dedicated “home” section in the XML spec, and the last is, I suppose, a matter of opinion. The third issue was dispositive for me, as I wanted the ability to play with OpenSocial in the future.

Incidentally, the fact that my puzzle site looks reasonably OK in the “canvas” view is largely a matter of luck; if you take the XML spec above and plug in other sites, you’ll find that some look OK, while others don’t.

Future Work

After this digression, it’s back to work. We’re coming up on the end of April, after which I plan to move on to other projects, so I want to spend the balance of this month on the most interesting issues. To me, those seem to revolve around OpenSocial. With that in mind, here’s what I want to look at for the rest of this month:

• Look into making the widget easier for people to find
• Add social features to widget
  • load/save?
  • sharing?
  • collaboration?
• Better aStore placement
• Puzzle forum postings

Yesterday’s Stats

This is the last day of the higher-budget, higher-CPC bid data. Traffic stats seem to have improved a little – mostly in the “visitors” category – but I’m saturating my Adwords budget, and unwilling to increase it. (This is a clear money-loser, and my curiousity has its limits.) On Monday we’ll see 3 days of data based on a highter-budget, lower-CPC bid approach.

Follow Along

You can subscribe to my RSS feed, if you’d like to follow along with this month’s project, in which I attempt to create and popularize a puzzle site.