Streamlining Application Authorization

We've heard from many users that adding applications is cumbersome, since they have to make so many choices on the application add page. Users have expressed concerns about adding an application without having experienced it first, because they can't predict what's going to happen when they add it or because they don't want to clean up their profiles afterwards.

To reduce user friction when encountering a new application, we're streamlining the way users authorize applications when they first encounter them. We're doing this by recommending that you use require_login instead of require_add when the user first interacts with your application. By doing so, we believe users will be encouraged to explore your applications more and with less hesitation. As users engage with your application, they can access additional features and integrate your application deeper into their profiles when it makes sense within the application user experience.

You should start using require_login in place of require_add now. When the new profile design goes live to all users, we're going to redirect require_add calls to require_login. When a user goes to an application for the first time and is prompted to log in, she will see a simpler screen, like in the screen shot here. Once a user authorizes your application, you can utilize all the API methods that access information about the user, publish stories to News Feed and Mini-Feed, and send the user notifications.

How Will Users Integrate Applications?

When these changes launch with the new profile design, your existing users will continue to have the same settings and integration points that they configured before. For new users, this is what's happening to the various integration points the user sees on an application add page now:

• Know who I am and access my information: This option and your application's Terms of Service will be the only permissions users need to agree to before accessing your application for the first time. This is similar to the login page that appears when you call require_login. Once the user logs in and accepts your Terms of Service, she won't have to log in to your application again.
• Put a box in my profile: This option is now an FBML button that you can incorporate into your application's canvas page. You can test this on the new profile beta sandbox now.
• Place a link in my left-hand navigation: This option is going away with the new profile design because the left-hand navigation links will migrate to the Applications menu in the new top-level Facebook menu bar. The Applications menu displays a list of recently used and bookmarked applications (an application is considered to be recently used if a user -- logged in or not -- has visited its canvas page). Users can bookmark an application when they are on that application's canvas page and they can rearrange the bookmarks through the Edit My Applications page.
• Publish stories in my News Feed and Mini-Feed: This option is enabled by default. Applications can send one line stories to users automatically, and short and full stories with user approval. Users can change this setting on the Edit My Applications page.
• Place a link below the profile picture on any profile: Profile action links will not exist in the new profile.
• Send me notifications via email: We know that email is an important communication channel for many of you to reach users. However, we've also seen a surprisingly high number of users mark application email as spam instead of simply unsubscribing from it. In order to preserve email as a channel for high quality communications, email to users is disabled by default. Instead, you can offer users a way (such as an FBML button or an FBML attribute you can append to your own link or button) to opt-in to receiving email from your application on your canvas page.

In addition, we'll deprecate some associated FBML tags as well. For more information, read Changes to Existing Platform Components.

New Application Metrics

With these changes, we want to emphasize the importance of a good user experience and user engagement. We will publish new metrics soon, which focus on user engagement with applications, including data like how many users have been active with your application in the last week and the total number of canvas page views.

We'll also provide aggregated statistics around how many people have added the various integration points for your application -- your application tab, profile box, and application info section -- as well as who has subscribed to email or bookmarked your application.

Since users won't be adding applications in the traditional sense, you're probably wondering how they can remove them. Users can adjust all their application settings on the Edit My Applications page including the ability to stop granting applications access to their information.

Changing User Sessions

Since the flow for adding applications is changing, on July 15, we're going to stop granting infinite sessions to Web-based applications automatically, like we do today. (Desktop applications will continue to be granted a 24 hour session key, and mobile clients will continue to receive infinite sessions, like they currently do.) The session key you'll get will last one hour, so, for example, you won't be able to post News Feed stories for a user after the user's session expires. However, when the user approves your application's Terms of Service, you can offer the user the option to grant an infinite session (provided the user agrees to be kept logged into your application). And you can store a session key each time a user interacts with your application.

Until July 15, we'll grant a temporary session key for each user that lasts 24 hours. Each time the user interacts with your application, we'll grant another session key or renew the existing one, so we recommend you store the most recent key.

At the same time, we're also removing sessions from many calls so there's less need for infinite sessions. For example, calls like profile.setFBML, photos.upload, and users.hasAppPermission no longer require session keys today. And we're changing more methods so you won't need a session key to do something when the user is offline, like send a notification. We put a listing of which API methods no longer require sessions on the wiki. We’ll add more methods to the list as we change them.

Our Developer Terms of Service prevent caching of data for longer than 24 hours, so this change mainly affects those developers who were batching up some calls that currently require an active session. The result is that we'll do a better job distinguishing whether certain API calls should require an active user session.

Contacting Us

We continue to want to hear from you about the new design and your experiences trying it out. Please report any bugs you see in the new design. Make sure you use the New Profile category. You can help us solve your issue faster by adding one of the following components to your report: Feed, Info Sections, Profile Boxes, Publisher, and Tabs.

You can send us your feedback and ask questions in the New Profile and Related Changes section of the Developer Forum.