Ben Dodson

Freelance iOS, Apple Watch, and Apple TV Developer

WikiLocation adds support for 36 locales

It's been just over a year since I started WikiLocation, a simple REST-ful API to access geocoded Wikipedia articles. During that time, hundreds of developers have made use of the API in mashups, apps, and commercial products.

Today, I'm happy to announce that I've added locale support to the WikiLocation API. This means that the API now provides access to over 3.8 million geocoded articles across 36 different languages. The following languages are now supported via a simple "locale" parameter which can be added to any API call (full details can be found in the WikiLocation API Documentation):

  • ar - 6,273 articles
  • bg - 17,689 articles
  • ca - 128,364 articles
  • cs - 7 articles
  • da - 23,041 articles
  • de - 335,275 articles
  • en - 1,101,616 articles
  • eo - 45,864 articles
  • es - 141,352 articles
  • fa - 15,519 articles
  • fi - 16,494 articles
  • fr - 248,977 articles
  • he - 1 article
  • hu - 25,830 articles
  • id - 16,634 articles
  • it - 149,882 articles
  • ja - 60,780 articles
  • ko - 7,805 articles
  • lt - 33,280 articles
  • ms - 24,628 articles
  • nl - 446,506 articles
  • no - 42,267 articles
  • pl - 166,734 articles
  • pt - 141,814 articles
  • ro - 23,297 articles
  • ru - 190,546 articles
  • sk - 5,451 articles
  • sl - 9,719 articles
  • sr - 52,093 articles
  • sv - 31,790 articles
  • tr - 9,448 articles
  • uk - 96,889 articles
  • vi - 71,375 articles
  • vo - 94,470 articles
  • war - 91 articles
  • zh - 19,828 articles

In addition to these new articles and language filters, I have also updated the website with a new visual design which should make it easier to find critical information. Finally, the API has been relocated to a new dedicated server to provide even faster access for your applications.

If you have any feedback or questions relating to the API, please get in touch.

One year on: further thoughts on the Gowalla API

Today is the one-year anniversary of a letter I put together entitled "Thoughts on the Gowalla API", a very critical look at the ever-changing API provided for the popular location-based service. The article was picked up on TechCrunch and has been mentioned at conferences and events but I also like to think that it prompted a few changes. In this post, I want to revisit some of the points I made and hopefully highlight some of the changes that have come about as well showing where further improvements could be made.


When I first put the post together, I was running a service called Gowalla Tools and coming up against constant changes to the API and a very unresponsive developer community. I decided to put the tools and services I was building on indefinite hiatus whilst I waited for some changes to take place. The most important of these was putting in place a process of notifying API developers when changes were going to happen rather than making them and only occasionally sending out a notification a few days later. Fortunately this is now the case and Gowalla have assembled a fantastic team of developers who are constantly available on the Gowalla Developers Google Group. The big changes really started to happen in August 2010 when Gowalla announced that their OAuth 2.0 implementation was now complete and you could now make secure authenticated calls including the ability to check users in at a spot (something which hadn't existed up until that point).

Once OAuth 2.0 was introduced, I started to play around with the API again and launched a new service called Wallabee in September. The first application was entitled "Wallabee: Travel Edition" and allowed users to check-in using over 95% less data than the official app making it a) much faster and b) a lot cheaper when you are travelling overseas. The app was a big success, frequently appearing in the "What's Hot" section of the App Store, and several of the Gowalla employees have used it whilst travelling. Over Christmas I made a number of announcements about future app plans and in March 2011 I, along with a number of contributors, launched The Wallabee Pouch. It was a new player guide, a directory of information, and home to The Item Directory, the largest and most up-to-date repository of Gowalla items. This was all made possible due to an API that no longer changed and the incredibly helpful advice provided by many of the Gowalla Developers. I'd like to personally thank Adam McManus who provided a lot of advice and support whilst I was working on The Item Directory, probably the biggest drain on their API at present.

I went to SXSW in March and was very privileged to meet the Gowalla team and spend some time chatting to their developers. I also listened to some incredibly powerful talks by Josh Williams and Jon Carroll which made me make some fundamental changes to the way I was working with Gowalla - you can read all about that on my SXSW and Gamification post. It eventually led to me handing over Wallabee to another developer so I could focus on some of my own Gowalla apps that were focussed on the story and travelling elements of the service rather than the item and game based sections, but I'll get back to this shortly.


We accept that changes have to happen but these just need to be conveyed to developers in a better way. We propose that any changes be submitted to the Gowalla Developer Group at least 1 week in advance of a change so that we can update our code as necessary. We also suggest that a “version” parameter be added across the API so that legacy scripts can continue to work without changes. In this way, a developer can move to the next API version to take advantage of any new features and data but won’t risk having their hard work undone by what could be a very minor change (e.g. renaming a parameter).

