As I’ve recently completed my first Facebook Application I thought it might be worthwhile writing up my lessons learnt, in the hope that they will help someone else. Initially I though this post would be a technical discussion of the features and limitations of the API itself, but as soon as I started looking over my notes I realised most of the useful things I’ve actually learnt aren’t actually technical.

So here we go, gather ’round children.

Facebook Apps run on Facebook

No really, they do. The thing is everyone understands this, but I don’t think everyone necessarily appreciates how empowering, and constraining that can be. Usually when building an app, an initial concept is dreamed up, it’s fleshed out through prototyping or specing (or some combination of the two), bugs are fixed, design mistakes are correct, usability is improved, then you launch it.

Now, the misleading thing is that for a Facebook App the same steps are needed, but everyone one of them has an entirely different set of constraints. For example, say you’ve brain stormed a brilliant idea for a Facebook App that you’re convinced will dramatically increase your company’s/product brand visibility, make you rich beyond your wildest dreams, and win you the adoration of the girl (or boy) you always lusted after.

You start prototyping it and you discover that, because of how Facebook allows you access to it’s data, your killer feature can’t work exactly as you envisioned it. So you tweak your concept and throw yourself back into prototyping. Very soon you find yourself up against another wall and you have to stop and subtly change your design again. Pretty soon all the little changes add up and you realise that you idea doesn’t look anything like it did when you started. Maybe thats fine, but maybe that means the business plan needs to change or, if you are building the app for a client, you may need to renegotiate what you’re actually delivering.

Of course now you scoff at me, “It obvious that you’ll need to research the capabilities of any new platform before you finalise any plans”, indeed you chortle with glee at my naiveté. But I’m not convinced that just research is actually enough, I personally read everything I could get my hands on before starting, I even spent several days with my head buried in Facebook’s API WIki. And this was before I put pen to paper or wrote a single line of code.

Why isn’t it enough? Because there is a lot of information out there, but much of it is out of date. I spent an awful lot of time sifting through conflicting info trying to work out which to believe. This isn’t helped by the fact that, although Facebook’s own documentation is very good in some areas, it’s frustratingly vague in others. At the start, It can be very difficult to draw yourself a convincing conceptual picture of how all the various Facebook pieces fit together.

Your next problem is that, just when you’ve figured it out, Facebook goes and changes on you. It’s a very fast moving platform that can leave you, your plans, and your client eating it’s dust if you aren’t paying attention. Agility is important here, there’s nearly always a way forwards but it might not be exactly as you envisioned it at the start.

Eh, but you said it was empowering too, right?

Absolutely. You get to leverage (steal) all the best bits from Facebook and take advantage of all their hard work making their platform work on every browser in existence. You need a Captcha widget to stop your app getting spammed to death? No problem, just use Fb:captcha. It already does most everything you’re likely to need and you don’t need to maintain it. Facebook’s doing that for you. There are pre-written widgets for feed items, comments, editors, user selection, dialogs, and variable cornucopia of other interactive gifts that you can embed into your app with the absolute minimal amount of effort.

Think of how much time you usually spend designing and styling the look and feel or your web apps, then take one tenth of that and that’s probably what you’ll need here. I mean, apart from adding your own highlights and bits of branding, you’re going to end up with something that looks like Facebook. You could make it look completely different from Facebook but you don’t really want to freak out the Facebook user’s, do you? So you’re mostly going to use Facebook’s colours and their styles for buttons and tabs (not to mention headings, links, etc).

There’s plenty of information out there that details how to get the Facebook look, you’d be surprised how far you can get initially just by doing a bit of copy and pasting and focusing on getting the basics (text sizes/fonts, link colours) right. Don’t get me wrong, you’ll still need to put time into spit and polish. You still need good copy. usability, and all the other fun things that go hand in hand with this type of work, but the style issue? Mostly sorted for you. This frees you of a lot of additional cognitive load and allows you to focus on the stylistic details that really allow your app to slap its users in their faces with its own unique awesomeness.

So…in summary

The important thing to remember is that, if this is your first Facebook App, then allow much more time for research and prototyping. If your deadline is tight and you can’t spare the time to learn by doing then you better be agile in your requirements. If you play by the rules that Facebook sets down you can achieve some very cool things, if you don’t you are going to have a very frustrating and fundamentally futile fight ahead of you.

So pick your battles and make the best use of the advantages Facebook can give you, but if you intend to wrestle Facebook into your own vision of how things should work well…don’t say I didn’t warn you.