7 essential planning tips when developing your application on Facebook Platform

Once you have come up with a great idea for a Facebook application, seeing an idea all the way through its implementation can be a tricky business. Once you’ve figured out how the application is supposed to work, your design of the implementation – the strategy of how you will code up your app – is crucial to the success of your initial version.

When targeting the Facebook platform, it’s essential we consider the following seven items before we even begin to start coding:

1. Access control integration
2. Life cycle callbacks
3. Friend tracking
4. Notification map
5. Invite/request positioning
6. Advert usage/placement
7. Your main logic!

To guarantee your app’s successful development, read on for tips and tricks about all of the above.

Access control integration

If you’re creating a web-based facebook application, your users are going to need to log in. This means logging into your application “on facebook”. From a coding perspective; before your main application logic executes, you need to check that the user has indeed logged in.

It’s not a big problem if they haven’t logged in yet – you simply redirect them to a Facebook URL (specific to your application) and Facebook will take care of the authentication for you. Because this check-and-redirect needs doing for almost every request, it should be a separate piece of code that can be re-used for any future applications you create.

If you’re writing your application in Java, TheLiveWeb has a free servlet filter that takes care of checking a user’s login state for you. Their page describes how to integrate the filter into your application.

Life cycle callbacks

Facebook’s stats system will tell you how many users you currently have, but it’s a good idea to track when users are adding and removing your application for yourself. If nothing else, it will give you tremendous flexibility to analyze user behaviour at a later date. By tracking the add and remove timestamps, you can answer questions such as:

• Do user “adds” coincide with the marketing campaigns I’m running?
• Is my application a popular addition at any particular times of day?
• Are people starting to use my application more at the weekend or during the week?
• Is user up-take of my application growing or shrinking?

While no single analytic is essential for a successful application, these can provide some insight into how your application integrates into the lives of your user base. If your application is about tracking football results but all your adds happen between 10am and 4pm Monday to Friday, then you know can make a fair guess that everyone is using it at work. You can then harness that data to cross sell to your customers or to build a network of related applications around your original application.

The built-in Facebook Developer application provides some basic stats on application adds and removes. By integrating life cycle callbacks into your application you can track the data yourself, leaving you free to do all the analysis you need – now or in the future.

Setting up lifecycle callbacks is easy. In the Facebook Developer application, configure the Post-Add URL and the Post-Remove URL to point to your own application. (Note: the add URL should be a URL that begins with apps.facebook.com whereas the remove URL should be an internal URL of your own). The add URL should also show the user a page that welcomes them to your application and encourages them to start using its main features.

Note: if you are using the access control filter mentioned in the previous section, make sure your add and remove URLs are not covered by the filter.

Friend tracking

Facebook’s terms of service forbid you from storing the social graph on your own servers so you immediately do not need to worry about tracking friend adds (and removals) in your application. However, “Friends” are the most important aspect of Facebook to users, so it is important you remember to integrate friend status into your application where ever it is appropriate.

For example, if your application is a dating application, then when your present a list of registered users that are all single, it is important to highlight friends or friends of friends where appropriate (and similarly to provide options to exclude friends where appropriate!)

Friends offer application designers essential context information about where the user lies in relation to the rest of the Facebook user base and their importance should not be under-estimated.

FQL allows deep querying of the social graph with exciting potential that is largely untapped at the time of writing.

Notification map

A notification map documents the points at which your application starts communicating with users that are off facebook at the time. It is something you should create when as soon as you have the preliminary designs of your user interface complete. Notifications contact users via email, letting them know of a new reason to visit your application. They can also simply appear in the ‘notifications’ panel that is linked from a user’s Facebook home page.

By pausing to consider all possible points that your application could send notifications, you will maximize the chances of repeat usage of your application as you remind users of your application’s relevance to them.

For example, if you had created a group blogging application, it would seem sensible to send a user a notification (ideally via email) when they had been invited to participate in the blogging. That would be a bare minimum to actually encourage the new user to use your application. However, to keep the user aware of everything that is relevant to them, you could send a notification whenever another user in the group posts a blog entry. Because of the nature of the notification mechanism, this can be discreet enough to only inform the user and not annoy them. Notification sending should be inherent to the design of your application. A happily notified user is more likely to spread the word of your applications to their friends.

Facebook recognises the potential for abuse of the notification system, and so your application can be marked as ‘spammy’ by Facebook if you send too many irrelevant notifications to users. By considering the notification map ahead of the implementation, we can maximise the opportunities to keep users interested while ensuring only useful, non-spammy notifications are sent.

Invite/request positioning

This is a bit of a no brainer – you want people to encourage all their friends to use your application, but there are a few different strategies, some more ethical than others. You can place your invite screen in a few different places:

1. As the first thing that a user of your application is shown. This is a risky business – it will mean some users auto-invite all their friends but you risk alienating a lot of other users who will just remove your application quicker than they added it
2. As an incentive to see some “result”, eg. to see your quiz score or your dating matches.
3. In a panel/tab all of its own
4. Some happy medium between 2 and 3 – position the invite panel so that it accompanies relevant features. eg. when a user is viewing all the people have sent them a cuddly teddy bear (with your Teddy 2.0 application), encouraging them to invite their friends to send more teddies is in keeping with the cuddly goodness of the application.

From a technical perspective, you don’t need to track any data to maintain the above, you simply need to consider the invite panel when designing the user interaction of your application. While the most widely deployed applications may suceed through mis-leading use of the ‘add panel’, a well-balanced level of invitation opportunities is most likely to encourage users to verbally spread the word about your application.

Advert usage/placement

The subject of revenue models for facebook applications is beyond the scope of this article, but advert placement is an easy one to consider with minimal risk associated with it, (especially when using off-the-shelf ad programs such as Google AdSense).

Your main application logic

Without your logic, you have no application, so this is clearly a crucial to your application. However, on older platforms such as Windows, your application logic is what your entire build is about, the widgets and controls are simply the way that a user interacts with your core business logic.

Less so on Facebook platform. While FBML is a web 2.0 equivalent of your Windows controls, the extent of the available Facebook APIs mean that platform integration becomes part of your application rather than just a building block.

This truth goes even further when you consider that 3rd party Facebook applications are effectively Facebook-branded by default. When choosing Facebook platform it is important to get the levels of integration and separation right for the benefit of your users and the long-term success of your application.

Have you built an application on Facebook platform? Run into any design difficulties I haven’t covered? Please share them in the comments below.

Advertisement