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.

This morning an interesting Tweet arrived on a subject that I’ve been thinking about quite a lot lately:

there seem to be more people using twitter apps than twitter web. What is twitter doing wrong?
@katykat

In April 2008, ReadWriteWeb carried out a study How We Tweet: The Definitive List of the Top Twitter Clients that showed that only 56% of Twitter users used the web interface. My gut feeling tells me that that figure is lower now, given the growth of use of devices like the iPhone. 

This is a perfectly valid question to be asking in the context of a traditional website. But Twitter isn’t a website, it’s more than that, it’s a service like email. You are not restricted to interacting with your email via one particular method. Likewise, by building upon Twitter using their API’s you are not restricted to using their service in the one and only way that you can, you have choice in how you interact with their service. The important thing isn’t the website, it is the service. Twitter.com could basically become a one page website and as long as the API’s were maintained the service would continue as normal for much of the twitter community. The user has a variety of choices in interacting with the service based upon their personal preferences. They can choose the relevant application based upon interface they like and the features they are going to use.

Flickr, despite having a far greater number of API’s available, hasn’t followed the same path as Twitter. Most people still interact with Flickr via the standard web interface. This is mostly due to their terms of use which forbids people replicating the user experience of Flickr:

Use Flickr APIs for any application that replicates or attempts to replace the essential user experience of Flickr.com

Rev Dan Catt who up until recently worked at Flickr said:

I’ve often joked that I could probably get more stuff done working with the Flickr API outside of Flickr than inside.

 So to answer the question, I really don’t think Twitter is doing anything wrong, they are doing everything right.

What can Libraries learn from what Twitter and to a lesser degree Flickr, are doing? Can we start to think about our catalogue (or other core services) not as a website, but as a service. The website version of the catalogue may just be one aspect of the delivery mechanism for the information we wish to distribute. Why can’t we look at providing our services to our users in any way they wish to be able to interact with them?

Why can’t we provide specialised access to our catalogues to specific user groups, so they (or anyone) can create:

• a simplified interface for high school users without all the complex features they don’t use
• allow an historical society to create an application based upon their needs
• an complex view of the catalogue for academics or librarians
• a visual or geographic based search
• a social network based around the catalogue

Institutions like the Brooklyn Museum and collaborative efforts such as DigitalNZ are providing their content to developers to do exactly this sort of thing. It’s very early days still and it will be interesting to see what starts to develop.

Let’s start thinking about interacting with the service, not the website.