Paul Hagon

On the 24th of July I gave a presentation to the Canberra Web Standards Group on Building location aware websites. Here are the slides and notes from my presentation.

Slides 1-2
Welcome I’m Paul Hagon a web developer at the National Library of Australia. This is my twitter handle if you are twittering about my presentation while  I talk

Slide 3

Slides 4-5
Traditionally websites have required the user to make a choice about their location. This is stored in a cookie or within the user login.

Slides 6-9
There are applications where I don’t want to make the choice. I am travelling and in a different location and I want the information that is relevant to my current environment. A perfect example of this is the weather. I’m primarily interested in the weather and forecast for where I am.

Slide 10
The W3C geolocation group released their first working draft in late 2008. Their final recommendation is due to be released at the end of 2009. Their goal is to:

define a secure and privacy-sensitive interface for using client-side location information in location-aware Web applications

Slide 11
Location detection takes a variety of forms. The first form is an IP address lookup. If you are lucky this might give you the users location to the nearest town or state. It is generally fairly inaccurate. The next option is to determine the location of your wi-fi network router. If the user is on a cellular network, their location can be triangulated by  using the tower ID’s. These methods can be very accurate (to within a couple of hundred metres). The final method is to use a dedicated GPS chip and obtain a satellite fix. This is accurate to within a few metres.

Slide 12-13
Mobile phones started to have built in GPS chips, but it was really the iPhone that opened up the possibilities in this area. The problem was, the location sensors could only be accessed through dedicated iPhone applications written in Objective C. We are web developers and like angle brackets rather than square brackets. It’s a bit of a leap to go to a ‘proper’ programming language

Slide 14-15
Recently 2 developments took place. Firstly Firefox 3.5 was released. In amongst the newer JavaScript engine and native HTML5 audio and vide support, it also featured native geolocation functions. The iPhone operating system was also upgraded to OS 3.0 and with it, access to the iPhone location sensors was made available to mobile Safari.  Both of these implemementations followed the draft W3C guidelines. Native geolocation is also available within development builds of Opera and Fennec (mobile Firefox).

Slide 16
So where does this leave Internet Explorer (and the desktop version of Safari)? Users of these browsers can download Google Gears. This is typically used to offline access to things like gmail, Google docs etc. It also makes available some geolocation functions, although they are slightly different to the W3C recommendations.

Slide 17
A user can also use a service such as Fire Eagle to update their location, and this web service has an API that allows the data to be shared between sites (for example automatically updating your twitter location).

Slide 18-20
Privacy is a major concern. A user has to opt in to sharing their location with a web site. These services store IP addresses, the access point information and a unique identifier (for a period of 2 weeks). No identifiable information is passed to or stored by these services. You probably have in place something in your privacy policies to cover storing log files. We tend to know a fair bit of general location information about our users anyway from things like Google Analytics reports.

Slide 21
Users start broadcasting their location through services like Google Latitude or brightkite. This raises many more privacy issues, and they have options to allow a user to decide just how much information they wish to share.

Slide 22-30
The code to make it happen. Create a function that we can call from an event like a page load or event click. Make a location call. If the call is successful, extract the latitude and longitude. If it is unsuccessful (may not be able to get a signal or the service may not be able to resolver your location) do something else.

Slide 31
Reverse geogoding is the process of turing a latitude and longitude into a human readable form.

Slide 32-37
An example of a location aware application. It’s a mashup searching for photos in a particular location. Firstly in Safari (a non native geolocation aware browser) the user has to pick the location. In Firefox 3.5 (a native geolocation aware browser) the user can ask to be taken directly to their location. The browser asks for their permission before making the call. The location is accurate to a few hundred metres. Now some of the results aren’t totally accurate. It is searching via a name as there is very little location data in the records.

Slide 38
There are 3 instances of Parkes on the page – Parkes ACT, Parkes NSW and a name, Henry Parkes. It can’t differentiate between them

Slide 39
There is a service called Yahoo Placemaker where you can pass in data and it will return the geographic information for that data.

Slide 40
Passing in Parkes Australia we get the relevant geographic information for both locations of Parkes

Slide 41-43
Placemaker also accepts a URL as input. Lets pass some information from Open Australia into it. Open Australia is an application that allows users to see what their members of parliament have been doing. We could add location aware services to this to instantly be able to select the senator for the area we are currently in, or to find all the references to the area you are in, to see what decisions have been made that may have an effect on you.

Slide 44
Placemaker extracts the location names from the text of the page and returns any associated location data

Slides 45-48
Is this usable or is it still too cutting edge? iPhone usage is small (in the overall website usage), but users update quickly and have the capability to use location aware services. Firfox usage is also small, but as it has just been released it will take a little time to build up a user base. Firefox users tend to update rapidly. Users whose browsers have the capability to use location based services if they install Google Gears is more than 95% of our visitors.

Slides 49-50
I expect to see many more location based websites in the future. This presentation is available on slideshare & the references I’ve used are up on delicious. Thank you.

It’s that time of year again & I’m staying up late to watch the coverage of the Tour de France. I’m following a couple of the riders on Twitter, but I found their tweets were getting buried in amongst the rest of the noise. So, I built Tweet de France, a little application that merges the Twitter feeds from a number of riders in the tour into one feed.

