Facebook Development: Hello Birthday V2 Open Graph

Well, it has been a few months since my original post on Developing Facebook applications (Hello Birthday’s original post). During this time, Facebook has introduced a new API called Graph (Graph Docs). A big change is the authentication protocol moving to OAuth 2.0. Yay for OAuth, because it definitely simplifies things…

Facebook continues supports the legacy Rest API, which is good because the new Graph API is still changing slightly here and there… If you have Rest API keys stored, you can easily upgrade them using one of the new API’s function calls.

The most exiting feature that Graph introduces is the ability to subscribe to user attributes, like friends, application permissions, and current location.

As you can imagine, this has huge performance gain implications and reduces the need for overly complex web apps with polling-like data integrity processes… Read: No longer do I have to ask Facebook if a user has given me permission, because I know now what I have when they sign up and if it changes at any given time.

Facebook is pushing iFrame Canvas apps. Beware of this. It is a difficult, and hack-prone, situation where you have to find a way to authenticate a user within an iFrame and use Javascript to do a top.window redirect. Facebook Developers say better support is coming. For now, JS is your friend.

Let’s move on though… The new API is great and all, but I’m more interested in talking about some of the insights gained from my first real FB App. Here are some high level lessons learned from my non-iframed canvas app (v1):

  • Javascript support is limited
  • FBML is really a sad attempt at a markup language, I’d rather see HTML sensitive attributes that do the same thing FBML does, without he need for a whole new language
  • Global styles were less-than-easy to work with due to FB rendering my page within theirs
  • Rendering pages requires all of Facebook’s shell to render. Boo
  • Porting the app to be a stand-alone web app is not trivial, plan out your adventure ahead of time. If you think your app might become a standalone product plan for it (the best you can)
  • Unable to fine-tune performance (you <strong>can use memcache though!</strong>)
  • As the previous note hints at: use memcache it makes life so much easier if you’re dealing with a lot of data and constantly using lists of friends and information about each friend
  • Get a friend to work on the app with you. It makes testing and continued efforts so much easier. Thanks Joe :)
  • Get a good set of friends to bounce ideas off of. Thanks Jon, Erica, and others whose names escape me right now
  • Ask your USERS for feedback early & often
  • It’s nice to have my app feel as though it belongs in the Facebook layout. I think this is a big win to Canvas as a whole
  • The API has worked very well for me and I’ve experienced little to no hiccups
  • Love FQL
  • Facebook developers are somewhat easy to get a hold of but problem solving may take time.

During development of V1.5 (the transition to the Graph API) some of the changes made were:

  • Move to an iFramed app
  • Clean up transitional code that helped me get from boot-strap to version one
  • Remove FBML mark up
  • Implement more personalization options to the user experience
  • Create more of an “experience” for that matter… Adding descriptions next to links to give context. An ongoing effort, by the way
  • Became more transparent in implementation details: I told my users more about how Hello Birthday worked, what features were being built, and what bugs I found.
  • Listened to feedback and added: Personalized Messages on a global level (defining a set of default personalized messages that are randomly selected during the wishing process)
  • Listened to feedback and changed: Birthday messages to be delivered during the day at user specific time ranges.
  • Fixed issues related to local time zones
  • Identified users who have privacy settings that don’t allow Hello Birthday to retrieve their birthday *big one*

One of the points above is really important (bullet point 6) and it hovers around the idea of creating an open dialogue between you and your users so that they feel comfortable complaining, suggesting, and critiquing features. My users are the debuggers, like with most applications, and just by letting people know when I was making changes, what they were, and screenshots of what to expect I was able to generate immediate feedback. The best part is, that feedback was both good, bad, and off topic! I was receiving (as comments to the posts on the App Wall and via e-mail) bug reports, thumbs up, and thumbs down on different ideas/feature enhancements. By continuously increasing the number of posts (to a certain degree) I was essentially getting into the daily lives of Hello Birthday’s users and it caused an awesome feedback loop to begin where there now exists a few users who love to let me know when things break! Awesome.

I’m very close to having the version two of Hello Birthday launch. As you can imagine, there is a bit of hesitation around the new authentication protocol and making sure my legacy API key’s of my users transfer over. I’ll write a post on that (if it ends up not being trivial). At any rate, I’m looking forward to seeing the feedback on version two. There has been a lot of subtle changes and feature enhancements that I’m sure (because of feedback received already) will be welcomed nicely.

You can expect a post after the launch of V2 where I will go over some of the insights Facebook provides to developers for their apps. There’s a lot of interesting data around conversion rates and what permissions people grant your application that I want to share! Thanks.