This is probably the biggest area of improvement that the Gowalla API has undergone. This time last year, parameters were changed without consultation and code breakage was a frequent distraction. Now however, many changes are submitted to the Developer Group in advance and opinion is sought on the best ways to improve the API. This was highlighted most recently to me by Rob Mack who sent out an incredibly detailed post about changes they were going to make to the Check-In API. The changes were detailed along with a timeline of when they'd go into effect (3 weeks in future) and a promise that anybody who wouldn't be able to meet the deadline would be able to get an extension if they emailed. This was followed up weekly with reminders of the impending changes. It's this kind of conversation and service that goes beyond what I had originally suggested and makes it such a pleasure to work with the API now. There have been numerous suggestions from the community that have been added to the API in recent months and responses to bugs or questions are incredibly fast. Whilst versioning hasn't come into effect, it hasn't really needed to as any changes have been non-destructive or have had a sensible transition period.

It may also be worth setting up a dedicated Twitter account for API changes as Foursquare has done with @foursquareapi - this would allow you to make quick posts to the community about any changes or downtime.

Whilst posts on the Developer Board have been greatly improved, I still believe that having a Twitter account for broadcasts about downtime or any major changes would be a good idea. I currently subscribe to the full emails of the board and so I can get an email whenever anybody posts something new - sometimes these are API developers asking basic questions yet sometimes they are important posts by the Gowalla devs that could easily get lost in the noise (especially if you have digests on). By having a feed that just posted notices from the Gowalla developers, visibility of changes would be greatly improved.


I originally wrote a section about cheaters purely because the option to check-in was not available in the API despite the fact it could be done easily using a JavaScript hack on the mobile site. The main reason for not having it in the API was that it would increase the ease for cheaters to make false check-ins just to collect stamps and items. Whilst the API was eventually updated to allow check-ins, the number of people cheating the system is still very high. A lot of trips are completed by people that haven't been to the spots and increases in check-in radius (which was a sliding scale depending on spot size and is now 5km regardless) have only exacerbated the problem. A lot of Gowalla players report these users to Gowalla via GetSatisfaction or email but there isn't any visibility on action taken. There have, however, been instances where users have been suspended for checking-in too fast, oftentimes incorrectly just on the basis of community feedback. In my letter last year, I said:

With regards to cheating, it should be fairly simple to ascertain if somebody is checking-in illegally as you can measure the time and distance between two spots and see if the speed is over a certain threshold (e.g. if you have checked-in at Austin and London within 2 minutes then there is obviously a problem). An automated system could monitor such things and then suspend an account giving it limited permissions (e.g. no item trading) until a Gowalla developer (or STE member) has a chance to review the account and unlock or ban the user.

I know that this is possible as I decided to build my own system to do exactly this detection in order to stop the vigilante justice that had been seen. However, many of the cheating accounts are private and are therefore unaccessible through the API which means Gowalla needs to tackle this problem themselves. I still believe that an automated system could work and involving the STE members would allow for a certain level of visibility on solving the issue.

These issues are particularly troubling at the moment due to the launch of Gowalla Rewards, the ability to pick up items at certain locations which have some form of real world reward attached to them. This issue has been solved slightly by a policy Gowalla put in place which basically limits how many items you receive based on the number of check-ins you make - whilst a good system, it did essentially pitch those players who like items against those that like the stamps and trips (again read my post on gamification for more details on this) and it wasn't relayed to the community very well at all. There is still a lot of work to be done in this area in my opinion.


One of other items I suggested was:

Creating a directory of applications that use the API (such as Foursquare has)

Again, this is something that hasn't happened yet but there have been some very small moves to publicise things that have been made with the Gowalla API. On the post announcing OAuth integration, a couple of projects that used the API were mentioned and on the official Gowalla twitter feed, a couple of web apps have been mentioned (they both did the same thing about 4 months apart, but still). However, making brief reference to 4 apps over the course of a year doesn't really promote all of the cool things that people are making. It also doesn't encourage other developers to get involved as, without promotion by Gowalla, the API feels a little like an afterthought which is a shame given the huge amount of improvement that has been made.

A page highlighting some of the applications made using the API would enable new developers to see a benefit to writing apps for the service - it also enables developers to get their app across to the core audience (as most apps developed are going to be targeting users already on the Gowalla service). I'm hopeful that the Gowalla twitter account will be posting out a few more of the great 3rd party apps that people have made over the coming months.


