Out of this frustration, and from a desire to reduce the boilerplate involved in writing a new apps for the watch, I began to develop a framework that I called Cicada.

Cicada provides a couple of key things for hackers who want to explore app ideas. First, it provides a menu system to pick between watch-compatible apps installed on the phone. Only the app that’s currently on the watch screen gets the button press events. Second, it has a widget mode that lets you run three independent apps at the same time, with each getting one third of the watch screen, so you can mix and match pieces for your watch display.

Here’s a little walkthrough of the Cicada interface on the phone side:

Cicada mostly runs in the background on your Android phone, but it also has a very basic control UI. It’s nothing I’m proud of, but it’s done the job while I’ve been focused on the APIs and plumbing. This is what it looks like when it’s not running.

When Cicada is active, you see a copy of what’s on the watch screen, which is handy for taking screenshots. Here you can see the app list. Pressing the top and bottom buttons on the right side of the watch move the selection up and down, respectively, and pressing the middle-right button launches the selected app. Cicada automatically detects when you install or uninstall watch-compatible apps from your phone, and updates this app list instantaneously.

Now I’ve launched the “Widget Screen” app that’s built in to Cicada. This app has an associated settings UI, as you can see from the button that appeared. (Pressing the upper-left watch button would bring me back to the app list.)

In any case, the widget screen is showing several different apps at once. How did I set that up?

Tapping that settings button on the phone screen brings up the (similarly unvarnished) widget settings view, where you can see the list of apps that were being shown on the widget screen: an app showing the current status of my London tube line, a basic clock, and an app that shows the next appointments from my Google calendar.

Here I’ve tapped one of the widget slots, allowing you to see the list of apps that have declared that they can run as widgets.

I’ve made a few changes in the widget configuration. You can’t see it here, but as I’ve made each choice, the watch display has updated itself so I can see the new look.

Here’s what the new set of widgets looks like on the watch. I’ve moved the clock to the top, and swapped out the bottom widget for an app that shows bus arrival estimates in San Francisco. Now, if I press the lower-right watch button next to the bus times widget…

…it launches the bus times app in full screen mode, showing more detail. (As before, pressing the upper-left watch button would bring me back to the widget screen.) Note that this is the same thing I’d get if I’d chosen “Next Buses” from the initial app menu.

Anyway, that’s a quick look at Cicada. It’s not quite polished enough to put up on the Android Market yet, but if you’re a developer interested in building Android apps for putting glanceable information on the digital MetaWatch, it’s definitely far enough along to be useful to you. You can find the source code for the framework and many sample apps in the Cicada project on GitHub.

To get an idea of what’s involved in writing a Cicada app, have a look at the source for the Digital Clock sample app (less than 100 lines of code, including the license header). You just subclass the CicadaApp service class, implement onResume(), onPause(), onButtonPress(), and draw your watch screen in onDraw().

I’ll write more about Cicada here soon, but if you have any questions in the meantime, post them in the comments below or in the cicada-dev Google group.

UPDATE

There’s now a MetaWatch Wiki; updated versions of the content below can be found there, particularly in the Hacks and Libraries & Frameworks pages.

Developer Resources

• Official MetaWatch Forums
  (also good for general questions—please don’t ask them in the comments!)
• #metawatch IRC channel on Freenode
• MetaWatch wire protocol (PDF)

Libraries & Frameworks

• Official Meta Watch Manager for Android source code (Android)
• Official MetaWatch firmware source code (Embedded C)
• PyMetaWatch (Python, Linux/Windows/Mac)
• MetaWatch (C, Linux)
• MetaWatchManager (Android BroadcastIntents)
• .Net port of PyMetaWatch (.Net)
• Cicada (Android app framework & runtime)
• MWKit (Objective-C library for Mac OS X and jailbroken iOS)
• MWManager (Mac OS X app to drive the watch)

Hacks

Assorted app prototypes that I put together

Minecraft Clock, also done by me

Controlling room lights via OpenAMI by Kai Aras

Remote control by Kai Aras

Qt Animation by javispedro

Showing Google Maps for your current location by Zero Cho

Desktop Mac App notifications via Growl by Kai Aras

Jailbroken iOS support by Kai Aras

Album art and song title display by javispedro

Firmware tweaks by Garth Bushell to add a 24-hour toggle to the embedded menu and to add the year to the idle display. (source code)

