5 Questions for Simon Willison

Posted on February 10, 2010 by Kay Kremerskothen

Simon Willison kindly took time out of his llama-spotting, Python wrangling (Django co-creating), MP expenses crowdsourcing day, to answer a few questions about he and his co-conspirator Natalie Downe‘s latest journalistic foray.

1. What are you currently building that integrates with Flickr, or a past favorite that you think is cool, neat, popular and worth telling folks about? Or both.

Simon: Our main project at the moment is WildlifeNearYou.com. It started life as a holiday hacking project with twelve geeks, on a Napoleonic Sea Fort, in the channel islands, half way between England and France, with no internet connection (see devfort.com for background info). Natalie and I continued to work on it after we returned to civilisation and we finally put it live last month. 170 people have imported more than 6,500 photos from Flickr in just the past few weeks, so people seem to like it!

The site’s principle purpose is to help people see wildlife – both in the wild and in places like nature reserves or zoos. We ask people to report wildlife they have seen by adding trips, sightings and photos – they get to build up their own profile showing everything they’ve spotted, and we get to build a search engine over the top that can answer queries like llamas near brighton or otters near san francisco.

In addition to that core functionality, we have a couple of fun extra features based around people’s photos. Our users can import their pictures from Flickr, and use WildlifeNearYou’s species database (actually sourced from Freebase.com) to tag those photos. We then push the tags back to their Flickr account in the form of text tags and machine tags – if they tell us the location (e.g. London Zoo) we’ll geotag their photo on Flickr as well.

If they don’t know what the animal in the photograph is, other users of the site can suggest a species. If the owner of the photograph agrees with the suggestion the species will be added to their list of sightings and the correct tags applied (and pushed through to Flickr).

Finally, we have a really fun crowdsourcing system for identifying and rewarding the best photos. If you go to http://www.wildlifenearyou.com/best/ we’ll show you two photos of the same species and ask you to pick the best one. Once we’ve collected a few opinions, we award gold, silver and bronze medals to the top three photographs for each species. The best photo is then used as the thumbnail for that species all over our site. Here are our best giraffe photos, as voted by the community:

http://www.wildlifenearyou.com/animals/giraffe/photos/best/

2. What are the best tricks or tips you’ve learned working with the > Flickr API?

Simon: It really is amazing how much benefit we got out of pushing machine tags over to Flickr. One feature we got for free was slideshows – once you have a machine tag, it’s easy to compose a URL which will present all of the photos tagged with that machine tag as a slideshow on Flickr. Here’s one for all of our photos of London Zoo:

http://www.flickr.com/photos/tags/wlny:place%3Dp1/show/

Even better, our site can now be queried using the Flickr API! Here’s a fun example: finding all of the Red Pandas that have been spotted in Europe. WildlifeNearYou doesn’t yet have a concept of Europe, but Flickr’s API can search using Yahoo! WhereOnEarth IDs. We can find the WOEID for Europe using the GeoPlanet API:

http://where.yahooapis.com/v1/places.q(‘europe’)?appid=[yourappidhere]

The WOEID for Europe is 24865675. Next we need the WildlifeNearYou identifier for red pandas, so we can figure out the correct machine tag to search for. We re-use the codes from our custom URL shortener for our machine tags, so we can find that ID by looking for the “Short URL” link on http://www.wildlifenearyou.com/animals/red-panda/ (at the bottom of the right hand column). The short URL is http://wlny.eu/s2f which means the machine tag we need is wlny:species=s2f

Armed with the WOEID and the machine tag, we can compose a Flickr search API call:

http://api.flickr.com/services/rest/?method=flickr.photos.search&machine_tags=wlny:species=s2f&woe_id=24865675&api_key=…

That gives us back a list of photos of Red Pandas taken in places that are within Europe. Add &extras=geo,url_s,tags to get back the tags, latitude/longitude and photo URL at the same time. The wlny: machine tags that come back can be used to link back to the place, species and trip pages – for example, wlny:place=p6p means the photo was taken at the place linked to by http://wlny.eu/p6p

