Facebook Connect UX Challenges

Recently, our very own Ryan Moede weighed in on Facebook's newest API addition, Facebook Connect. Around the same time I began to research the technical challenges that Facebook Connect posed by attempting to add Facebook Connect to an existing application. Using Facebooker and some custom Facebooker extensions I was able to successfully integrate authentication, registration, and news feed features. During this process I came across several user-experience challenges surrounding the Facebook Connect authentication mechanism. Depending on the nature of your FB Connect application, these issues might present some real headaches for both users and developers.

Facebook Connect Authentication UX Consequences

Facebook Connect determines your authentication state by checking to see if you are logged into the actual Facebook website. This means that you can be logged into a Facebook Connect application and, in another window, logout of Facebook. At this point your Facebook Connect application will not have any indication that its session has been destroyed. In addition, logging out of a Facebook Connect application automatically logs you out of Facebook. This poses a potential problem when a user has multiple Facebook Connect applications open as they all will lose their session when the user logs out.

Facebook Connect determines the authenticated state of the user on the client-side via the Facebook JS API. Check out the JavaScript API Authentication Model wiki page for a detailed explanation of Facebook's JS based authentication. A simplified Facebook Connect client-side authentication flow looks something like:

• Load the response from the server.
• Download the Facebook JS API.
• Initialize any required JS API features.
• Verify the current user is logged into Facebook.
• Set the appropriate cookies that indicate a valid Facebook Connect session.

This method of keeping track of a user's authentication state means that the server's view of the user's state is always one request behind. When combined with a decentralized way to log in/log out, this system can result in some confusing user experiences. For example, if a user is logged into Facebook and navigates to a Facebook Connect application the Connect application will respond with a page for an unauthenticated user. After the client-side JS authentication runs and sets the appropriate cookies, the next request will pass these along to the server.

Issues can also arise if the server has generated a response for an authenticated Facebook Connect user (i.e. one that has UI elements such as XFBML forms or the ability to post to a news feed) and that user logs out of Facebook. When the user submits another request to the server with the instructions to post something to their news feed, the server will see what appears to be a valid session in the cookies because the client-side code hasn't been executed. The server will attempt to use this session to post a news feed item and be rejected.

Facebook Connect UX Solutions

Here are a few ways to solve these UX challenges:

• Use JS to provide modal notifications to alert the user that a change in authentication status has taken place.
• Use the REST API to try and keep track of the session status by checking the API for a valid session on each request.
• Accept the fact that the server is one request behind and forward the user onto the appropriate page as soon as possible.

We decided to go with the REST API based approach in our Facebooker extensions as it proved to be a more flexible and seamless solution. Deciding on how to handle these situations depends on the nature of your application, but the degree of seamlessness increases the complexity with any of these solutions.

"Real World" Examples

To see a concrete example of one caveat surrounding JS based authentication we'll take a look at the official Facebook Connect demo application, The Run Around. First, make sure you have the application added to your profile by going to The Run Around and clicking the Facebook Connect button. This will log you into Facebook if you are not logged in and add the app to your account. Next, close the Run Around window and delete any cookies that exist for somethingtoputhere.com. This will leave you in the state where you are logged into Facebook but haven't logged into The Run Around. Finally, open a new window and go to The Run Around. You'll be greeted by a login screen which, after a second or two, will forward you to your personal Run Around page. I thought this was a pretty clunky experience, especially if I've already started entering my native login or if loading the JS takes an abnormally long time.

The inverse user flow, where a user is logged into The Run Around and then logs out of Facebook, results in a similar glitchy experience. If you are not already logged in, log in to The Run Around. Open a new window and go to http://facebook.com. Logout of Facebook, bring up the Run Around window, and hit refresh. The page will load like you are still logged in. Seconds later, when the JS determines you are logged out, the "Welcome Mr. Facebook User" dialog in the upper right changes to "Welcome,". The "Publish this run to Facebook" checkbox continues to be displayed, even though there is no way you can do this as you have logged out of Facebook. Trying to input a new run at this point, with the checkbox checked, forwards you to the login page. We found this to be a very confusing user experience.

Facebooker Extensions Wha?

I'll be releasing the set of extensions to Facebooker that really help simplify all the above issues at the cost of an API call to verify the Facebook session on each request. Watch the blog for more information.