Let me know what else you find (though I reserve the right to not post everything that I come across).

Lately I’ve been experimenting with the possibilities of Bluetooth watches. While I was fooling with Travis Goodspeed’s PyMetaWatch library for talking to the MetaWatch from Python code on your PC, I remembered a fun hack that my friend Michael Dales had done to control lights in the real world from actions and switches in the virtual world of Minecraft.

Minecraft is an engrossingly open-ended game that involves exploring caves for minerals, then using those materials to build more tools and buildings. To complicate matters, there’s a day/night cycle, and night time brings zombies, skeletal archers, and other nasty ssssurprises. The upshot is that it’s a lot safer to travel during the day.

If you’re mining deep in a cave, though, how do you know when it’s safe to emerge from your spelunking to haul your loot home? Notch, the game’s creator, eventually added the ability to craft an astronomical clock in the game to tell you what time of day it was.

So, how did I get it on my wrist? Here’s the crafting recipe for this hack: I wrote a little mod for the Minecraft server that spit out the virtual world’s time of day, using V10lator’s lib24time library and the gratifyingly straightforward Bukkit Minecraft modding system. From there, I have a Python script that uses PIL and the assets from the game to render an approximation of the Minecraft watch at the given time of day.

Finally, I’m using my fork of PyMetaWatch to send the image from my Mac to the watch via bluetooth.

It works, but it’s very laggy right now. (Eagle-eyed Minecraft fans might have noticed that my screenshot above is more evocative than accurate.) The slowdown seems to be somewhere in the PyMetaWatch/lightblue combo, which is taking an agonizingly long time to send a bitmap to the watch. I can generally send a bitmap from my Android phone in less than a second, I suspect that either lightblue is configuring the bluetooth RFCOMM link for a ridiculously low speed, or there’s some overhead in the PyObjC bridge that it relies on. Let me know if you have any ideas.

Update (Sept. 17): Today I tried a different tack, involving an Android app loading the clock image from the Mac over wifi and sending it to the watch via MetaWatchManager, and it worked much better. Here are a couple more pictures showing the watch time more or less synced up with the time on the in-game clock:

As the MetaWatch bluetooth watches are getting closer to shipping, I figure it’s a good time to talk about some of the UI experiments I’ve been doing with them, to give you an idea of what they might be useful for.

MetaWatch is a line of hacker-friendly wristwatches that can be paired with smartphones to enable new kinds of lightweight interactions. In the same way that glancing at a wristwatch is faster and less disruptive than pulling out a pocket watch to check the time, you can imagine how glancing at a connected watch could be more convenient and sociable than pulling your phone out of a pocket or handbag to see cloud-based information.

After my previous experiments in showing live bus times on an older bluetooth watch, the guys at Fossil got in touch with me, and over the past couple of years I’ve served as an unpaid advisor to the MetaWatch project, in the hopes of helping to make the end products as developer-friendly as possible.¹

There are a lot of things to like about the MetaWatch devices:

1. The screen of the digital version is always on, so the information on it is always a discreet glance away. You don’t need to push or swipe anything to bring it to life.
2. The battery life is reasonable, so you can wear these things for the better part of a week without having to charge them.
3. Since they’re designed by experienced watchmakers at Fossil, the MetaWatch devices look more like fashion watches than cookie-sized computers strapped to your wrist.

There are definitely some trade-offs, though, compared to other devices with more horsepower and flashier displays:

1. As an Android app author, you’re basically treating the MetaWatch as a dumb terminal. You send pixels to the screen, and you get button presses back. This gives you a lot of control, but the downside is that watch-based UIs are a lot less responsive than you’d like.²
2. The low-resolution monochrome display isn’t as sexy as color touchscreen devices like the iPod Nano or the WIMM Platform. They’ve made the most of it by hiring Susan Kare, designer of the original monochrome Mac graphics, to do the default imagery. You can’t reuse existing designs—for best results any UI is going to have to be custom-designed for this thing.

With that out of the way, here are a few prototypes that I’ve made over the past year or so.³ I hope you’ll excuse the rough graphics in places; I mostly wanted to see how these interfaces would feel if they were always easily accessible on my wrist.

