We launched a beta today of our mobile potholes map, which features extensive use of geolocation using the user’s Web browser. This has been on my and James Wilkerson’s plate for a long time, and it feels really good to get at least this version out in the public.
The mobile site is at http://dmreg.com/potholes.
You can see the desktop browser version at DesMoinesRegister.com/potholes, and there’s more info on that project in a previous post.
This is our first extensively location-aware site, and it’s our first really extensive specialty mobile site, so there’s a lot of figuring out still left on this one. But we’re pretty happy with the result.
We used quite a few methods that were different or modified from our other mapping projects.
1. For geolocation, we’re using the W3C geolocation API built in to many phones’ browsers. Safari for iPhone and most Google phones have it, but BlackBerries don’t. Theoretically we’re also supporting Google Gears geolocation, but we haven’t really tested it on mobile devices.
2. We used the Google Static Maps API instead of the more-familiar Javascript API. The Javascript API actually works fairly well, technically speaking, on iPhones and Google phones, but the user experience can quickly become confusing. Dragging things on the map is hard on a mobile device, and zooming in and out on the map often messes with the browser zoom. The static maps API is a lot lighter load for a mobile connection to bear. Almost as a bonus, because I was about ready to write off the BlackBerry browser, using the static API also enables BlackBerry users to use the site (the lack of browser GPS still limits BlackBerry users, but they can at least submit a pothole using an address).
3. We’re using Prototype’s Ajax and JSON to load points and send new pothole data. We’ve done this a few times now, and it’s becoming our standard. JSON is lighter than XML on the server, and you can send data back and forth as Javascript objects, which makes sending complex data much easier (and much easier to modify later).
4. We did this as a website instead of an app in order to work with more platforms at once, and because we’re much better at Web design than objective C (which is to say I know not a bit, and learning will take a while). I’m curious to hear others’ thoughts on this, because I think most journalism shops are going to have a hard time making the economics of iPhone, BlackBerry and Google apps a pretty tough thing to make work. As long as mobile browsers keep developing quickly, I think this is probably the way to go for now, unless you can afford to build your own apps, have a lot more time to devote to one project than we do, or can afford to pay someone else to build them for you.
Check it out, let me know what works and what doesn’t.
Michael Corey is a news applications developer at the