In part 1 I talked about the end user experience on Facebook and why I don’t believe they are doing a very good job and offering a great photo experience to users. In this post I want to focus on Facebook as a development platform for people like me to build apps leveraging the data within Facebook.
Ah, where to start. How about I start with the Facebook f8 developers conference I went to in April. In the words of Mark Zuckerberg, the APIs Facebook makes available to developers are the same APIs used to power Facebook. He says this with such enthusiasm and conviction that if these APIs are good enough for Facebook, they are good enough for me to build my app. The problem is, I am not trying to build Facebook, I am trying to build something using the data within Facebook. Any developer knows that to build a product of the scale that Facebook is at requires serious tradeoffs and optimizations. Over the past 6 months I’ve become intimately familiar with the Facebook APIs. It is clear that they are there to meet the needs of the Facebook product, with little olive branches here and there to demonstrate they aren’t completely ignoring the needs of developers.
To be fair to Facebook, they are trying a little bit harder to make developers live’s easier. The APIs are now versioned and will last for two years. Well, almost. The 2 year guarantee only applies to core properties. When looking at the documentation, very few properties are core. Even if 99% of the properties were core, there could be one property that is critical to my app, and Facebook could remove it, change it, or do something else to the property that could make it impossible for my app to function the way intended, it could kill my business.
For the past 2 years or so, Facebook has had two different APIs for accessing data, FQL and the newer Graph API. At the f8 conference, Facebook announced they would be deprecating the FQL API in 2 years. In my opinion, the FQL is the richer of the two APIs. I have my gripes about FQL, but it certainly provided a richer way to query information. So Facebook is removing capabilities from the developer and shifting more of the heavy lifting from Facebook to the developer. It is rare that a modern development platform makes a wholesale cut in functionality resulting in a net reduction in capabilities of the platform. Sure, APIs come and go, tweaks here and there, but this is big. This is the exact opposite of a WOW feature that opens the door to a whole new world of possibilities of what I could build.
What is perhaps most frustrating is that with what few fields I can filter on, depending on what the value I use for the filter, I might not get results, even if I know there are matching results. I believe this has to do with the Facebook internal 5000 row limit. I can’t tell you how many forum posts I’ve seen on Facebook app developers getting tripped up on the internal behavior garbage Facebook makes its developers deal with. Yes, they explain what is going on and how to deal with it for some situations, but is it really even necessary to expose this dirty internal laundry to your development community? And for the scenarios that have no pattern for reliably getting results, it makes any filtering with the API completely worthless.
At f8, Facebook did announce some new ways of querying data. However they were very narrowly focused. Being able to make queries with more filter conditions and get consistent results would be a huge improvement.
Let me go back to the scenario I mentioned in my previous post about finding photos from my anniversary and look at it from the developers point of view. In Sepia, I have been going through different scenarios such as friends’ birthdays, mother’s day, father’s day, anniversaries, etc to try and automatically find relevant/interesting photos from Facebook. Since Sepia is an application I am developing, I am not restricted by the user interface provided by Facebook. I am primarily constrained by the quality of the data within Facebook and the APIs offered by Facebook to access that data. Remember what I said about Facebook nuking all metadata from photos when I upload them? Well, there goes a ton of interesting information I could have used to build new ways of enjoying your photos. My friends who uploaded photos days or weeks after the wedding were not easily found with a search on our anniversary date. So with what little data I have left to work with, it may not even be an accurate representation of reality that allows me to find relevant photos from our wedding.
Unlike the Facebook app and web site, I can use the Graph to search for photos by a date range, or if me or someone else is tagged in the photo. Beyond that, I can’t do much more. I can’t search by location, description, comments, or more complex queries including multiple dates or date ranges, or multiple people tagged. A location search for example requires me to download all photos that could potentially be relevant, and then implement my own filtering to narrow down the results. This isn’t rocket science, but it is more work for me, doesn’t scale very well, and is something relatively basic that one might want to do with photos. A company serious about building a developer platform to work with photos should have this.
Data Beyond Photos
One of the reasons I started building Sepia on Facebook rather than another platform with photos such as Flickr or Google+ is because of the rich data set available beyond the data primarily associated with photos. This additional data would allow me to provide much more context and meaning to the photos of my life. For example I wanted to be able to send a couple a collage of photos from their wedding on their anniversary. Unfortunately their anniversary is not exposed to developers. I know this is more of a bonus feature, but it is the kind of information that can allow developers to completely transform how we relive the moments of our life through photos.
Many users don’t let apps their friends use access their photos. Having this setting makes sense, but I am doubtful many people are aware of it and what setting it has. If your friends do have this set, it is not explicitly noted to the friends of the user who has prevented access to photos. As a user of an app, I may think the app is broken if I don’t see John’s photos. Privacy is an inherently complicated problem, and Facebook needs to do more to educate people about the settings available and to help people choose the settings that make the most sense in the context of scenarios in which those settings apply. This is no different than Facebook’s own strong advice to app developers to ask users for permissions to user’s data in the context of why they need it. So why isn’t Facebook following the same best practices it encourages others to follow? I realize this in many cases will require collaboration with app developers, but in the end, it would result in richer apps and a better end user experience.
With Facebook’s new versioned Graph API, one of the new aspects of it is that I can’t access any friends data from an app unless that friend is also using the app. This pretty much trumps the privacy issues I just described thus far. I don’t blame Facebook for this change though. Users need to own and control their data, and this theoretically should allow them to do that more easily. For developers, our challenge is now even greater to figure out how to get more users on board. With a significantly reduced set of data to access when I sign up for an app like Sepia, the experience will be much more limited that it otherwise would be if all my friends were using it as well. I believe Facebook needs to work with developers to find ways of encouraging people to sign up for apps that enhance the Facebook experience. Without a rich app ecosystem, Facebook will be limited by their own resources and ideas, leaving the door open for competing social networks to attract users away from Facebook. Microsoft and Apple (iOS more specifically) are only what they are today because of the armies of developers out there who built on the rich developer platforms those companies provided. Facebook is far from accomplishing a similar feat.
The features Facebook offers for your photos are squarely targeted at sharing new photos for people to see now. The lack of rich metadata on photos unless added by Facebook users, and the week development APIs doesn’t foster a rich community of photo applications on Facebook. Yes, simple compelling scenarios can be implemented as Sepia has demonstrated with the This Day in History emails. Some more interesting scenarios can be implemented with significant development effort, but are limited to the quality of the data within Facebook. For Facebook to be serious about photos for end users and developers, they need to support the rich metadata people expect from photos and enhance their APIs to make it even easier to build compelling applications with photos on Facebook.