Celebrating Interesting Flickr Technologies

I’m not a big fan of nostalgia. I view with great suspicion the idea of the supremacy of the past, but it’s hard to look at the web today and think it’s better than what we had once thought was possible.

I recently read a piece praising Flickr’s approach to URL design (discussed on Hacker News). It made me think about some of the technical choices and ideas we saw come out of Flickr that we should celebrate.

There was a period on the web, before the walled gardens rose up, where the focus was more towards the interoperability of content. Flickr at its prime was a powerhouse of innovative and experimental features that put this ideal at the forefront. The things they released were genuinely fun and exciting to use as a developer interested in connecting different corners of the web.

Their API

Flickr’s API was one of the first publicly available APIs that took hold of the imagination of users. They had to explain the concept to us from first principles because we didn’t have the intervening decades of experience using them to understand what the point was.

Yet, decades later, it’s still one of the most enjoyable and (importantly) easy APIs to use. The sandbox example site allows you to test every query or call easily. You can call it from a server or from a client with a JSONP request. It’s full of endpoints that do exactly what you’d expect a photo site to offer even if their method names don’t perfectly line up with modern RESTful APIs. Plus it has a swathe of interesting and unusual functionality that can surprise and delight if you take the time to explore it fully.

Did you know, for example, that it’s possible to send the flickr.places.find a street address and the API will try to resolve that address and provide you the relevant place related information for it. A place in Flickr is one of the following types: neighbourhood, locality, county, region, country or continent. You can use that information to make a call to their flickr.places.getShapeHistory method which will return not just the list of latitude and longitude values to make a detailed polygon of that place. It will also return a value containing the URL for downloadable shapefiles which can be loaded into other GIS software to get incredibly detailed boundaries.

If you’ve ever tried to do anything place related on the web you might recognise what an amazing and useful feature this could be. Users don't think in latitude and longitude; they think in more abstract places. Having a service that thought about that and helped provide a consistent idea of what a place is was a massive help in providing a consistent experience to people wherever they were in the world.

Where on Earth ID (WOEID)

Because photo metadata often included latitude and longitude, Flickr obviously thought a lot about location awareness and identity of place. It's one thing to want to see photos from my recent trip to Sydney, but if I want to view the photos I took near Bradley's Head instead of those photos I took near Bennelong Point that's a more complicated ask. Further, if I want to see my Bradley's Head photos because that's where Taronga Zoo is, and I want to see my Bennelong Point photos because that's where the Opera House is, it becomes even more complicated. As a user I'm not going to want to use specific latitude and longitude coordinates to be able to dig ever deeper into my photo collections.

Flickr’s solution for this problem was to implement something called the Where On Earth ID (WOEID) which tried to attribute unique identifiers to specific features on Earth. This gave a way to disambiguate queries exactly in the way described above by allowing specific WOEIDs to disambiguate between the Opera House, Bennelong Point, Circular Quay, Sydney Harbour and the City of Sydney, all of which could conceivably share overlapping latitude and longitude coordinates.

Machine Tags

One of the biggest challenges with building things that aggregated content from different places was figuring out how to get just the content you cared about and not have the things you were pulling in be irrelevant or confusing for your viewers. One of the major features Flickr introduced to help with this was something called a machine tag. These were perfectly normal tags except they took the form of namespace:predicate=value.

These tags allowed people on Flickr, and even developers on other sites, to get exactly the content they wanted depending on increasingly granular machine tag queries. Machine tags are somewhat confusing to wrap your head around if you haven’t encountered them before, so a few examples might illustrate their use:

• Show me all the photos related to the ABC Open Project called Faces
• Show me all the photos related to all ABC Open projects
• Show me all photos that have been tagged with the predicate place

That last one is interesting because it shows us that two different primary namespaces used place (foodspotting, a defunct restaurant app, and the Pleiades project looking to curate photos of ancient cultures and architecture)
The Pleiades project allows us to look at curated photos based on their geographical location in ancient times.
The Pleiades identifier for Lugdunum (now Lyon, France) allows us to use that unique id in the URL to query Flickr for all photos showing artefacts from that location.
Machine tags were powerful and fun on Flickr, but it was their adoption across other sites that allowed some incredible remixing and aggregation of content. It allowed photos of live bands and artists to be tagged with their MusicBrainz identifiers. It allowed event sites to pull in photos for specific events on specific dates. Communities given access to perfectly normal tagging systems have done some extraordinary things. It's a shame we never got to see machine tags reach the same level of adoption and commitment.

It’s a massive testament to Flickr’s remarkable longevity that all of the examples above still work even as the groups, projects, individuals and applications that generated them initially have long since vanished.

I’m not across enough details to speculate on the eventual downfall and failure of Flickr, but as a developer I enjoyed the things it did well, the experiments it tried, and the openness it encouraged. They advocated for a vision of the web as an open and remixable aggregation of personal interests that resonated with me then and continues to resonate with me now. That it wasn’t the vision that won the war of attention is a great shame.