Back to News for Developers

Using Developer Principles as a Guide to Creating Good Experiences

December 18, 2009ByPaul C. Jeffries

As we pass the December 16th and 20th deadlines for enforcement of our new Developer Principles and Policies, we wanted to talk more about Facebook Platform's principles, including the role they play in enforcement, the creation of policies, and how you should use Platform.

The Developer Principles lay out the core of our philosophy behind creating a good application. Our policies stem from this framework, and we'll keep striving to keep the policies and examples comprehensive -- but to protect the ecosystem, as we stated in our Developer Roadmap announcement on October 28, we will be enforcing on the principles too. Embrace them as you design and operate your applications and you'll be doing right by users and the community:

  1. Be trustworthy
    • Respect privacy
    • Don't mislead or surprise users
    • Don't spam -- encourage authentic communications
  2. Create a great user experience
    • Build social and engaging applications
    • Give users choice and control
    • Help users share expressive and relevant content

Enforcement

We recognize building applications that abide by the spirit of our policies and principles requires judgment on your part. We're committed to working with you and will share our perspective in the Developer Forum and future blog posts. This should help inform your decisions as you build great applications. We'll continue to update the policies and Examples and Explanations as issues arise or the product changes.

We will strive to be as consistent and transparent as possible in our enforcement of these policies and principles as we focus on safeguarding the user experience on Platform. Enforcement actions range from warnings to suspension of functionality to outright disabling of applications. These actions will be driven by a variety of factors including the severity of the violation, the developer's policy compliance history, and the violation's impact on users.

Examples

As part of our effort to help you understand how we think about these policies and principles, here are a few examples with our perspective:

  1. As an example of how to apply the principles in your understanding of policy, consider Developer Policy V.4:
    You must not prompt users to send invitations, requests, generate notifications, or use other Facebook communication channels immediately after a user allows access or returns to your application.

    If you try to skirt this rule by showing a low-significance page, whose primary purpose is to buffer the next page's prompt for invitations, immediately after the user comes to the application, we would enforce against it. Our intention is for users to meaningfully engage in an application before being prompted to contact their friends.

  2. To help users easily return to your application, we offer bookmark functionality. Our bookmark-specific rules state:
    V.10 You must not prompt users to bookmark your application (e.g., by using a modal window or pop-up dialog). Instead, users must explicitly invoke any bookmark option you provide.
    V.11 If you provide users with the option to bookmark your application, you must use our bookmark button or design your own using a similar style and prominence.

    The intent is that users should be left to their own initiative as to whether to bookmark your application, and that the UI should clearly indicate what's going to happen, without being overly intrusive. We offer this functionality to developers so you can harmoniously integrate the bookmark button your application's navigation and controls. But it's a violation of the principles to avoid a "prompt" by instead presenting a flashing, urgent call to action that says "Bookmark Now!", placing it in an interstitial page (for example, while a page is loading), or other similar implementations. If we see anything like this, we'll place your application on moratorium or disable it.

  3. The stream story rules include:
    "You must not use stream stories as a method for users to invite friends to your application," (VI.B.3) and " [...]In no case should a stream story serve primarily as a means to promote or advertise your application." (VI.B.9)

    If you're urging users to publish a story just to get friends to play with them ("Recruit your friends! Click here to post a Feed story!"), that isn't authentic sharing of expressive and relevant content. It's an inauthentic and spammy use of communication channels. Users who intend to invite others to your app should do so via invitations, the designated channel for that purpose.

Questions?

We understand there can be genuine confusion among well-intentioned developers, so if you have questions please share them in the Developer Forum and we'll try to clarify. But the principles provide straightforward guidance on the basics of serving users. If you exemplify them in your to use of Platform, our goal is that you won't have to worry about policy enforcement and can instead focus on success and providing the best experience for users.

Paul and the rest of the Platform Policy Team think it's good to stand on principle.


Tags: