One of the most visible changes in GasBag 2.0 was our move away from Google's map over to Microsoft Virtual Earth. It's been really interesting to watch the way this change has been received, because it hasn't worked out exactly the way we anticipated.
Today I'd like to tell you all the story of why it was that we switched, and hopefully give you some insight into what we were thinking. If you don't like the change, I totally understand, but hopefully you'll find it an interesting story nonetheless.
The story starts in Summer, 2008. We had the idea to build this application, so we all went out and bought Macs, downloaded XCode and got started. The initial concept was to deliver "map-based, community-driven mobile gas-price finding". That's a very hyphen-rich mission statement, but there it is. We pretty quickly got to a point where we needed to embed a map into our app, and this is where things suddenly got hard.
And we kept thinking that right up until the day that we finally got accepted into the dev program and were able to install the app on our phones. You might think that a day like that would be cause for celebration, but instead we were all hugely disappointed. You see, running our application in the Simulator brought with it all the processing power of my laptop's fairly significant CPU to it plus the huge bandwidth of my home Internet link. Needless to say, the iPhone does not have as much CPU power as my MacBook Pro, nor the bandwidth. So we ran the app up on our phones and quickly discovered that the sub-second load times we'd seen from the Simulator were complete fiction: load times on the phone were about 60 seconds, and the beautifully smooth interactions we had in the simulator were nowhere to be seen either -- movement was jerky and the slow interactions affected usability badly -- pinching and swiping both worked in the app, but it was so slow to respond that for the most part nobody noticed.
Undeterred, what followed was a solid month of hacking on the code to get it into shape. We managed to get the typical load time down from 60 seconds to about 10, improved the responsiveness of the map, and we eventually got it to a point where, well, we weren't thrilled about it, but it was definitely workable, and with the screaming about gas prices at the time, we thought we helped more people by releasing than by holding it back.
So release we did, and things actually went pretty well ("well", in the sense that a startup uses it, means that the first day's deluge of users brought our server to its knees, requiring a quadrupling of compute resources to handle the load), and we saw some solid growth, helped by the gas price crisis, and for a while, we forgot about the map.
Along the way, we started discussions with WhatGas, who are an awesome bunch of guys in the UK doing some similar stuff on the web. We saw some great synergies, so we formed a partnership with them, and then began the hard work of retrofitting internationalization (or i18n as we call it) to the server and to the app. We also figured that since we'd done all that hard i18n work, why not release it in Australia at the same time. And so we got a good database of stations in Australia, and launched it and held our breath.
It was at this time that I was suddenly acutely aware of our map's shortcomings again. As a co-founder and Sydney-sider, I felt duty-bound to enter petrol prices everywhere I went, and so I religiously did exactly that. And it was at that point I realised what I imagine a lot of our users had known for a long time: the map was too slow.
But what to do? Well, fortunately the iPhone dev community has come a long way since our initial efforts, and a particularly bright developer called Joseph Gentle invented RouteMe, which is just an awesome piece of code to display a fast, responsive map in your application. So over my Christmas "break", I put together a prototype with RouteMe, and... wow! It solved pretty much all of my gripes with version 1, just like that (you'll have to imagine me snapping my fingers at this juncture).
But Google Maps as a source of map imaging just wasn't available. Not only did RouteMe not support it, we looked at the Google Maps terms of service and it was pretty clear: you can't use the map imagery outside of Google Maps. A little more research showed that they were serious about it too, having served several take-down notices to websites who had tried to push the limits. In contrast, Microsoft actually provides a detailed explanation, including source-code, on how you can build an app using their map imagery.
So we went ahead and launched with Virtual Earth as our source of map imagery. This time, we were truly proud of the application: we could say with a completely clear conscience that it was the fastest app of its type, and that it was easy to use. Like I said, all our gripes from previous versions were basically eliminated. We released, and also pushed out GasBag Pro, which added some features users had been asking for for way too long in our books.
But this is where the surprises started rolling in. We've had a huge amount of feedback from people saying "Why did you take the Google Maps away?! The new map is ugly and waaaay slower." Needless to say, we were surprised: we'd done a lot of testing prior to release, and the response was unanimous: version 2's map was a huge leap forward in terms of performance and usability.
We've now looked into a few of these, so let me give you the scoop: the issue is with caching. For those who don't know, this is a technique used in many programs in many ways, whereby the computer remembers something it did before, in case it needs to do it again. When that happens, the computer just inspects the cache and gives back the answer it worked out last time. In the case of HTTP based applications, web-browsers (and web-browser toolkits) will store data that they download from webservers, and use this cached copy the next time that document is requested.
Now as part of that effort to get version 1's load time down from 60 seconds to 10, we shipped with what we called a primed cache: we shipped with a cache that had already been loaded with map tiles for some commonly used areas, and a bunch of other stuff that we figured most of our users would need. We didn't do that with version 2. Mostly this was because the huge win in load times that RouteMe got us somewhat obviated us of the need to do so, but it was also because we wanted to shrink the download size. Version 1 clocked in at around 7MB, while version 2 is a little over 1MB -- much more palatable, especially when you're on the road and don't have a WiFi link to work with.
So what people are now seeing is that when they upgrade to 2.0 and fire it up, they're met with a few seconds of a grey screen while those first map tiles are pulled down. Similarly when they pan around, there's more grey where the first version didn't have it because those areas were in the primed cache. I hope that they're also seeing that when they do that panning, the application responds instantly, zipping and zooming wherever their finger takes it.
But the great thing about a cache is that it remembers -- after you've suffered through those first few seconds of downloading map tiles, you'll never need to wait for them again; the phone will store them and the next time you load up the app, you should get a map on the screen within about 3 seconds of tapping the GasBag icon. That's faster, much faster, than CoreLocation is able to get a fix on your location in most cases, which is pretty hard to beat.
As for the map being ugly, well, I got used to the Virtual Earth imagery pretty quickly, but it was a bit of a shock initially. As things stand, we really don't have much of a choice at the moment. The good news is that the popularity of mapping apps on iPhone is bringing with it renewed interest in mapping imagery, so we're hopeful that new options will appear in the not too distant future. We're certainly keeping an eye out.
But hey, don't get me wrong, we love the feedback. The good and the bad. So keep it coming, and thanks for your patience while we try new stuff like this out; we hope that we're making a better app for everyone.
James -- CTO and Co-founder.