This is pretty powerful stuff, and it’s all a natural consequence of writing machine tags back to Flickr.

(editors note: or even a slideshow of European red pandas)

3. As a Flickr developer what would you like to see Flickr do more of and why?

Simon: One thing that would make my life an enormous amount easier would be a Flickr-hosted photo picking application. For WildlifeNearYou I had to build a full interface for selecting photos from scratch, with options to search your photos, browse your sets, browse photos by place and so forth. The Flick API makes this pretty easy to do from a back end code perspective, but designing and implementing a pleasant front end is a pretty major job.

I’ve wanted to implement simple photo picking from Flickr on various other projects, but have been put off by the effort involved. WildlifeNearYou is the first time I’ve actually taken the challenge on properly.

What I’d love to see instead is an OAuth-style flow for selecting photos. I’d like to (for example) redirect my users to somewhere like http://www.flickr.com/pickr/?return_to=http://www.wildlifenearyou.com/selected/ and have Flickr present them with a full UI for searching and selecting from their photos. Once they had selected some photos, Flickr could redirect them back to http://www.wildlifenearyou.com/selected/?photo_ids=4303651932,4282571384,4282571396 and my application would know which photos they had selected.

This would make integrating “pick a photo / some photos from Flickr” in to any application much, much easier.

On a less exotic note, we have to do quite a few bulk operations against Flickr and having a bulk version of the flickr.photos.getInfo call would make this a lot faster – just the ability to pass up to 10 photo IDs at a time would reduce the number of HTTP calls we have to make by a huge amount.

4. What excites you about Flick and hacking? What do you think you’ll > build next or would like someone else to build so you don’t have to?

Simon: We’re going to be working on WildlifeNearYou for quite a while – I certainly don’t expect to get tired of looking at people’s photos of wildlife for a long time. We have a bunch of improvements planned for the “best photo” feature – we want to start showing your medals on your profile, and maybe have a league table for the best photographers based on who has won the most “best picture of X” awards. Once we’ve improved our species and location data we should be able to break that down in to best photographer for a certain area, or even for a category of animal (best owl photographer is sure to be hotly contested).

We also want to streamline our “add trip” flow based on Flickr metadata. If you import a bunch of geotagged photos, we can guess that they were probably taken on a trip to London Zoo an the 5th of February based on the location and date information from the pictures.

As for other projects… I’d love it if someone else would build the general purpose photo picker idea above – it doesn’t necessarily have to be Flickr, anyone could provide it as a service.

5. Besides your own, what Flickr projects and hacks do you use on a regular basis? Who should we interview next?

Simon: Matthew Somerville’s work is always interesting, and his current project, Theatricalia, is a single-handed attempt to create an IMDB for theatre productions. Naturally, he’s pulling in photos from Flickr based on his own machine tags.

5 questions for Matt Biddulph

Posted on July 27, 2009 by Kay Kremerskothen

Matt Biddulph takes lovely photos. And apparently when he isn’t taking photos he find times to be the founder and CTO of Dopplr. Which makes us happy, because we’re big Dopplr fans. If Flickr is the site where photos become social objects, Dopplr is that site for travel. Except with personal informatics, and positionally dependent rainbows. (we have a well documented weakness for rainbows)

Dopplr is consistently one of the most interesting projects tying together the loosely joined datastreams into a cohesive whole, and Matt’s meditations on how to do that are not to be missed.

1. What are you currently building that integrates with Flickr, or a past favorite that you think is cool, neat, popular and worth telling folks about? Or both.

Matt: I’m the CTO at Dopplr, and we use Flickr all over our site to integrate our users’ travel pictures and illustrate places in our “Social Atlas”. We’re particularly happy with Flickr’s recent integration of Dopplr places into their automatic machine tag handling