Imagine this: you’re at the airport, hands full of luggage, and you just want to know where and when you need to be at your gate. Wouldn’t it be handy if you could glance at your wrist to find out? Matt Webb called this use “personal signage”, which is a nice way of thinking about it—you can get by with a lot less screen real-estate if your devices know exactly which part of the departure board you’re interested in.

How long do you have to work before your next meeting? It’d be great to be able to see that at a glance.

When you’re driving home, the time that’s really important to you is when you’ll get there. Assuming your phone knew your commute home, it could check current traffic conditions and show you the time you’d get home if you were to leave now.

Since I take the London Underground home instead, what I want to know is how the trains on my line are running.

Of course, the watch has several buttons that can enable you to trigger phone actions. I always text my wife when I’m heading home from work, so I wrote a little app to send a canned message with a single button press as I’m walking out of the building.

If you’re an author who compulsively checks your Amazon rank and social network stats, you could put those things right on your wrist and avoid the distraction of surfing to those sites.

I was curious how my commute time broke down, so put together a custom stopwatch app. I hit the button when I stepped off the bus or got out of the tube, and the app saved that “lap”. (It also used the time of day to know whether to reverse the order of the steps in the list.)

If you want to keep yourself focused on important things, perhaps a little memento mori reminding you how many days you had left (actuarially speaking) would help?

If that’s too morbid, you could try the Pomodoro Technique of staying focused on work in 25-minute increments, and have the watch vibrate when it’s time to take a break.

Finally, a little bit about the development process: to make it easier to quickly build new MetaWatch apps, I put together a little framework called Cicada. It detects watch-compatible Android apps as they’re installed on the phone and automatically adds them to an on-watch menu system.

A Cicada app can run in full screen mode…

…and optionally, the same app can be run in widget mode alongside other apps. Here, the same realtime bus times app is only using the bottom ⅓ of the screen, with other Android applications providing the tube status widget and the digital clock widget.

I’ll talk more about the Cicada framework in a later post.

Fortunately, the iPhone’s Safari supports bookmarklets, so I whipped up a little bookmarklet that makes it easy to see the real original page in Reader. Here’s how to use it:

1. On your desktop computer, drag the following link onto Safari’s bookmarks toolbar: Super See Original
2. Sync your iPhone
3. Once that’s done, go to Google Reader on your iPhone, and navigate to a blog entry.
4. Hit the bookmark icon at the bottom, then choose Bookmarks Bar > Super See Original
5. The original page for your blog entry should open in a new “tab”!

I have no doubt that the Reader team will eventually make a more iPhone-optimized version of Reader, but until then, hopefully some of you will find this useful.

As I was setting up the blog, found that I really wanted some kind of outboard brain that could help me keep all the people and sites straight, and hopefully provide a useful reference for others. For expediency’s sake, I just used the handy “one-click” install of MediaWiki that DreamHost provides and started typing away. A few weekends later, the Headway Wiki was starting to become something useful—but I was definitely chafing against MediaWiki’s limitations. I found that I generally wanted to represent the same kinds of things about each entry:

• the name of the site
• the web address
• who runs it
• when it was launched (often with some degree of fuzziness, because even the site’s creator doesn’t really remember)
• which agencies it serves

…and a few other miscellaneous things. Unfortunately, MediaWiki is really oriented towards prose—and in fact, I found myself using repetitive prose (with a smattering of bulleted lists) to express these things. Even worse, when I wanted to connect a entry about a third-party transit site to an entry on the agency that it was helping out, I had to manually maintain the link on both ends of the connection. That is, I couldn’t just tell the system that Boston Subway Station Map had information about the MBTA, and have it automatically display that in the MBTA entry—I had to go and edit the MBTA page by hand.

I did make use of MediaWiki’s (apparently) single structural feature: categories. Categories are basically simple tags that you can add to articles, so that the software can automatically generate an index of articles that all share a particular tag. Still, in the end it was far more work than I wanted to do.

There really should be a better way to put together a structured data collection like this, something in between limited expressiveness of MediaWiki and the programming involved in putting together a custom database-backed website using Ruby on Rails or what have you. I’m pretty sure that it’s possible, because I spent several years of my life working on tools like that for the MAYA Information Commons project. Sadly, that work still isn’t available to the general public, so it’s not really a contender here. However, there are a few intriguing new possibilities.

