Here's a nice article on single point gesture recognition for games, here are lovely simple single stroke and multi-stroke gesture recognisers in javascript. Here's the corresponding paper. Here's a paper about modelling gestures using Markov chains.

And here's a gesture recognition discussion thread featuring some of the above links and many more.

Curling is unexpectedly popular again. We're measuring this.

Continuing a four and half year old seed of thought that Matt Webb planted about sporting metaphors, I'm imagining that Curling is project management:

• sweeping in front of the stone to both clear a path and influence the direction, but without touching it
• a good curling strategy is to both knock the competition out of the way and get closer to the target, sometimes with different stones
• ...plus you can drink and smoke while you play (thx Aaron and George)

I was going to labour this point a little bit, but wikipedia sums it up nicely. In Curling, "two sweepers with brooms or brushes accompany each stone and use stopwatches and their best judgment, along with direction from their teammates, to help direct the stones to their resting place, but without touching the stones."

And now back to measuring things.

I have a GestureWorks license available to me if I need it but I haven't evaluated that yet because I have a little time to experiment and I'm really just curious about how it all works. I'm using Flash, and I'm successfully receiving TUIO messages using udp-flashlc-bridge and tuio-as3 with a LocalConnection. It's working nicely so far, and I already adapted Modest Maps to deal with rotations and got up and running quite quickly.

The reason I'm reaching for my blog for the first time in a while to ask if anyone reading has experience to share about developing software for this kind of platform? Specifically I'm wondering if anyone has hints about how to go from raw cursor information (potentially from several fingers on several hands) and turn that into meaningful motion? What I can do so far works really well with two fingers but I'm wondering where to go from here.

Some of the steps seem simple. For example, if a cursor appears and disappears in a short space of time and doesn't move very much, that's a tap event. If two cursors appear and disappear twice in the same place in a short space of time, that's a double-tap event. If a single finger cursor appears and moves, that's a drag. A fast drag could be interpreted as a swipe. You can code some momentum/physics in there to make it feel right. So far so good. This much is intuitive.

So then... there's the whole task of doing hit-tests on each interactive object on screen so that you don't combine cursors into gestures unless they're acting on the same thing. This is familiar territory for me. But where intuition breaks down for me is if two or more fingers appear and move in roughly the same direction - is that a drag gesture? But how do you define roughly, or should you also interpret it as scaling or rotation? And when do you decide to ignore the scaling?

And then, if several fingers are doing this, potentially in opposite directions, how do you boil that down into a gesture? Or if several people are all mashing the table at once, how do you filter out the noise? Can you? There are some juicy interaction design problems in here that I know I'm not the first person to think about by a long shot (hat tip, hat tip, hat tip, hat tip, hat tip, hat tip etc). But I don't see much discussion of the interpretation of raw touch information into gestures. If you know of good projects that have solved these problems before (in an open way) I'd love to hear about them!

One idea I've had is to use a clustering algorithm like k-means to get two groups of points, and filter out the outliers, and then continue to apply slightly naive two-finger algorithms to build rotation/scale/translate matrices. Are you an old school multi-touch/reactivision hacker? Have you built touch tables for a living? Does all of this sound familiar to you? Let me know your thoughts!

"Mr. Micawber was waiting for me within the gate, and we went up to
his room (top story but one), and cried very much. He solemnly
conjured me, I remember, to take warning by his fate; and to
observe that if a man had twenty pounds a-year for his income, and
spent nineteen pounds nineteen shillings and sixpence, he would be
happy, but that if he spent twenty pounds one he would be
miserable. After which he borrowed a shilling of me for porter,
gave me a written order on Mrs. Micawber for the amount, and put
away his pocket-handkerchief, and cheered up."

I am the Mr Micawber of time, being that I'm over-spending just slightly this month. Hopefully I'll make it up this year!

If I had more time I might blog about a small revival in minimal geeky location-based fun stuff that's happening with sites like noticin.gs and blockchalk.com. I might also note that foursquare got funding which is good because even though I'm not particularly attracted to the service it's a better experience than its competitors by a long way (and much less creepy, I think). And I'd note that opengeodata.org has stopped being about OpenStreetMap exclusively and that if you want to get Steve Coast's attention there are a million things he's thinking about these days.

If I had more time to blog and more time to think, I'd stop leaving cranky comments trying to answer Manuel Lima's false dichotomy and Robert Kosara's straw man and I'd stop worrying about definitions of data and aesthetics and analysis and I'd be happy to frame the argument in terms of prickles and goo instead.

