Filepicker.io’s goal is to connect the user’s files, photos and videos to the applications that need them. Recently we have been working a lot with user photos and here is what we learned.
Photos are hard to work with for a developer
As a developer looking to add the photo experience into your application you have two problems:
1. There are lots of good photos on Facebook, Instagram, Flickr, Picasa/G+ and they are hard to get to: Users are uploading a lot of their photos into these platforms. Facebook has 90 billion photos with about 250 million photos uploaded every single day. Flickr has about 6 billion photos, Picasa has 7 billion photos. Imagine all the awesome applications possible if you had access to these photos easily. One of my favourite services that does more with all these photos is Picplum. Picplum allows you to print and send your photo prints to loved ones. (Full disclosure: Picplum is a Filepicker.io customer).
However, to access these photos from your web or mobile application, you will need to build separate integrations with each of these platforms and manage these integrations.This takes time and is messy. Some examples of these nagging issues:
—-Dealing with the Oauth implementations
—-Inconsistencies among the APIs
—-Not having officially-supported back end libraries (such as ones for python)
—-Keeping track of API keys: For some APIs (looking at you Facebook), the fact that oauth url’s are hardcoded means you need separate keys for local, dev-servers, staging servers and production servers. It gets unwieldy pretty quickly.
Source: Greg Westfall, Flickr creative commons
2. Building a photo upload interface for photos on the user’s hard drive is messy:
Not all types of photos are in the cloud. Personal photos with intimate moments that are worth sharing with friends are, but professional photos or product photos often aren’t. For example, if the user were creating a AirBnB listing or if a fashion designer were creating a gallery on an ecommerce marketplace, those photos are unlikely to be on Facebook. Providing a frictionless user interface for uploading images isnt easy. Check out this video from John Koetsier of Venture Beat on the number of clicks (6!) it takes to upload an image from the hard drive to even a well established application like Facebook. It’s not just that, there are other hard and boring problems that the developer has to write custom code for. For example:
—-Drag and drop interface to reduce UI friction or UI elements such as progress bars to provide the user feedback on status
—-Dealing with multiple mimetypes
—-Multi file select and background uploading for responsiveness
—-Algorithms to ensure that large file uploads happen smoothly and reliably
—-Image conversion such as resizing on-the-fly or on-demand.
But if working with photos is this hard, why even bother?
Photos are valuable
If you are building a consumer web or mobile application you should include a heavy dose of photos in the user experience (unless you are building a text editor!). Photos provide an immediate and visceral connection between the user, your product and your use case.
Source: pfarrell95, Flickr creative commons
Recent experiments have shown that photos surpass any other content type in user engagement. In this experiment by Jon Loomer on his facebook content types, he shows how photos have 2-3x more engagement than other types of content. A quick summary of his results are below.
Photos also carry valuable metadata-such as EXIF data that captures time and geo coordinates that can make your application more context aware.
So in summary, the photo uploading process is broken and is a real bi*ch. You can’t do without photos if you are building a consumer app, yet you have to burn precious engineering cycles dealing with all the backend plumbing. We have had our fair share of heartaches and learnings with this at Filepicker.io. So ping us if you want to exchange notes.
Follow the discussion on HN
Major props to John Koetsier at Venture beat whose article inspired us to dig deeper into issues with photo uploading.