This year we’ve been radically upgrading our city information pages (e.g. http://dplr.it/san-francisco) and Flickr photos have been an important part of that. Designer Matt Jones came up with a combination of rich information visualisation and beautiful images, combining sparklines with photos of cities that we source from Flickr’s geotagged Creative-Commons licensed contributions.

The Flickr API is key to how these pages are made. Although ‘interestingness’ is a powerful sorting metric, we found that just asking for the most interesting picture of a city didn’t always give us the right aesthetic (just as Dan Catt’s pandas occasionally show a preference for bikinis). Instead, our developer Tom Insam built a workflow tool that shows site admins a list of the top pictures per place. It displays a preview of a sample data visualisation overlay, and limits the pictures to those licensed for derivative commercial works.

An admin can quickly work through our most popular cities, choosing pictures and a few design settings (such as whether to use black or white text for best contrast). Once a month, a script runs through our chosen images, regenerating this month’s data viz and removing any photos whose license has changed since our last check. This happens more often than we expected.

2. What are the best tricks or tips you’ve learned working with the Flickr API?

Matt: To make our city page Flickr integration possible, we had to correlate our city database with Flickr’s geotagging data. Our data is sourced from GeoNames and augmented by us and our users. Luckily Flickr provides a handy reverse-geocoder that maps a latitude/longitude point to an identifier. As a bonus, Flickr now uses the same “WOE IDs” as Yahoo’s Geo APIs, meaning that this correlation between our IDs and theirs can be used to lookup other rich geo data elsewhere on our site. We also started supporting WOE IDs in our own API in return, and we were very happy when Flickr started linking to our city pages from their own place pages.

Another tip for integrating Flickr API calls into web pages is to consider whether you can achieve a feature with purely client-side code. Rather than have our webserver tied up waiting for an HTTP request to return from Flickr, in certain places we serve up jQuery code to perform Flickr queries from the clientside, inserting the results into the page via ajax.

3. As a Flickr developer what would you like to see Flickr do more of and why?

Matt: I’m in complete agreement with Kellan — that realtime APIs are going to be big. For example, I want the ability to register an interest in something (“the latest CC-licensed photos of London”) and get the data pushed to me whenever new results are ready. This might be implemented using Web Hooks, like when github makes an HTTP POST for you whenever you push into a repository. It might be over XMPP, as used by Fire Eagle, when services register for publish-subscribe notifications of new location pings. The choice of technology is less important than the new possibilities (and design challenges) of the realtime web.

4. What excites you about Flickr and hacking? What do you think you’ll build next or would like someone else to build so you don’t have to?

Matt: The best thing about Flickr for hacking is the sheer amount of data that the community collects. The recent release of shapefiles derived from tags and geotagging is very exciting and has huge possibilities for geo mashups. I’m looking forward to firing up a Maps From Scratch instance and figuring out how to combine it with data from our service. There are some screenshots of my early experiments using Flickr’s clustr tool on our Social Atlas data at http://www.flickr.com/photos/mbiddulph/tags/clustr/

5. Besides your own, what Flickr projects and hacks do you use on a regular basis? Who should we interview next?

Matt: I nominate Dave Beckett, author of the C library and commandline tool Flickcurl because I use the commandline tool as a quick interface to Flickr data all the time. As a devotee of dynamic languages, I’m interested to hear about what it’s like to program the web in C.

5 Questions for David Wilkinson

Posted on February 13, 2009 by Kay Kremerskothen

On the last 5 Questions I posted, I ended with “Thank you, Gustavo. Next up (unless Kellan gets in first!) dopiaza.” Well Kellan did indeed get in first, with both Jonnie Hallman and Fraser Speirs. So now, without any more procrastination, I present David Wilkinson, “Utata’s architect” as described by Gustavo …

1. What are you currently building that integrates with Flickr, or a past favorite that you think is cool, neat, popular and worth telling folks about? Or both.

David: I guess one of the most visible things that I’ve built so far is the Utata web site (http://www.utata.org/) and the tools that surround that. Utata, the Flickr group, is a pretty lively community, with over 16,000 members and a pool of over 270,000 photos. In Utata, we like to encourage people to participate, and our web site expands on the group pool and discussion threads on Flickr with a variety of projects for members to participate in, blogs that feature photos picked from the pool, and a wide variety of articles, notices and links. The key thing we’ve tried to do in Utata is to ensure that participation is simple and straightforward. Anyone can come along and join in – the only requirement is that you have a Flickr account.

Some of the most popular parts of Utata are undoubtedly the group projects – there are typically about three or four group projects in progress at any time, each with their own theme. To take part in a project, all members need to do is tag their photo with the specified project tag and it will then automatically get included in the project pages on the Utata web site. We do all of the hard work of keeping track of which photos are in which project, and presenting the project pages to the world. It is participation made easy – “tag and run”.

To make all that happen, there’s a whole pile of stuff in place behind the scenes. We have a sizeable set of PHP classes, a bunch of perl scripts and a MySQL database, that between them keep track of who all the Utata members are and which photos have been added to which project. The end result of all of this is a pretty smooth and largely automated system. A bunch of cron scripts keep the project database up to date and we have a private administration site that allows Utata administrators to quickly and easily perform a wide variety of tasks: they can set up and publish new projects, create polls, update member details, post new blog entries and so on. We also have HAL, the UtataBot, who keeps a watchful eye on the group pool, making sure that members abide by the rules and that we don’t just become a general dumping ground [RevDanCatt: here’s another pool cleaning bot, hipbot]. There are also the Utata badges that show off the latest contributions to the group pool. Actually, it’s only now, as I sit and write this list, that I realise just how much code there is sitting there on the Utata servers.

Project

One of the key parts of the system is the list of projects and their entries. Utata is a popular site, and it’s clearly not feasible to go back to Flickr to search for project entries each time a page is viewed, so a good deal of the code that runs Utata is devoted to maintaining our local copy of that data – keeping the cached data up to date and retrieving less commonly used elements from Flickr on demand as various pages are viewed. Given the number of projects held on Utata, and the size of the membership, it’s important to make efficient use of the cache, and I’ve tried a number of different strategies to minimise the number of API calls required. The biggest thorn in my side here is the limitation in flickr.photos.search that you can only ever get back the first 4000 photos for a tag-based search. I have some work-arounds to get around that, but if that limitation was ever increased I could make the whole thing far more efficient.

An interesting, but little known fact about Utata, is that it has its own API, which if you were to take a close look at, might well look rather familiar – it uses the Flickr API as its role model. There are only has a limited number of methods right now, but the framework allows more to be added quite easily. The idea behind the API is to enable other interesting applications to be written. There are only a few of these external applications in existence at the moment – there’s a stand-alone project browser, which I don’t think anyone other than me uses. A more interesting one is the Utatascreensaver, which cycles through photos from the Utata project of your choice.

As well as Utata, I dabble with a variety of other projects. The main thing I’m working on right now is a revamp of my Set Manager (http://www.dopiaza.org/flickr/setmgr/). One of the first comments I ever posted to Flickr Ideas was a request for Smart Sets – sets that could dynamically update themselves. You can think of them as the photographic equivalent of SmartPlaylists in iTunes. At the time, I was just starting to experiment with the Flickr API, so I decided to try my hand at building an application to create sets automatically. It’s not especially complicated, it’s really just a simple wrapper around flickr.photos.search, but it has certainly struck a chord with people, with currently over 25,000 authenticated users. It hasn’t changed very much since it was first written, so I figured it was time to give it something of an overhaul.

I’ve recently been playing around with Adobe’s Flex framework and decided that revamping the set manager would give me a good excuse to get to learn more about Flex and understand how it all hangs together – and so Version 2 of the set manager is now well under way. This new version allows you to not only build sets based on tags, interestingness, date and so on, it also allows you build sets based around location – the places API provides a very easy way to get access to all of the photos in a given location. For a more visual approach to set building, I’ve also hooked in Google Maps (sorry, Yahoo!) using their rather nifty Flash component to allow areas of interest to be easily chosen. This new Set Manager also piggy-backs on some of the work I did on Utata – it now exposes an API, built using the same framework as the Utata API, to allow the Flex application to communicate with the server.

Most of the Set Manager revamp has now been completed, and few Flickr stalwarts have been helping test it all out. The plan is to get this new version up and running by the end of the year – all I need is a little more spare time to finish things off…

2. What are the best tricks or tips you’ve learned working with the Flickr API?

David: Gustavo sneaked in ahead of me here and got in first with some of the best answers, but the main one is worth repeating – cache your data. Every API call you make can add several seconds on to the run time of your application or the load time of your web page, so you should really think carefully about whether each API call is necessary. If you think you’re going to need that data again in the near future, store it away somewhere – in a database, in the user’s session, anywhere. A good caching strategy can make the difference between a snappy responsive web site and a painfully slow, treacle-laden disaster.

One thing that seems to catch out a lot of people is the 4000 item limit to searches, which seems to be poorly documented (i.e., not at all). If you’re not aware of this limitation, it can suddenly rear it’s ugly head when you’re least expecting it – and usually when it’s least convenient. I remember the first time a Utata tag exceeded 4000 photos (the utatafeature tag currently returns over 16000 photos) and that certainly caused a few headaches. The only solution to this problem seems to be to construct your searches so that they’re sure to return less than 4000 matches. For the Utata tag searches, I ended up breaking the search down into a set of searches using smaller date ranges and aggregated the results. It’s not perfect, but it seems to be holding up.

And if you build an application or tool and release it out into the world, be prepared for an endless stream of emails from people who want it to do something just a little bit different from what it does right now…

3. As a Flickr developer what would you like to see Flickr do more of and why?

David: Well, more Kitten Tuesdays are clearly an obvious priority. Apart from that? Well, here goes:

One of the biggest things I would like to see is a better way for Flickr members to allow API access to their photos. At the moment, users can either opt in or opt out of third-party API searches – it’s an all or nothing thing. There are good reasons for wanting to opt out of searches. It is all too easy, for example, to get an API key and create a rogue application: one that might display photos in an unwelcome context – on a commercial web site, perhaps. Of course, applications that violateFlickr’s terms of service tend to get shut down pretty quickly, but someone has to spot them and bring them to Flickr’s attention before that can happen. Threads regularly appear in the help forum about this, and many people choose to opt-out of public API searches to avoid having their photos show up in places they don’t expect. The problem with opting out is that members can then no longer make use of some of the applications and services that they would actually like to have access to their photos. Utata is a good example – we have many members who would like to take part in the projects but can’t because they are not willing to opt back in to API searches on a global basis.

I would like to see the current opt-out system expanded to allow members who opt out to then opt back in to API searches for selected applications – an API application white list, if you like. That would allow people to explicitly choose which applications were trusted and so grant them access.

There are a few changes to existing API methods that I’d really like to see:

– That 4000 photo limit I keep mentioning – it would be really nice if that could be lifted, even if only for certain search types, such as time-ordered.

– flickr.photos.getInfo returns a whole host of useful information about a photo, but if I want to display that photo somewhere, I also invariably need to know what sizes are available to me. flickr.photos.getSizes gives me that, but that’s now two API calls. I almost always end up calling these two methods as a pair – it would be really nice if flickr.photos.getInfo could optionally return the sizes as well.

– One of the most common feature requests I get for my set manager is the ability to sort by number of favourites, or by views, or by number of comments. Allowing flickr.photos.search to do this would make a lot of people very happy.

– and I know it’s been mentioned quite recently, but searching on EXIF data would be very nice…

4. What excites you about Flick and hacking? What do you think you’ll build next or would like someone else to build so you don’t have to?

David: The thing I love about Flickr is that it’s not just about the photographs. The social network – that jumbled mass of communities that live within Flickr – is really the thing that makes Flickr so compelling. Without those interactions and relationships between people, Flickr would be just another web site full of photos, but as Gustavo’s graphs featured in the last 5 Questions help demonstrate, there’s much more depth to Flickr than a simple on-line photo gallery. It is quite fun building tools to help people perform particular tasks more easily – creating sets, uploading photos, managing group subscription, and so on – but all that’s not a patch the satisfaction gained from building tools that help whole new communities develop. That’s what makes Flickr for me: the people.

What will I build next? I don’t know. There’s always something to tinker with, and you never quite know where that tinkering will lead. The whole shapes thing looks quite interesting, but I haven’t had chance to really have a proper look at that yet. That might well be next on my list to play with – who knows?

5. Besides your own, what Flickr projects and hacks do you use on a regular basis? Who should we interview next?

David: The Flickr tool I’m using the most right now is Jeffrey Friedl’s ‘Export to Flickr’ Lightroom Plug-in (http://regex.info/blog/lightroom-goodies/flickr/). It’s a super little application – it integrates seamlessly with Adobe Lightroom, and does a brilliant job of streamlining the upload process. It’s a very well thought out piece of software – definitely my favourite Flickr tool of 2008.

Who to interview next? Sam Judson (http://www.flickr.com/photos/samjudson/). Sam was technical editor on my Flickr Mashups book (did I forget to mention that I wrote a whole book on building Flickr applications? Flickr Mashups, published by Wrox. Buy one now.). Anyway, as I was saying, Sam was technical editor on my book, and did a great job there, helping point some of my most embarrassing errors before they gotcommitted to print. He knows lots about the API and has been using it for even longer than me. He’s the author of the FlickrNet API library (http://www.codeplex.com/FlickrNet) and a regular contributor to both the Flickr API group and the developer mailing list.

Dan: Thank you, David, and sorry about taking forever to post your answers :) Next up Sam Judson.

Photos by dopiaza, Malingering and Axel Bührmann.

5 Questions for Fraser Speirs

Posted on January 22, 2009 by Kay Kremerskothen

If you’ve been around Flickr for a bit then you’ve seen probably seen Fraser Speirs photos. If you’re a Mac user then you’ve almost certainly encountered his code. He built the Flickr Uploadr 2.0 for the Mac, and the hugely popular FlickrExport for direct uploading from iPhoto and Aperture. Lately his DarkSlide has brought Flickr browsing, discovery, and sharing to the iPhone.

1. What are you currently building that integrates with Flickr, or a past favorite that you think is cool, neat, popular and worth telling folks about? Or both.

Fraser:Most of the last year has been all about putting Flickr on the iPhone. I started back in March, when the first iPhone SDK was released, and cranked the code handle probably harder than I ever have before. Hours turned into days, days to weeks and weeks to months but Exposure was ready for day one of the App Store. It’s been rolling along steadily ever since, particularly with the recent 1.5 update and its cool new name – Darkslide.

The thing that I’ve most enjoyed seeing people get immense pleasure from in Darkslide is the Near Me feature. Near Me takes your iPhone’s current location and searches Flickr for photos near that point. People have found everything from great pubs nearby to, um, slightly compromising pictures of their neighbours.

2. What are the best tricks or tips you’ve learned working with the Flickr API?

Fraser:For anyone developing desktop or mobile applications against the Flickr API, you must, must, must do all your network operations asynchronously. Anything else produces a quite terrible user experience. Hint: UI animation can give you a few fractions of a second to make it feel faster to the user, and perceived speed is often more important than actual speed.

Secondly, if you’re working on a mobile device, download thumbnails in parallel (though not so much as to make the servers cry). Early versions of Darkslide downloaded 75px thumbnails one at a time, and the network latency turned out to be about as long as the time taken to download a thumbnail. The experience was painful. Newer releases request about ten at a time, and the user experience is much improved. Beware latency!

3. As a Flickr developer what would you like to see Flickr do more of and why?

Fraser: I’d like to see some queries turned around a little faster. When you’re working on mobile devices, the user’s attention span is oftentimes quite short. Between a couple of seconds in network latency and a couple of seconds turnaround time on the query, then the download time for a chunk of XML, it can sometimes get a little sluggish.

API-wise, I really would like an API for group discussion threads. A good number of users ask me about Darkslide support for group discussions on a regular basis.

Finally, a plea to keep the mathematics of maps simple for mathematical dullards like myself. I know programmers are all supposed to be maths wizards, but I truly stink at maths. I love that flickr.photos.search can do a radial search around a point, rather than requiring me to compute a bounding box. It would be great if all maps-related API let us do this kind of thing. I’m still trying to get my head around the location corrections API :-)

4. What excites you about Flick and hacking? What do you think you’ll build next or would like someone else to build so you don’t have to?

Fraser: What excites me? Well, I love photography so I love making things that make it easier for me to look at great pictures. I love that Flickr is becoming the web’s de facto repository for photography, and I love helping to make that happen.

I’m also excited to see that the Twitter/Flickr axis is starting to turn into a very powerful tool in the hands of ordinary people. I’m writing this a couple of hours after US Airways flight 1549 went down in the Hudson River. Where did I get my first news and photos of this event? Not the BBC – who had nothing up at the time – but news from Twitter and photos from Flickr.

One of the first great photos of US1549 was taken by Twitter user jkrums and posted to TwitPic. It was later reposted to Flickr after TwitPic went down under the load. Maybe next time that will be an iPhone user using Darkslide and putting the photo on Flickr first.

This is power in the hands of ordinary people and, as a citizen of the world’s biggest surveillance society (one CCTV camera for every 14 people in the UK), I think it will be increasingly essential that citizens have this kind of global reach.

5. Besides your own, what Flickr projects and hacks do you use on a regular basis? Who should we interview next?

Fraser: I’m a big Twitter user and one simple-but-not-that-obvious thing I’ve done is to pipe my Flickr activity RSS feed into Twitter using TwitterFeed.com. I also write my blog with Daniel Jalkut’s MarsEdit blog editor, which has Flickr integration in its “Media” panel – this lets you drag and drop pictures from Flickr as HTML tags right into a blog post. Great timesaver. I also use Scout to see the occasional time that one of my photos makes it to Explore :-)

Whom should you interview next? I’d like to hear from Matt Biddulph at Dopplr. I’m very interested in where Flickr photos end up, and Dopplr are making interesting use of Flickr photos in the things they do, such as producing personal travel reports with CC-licensed Flickr photos.

5 Questions for Jonnie Hallman

Posted on January 15, 2009 by Kay Kremerskothen

If you reach way back into the dusty, distant corners of your mind, you might remember 2008. Its fading but there. And back in 2008, Jonnie Hallman was tapped as our next 5 questions interviewee. And what better way to kick off 2009, then with these great answers.

Jonnie Hallman has built a cult following around his award winning desktop app, DestroyFlickr: “alternative view of Flickr”. He also recently turned his creative/destructive eye towards Twitter, with DestroyTwitter. Download them, taken for a spin, come back with your understanding altered.

On a sad note, Jonnie tapped Jonathan Harris as the next link in the interview chain, but I was totally unable to get in touch with him, so we’ll be kicking off a new chain soon.

But onward!

1. What are you currently building that integrates with Flickr, or a past favorite that you think is cool, neat, popular and worth telling folks about? Or both.

Jonnie: I’ve spent the past year or so working on an Adobe AIR app called DestroyFlickr. It takes an alternative approach to viewing Flickr content, focusing on the UI and its relationship to the photos. It actually began as a first-time experiment with both AIR and APIs in general. Prior to DestroyFlickr, I only had experience with programming websites, but quickly realized how much I prefer developing software—I like the idea of consistently improving a single project by adding new features and fixing bugs. The app uses a system of “workspaces” and “canvases” to organize the environment. Each user/contact has his/her own workspace with four canvases—“profile”, “photos”, “photo” and “contacts”. A user can switch between canvases easily and return to previous ones without reloading them.

In the beginning, I focused on features that felt obvious to me: a dark environment that’s easy on the eyes and beneficial to the photographs, the ability to flip through pages of photos in a matter of seconds, and the option to see a photo at a larger resolution without reloading it altogether. About six months into development, when DestroyFlickr started to get serious, I began implementing features that would really improve the average user’s workflow: the ability to present fullscreen, drag and drop downloading and uploading, and one-click download-all for easy backup. I originally abandoned DestroyFlickr after a few months because the only people using it were a handful of my friends who I actually had to persuade to use it. Learning of the Adobe Design Achievement Awards competition really saved it. I can’t thank them enough for all the attention DestroyFlickr has gotten since. It went from 28 users to over 6,000 in a little over a month. Now, it’s at about 7,500 and still going strong.

2. What are the best tricks or tips you’ve learned working with the Flickr API?

Jonnie: I think the most important thing to do before starting any Flickr project is to write a very simple and robust wrapper for calling methods. I use a “Method” class that has a single static function, “call”, which handles everything and returns a loader. By setting up an adaptive system, I was able to avoid hundreds of lines of redundant code. Regarding specific methods, the flickr.photos.search is certainly the APIs best kept secret. I’ve found it to be extremely useful on a number of levels and really wish the API had more methods like it.

3. As a Flickr developer what would you like to see Flickr do more of and why?

Jonnie: I’d like to see more parameters and methods for groups and contacts. I know contacts is a touchy subject since you run the risk of apps that add contacts by the thousands, but I think Flickr’s been on the ball with filtering out malicious keys. The majority of requests I get from users ask for features that can’t be written because the API is a bit limited in those parts. Overall, I find the API to be extremely generous, but there are a few essential areas that aren’t as open as others. Specifically, a parameter that’s missing is the number of times a photo has been called someone’s favorite. I’d also really like to be able to retrieve my API key stats.

4. What excites you about Flickr and hacking? What do you think you’ll build next or would like someone else to build so you don’t have to?

Jonnie:The endless possibilities excite me. Flickr provides such a cohesive and substantial API with both a testing ground and stat tracker. Regarding what’s next, I’m going to continue adding onto DestroyFlickr between work and school, so anything new will be piled on top. I have plans of adding a workspace for groups and possibly a canvas for sets, but I need to approach both with caution and make sure I have a solid plan before I start any writing. I thought about making a separate uploader or backup app, but I think I’d rather make DestroyFlickr an all-in-one.

5. Besides your own, what Flickr projects and hacks do you use on a regular basis? Who should we interview next?

Jonnie:Prior to DestroyFlickr, I tried out just about every Flickr app listed on the site just to see what’s possible. What caught my eye, though dormant for about two years now, is Jonathan Harris’ Time Capsule. I’d love to see what he has to say about the API as it is now and how he’d improve upon it.

Bonus question: what’s up with the name “DestroyFlickr”?

Jonnie: DestroyFlickr’s name is based off my mantra, “Destroy Today,” meaning to make the most of each day by destroying it. I see destruction as a form of creation. DestroyFlickr is not out to literally destroy Flickr, but rather develop upon it and take advantage of what Flickr provides.

code.flickr.com

Tag Archives: 5 questions

5 Questions for Simon Willison

5 questions for Matt Biddulph

5 Questions for David Wilkinson

5 Questions for Fraser Speirs

5 Questions for Jonnie Hallman