"it is inevitable that there will soon be a large number of hybrid designer-engineers that shall radically reconstruct the visual landscape." – John Maeda

This debate isn't new and it's not going away either. John Maeda and friends have been pointing out the rise of gooey-prickles and prickley-goo for years. I wonder if prickly folks at RISD are getting gooier, and vice versa.

My money's on the middle ground too, which is why I find narrow and divisive definitions so frustrating. Why can't we have aesthetically pleasing data analysis? (Of course there will be pure analysis with no emphasis on aesthetics, just as there will be pure aesthetics with no emphasis on data. Sometimes the latter with be art to make a point. That's cool!)

If I had more time to think and blog, I'd have told you about our intern Amy Martin and how she worked with us over the summer on some Wikipedia stuff to hone her hybrid designer-developer skills, and how that seems to be paying off nicely. And I'd mention the new GAFFTA space in San Francisco that is running workshops also recognising this kind of work without worrying overmuch about definitions. We'll be there next month.

Gosh. If I had more time I'd never blog.

Before that, but I've been slow to update, Tish Shute posted a long and detailed write-up of Where 2.0 and WhereCamp featuring a couple of quotes from me and a lot more from Aaron Cope.

Last week we released a Historical Hurricane map for msnbc.com, a follow up to our forecast tracker from last year which was recently accepted into the SIGGRAPH Information Aesthetics showcase. You can read more about the historical map on the Stamen site, or just go ahead and explore the finished thing:

Further to our updates earlier last month, we just released another round of improvements to Oakland Crimespotting. Mike and Eric have full details. I'm particularly pleased that we're able to open up our archive of around two years worth of data, but also that we're able to try something new with an interface for filtering by time of day.

We jokingly started calling this a time pie, and now we're stuck with it... in a good way. I'm still not 100% sure it's intuitive, but I think that working the real sunrise and sunset times in there should help. The only comparable interface I could find was this:

If you know of any other similar ways of selecting/filtering 24 hours, let me know in the comments!

Other changes we've made include numerous small performance optimisations, new sliders in the marker info-bubbles, date labels on the timeline and the crime-type filters now double as a full legend. The whole thing has had a design overhaul too thanks to Geraldine.

We've got a few more features planned for release soon, and we've started a blog to keep track of new developments. Now is a great time to let us know if you have suggestions or feature requests! Feel free to leave a comment here or email info@crimespotting.org if you prefer.

I've heard it said that this would be the best phone in the world if it wasn't for the iPhone*. I can believe it. So this is the second best phone in the world, and you write software for it using Java and (optionally) Eclipse. I know Java and I use Eclipse all the time for writing Flash apps, so this is a tempting prospect: world class hardware, easy to use software. Let's go!

* We can debate what it means to be the best phone in the world at the moment - suffice to say that I know that hardware alone will never do it. Apple's retail experience, customer support, iTunes store, developer tools etc. all leave Android and others with a lot of work to do. But it is a nice phone, certainly. I also haven't been using the phone for voice, nor have I been syncing my emails and calendar with the phone... so this isn't a review by any stretch of the imagination.

There's a brand new update available for the Android OS, version 1.5 aka "Cupcake". My phone came with 1.1 and despite some prodding it wouldn't go ahead and upgrade itself. So I had to download the 1.5 updates and do it myself. That page is full of long and complicated explanations but basically you're just copying files, renaming them to update.zip and rebooting the phone, twice. (Mine got confused in the middle because it finally started to automatically update itself and I let it. If that happens just ignore it and continue with the manual process and everything should be fine.)

My main focus with tinkering with the phone has been to get the API demos running so I can get a sense for how easy it is to work with the Google MapView classes and also how much boilerplate code I need in order to load data over the network and draw pretty things with OpenGL. The Hello World tutorial worked straight away: if you have the phone plugged in it automatically installs your app and runs it on the device, if not then it fires up an emulator. Getting the API demos up and running was a little trickier because it involved importing the project from android-sdk-mac_x86-1.5_r1/platforms/android-1.5/samples/ApiDemos first, but it did work after I upgraded to Cupcake.

For the MapView to work you need to jump through some app signing hoops before you can get a Google Maps API key that will allow the device to load map tiles. The documentation is quite dense but if you're just playing around in Eclipse you can sign things with your debug key; in this case the API key signup page tells you what to do. Just be sure to log in with the same Google account you'll be using in the Android Marketplace, if you get that far.

Once I'd kicked the tyres with the demos I decided to jump straight in and try my hand at an app that loads data from a web service and displays it on a map. The learning curve was OK, here's a list of things I wish I'd known about before I started:

• Like any good Swing programmer or web app developer, I have a head for asynchronous operations and I'm comfortable with callbacks and so on. Of course Java is a little more verbose with this, and the need to run UI code on the UI thread but have long running tasks in a separate thread can quickly lead to spaghetti code. Thankfully Android has an AsyncTask class which really elegantly wraps up the pattern of bouncing between two threads and tracking the progress of long tasks. Completely recommended over lots of new Thread(new Runnable()).start(), not least because it lets you cleanly cancel things in onDestroy, too.
• The Android libraries include the Apache HTTP library, which is quite good (if a little verbose). This HTTP & JSON example is great, and as I discovered if you reuse the HttpClient object your app will load lots of data happily and with good performance.
• The android.util.Xml class will make you a SAX parser for XML parsing. This tutorial otherwise covers what you need to know about SAX parsing and Java if you haven't done it before. The Xml class's convenience function cuts out the AbstractThingerFactory boiler-plate code that Java programmers are generally too tolerant of.
• In MapView, an ItemizedOverlay with no items still needs to call populate or your app will crash as soon as you interact with the map. This is a known issue, I'm not sure if it's a bug, I'm mainly noting it here for search engines.
• It turns out Activity.onCreate—the standard entry point for Android apps—gets called if the screen rotates, which happens if you open the keyboard on the dev phone/G1. If you used onCreate to fire off a bunch of threads and load data, you need to drop those threads in onDestroy, pass a copy of the data you want to keep onRetainNonConfigurationInstance, and get it back with getLastNonConfigurationInstance. The Android Guys explain all this and more in a three part series, but the second part was most useful to me.
• Compilers and code generation and XML config files are all fine, but the Android manifest file is king. If you're using the Google MapView library you need to declare this in the manifest or your app will unceremoniously crash.
• Likewise if you're using the network or asking for location information, you'll need to add the relevant permissions to the manifest, or your app will fail (with no explanation). I'm not sure why this is the case, and why the SDK even lets you compile an app that requires internet access without prompting you to add the INTERNET privilege, but it does. As far as I can see these permissions aren't exposed to end users, but perhaps they'll help people navigate the Android Marketplace once there are devices out there with varying capabilities?

All in all it took me just over a day to get to the point where I felt confident that the phone was doing what I was telling it, and that there wasn't too much magic and surprise crashes were rare. The next thing I want to investigate is the OpenGL ES implementation, which I'm hoping is as slick as the iPhone's. I've been keeping a list of android links I think are worth reading at del.icio.us/TomC/android - let me know if there are any other neat/essential APIs in the Android universe that you think I should take a look at.

• Two talks about baseball stats. This first was from Michael which featured his latest R-driven experiments using pitching data and 2D colour ramps in the CIELUV colour space. He has a nice little R webserver running which can do the clever business with kernel density plots (look closely at those pitch charts, those aren't stacked circles). The second was from Shane Booth who showed sketches for StrategyFan, a forthcoming project with Rio Goodman that lets people create and visualise their own metrics for players and teams. Think "day trading for baseball". (Shane was probably the designeringest person there, and has a lovely tumblelog that ffffound hhhhounds will love).
• A talk about NBA graphs from the homepage-less Brad Stenger, with reference to a timely no-stats all-star article and computational journalism in general (look out for more on this at SxSW and OSCON).
• A talk from Lee Byron, who sadly (criminally) couldn't tell us what he's up to as a data scientist at Facebook (because that's not how they roll, obviously), but did tell some good stories about being the industrial design / motion graphics spanner-in-the-works at the NYTimes during the Olympics last year. (And hey, he got to push a personal project through and include an easter egg in there, well done!)
• A talk from Pete Skomoroch, whose visit to town catalysed the whole event in the first place. Pete showed us some work he's been doing at Juice Analytics, lifting clients out of the dark ages and automating previously laborious data mining processes. People cluster search referrals manually, apparently. In 2009.
• Brendan O'Connor from Dolores Labs showed us some of the stuff they're doing with (and without) Mechanical Turk, including those lovely colour name diagrams and the surprising news that the hot-or-not site genre is definitely not dead, and can also produce interesting stats by posing relatively simple questions to millions of people.

Thanks to Michael for putting on a great event and getting everything together at such short notice. Hopefully there'll be another one soon!