Now I could use Tweetdeck and set up a group & achieve the same thing, but Tweetdeck just doesn’t do it for me and I like to experiment.

Today the Mozilla group released Firefox 3.5. This release has many new features, but one that really interests me is the inbuilt geolocation service. This release also comes hot on the heels of the iPhone OS3.0 software upgrade that also brings inbuilt geolocation to the mobile safari browser. Why is this exciting? They are both based upon the W3C geolocation specifications. I’ve previously written about geolocating using various browser plugins. This is a messy way of doing it and required a lot of code forking to cover the different possibilities. Now we have a standard way of doing this type of thing.

How do we do it?

Let’s start by creating a call to the browsers in built location service. We need to firstly check that the browser supports location services. If it does, then make a call to try and get our location. If we get a successful location we can display the latitude and longitude. We may also get an error. This may occur if the user decides not to share their location or there is an error in the system.

<script type="text/javascript">
// Check in the browser supports native geolocation and make a call to the geolocation service
function findLocation() {
  if(navigator.geolocation) {
    navigator.geolocation.getCurrentPosition(successCallback,errorCallback);
  } else {
    var displayLocation = document.getElementById("location");
    displayLocation.innerHTML = "Your browser doesn't support geolocation services";
  }
}

// Extract the latitude and longitude from the response
function successCallback(position) {
  var latitude = position.coords.latitude;
  var longitude = position.coords.longitude;
  var displayLocation = document.getElementById("location");
  displayLocation.innerHTML = "latitude: " + latitude + ", longitude:" + longitude;
}

// There was an error
function errorCallback() {
  var displayLocation = document.getElementById("location");
  displayLocation.innerHTML = "Sorry, we couldn't find your location";
}
</script>

We are now able to display our current latitude and longitude – see example 1.

Displaying a map

Now that we have a latitude and longitude it’s much easier to visualise our location if we plot it onto a map.We will keep the same basic code and add some Google Maps script to it.

<script type="text/javascript" src="http://www.google.com/jsapi?key=YOUR_GOOGLE_KEY"></script>
<script type="text/javascript">

// Because we are using a geolocation service we need to make sure sensor=true
google.load("maps", "2", {"other_params":"sensor=true"});

// Check in the browser supports native geolocation and make a call to the geolocation service
function findLocation() {
  if(navigator.geolocation) {
    navigator.geolocation.getCurrentPosition(successCallback,errorCallback);
  } else {
    document.getElementById("location").innerHTML = "Your browser doesn't support geolocation services";
  }
}

// Extract the latitude and longitude from the response and display a map
function successCallback(position) {
  var latitude = position.coords.latitude;
  var longitude = position.coords.longitude;
  document.getElementById("location").innerHTML = "latitude: " + latitude + ", longitude:" + longitude;

 // Display the map
  var map = new GMap2(document.getElementById('map'));

  // Centre the map around the latitude and longitude
  var latlng = new google.maps.LatLng(latitude, longitude);
  var zoom=16;
  map.setCenter(latlng, zoom);

  // display the default controls
  map.setUIToDefault();

  // Add a marker
  var point = new GLatLng(latitude, longitude);
  map.addOverlay(new GMarker(point));
}

// There was an error
function errorCallback() {
  document.getElementById("location").innerHTML = "Sorry, we couldn't find your location";
}
</script>

Now it is much easier to determine our location by turning the numbers into something visual and meanignful. Try it out in example 2.

These code samples will work for both Firefox 3.5:

And mobile Safari on iPhones and iPod touches running OS3.0

Now you have the basics of obtaining a latitude and longitude, you can start to use these techniques in your own applications to display locations or items that are relevant to the user in that location.

Over the past couple of months I’ve been building a little application using the API’s from the DigitalNZ project. DigitalNZ is a collaboration between government departments, publicly funded organisations, the private sector, and community groups to expose and share their combined digital content. Part of their plan to expose their data is to provide a publically available API for developers to expose their content in ways they may not have thought about.

Typically, a large dataset has a search box as it’s main interface. I wanted to get right away from that approach and create an engaging interface. This uses a map interface to allow the user to freely explore the content.

It currently uses a combination of API’s from Google and Flickr to convert a latitude and longitude from the map to obtain a place name. It then displays a shapefile from Flickr to approximate the area being searched, and returns a list of relevant results from DigitalNZ. Since I started work on this, the data returned from both of these API’s have been released under a Creative Commons license (Yahoo have released their geoplanet data and Flickr have release their shapefile data). I’ll end up incorporating these releases into the application rather than relying on the API’s for the functionality.

Explore the contents of DigitalNZ.

A little while ago, work upgraded our voicemail system. This new system is a nightmare to use.

When you are designing a system you need to give a priority level to all the tasks that are available and create a heirarchy. Not all tasks are equal. For a voicemail system the key task that is being carried out 99% of the time is checking a message that has been received. Other tasks like creating a message (although initially is important, is hardly ever used again) do not have a priority level the same as other interactions.

Have a listen to what is required to receive a message (MP3 file).

It takes nearly 50 seconds before I can receive a message and it buries that option way down in the menu structure. It is also set up that I have to use a different key combination to get to the menu choice I want (for instance, I can’t keep pressing 1 to get to the key function).

Give key tasks higher priority in the navigational layout and make them simple to get to.