December 18, 2018
December 17, 2018
December 14, 2018
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.
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:
In addition, we'll deprecate some associated FBML tags as well. For more information, read Changes to Existing Platform Components.
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.
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.
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.