Posts Tagged ‘API’

DigitalNZ location search

Thursday, June 18th, 2009

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.


How libraries can learn from Twitter

Friday, May 29th, 2009

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?

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. 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

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.

State Library of New South Wales Flickr mashup

Wednesday, October 1st, 2008

The State Library of New South Wales have joined Flickr commons, which means that with one small change to my code, I can reproduce my “then and now” mashup for their collection.  There isn’t a great deal of photos that have been geo-tagged as yet, but that’s the beauty of this – anyone can go in and add tags and it will evolve into something useful over time.  Check it out.

State Library of New South Wales then and now mashup

Powerhouse street view mashup

Tuesday, August 19th, 2008

Recently I’ve been thinking of more and more ways that museums and libraries can expose their collections via other methods besides typing a search term into a search box – yawn…

Like most Australians I’ve been playing around with the street view data Google have added in for Australia cities and it got me thinking, how could this be used by museums and libraries.  An obvious candidate is photographs as many photographs are of street views. Earlier this year the Powerhouse Museum in Sydney joined the Flickr Commons with their Tyrrell collection.  In a report on their first 3 months at Flickr, Seb Chan noted that over 50% of the photos were geocoded.  This provided the perfect scenario for an experiment as every Flickr account has a geoRSS feed.  Could this RSS feed be incorporated with a Google maps street view to provide historical photos and contemporary street images side by side?

After about 30 minutes of coding I had a nice proof of concept demonstration page happening.  The interface is a little clunky, but it works.  This could be improved by using the Flickr API rather than the RSS feed to generate the images. There are some issues which you can’t resolve, like the rotation of the street view compared to the photo, but this isn’t really a show stopper.

I would love to know your thoughts?  Am I on to something here?