Monthly Archives: April 2008

Twitter API updates, FireEagle and new Flickr API fun

Posted on by

Last night twitter released their next batch of API improvements, of course the one that caught my eye was …

“[NEW] /account/update_location.[xml|json] – sets the location for the
authenticated user to the string passed in a “location” parameter.
Nothing fancy, no geocoding or normalization. Just putting this out
there so developers can start playing with how geolocation might fit
into their Twitter applications.”

saving woeids in the location field

… which is nice as it’s just thrown in there as a ‘what if’ type of thing. There’s no direct reason for twitter to have location stuff, (well no more than Flickr I guess) but everyone knows that everyone wants it.

It’d be great if you didn’t have to update twitter yourself and there was something else out there that could do it for us.

Read the rest of “Twitter API updates, FireEagle and new Flickr API fun” for more on Twitter’s location API, FireEagle, and Flickr’s not-a-geocoder.

FireDopplGängEaglr

Posted on by

First, there was filtr but that’s another story entirely. The point being that I gave up carrying around a capital-C camera a few years ago choosing instead to make do with cameraphones and the availability of cheap, unlimited data-plans in the U.S.

I am mostly lazy and can’t really be bothered to shuttle photos around from one device to another only to move them again to the giant device in the sky called Flickr. Before filtr I relied on the upload by email feature to snag a photo and quickly share it with the future-past but the desire to touch up — or filter — the photos before upload meant that I needed to write my own service to accept, process and then upload pictures to Flickr using the API.

ph:camera=n82

Which is what I want to talk about. Sort of.

Read the rest of “FireDopplGängEaglr” for thoughts on FireEagle, Dopplr, place, and the DWIM engine.

Inside Photophlow: an interview with Neil Berkman

Posted on by

photophlow

I knew when we started talking about Code.Flickr I wanted to have interviews with third party developers, and I knew that I wanted my first interview to be with Neil Berkman, one of the engineers behind the amazing Photophlow

1. Can you say a bit about what Photophlow is for people who don’t know?

Photophlow is a web application for real-time group Flickr browsing. As you search and share photos the group you’re browsing with sees the same things you are instantly. You can comment on photos, fave them, tag them and more, and all of this is shared with the group in real-time. Photophlow is meant to be used for all types of interactions around photos – organized activities such as group critiques and tutorials, as well as just plain hanging out and sharing.

We also integrate with some other services like Twitter and Tumblr. For example you can send out a Twitter message with a link to your Photophlow room to invite your followers to a real-time conversation over photos. We also integrate with the major IM networks to notify you instantly when things happen in Photophlow, like someone commenting on one of your photos.

If you’d like to a quick tour of Photophlow I’d recommend this screencast.

(editor note: Also checkout the photophlow group!)

2. How are you integrating with Flickr? What services or API methods do you use?

We use quite a bit of the API. Your identity on Photophlow is your Flickr identity, so of course we take advantage of authentication. We currently have two types of rooms – “personal rooms” tied to a user and rooms based on Flickr groups. We use the contacts and groups API’s to give control over privacy.

We take advantage of almost all of the API methods for browsing or searching for photos. And of course tagging, commenting and faving all go through the API.

One of my favorite features makes use of machine tags. We let you specify custom “photo emotes” – for example if you type /smile as a chat message we’ll show a photo you’ve tagged as phlow:emote=smile. Another makes use of the Yahoo Term Extraction API. We use this to determine interesting words and phrases in chat messages and we turn these into Flickr search links. Keying off of the conversation like this works really nicely for discovering areas of Flickrspace that you might not discover otherwise, and the results you get from clicking on a random phrase are often very funny and unexpected.

3. What if you favorite part of working with the Flickr APIs?

The nicest thing about it is the completeness. So far we’ve found that almost everything we’ve wanted to do has been possible.

4. What (if any) where the challenges?

The major challenges we face are due to the unique real-time group nature of our application. We’d like to be responsible consumers of the API so we set some restrictions for ourselves, such as never making a separate API call for each person in the room. For example when we display a photo we don’t indicate whether it’s already a fave because we’d need to make this call multiple times. We turned this into a feature – if you “re-fave” a photo we delete your previous fave and add it again, moving it to the top of your list.

5. What else should I have asked you? (I’m new at this!)

How about “what would you like to see added to the API?”

One is “invite photo to group”. Some group admins are using Photophlow to review photos to invite to their pool. It would be great if we could allow them to actually issue the invitations from within Photophlow.

Another, much larger one would be the ability to invite your Flickr contacts to use a Flickr-based application. This would take a lot of work to ensure that it could be done in a non-spammy way. Even I have mixed feelings about it but as an app developer it would be nice to allow people to use their existing connections on Flickr to be able spread the word about an application more easily.

6. Are you using any open source components in Photophlow, especially any that relate to Flickr? Are you planning to release any?

Like everybody these days we make heavy use of open source. The part of Photophlow that interacts with Flickr is developed using Ruby on Rails, and we use the Ruby API for Flickr. We’ve hacked this up a bit and may either clean it up and contribute back or take another look at the current Ruby Flickr interfaces and see if we might want to switch.

