As mobile devices grow in popularity towards being the most common way people access the web, so does the desire of both business owners and developers to leverage the devices' new capabilities. Often this comes in the form of an application, but with the advent of responsive design and improved mobile browsing it is taking place with increasing frequency in the browser.

One of the most obvious and useful features to employ in the mobile context is location finding. All the most popular mobile platforms have the ability to determine their location, often to within a few meters. This can be useful in many ways, but let's look at a relatively simple use, getting from where you are to where you want to be.

Picture this. You are downtown waiting for your friend to finish work, sitting in a small cafe, surfing the web. You just landed on the website for a great new store and you want to check out. You can see from the contact page that the downtown location is on Granville Street but you're not sure where it is, how far it is from the cafe, or if you have time to get there and back before your friend gets off work. Now, as a mobile savvy user you know you can copy and paste the address from the website into the search bar of your map application. While certainly achievable, this can be an annoying task. What if you could simply click on the address and have your map application open displaying a route from your current location to the store? To me, this sounds like the ideal interaction! Is it possible?

The answer is yes. Well really the answer is "yes, but...". The iPhone is the only platform on which I have created the desired experience of a single click taking you straight to the directions. On the other devices I was only able to plot the destination. The user then had to switch to the 'directions' view manually to plot their route, but even this is light years ahead in terms of user experience from having to copy and paste anything.

So, how do we make this work? First, let's start with a default behavior that will give desktop users the information they need by linking to Google Maps. Our example location will be:

Zelen Shoes
894 Granville Street
Vancouver, BC V6Z 1K3

URL Structure

To find this location on the Google Maps website you'd need a link like this:

<a href="http://maps.google.com?q=894%20Granville%20Street%20Vancouver%20BC%20V6Z%201K3">Find Us</a>

 

iPhone

The good news is that an iPhone would actually hijack this URL and open the map app automatically. But it would not plot the route. To plot the route we'd need to modify the URL to:

<a href="http://maps.google.com/?saddr=Current%20Location&daddr= 894%20Granville%20Street%20Vancouver%20BC%20V6Z%201K3">Find Us</a>

 

Here we are setting the source address to "Current Location" and the destination address to our store. If you'd like more information about constructing query strings for Google Maps take a look at http://querystring.org. In my experience anything you can do with them on Google Maps will work in the iPhone app.

Android

Instead of simply hijacking URLs to Google Maps like the iPhone, Android is employing the geo: protocol which relates the specific intent to find a geographic location. This may or may not be a better approach, we can leave that debate for another day. Here, let's just talk about how to make it work.

Unfortunately the current implementation of the geo: protocol on Android devices does not give us the ability to request a route but it will let us plot our destination map. From there we can use the 'directions' feature of the application to view our route.

For information on the geo: protocol and other 'intents' take a look at the following link. http://developer.android.com/guide/appendix/g-app-intents.html

Here is how we'll construct our URL for Android.

<a href="geo:894%20Granville%20Street%20Vancouver%20BC%20V6Z%201K3">Find Us</a> WP7

 

Windows Phone 7 and the IE Mobile browser use another protocol, the maps: protocol. In fact, iPhone and Android will also respond to this protocol, but in my tests the iPhone did not respond to the Google Maps parameters outlined above which means you can drop a pin, but not plot a route. Android is limited to this functionality even when using the recommended geo: protocol so really we could use the same maps: URL structure for both Android and WP7. Again, the user has to switch to the 'directions' view.

<a href="maps:894%20Granville%20Street%20Vancouver%20BC%20V6Z%201K3">Find Us</a>

BlackBerry

BlackBerry is definitely the odd man out in this scenario as it requires JavaScript instead of simply responding to a protocol or URL.

You could apply the following function using event handlers from a JS file but for this example we're going to apply it inline so we can see how the structure compares to the other platforms.

<a href="javascript:blackberry.launch.newMap({'address':{'address1':'894 Granville Street','city':'Vancouver','country':'Canada','stateProvince':'BC','zipPostal':'V6Z1K3'}});">Find Us</a>

 

I have only tested this on one BlackBerry and I am not sure if all models support location finding or this JavaScript. One thing I did notice in testing is that it validates the address. I had entered an incorrect postal code for one test and I got an error saying the postal code was not valid. It was in a valid format but was not an actual postal code.

URL Overview

I should mention at this point that I am trying to achieve our goal in the simplest possible manner which is through a straightforward, familiar, hyperlink. There are some more complex approaches which involve generating KML files or accessing various mapping APIs but I wanted to rely as heavily as I could on native functionality for three reasons. First, the interface will be familiar to users. Second, I have never seen a custom map solution which worked as well as the native apps. Finally why would we spend time and money developing a custom solution when a perfectly good one already exists.

Default

<a href="http://maps.google.com?q=894%20Granville%20Street%20Vancouver%20BC%20V6Z%201K3">Find Us</a>

 

iPhone

<a href="http://maps.google.com/?saddr=Current%20Location&daddr= 894%20Granville%20Street%20Vancouver%20BC%20V6Z%201K3">Find Us</a>

Android

<a href="geo:894%20Granville%20Street%20Vancouver%20BC%20V6Z%201K3">Find Us</a>

WP7

<a href="maps:894%20Granville%20Street%20Vancouver%20BC%20V6Z%201K3">Find Us</a>

 

BlackBerry

<a href="javascript:blackberry.launch.newMap({'address':{'address1':'894 Granville Street','city':'Vancouver','country':'Canada','stateProvince':'BC','zipPostal':'V6Z1K3'}});">Find Us</a>

 

Making it work

I won't be going into detail in this post about how to implement this on your site but I will give a basic outline of one approach using JavaScript to rewrite the URLs.

  1. Setup your links using the default URL scheme pointing to Google Maps.
  2. Use JavaScript to determine if the user is on one of our targeted platforms by analyzing the user-agent string.
  3. If a target platform is being used to extract the address data from the existing URL and construct a new URL, use the models described above.
  4. If the user is not on a targeted platform leave the URL as is.

Conclusions

Hopefully, one day all browsers whether mobile or desktop will conform to a single URL structure or protocol for opening map sites and applications, plotting routes, performing searches etc. Until that day, and I wouldn't hold my breath, we'll have to target individual platforms if we want to make address information more useful by linking it with map applications and websites. What would be even better than a protocol or URL structure is if browsers allowed you to define a default map service and then parsed the page source for microdata as described on microformat.org or schema.org. Semantics and functionality!

As my next contribution to this blog I plan to build a jQuery plugin to handle these rewrites automatically, so stay tuned. Also, this article is by no means exhaustive so please feel free to post your ideas or comments and we'll see if we can't make this the definitive guide to opening native map apps from the browser!

References

Share