Enter Dabble DB. At first blush, it looked like just the thing that I was looking for. It has what’s probably the best available interface for experimenting with different ways of representing interconnected information. It’s pretty straightforward to create an item, add a few fields to it, and make some of those fields two-way links to other items. That’s no small feat, since my former co-workers and I spent the better part of 2004 building something similar (and if Dreaming in Code is to be believed, the folks on the respected Chandler team were at it for even longer, at around the same time). So far, so good. But after an evening trying to make the Headway data work in Dabble DB, I’ve run into a bunch of significant shortcomings.

No boolean fields

Starting with the smallest thing, there’s no straightforward way to represent a simple checkbox for things like “does this feed contain schedule information”? You can work around this by creating a multiple-choice field with the options “Yes” and “No”, but they’re missing an opportunity to make entering and displaying these fields simpler.

Limited spatial information

Here we are, a couple years after the Google Maps API catalyzed a geographic revolution on the web, and Dabble DB’s only location options are “US or Canadian state/province code” and “Country Code”. To their credit, they do automatically link to a Google Maps search for your term in some cases, but they could provide far more interesting map views if they simply had a lat/lon geocode field and just dumped it into Google maps.

Ontological limitations

It’s very cool that Dabble DB lets you put one item in multiple “categories” (schemas, basically). But in practice, their implementation is less handy than it would seem. Say you had two kinds of things, “websites” and “data providers”, both of which have names (of course) along with other more category-specific fields. If it turns out that you want to represent something that’s both a website and a data provider, and you put both categories on the same object, you end up with two name fields.

You could take a different tack and say that a “data provider” is a specific kind of “website”, so only the website category will have a name field. That’s great, but then there’s no easy way to have the system automatically add the “website” category when you go to create your next “data provider” item. Even worse, when you go to create a new view of your data based on “data providers”, there’s no way to choose to display the “name” field from the “websites” category in the table. (Note: this isn’t strictly true for the name field, since they special-case it so that you always have some kind of identifier, but it’s true for other attributes.)

Rudimentary public views

I could probably work around all those things, but there’s one thing that makes Dabble DB unusable for the Headway data set: the public view is horribly impoverished. Here are the results of my experiments: my lovingly interlinked data has been reduced to a box of yellowing printouts, metaphorically speaking. There’s no apparent way for the viewer to see a single entry laid out in a readable form, let alone follow links between items or search & filter by different attributes.

It’s a shame, because Dabble DB really is the best that I’ve seen so far in most other respects.

Freebase to the rescue?

There’s another contender on the horizon: the wonderfully named Freebase. Tim O’Reilly recently threw a debutante ball for it on his influential blog, and it’s easy to see why it stirred some excitement (and controversy) in the online community. It sounds quite a bit like the things I was working on at MAYA, but with a pleasantly simple web-based interface and without the radical peer-to-peer architecture. On the other hand, it’s hard to say for sure, since the alpha is currently only open to a few fortunate souls, and details are scarce. Hopefully I’ll get a chance to check it out soon.

In the meantime, Dabble DB has a lot of potential, especially since they recently launched their free Creative Commons version (which made it a viable option for Headway). Hopefully, with a few refinements, they’ll be able to turn it into a compelling alternative to developing custom code any time you want to share some interconnected information.

A few weeks ago, I went on a hike to Treasure Island, and I thought it’d be a good opportunity to try out the state of the art in simple photo geotagging, so that people could see photos of my trip on a map. My first test involved:

1. Uploading the photos to Flickr using FlickrExport for iPhoto
2. Finding the spot for each for photo in Google Earth, creating a placemark, and copying the latitude and longitude into geo:lat= and geo:lon= tags on the Flickr image.
3. Using Scott The Hobo’s Flickr Photoset Maps to turn the geotagged photoset into an online map.

The resulting map is pretty nice, sluggish Yahoo map aside, and the process wasn’t too painful. The worst pain point was the cut-and-paste geocoding process.

However, since Google just released a whole slew of geographic updates, not to mention a barebones (but snappy) photo hosting service, I thought I’d give it a try using Google tools.

First step: get the photos into Picasa, Google’s excellent free Windows photo organizer. I used FlickrDown to download the photoset from Flickr to my Windows box. It was simple, though I was sad that there was no way to preserve my photos’ tags. I then downloaded the new version of Picasa from the Picasa Web Albums site. (You need to get this specific version to be able to do the fancy stuff I’m about to describe.) Picasa immediately found and imported the downloaded photos—so far, so good.