One of the final criticisms I had was in the documentation of the API as it was particularly sparse. Most of the comments on the Developer Boards were about errors being returned that weren't documented anywhere or about nuances in the API calls (e.g. why can't I check-in at the same place twice within an hour?) - However, the documentation has improved dramatically over the last few months with the Gowalla team listening to feedback from developers and patching up the docs or adding new pages as requested. A particularly difficult area was the new PubSubHubbub feature (which should really be publicised more - it's amazing) yet documentation was put up within a few days of a request on the boards.


Overall, the Gowalla API has improved dramatically in the past year. With a solid foundation and regular updates from developers, there is now very little risk to basing an app on the API as opposed to last year when maintenance was taking longer than development. There are still a few areas which could use improvement, particularly around publicising of 3rd party endeavours and communicating better around misdemeanours, but on the whole I can wholeheartedly recommend the API to any developer interested in location based services. There have been a lot of new API calls created and I get the feeling that there is some very exciting stuff around the corner. I would also recommend looking into the PubSubHubbub functionality as this puts Gowalla way ahead of its competitors by providing real-time notification of check-ins.

Finally, I'd like to thank all the developers at Gowalla who have put so much time and effort into improving the API, particularly Adam Keys, Andrew Dupont, and Rob Mack who have been incredibly responsive on the Developer Boards.

Font Finder: Now available for Firefox 4 and Safari 5

Many of you will be familiar with Font Finder, one of my first Firefox Extensions. The purpose of Font Finder was to display information about the selected font within your browser including information like size, line-height, color, etc. It also went further by not only showing you the font-family stack, but also determining which one was actively being rendered on your machine (as the font you see might be different to other users depending on your installed fonts).

I'm happy to announce that as of today, Font Finder is now available as a Safari 5 Extension. It has also been updated to be fully compatible with Firefox 4. I'm not planning on building it for any other browsers (e.g. IE9, Chrome) but if you have any suggestions for improvements to either version, please get in touch.

This is just the first step in porting Font Finder to Safari 5 and I will shortly be releasing an update which makes full use of the Safari UI rather than containing everything within an alert box - I will also be adding a lot more information, particularly around CSS 3.

Portal 2 on the new iMac (10.6.6)

Today I purchased one of the brand new iMacs that were released yesterday. One of the first things I installed was Steam and Portal 2 (as I'm looking forward to playing co-operatively with a friend on Windows) but I was surprised when trying to play that it required OS X 10.6.7

Portal 2 requires Mac OS 10.6.7

This is surprising because 10.6.7 has been around for a little while now so why wasn't it on the new iMacs by default. After trying a system update, I found that there was no update for the 10.6.6 iMacs and other people had tried the Combo Update downloadable from Apple to no avail.

After downloading all of Portal 2, I decided not to give up easily and see if there was a way around it. Developers are generally lazy and so they are probably just checking for the string 10.6.6 in the system version. As this version of 10.6.6 has all of the drivers for the new graphics card required for Portal 2, I thought there would probably be no harm in changing that system version to 10.6.7 to get past the Steam requirements. Turns out I was right!

To get your copy of Portal 2 running on your new iMac, navigate to /System/Library/CoreServices/ - now copy the file SystemVersion.plist to your desktop and open it for editing. Change the references to 10.6.6 to 10.6.7 and save. Now you'll want to delete the existing version and then copy your new file in it's place - you will need admin rights to do this.

Once that's done, fire up Portal 2 - you may get the "System requirements failed" message but if you press "Continue anyway" then Portal 2 will load and be perfectly playable (at 1080p).

Now, go forth and continue testing!

Note: when a 10.6.7 fix does come available for the new iMac, you should probably edit the SystemVersion.plist file and change the references back to 10.6.6 just to make sure nothing bad happens...

[20/05/11] Update: OS X 10.6.7 is now available through System Update for the new iMacs - make sure you reverse the process above before updating.

Review: Worldictionary for iOS

Worldictionary is a translation app for iPhone that allows you to use the built-in camera to detect and translate words on the go. The only language I understand other than English and the various programming languages I've picked up is Latin, so an app to help me understand various signs and documents in foreign countries is definitely useful for me!

Translating from English to French

When you launch the app, the camera is activated and you can instantly begin translating. All you need to do is line up the magnifying glass with the word you want to translate and it will automatically appear at the top of the app. The word it thinks it detects is displayed on top with the translation underneath.

Translation mistakes

As you can see from the image above, the camera doesn't always detect words cleanly (more examples can be seen from the history panel in the bottom right corner) but it is very fast at detection so these issues don't interfere too much. The app isn't designed to work with handwritten fonts but should work with anything in a regular font. The example document I'm using is a polling card for the upcoming election referendum here in the UK.

Language selection

To change the language, tap the bar at the bottom of the app which brings up a scrollable view listing an impressive number of languages to convert to and from. These are all available by default so there is no in-app purchase for language packs as per some other translation apps.

Translating from English to German

Once a new language is chosen, you can start translating instantly. I was struck by how fast detection and subsequent translation was and I experienced no problems with the app such as crashing or memory problems.

Translation results

You can tap the translated words or tap any previous translations listed on the right hand side of the app to go through to a more thorough translation detailing example usage, structure, synonyms, and definitions from the web (including services such as wikipedia and online dictionaries).

Whilst the translation is good and the app does what it says, I did encounter 2 problems which may stumbling points depending on your usage.

Firstly, the app only detects single words, not sentences or paragraphs both in camera mode and the manual input mode. This might be fine for the odd word lookup but isn't terribly useful for something more involved such as a menu or road sign. Also, without understanding sentences, words in some languages may not make sense (as many languages have words with different meanings depending on the surrounding words). Whilst understanding full sentences is still difficult for translation algorithms, I do think the app would work better if it could at least do the per-word translation on an entire sentence so you don't have to slowly input each word individually.

No translation without network access

The second problem is more important from my perspective but is also something that is unlikely to be fixed; you need to have internet access in order to perform translations. This is because the translation engine being used is Google Translate and therefore doesn't have offline access. The reason this causes problems is that many people travel abroad where data roaming charges are still completely excessive (I was charged £6 per MB whilst I was in the US recently) and therefore switch their data roaming off. The benefit of a translation app is that you can use it anywhere when you need it (e.g. translating a menu at a restaurant) and you may not have WiFi available - turning on the data roaming for translation could become an expensive habit, particularly if you haven't turned off other apps or push notifications before making the switch. Whilst the API calls the app makes should be fairly small, I'd be more worried about forgetting to turn off data roaming after I'd used the app.

Whilst these problems are present in other apps, there are some which manage to solve both of these such as Word Lens which gained a lot of publicity when it first launched due to the clever way in which it uses the camera not only to translate, but also to place the translated words back into the original camera image. It might be a more expense app with translation packs at £5.99 each, but it works offline and can translate whole sentences (in a very cool way). Unfortunately, Word Lens only works with English and Spanish translations so is not terribly useful if you are going to France or Germany for instance.

Worldictionary is a clever app with its word recognition and fast translations (depending on network speed) but its lack of sentence recognition and reliance on internet connectivity lets it down. If you can look past these issues, then I can recommend it as a good translation tool for those times when you need a rough translation or have a need for multiple languages.

Worldictionary is priced at £2.99/$4.99 as is available in the App Store.

Disclosure: I was given a free copy of this application to review. I tested it on an iPhone 4 running iOS 4.3.2. If you have an app for iOS that you would like me to review, please contact me.

iTunes TV Artwork Script

I have a large amount of TV shows stored in iTunes but not all of them were purchased there, particularly as you can buy a Blu-Ray of many TV shows for a fraction of the price of a Standard Definition download. The only issue I've had is that I lacked artwork for each of these shows. In the past, I'd just screenshot the 200px or so image that showed up in the iTunes store and use that, but since getting an Apple TV (which displays the artwork at a much larger size) I decided I needed a better solution. After a weekend of sorting out my iTunes library, I decided to take a look at the iTunes Search API and see if I couldn't find a way of getting that artwork. They provide a 100x100px thumbnail as part of the API response, but fortunately (with some URL experimentation) I found a way to get the full 600x600px artwork.

 You can find the working version on my projects page but I thought I'd share the code briefly below so you can see how it's done and adjust it for any other media available on iTunes (e.g. movies, music, apps).

$search = $_GET['show'];
if ($search) {
	$url = ''.urlencode($search).'&country=us&entity=tvSeason';
	$obj = json_decode(file_get_contents($url));
	$results = array();
	foreach ($obj->results as $result) {
		$data = array();
		$data['url'] = str_replace('100x100', '600x600', $result->artworkUrl100);
		$data['title'] = $result->collectionName;
		$results[] = $data;

As you can see, it makes a fairly standard API call to the US iTunes store (as that has far more content than any of the others) which returns a lot of information about the particular entity (in this case a TV series). However, the artwork URL provided is only good for a 100x100px image so I us a basic str_replace to change that to 600x600 (the only other size I've found that works is 200x200). Once that's done, I grab the title and stick it all in an array to loop through later - simple!

Hopefully this script will be of some use to you - it's certainly made my library look a lot nicer when browsing on an iPad or an Apple TV!

Gamification, Social Validation, Gowalla, and moving on from Wallabee - What I learned at SXSW

Since childhood, I’ve been a huge fan of maps and the concept of location. I used to spend hours drawing maps of the neighborhood where I lived and reading books and magazines about different countries and places around the world. Much later, I became a web developer and would spend a lot of time playing with the Google Maps APIs and creating mashups with the FireEagle service. When the iPhone came out, I was hooked; not only for the simplistic UI (I could write an entire blog on how less is more with UI) but by the fact that your location was always in the palm of your hand. Once the iPhone SDK came out, I switched careers purely because location-based apps were the stuff of my dreams and that’s what I wanted to spend my time on.

 Earlier this month, I headed to Austin for my first experience of SXSW. Whilst many people (myself included) went for the talks and networking opportunities, I was mainly interested in meeting the people behind Gowalla, a location-based service I’ve spent a lot of time with over the past 3 years. In Austin, I was staying with a group of friends who had come not for SXSW, but to collect the rare items and pins that would be available through Gowalla.

The purpose of this blog post is to explain what I’ve learned about the future of location-based services both from talking to Gowalla employees, and watching how people play Gowalla in the real world.

Gamification and Social Validation

One of the key buzzwords of SXSW 2011 was “gamification” which is loosely defined as:

The use of game play mechanics for non-game applications, particularly consumer-oriented web and mobile sites, in order to encourage people to adopt the applications

In the same way that apps add “tweet this” and “facebook that” buttons in order to tick the box for social media, it seems that the future is based around the idea of adding a game layer purely because other apps have one. These mechanics tend to be of the badge variety which works by giving the user digital badges for reaching certain goals. Some go further by giving you physical things (e.g. stickers) rather than digital items.

In addition to gamification, there is also the proliferation of the “check in” model of thinking. This is the idea that you can now check in to anything be it a location (Gowalla, Foursquare), TV shows (Miso, Glue), Books (GoodReads), or just about anything else you can think of. When the models are combined with social networks like Twitter of Facebook, it seems that most applications are generally designed to do 2 things; either tell people what you are doing or show-off to other people about how good you are at a digital task.

For me, the best talk at SXSW was by Josh Williams, CEO of Gowalla, in which he discussed the future of location-based services in a talk entitled “Where are we going”. The candid presentation talked a lot about where services had gone wrong but was also self-admittedly contradictory (especially when you look at the Gowalla service overall which I’ll come onto later). However, he had one key slide which I think resonated with everybody in the room:

Social validation is the primary driver for activity on today’s web

This is a profound idea that suggests the reason that people play with game layers, send tweets, check in on apps, and use social networks and services is purely based on egotism; we do things not because we want to, but because we want to be accepted by society. This is not a new idea, but it is one that I think a lot of people have been blind to for a long time. With one sentence, Williams had made me uninstall a number of apps on my phone and take a fundamental look at the projects I was working on and the people I was interacting with.

Another key quote from the talk was:

Game mechanics are subservient to the usefulness of a service

Whilst this one didn’t hit me with as much impact as the piece on social validation, it’s something I’ve not been able to stop thinking about over the past few weeks. Social validation is the main reason people use a game mechanic but what is the driver for playing a regular game, watching TV, or reading a book? After thinking on it, I’ve concluded that the driver for offline tasks tends to be story, whilst online we tend to want to share our story. By way of example, I might watch Mad Men as I enjoy the plot, but I’ll tweet about it because I want social validation.

This describes the correlation between offline and social networking well enough, but what about game mechanics? These were created in order to incentivise a story action but tend more often to promote the idea of social validation. An interesting game mechanic to look at would be something like Xbox Achievements or PS3 trophies. These were designed to extend the life of a game by adding extra challenges that weren’t part of the main storyline yet have now evolved into an exercise in social validation. People will now play games not because they are interested in the game itself but because they want a higher gamerscore. I’ve seen (and been a part of) this idea myself and it’s only when I think about it that I realise that the best games I’ve played are generally the ones which don’t have achievements. Games like Zelda and Final Fantasy are good because of the story and core mechanic, not because they improve my gamerscore. I’m not saying that all achievements are bad, but I do feel that a game like Assassins Creed II is detracted from when players are performing tasks such as collecting 100 feathers for the sole reason of improving their gamerscore.

Whilst console games can have both this social validation aspect and a good storyline, a worrying trend with most new game mechanics and online games is that they don’t have the story portion at all. For instance, what is the point of Farmville? There is no ending, there is storyline, it is simply a game based around social validation. So it is for services like PackRat (made by the same people as Gowalla) in which you can collect items simply for the purpose of showing other people. Both these games (and others) have an element of a game currency (for purchases of items in the game world) which can be topped up with real money. You therefore end up actually paying real money to purchase items in a digital world for the sole purpose of showing them off to other people. I eventually stopped playing PackRat when I came to the realisation that I was spending money and time (sometimes jumping up when new items came out so I could be the first to get one) on a service which actually had no benefit. I maintain that the reason for this is that there is no ending - users might spend time collecting all the Pokémon on a Nintendo DS as they know there is an ending, but with Farmville, PackRat, et al., the whole thing is continual.

Gowalla: A game of two halves

So, what of location-based services? Gowalla has a difficult task ahead of it currently as it is walking a line of two different concepts; the idea of exploring the world and the idea of collecting items. I believe these can be defined as story and social validation respectively.

Gowalla have used variations of “explore the world” since they first started and it is one of the key things that drew me to them. With their beautiful artwork, it was easy to imagine that your travels were like those in the past where travelers would place a sticker on their suitcase from each place they visited. The concept of a digital passport imitating the real world was exciting and they have done a great job of extending this with featured spots and trips. More recently, highlights and notes have allowed users to show where there favorite places are both publicly and privately and encourage other people to visit those locations. One of the most interesting pieces they are working on is in telling the “story” of your travels. This has begun with them joining your flights together and showing the distance (and connecting flights if applicable) when you check-in at 2 or more airports in a row. They used this feature to award a special pin for those that had travelled to SXSW when they landed back at their originating airport (so I got mine at Heathrow after travelling back from Austin airport). Williams has been mentioning for a long time that these flight updates are “just the beginning” and I can envisage a future in which they can build up a digital holiday keepsake for you (complete with photos, highlights, check-ins, and tweets) by using this information.

However, the other side of Gowalla is one based on a game layer. Items have long been a sore point to many users (including myself for a time) as they were one of the key features that differentiated Gowalla from other location based services (such as Foursquare). As most new users were coming from PackRat, it is easy to see why items were such a key part to many peoples experience. However, like the never-ending gamification I described earlier, there is no ending for items. Once you have them all, you don’t get anything as a new one might be released next week. Therefore there is no end and no purpose to collecting them other than to show off to other people for social validation.

Gowalla have been slowly trying to lessen the importance of items within the game in order to focus on story, but as they have done so the community has been more and more vocal about the changes. One of the changes was to make it so that checking in to more than 5 places within an hour would trigger a switch preventing you from receiving items for the next 24 hours. This was at odds with the “collect them all” aspect of items which require checking in all over the place in order to get them but was done in the interest of making people check-in where they are right now rather than checking-in everywhere within 5km (the current distance you are allowed to check-in from your actual location) just to get items.

Unfortunately, I was privy to many embarrasing moments at SXSW where the Gowalla team were subjected to people complaining about items, check-ins, and the other aspects that I’m sure Gowalla don’t really care about (as they don’t build on the story mechanic). I saw some of the most childish outbursts I’ve ever seen in my life over something as simple as a digital item and it really put me off items as a whole.

In my opinion, Gowalla need to cut items lose in order to really grow as a service. Judging by the complaints on their GetSatisfaction pages, I’d say that the vast majority of complaints are about the game mechanic rather than the overall service and its story elements. If they were to cut off the game mechanic, Gowalla would lose a lot of users, but they’d be able to focus on the key part of the service; “seeing the world”. This in turn would build a better product and allow them to regain users who share their vision rather than trying to maintain the careful balance they have at present.

My current belief is that items are slowly being fashioned into rewards, a feature that was launched at SXSW. With rewards, some of the digital items you find are actually usable as promotional offers (so you might get a “free taco” item which allows you get a free taco when you check-in at certain locations). If they removed the non-reward items, they could have a social layer which has a purpose and isn’t tied so intrinsically with the limitations of exploration. By that, I mean that people would be encouraged to check-in only where they are currently, and by doing so they may receive one of these promotional rewards. Once a reward is used, it should then be archived as it then serves as a history of the promotions you’ve earned (which are a story in themselves). By doing this, you no longer have a part of the service which encourages multiple check-ins for items which have no value beyond social validation.

I have no idea if this is there current plan, but it seems a sensible way forward.

Wallabee: A project based on Gowalla items

If you’re familiar with my projects, you’ll know of a service I created called Wallabee. It’s a website (and set of apps) that build on the Gowalla API and basically dishes out a lot of information about items in particular. I originally created it as I wanted an easy way of finding out which types of spots items appeared at. Items were a fun feature at the start of Gowalla and I would travel to whole new places just to pick up an item - I used to think I was doing this because I wanted items but I eventually realised that I was enjoying having a reason to go to new places and “see the world”. Once I made the site public, it gathered a large following and has grown into various things since. There are apps, item hunters, tools to show Flickr photos at different spots, and a new guide which introduces players to key Gowalla concepts (as Gowalla itself has no tutorial). However, the most popular things every time have been things to do with items (which is confirmed by a new feature I built recently called the Item Directory which shows people where every item can be found in real time).

After SXSW and thinking on both the attitudes of people I’d seen and the talks I’d heard, as well as mulling over everything I’ve said above with regards to social validation, gamification, and the future of Gowalla, I decided that I just didn’t want to do this anymore. I’ve been working on Wallabee in its various incarnations for two and a half years and it wasn’t until I took a step back that I realised everything I was doing was based on items. I’m not interested in Gowalla items. I haven’t even been actively trying to collect them myself for the past year (yet I seem to have got them all just because of my slow check-in rate) so why am I building free apps based around them? I realised that I was doing it not because I wanted to, but because it was what most of the followers I’d gained (by starting with item-based tools) were asking for.

I’ve therefore decided to stop working on Wallabee and instead focus on building location-based apps that extend the story aspects of travel rather than the gamification aspects. If you’re a Wallabee user, then you’ll want to read my post on the Wallabee site about how this affects you, but basically I’m handing the site over to another developer who is interested in the gamification layer and in building upon the brand I’ve created.

I will still be using the Gowalla API and the Gowalla service as I think it shows great potential and is a genuinely exciting location-based service. I’ll be doing this under my own name rather than the Wallabee brand, however, and the apps will mostly be of a paid nature. This begins soon with a completely new app which I’ll be releasing shortly.

To the future

This blog post ended up being about five times longer than I intended but I hope it gives you an insight into what I think about location-based services moving forward as well as some of the social issues around game mechanics. To finish, I’d like to take one more quote from Josh Williams talk at SXSW:

Stay true to your vision

I lost track of my vision when I started developing tools that I wasn’t using myself. I’m looking forward to returning to my vision by creating new apps that will help people explore the world around them.

Mobile OS Updates: Android vs iOS

Over the last couple of months, I've been using two competing phones day-today; a Nexus S (Android) and an iPhone 4 (iOS). Whilst there are many differences and similarities, one of the things I want to talk about today is the different ways in which they deal with updates to the core operating system. System updates are a crucial part of the mobile experience - sometimes they offer major new features but they are usually minor updates to deal with bug fixes. So how do Apple and Google deliver their system updates?


The Android platform updates itself via an "over-the-air" system which appears to rely on individual carriers to push out system updates. Due to the large number of different devices, certain updates will only appear for certain phones and this fragments further by region and carrier. For example, Android 2.3.3 came out 2 days ago and only runs on the Nexus S at present - whilst a number of customers in the US have received the update, my Nexus S is still refusing to detect an update from 2.3.2 leaving me to conclude that it is waiting for my carrier to push it out. However, when an update does appear, the process is very slick. A notification appears to let you know you have an update including details of what this adds and the size (which for minor updates tends to be a couple of MB). One tap starts the download process and, once complete, the phone reboots and you're up and running. At no point do you need to plug into a computer or even connect to a wireless network. It's very impressive. However, the lack of cohesive strategy on when updates will appear and on what devices they will work on causes the whole process to be a bit of a disappointment, especially when you're waiting on a major bug fix or new feature.


The iOS update system is very different. Each update requires you to plug your iPhone into iTunes where an update will then download and sync to the phone. Each update includes the entire OS, rather than an incremental update, so is typically around 450MB (depending on device). This takes a long time to download but then takes about the same time again to install onto the device. The advantage to this process is that if something goes wrong you can restore from a backup immediately (whereas on an Android phone in the wild you'd be stuck without a phone). Also, when an update is available, it is generally available globally within 2 hours of release and there is a button you can press to check for updates manually. Apple also post a direct download link on their support boards so it is generally fairly easy to get an update regardless of your location or carrier. However, the lack of an over-the-air facility and the massive downloads are very tedious.

Update Statistics

When you look at the two download mechanisms, one would expect that Android users would update their phones more frequently than iOS users, particularly as the update is delivered directly to the device. However, the lack of support for devices and the requirement for carriers to approve updates means that only 0.8% of all Android users are currently running OS 2.3, with 57.6% on 2.2, 31.4% on 2.1, and the rest on pre 2.* software. It is difficult to contrast fairly with iOS as Apple don't release breakdown usage stats, but by looking at the usage figures the major apps are publishing you can get an idea. The number of users running iOS 4.* is around 90% with over 50% on the latest build of iOS 4.2 - there are only 10% running the previous generation family of 3.x and these are most likely users on the original iPhone and iPod Touches that aren't able to upgrade to iOS 4.0

Android Figures accurate as of Feb 2nd, 2011 (from Wikipedia)
Android 2.3 (Gingerbread): 0.8%
Android 2.2 (Froyo): 57.6%
Android 2.0/2.1 (Eclair): 31.4%
Android 1.6 (Donut): 6.3%
Android 1.5 (Cupcake): 3.9%

iOS Figures based on "Bump" application as of Jan 14th, 2011 (from Quora)
iOS 4.2.1: 52.89 %
iOS 4.2: 0.09 %

iOS 4.1: 27.50 %

iOS 4.0.2: 3.36 %
iOS 4.0.1: 2.95 %
iOS 4.0: 2.94 %

iOS 3.2.2: 0.49 %
iOS 3.2.1: 0.07 %
iOS 3.2: 0.10 %

iOS 3.1.3: 6.43 %
iOS 3.1.2: 2.52 %
iOS 3.1.1: 0.10 %
iOS 3.1: 0.21 %

iOS 3.0.1: 0.10 %
iOS 3.0: 0.22 %

iOS 2.2.1: 0.02 %
iOS 2.2: 0.00 %


I'm still keenly waiting for my update to Android 2.2.3 as it adds, amongst other things, a new feature which enables the NFC chip in the Nexus S to write to tags as well as read from them (something that should have been there from the start in my opinion). However, until my carrier pushes it out, I have to wait whilst other developers on US carriers get a head start. This would be fine for the average user normally, but I fail to understand why Google aren't hosting a manual update? An over-the-air update is convenient, but if there is a major bug fix then you should be able to download the update manually and do a tethered sync at the same time that Google pushes the update live.

The iOS system seems more archaic in that the updates are massive and you need to manually update, but the way in which Apple publicise the updates seems to ensure that users are updating. Whilst the statistics above aren't wholly reliable, it shows a trend that users are aware of iOS updates and willing to plug in and upgrade. From my own anecdotal evidence, I've seen similar high numbers of upgrade take-up with many non-technical people in my family running the latest version of iOS without any help to do it.

The way that Apple has done this better is that they a) publicise a new release (going to shows nothing about 2.3.3 aside from a blog post on the developer board directing you to download the SDK) and b) have a "check for updates" button that you can click when you hear that an update is available. The Nexus S has a "System Updates" section within "Settings" but this only shows updates you've already been told about rather than forcing an update check. From searching around the internet this afternoon looking for the update, I found a number of posts extolling the virtues of dialling *#*#2432546#*#* (which is *#*#checkin#*#*) which forces the device to do a checkin with your carrier and should push any updates that are waiting to you. This is not an update system for the casual user!

Furthermore, Apple have unified their product line so that a new iOS update is immediately able to run on the iPad, iPod Touch, iPhone, and now the Apple TV. There are certain devices which are excluded (e.g. the original iPhone and original iPod Touch) but these are well highlighted. With Android, I have no idea which phones can or can't update and if there are technical limitations for this (as with the iOS updates) or simply the carriers not being bothered. From some reports, it seems that the carriers are loathe to push out functional updates as they detract away from new products they are selling...

Overall, I think Apple needs to take some of the improvements in updating that Android has made such as pushing out incremental updates rather than forcing you to redownload the OS, and allowing you to update the OS without connecting to iTunes (even if this is only over Wi-Fi). However, the major problem with Android is that it is stitched up with mobile carriers, something the iPhone broke away from. When this extends to critical bug fixes, then it is the end user that suffers. Apple needs to take some cues from Android in terms of implementation, but Google needs to take back more "openness" from the carriers if they are to provide a sufficient update system.

Review: WorldCard Mobile for Android and iPhone

WorldCard Mobile is one of many applications that allows you to scan in a business card and have the details automatically loaded into your contacts. I haven't used one of these kinds of applications in a long time and so I jumped at the chance to test one when a review copy was sent to me.

 The opening screen is fairly straightforward with the option to start scanning either by taking a picture with the camera or using a photo from your library. There is also an "Exit" button which I disagree with from a UI point of view as that is the point of the physical home button surely? I'm probably being overly harsh as that kind of thing is prohibited by Apple and so I don't come across it much when looking at iOS apps, but I generally frown upon any duplication of standard controls with your own versions (for example, websites that have "back" buttons - that's what the standard browser "back" button is for!) Anyway, I had a business card for one of my friends who works in Australia so I decided to give that a try by using the Camera feature. This loads up a standard camera control and allows you to take your photo. Once captured, you can zoom into the image, rotate it, and choose the correct language from a choice of seven; English, French, German, Italian, Spanish, Portuguese, and Dutch. Pressing the "Recognize" button will then fire up the OCR system that ran in under 1 second on my Nexus S. As you can see, the captured data is incredibly accurate. The only problem was with the word "Lisa" which came out as "Usa" but that is partially due to the closeness of the letters on the business card and me not taking a picture close enough. I was particularly impressed with the intelligent way in which it parsed the data enabling it to set the fax numbers correctly as well as building the company name from the logo and footer and correctly picking out the job title. Editing any information that wasn't correct is very easy with a standard editing dialogue. I quickly fixed the name and saved before then pressing the export button. This sends the contact information into your devices address book. As I already had contact information for this person (pulled in automatically from FaceBook), it simply updated the existing record with the new work related information without any prompting. Overall, I'm incredibly impressed with this app and the very fast and accurate OCR software built into it. If you are frequently given business cards, I would highly recommend it as a quick and efficient way of storing them. WorldCard Mobile costs $5.99 and is available on the Android MarketPlace. There are other versions available at a higher price for recognising Japanese, Chinese, and Korean text. You can find more details at Disclosure: I was given a free copy of this application to review. I tested it on a Nexus S running Android 2.3. If you have an app for iOS or Android that you would like me to review, please contact me. Update: WorldCard were kind enough to give me a review copy of their app for iPhone as well. The interface is pretty much the same with very similar functionality although I did notice that the iPhone version allowed you to review your imported cards within the app (rather than just exporting them to the address book as on Android). However, the recognition quality didn't seem to be as impressive as the Android version with several errors being made compared to the one basic error on the Android app. I'm not sure if this is something to do with the code or with the iPhone hardware (although the tap to focus made me think the iPhone would function better) but for now I'll be using my Nexus S to do any business card recognition.

Enabling any HTML5 Video to work over AirPlay

It's taken a little while longer than I expected to but I've managed to put together a script to make any HTML 5 video playable through Safari on the iPad. With the advent of iOS 4.3, Apple are now allowing websites to add a special tag to their video markup in order to enable video streaming (as with the current 4.2 version you only get audio streaming). However, with one simple JavaScript bookmarklet, you can now enable AirPlay video for any website.

 First of all, you'll need to save the following bookmark - the best way is to save the link below as a bookmark on your computer and then sync it to your iPad via iTunes or MobileMe: HTML5 AirPlay Bookmarklet. Alternatively, bookmark this page on your iPad and then copy the text below:


You now need to edit the bookmark you saved for this page and paste the code above into the URL (you'll probably want to rename it as well).

Once the bookmark is saved, you just need to go to any HTML 5 video (such as or online and start playing it. You'll notice if you look at the AirPlay window that you can only stream audio. If you now load the bookmark, the video should disappear, and then come back with AirPlay now enabled for video. This short video below will demonstrate the process a little better:

So how does it work? To get AirPlay to send a video stream in Safari, you need to add the attribute x-webkit-airplay="allow" to the video tag. I assumed that by adding this to an existing video via JavaScript then it would automatically work. However, Apple have been slightly clever and ignore any parameters you add via JavaScript. So, I instead use JavaScript to add the new attribute before cloning the video, removing it from the DOM, and then re-adding it. This re-addition to the DOM seems to trigger something in Safari which causes it to re-read the AirPlay attribute and allow you to stream the video. Please note that this will only work with iOS 4.3 on the iPad with iOS 4.3 on the Apple TV. If you try and stream to an Apple TV running older software, Safari will crash.

This is currently in a very rough stage yet so far has been tested and works with as well as native HTML 5 video on websites such as - it doesn't work with any HTML 5 video wrapped in a custom skin (e.g. the BBC iPlayer) but who knows what will be possible in the future. If you have any additions or improvements, please get in touch.

Update: A few people have contacted me about embedded videos such as the one on this page. Unfortunately, with Vimeo at least, these don't work as they are packaged up in an iFrame rather than being native <video> content. JavaScript isn't able to access the contents of an iFrame from a different domain due to the cross-domain security policy. If videos are embedded natively, then they'll play fine, but for iFrame content you'll need to go to the original website.

Update: This workaround is still functioning in iOS 4.3 beta 2.

Update: And it is still working in iOS 4.3 beta 3.

Update: And finally, this works in the publicly available version of iOS 4.3 - enjoy!

Update: I've altered the article slightly as is now adding the AirPlay functionality automatically to their website (so I've changed the examples given). I've also added a copy-paste section of code as that may be easier for getting the bookmarklet onto your iPad.

Update: I've taken a look at using this on iOS 5.0 beta 1 but so far the AirPlay functionality isn't working well. This is more likely an issue with the beta (which is fairly buggy).

Update: iOS 5 has changed the defaults for how AirPlay works. This means that all online video is now classed as AirPlay enabled (unless the content provider opts out) making this bookmark now redundant.

« Older Entries Newer Entries »