7. What is next? Are you planning to build more with Flickr? Enhance your current app, or build something new? Is there an application you’re hoping someone else would build?

We plan on improving Photophlow in a number of ways. A big one is to provide more explicit support for events such as critiques and competitions. There are a number of fun features we’d love to build, for example the ability to add notes to photos and share these in real-time.

We’re also building a new web application called Videophlow, which allows for group synchronous video viewing with a “shared remote control”. Initially this will support Youtube but we’re planning to support other services and would love to include Flickr video as well.

Thanks so much Neil and good luck at Launchpad today!

Have you got a neat Flickr project folks should know about? Let us know in recommendations for the DevBlog thread!

Photo: “photophlow” by d.j. paine

Making a better Flickr Web Uploadr (Or, “Web Browsers Aren’t Good At Uploading Files By Themselves”)

Posted on by

Sometimes when browsers won’t do what you want by themselves, you have to get creative.

A Brief History Of Web Uploading

As any developer who’s suffered through form-based uploading will understand, browsers have very limited native support for selecting and uploading files. While useable, Flickr’s form-based upload needed a refresh that would allow for batch selection and other improvements. After some consideration, Flash’s file-handling capabilities combined with the usual HTML/CSS/JS looked to be the winning solution.

In the past, ActiveX controls and Firefox extensions provided enhanced web-based upload experiences on Yahoo! Photos, supporting batch uploads, per-file progress , error reporting and so on; however, the initial browser-specific download/install requirement was “just another thing in the way” of a successful experience, not to mention one limited to Firefox and Internet Explorer. With Flickr’s new web Uploadr, my personal goals were to minimize or eliminate an install/set-up process altogether whenever possible, while at the same time keeping the approach browser-agnostic. Because of Flash’s distribution amongst Flickr users, it was safe to have as a requirement for the new experience. (In the non-flash/unsupported cases, browsers fall through to the old form-based Uploadr.)

And Now, For Something Completely Different

By using Flash to push files to Flickr, a number of advantages were clear over the old form-based method:

  • Batch file selection
  • File details (size, date etc.) for UI, business logic
  • Improved upload speed (faster than native browser form-based upload)
  • “Per-file”, asynchronous upload (as opposed to posting all data at once)
  • Upload progress reporting (per-file and overall)

Flash is able to do batch selection through standard operating system dialogs, report file names and size information, POST file data and read responses. Flickr’s new web Uploadr uses these features to provide a much-needed improvement over the old form-based Uploadr. The Flash component was developed by Allen Rabinovich on the Yahoo! Flash Platform Team. http://developer.yahoo.com/flash/

This Flash-based upload method did come with a few technical quirks, but ultimately we were still able to make signed calls to the Flickr API and upload files.

Now You Can, Too!

The Flash and client-side code which underlies the Flickr Web Uploadr is part of the Yahoo User Interface Library, available as the YUI Uploadr component.

It’s The Little Things That Count: UI Feedback

Given that Flash reports both file size and bytes uploaded, it made sense to show progress in the UI. In addition to per-file and overall progress in-page, the page’s title as shown in a browser window or tab also updates to reflect overall progress during upload – for example, “(42% complete) Flickr: Upload Photos”

Under Firefox, an .GIF-based “favicon” replaces the static Flickr icon, showing animation in the browser address bar while uploading is active. This combined with the title change is a nice indication of activity and status while the page is “working”, a handy way of checking progress without requiring the user to work to bring the window or tab back into focus.

In showing attention to detail in the UI and finding creative solutions to common browser drawbacks, a much nicer web upload experience is most certainly possible.

Scott Schiller is a front-end engineer and self-professed “DHTML + web standards evangelist / resident DJ and record crate digger” who works on Flickr. He enjoys making browsers do nifty things with client-side code, and making designers happy in bringing their work to life with close attention to detail. His personal site is a collection of random client-side experiments. http://flickr.com/photos/schill/

Web 2.0 Expo: You’re in Our Town Now

Posted on by

O’Reilly made the understandable, if unfortunate, mistake of scheduling a conference about 6 blocks from FlickrHQ. And we’ll be descending on next week’s Web 2.0 Expo in droves. Besides lurking around in the halls, a handful of us have successfully bluffed our way onto the schedule. Which means next week is your chance to come see the people who make Flickr talk about doing just that.

Thursday, 04/24/2008

A Flickr Approach to Making Sense of the World

Dan Catt will be holding forth on “A Flickr Approach to Making Sense of the World”, covering all things geo and nerdy, and bending very large geo datasets to your will. Thursday 1:30pm – 2:20pm, Room 2006

The Next Generation of Tagging

Don’t go anywhere, because right after the Reverend, Kakul Srivastava (Senior Director of Product Management), will be exploring the insights that arise at scale, and how to cope with them “The Next Generation of Tagging: Searching and Discovering a Better User Experience” Thursday 2:40pm – 3:30pm, 04/24/2008, Room 2006.

Friday, 04/25/2008