Next, I went through and geotagged the photos using Picasa’s integration with Google Earth 4. I highlighted some photos in Picasa and selected the Geotag With Google Earth option hidden away in the Tools menu.

This took me to a slick geotagging interface in Earth.

Basically, you just drag and zoom around in Google Earth until the crosshairs (which are anchored to the middle of the display) are resting on the point that you want to tag the photo with. Then you just hit the Geotag button, the view bounces to give you visual feedback, and it moves on to the next photo. This was so much more pleasant than manually copying the location to Flickr. When I was done, it brought me back to Picasa. The photos all had little crosshair icons in the corner, indicating that they had been geotagged, and a quick look at the Properties dialog seemed to indicate that the location had been added to the image’s EXIF data.

Now that the images were geotagged, I found that I could use the View in Google Earth... option to see the photo on the map. It seems that this is implemented using some sort of dynamic folder in Google Earth called Picasa Link that constantly queries Picasa for images with geotags in their EXIF—so effectively, you can browse your Picasa library geographically using Earth! I tried adding a random geotagged phonecam image from the web, and sure enough, it showed up on Earth.

OK, so now that I had found geotagged image bliss, how could I share it? I tried the Export to Google Earth File option in the Tools → Geotag menu, which yielded a nice Google Earth KMZ file with the photos embedded.

Since Google Maps recently added support for viewing KML files, I decided to see if I could view my photos there. The results were not so hot.

As you can see, it wasn’t a total bust—the locations show up correctly—but the actual photos were nowhere to be found.

Since I’d seen examples of photos on maps, I was sure it could be done—maybe they just wanted the photos to be linked from the web. The Google Earth UI didn’t seem to give me any way to replace the photos with web links to photos. However, KML is a straightforward XML format—hand-editing ahoy!

(Incidentally, I was hoping that when I uploaded the images from Picasa to my Picasa Web Album account, it would do something smart. Sadly, Web Albums didn’t show any recognition that the images were geotagged, not even in the EXIF section. I’m sure that they’ll eventually sort that out, maybe by automatically generating KML links to Maps.)

Back to the hand-editing; first I had to unzip the KMZ file that Picasa had generated. (It’s just a normal zip file, rename the .kmz to .zip and you should be able to unzip it normally.) The only file that I needed was the doc.kml file; the rest of the archive just contained the photos and thumbnails. I stripped out all the style stuff at the top of the file, since Maps didn’t seem to be paying attention to the icons anyway. Then I replaced the contents of the description tag in each placemark with an image reference and link to the images on my Picasa Web Album. Then I uploaded the KML file, and it worked!

The result isn’t quite as nice as my original map, because I didn’t immediately see a way to get smaller images out of Web Album, but it does the job.

The verdict: geotagging with Picasa and Google is a dream, viewing geotagged Picasa photos is awesome, but the web mapping part of the Google photo story needs work.

(Incidentally, while you’re checking out my Treasure Island album be sure to try pressing the left and right arrow keys while you’re looking at pictures—you can flip through photos really quickly in Picasa Web Album!)

My teammates and I are proud to present Google Transit, a new Google Labs experiment focused on helping make public transit information more accessible and understandable. We’re starting with Portland, Oregon’s transit system, but we’ll be expanding it to support other cities soon.

For more information, check out the announcement, and if you have feedback or bug reports, we’d love to hear it at labs-transit_feedback@google.com!

1. Open regedit
2. Navigate to HKEY_CLASSES_ROOT –> Installer and select Products
3. Use the Find menu to find quicktime inside that part of the key
4. Delete the part of the tree that you find
5. You should now be able to install Quicktime and iTunes without incident

• You can now look for times near a particular address using the Location area under the map. In order to do this, I wrote a little proxy to feed addresses entered on this page to the wonderful geocoder.us free geocoding service, and return the results as JavaScript literals.
• The page now remembers your location, zoom level, and selected stop between visits.
• It now works in current versions of Internet Explorer.

At this point, it’s almost suitable for regular use. The biggest improvement that’s still on my list is to do a better job of handling stops that are too close together. Right now, stops can fall too close together on the map, making them difficult to click on individually. Automatically combining these stops would help the situation.