The Power of Online Communities

On Friday we’ll be kicking it off with some head to head scheduling. Our Community Manager Heather Champ will be bringing a ridiculous amount of expertise to The Power of Online Communities: Lessons from the Best of the Consumer & Business Community Managers. Friday 2:40pm – 3:30pm, 04/25/2008, Room 2009.

Capacity Planning for Web Operations

While across the hall John Allspaw will be explaining the art of Capacity Planning for Web Operations. (less politely known as, “If on the off chance your website doesn’t suck, you’re probably still screwed, ain’t you?”) John is literally writing the book on this subject, as well has helping plan Velocity. Friday 2:40pm – 3:30pm, 04/25/2008, Room 2010.

Casual Privacy

And in the anchor slot (thanks guys!), Kellan Elliott-McCrea (that’s me), will be talking about Casual Privacy, on techniques and algorithms for making lightweight privacy easy, while actually enhancing the sharing that is the heart of Web 2.0. (you might have seen the 5 minutes version last year at Ignite) 3:50pm – 4:40pm Friday, 04/25/2008, Room 2006.

Friends of Flickr

Perennial FoF Tom Coates of Yahoo Brickhouse and Fireeagle, will be giving his Designing for a Web of Data talk, and joining Matt Jones of Dopplr for Polite, Pertinent, and… Pretty: Designing for the New-wave of Personal Informatics. (Polite, Pertinent, Pretty, and British!)

And intriguingly, Children of Flickr: Making the Massively Multiplayer Social Web. But hopefully not in a “ … of the Corn” kind of way.

See you next week!

Flickr Uploadr, start to finish now

Posted on by

Starting at Flickr a short nine months ago, I was given the state of the Flickr Uploadr and told to make it better. Better meant many things. It meant cross-platform so we could move forward with one codebase. It meant localized in all of Flickr’s languages without hackery. It meant new features that would make uploading easier and encourage people to add metadata to their photos. And while we didn’t explicitly talk about it at the time, better meant open source.

Settling on a platform

Straight C? No. Java Swing? Adobe AIR? XULRunner? So many choices, each with advantages and disadvantages. I ended up choosing to work with Mozilla’s XULRunner, which is what makes up the guts of Firefox and Thunderbird. The main advantages of XULRunner were the ability to link in outside code libraries (like GraphicsMagick) and the availability of real multithreading.

Learning the hard way

Since the project began I’ve jumped more than a few hurdles. I documented many of the more exciting problems on my blog (rcrowley.org) as I went. Crash course follows:

Cross-platform XPCOM (a howto)

Working from Mark Finkle’s crash course for Windows got me halfway and some other scattered resources helped to piece together the skeleton of an app that will run on both Windows and OS X. The code has evolved quite a bit since then but this process got me on my feet.

XUL overlays demystified

As apps grow you naturally need to break files up to save your sanity. I never found the crystal clear example of overlays that I wanted, so after I trial-and-errored my way out of the corner, I wrote out this common use case that Uploadr uses in several places.

Threading in Gecko 1.9

I’ve been developing against XULRunner 1.9 (and therefore Gecko 1.9) which are the underpinnings of Firefox 3. The thread primitives made available in 1.9 are much nicer than in Gecko 1.8. Uploadr uses a background thread for event queuing and this is a stripped down example of that same pattern.

MD5 in XULRunner (or Firefox extensions)

The Flickr API requires developers to sign calls with MD5. MD5 is built right into PHP but is conspicuously missing from JavaScript. There are JavaScript implementations out there but (just for kicks), here’s how to take advantage of Mozilla’s built-in hashing library.

Fun with Unicode!

Flickr has, from the very beginning, been an international place. Well before it was available in eight languages, it would accept user input in any language through the magic of UTF-8. Uploadr carries on this tradition but to bridge the gap between Windows’ UTF-16 Unicode support and GraphicsMagick’s non-Unicode-iness, some hacks had to be liberally applied. This code has changed a bit since, so check the latest out in Flickr Subversion.

Video interview with the Yahoo! Developer Network

Jeremy Zawodny from the Yahoo! Developer Network came up to San Francisco to chat about the new Flickr Uploadr a few months back. We talked about the development process, open source and where the future might lead.

The future is here now with an extension API ready for use in version 3.1. Check out the documentation and helloworld extension or check out the full source code and build tools.

Welcome to the Flickr DevBlog!

Posted on by

Congratulations, you’ve found Code.Flickr, our new developer community site, and our new DevBlog.

The DevBlog is being written by the Flickr developers for the larger Flickr development community. We’ll be covering changes to the API (look for a post covering video in the Flickr API soon), cool Flickr related projects we discover, writing tutorials on Flickr API methods, and most anything else which catches our whimsy. If you have something you like covered, you can let us know on [in this thread] in the Flickr API group.

Its also the place to keep up on Flickr;s open source projects like the new open source Uploadr 3.0.

A Quick Tour

Beyond the blog, we’ve also got forums, a ticket tracker and a public SVN repository.

And we’ve got rainbows! And gears!