概要

このエントリでは、「Providing People Greater Clarity and Control」で紹介されている仕様変更を紹介します。
今回の変更は、パーミッションの煩雑さを解消し、ユーザ体験の向上を狙うものです。認可ダイアログやパーミッションを簡略化する為の仕様変更が伴うため、既存のアプリの開発者は早めに対応する必要があります。ややこしい変更ですが、認可ダイアログは潜在ユーザを実際のユーザへと変える大事なステップです。この仕様変更に適切に対応することで、アプリ開発者にとっても利益があります。

1. 文言が適切なものに

no_scope

これまで認可ダイアログで表示されていた「Basic Info(基本データ)」という項目は「public profile and friend list(一般公開された情報と友だちリスト)」という名称に変わり、より適切に実態を表すようになります。これはユーザがアプリ利用を開始する段階で必ず提供される情報である為、開発者が特に対応する必要はありません。「へー、分かり易くなったね、というか今まで曖昧だったよね」と受け流して大丈夫です。

2. 投稿系のパーミッションが1つに

今まで

アプリがユーザの代理としてFacebookに投稿を行う場合、ユーザから投稿用の権限を認可してもらう必要がありました。認可してもらう権限はパーミッションと呼ばれ、どのパーミッションをユーザから認可されるかによって、アプリにできることは変わってきます。たとえば、ユーザのウォールやタイムラインに投稿するならばpublish_actions、友だちのウォールなどに投稿するならばpublish_stream、チェックインするにはpublish_checkins、という具合にです。

以下のキャプチャは、publish_checkinsパーミッションを要求したときの認可ダイアログです。
with_publish_checkins

また、以下のキャプチャはpublish_actionsとpublish_checkinsパーミッションの両方を要求した場合です。
with_publish_actions_and_checkins
要求した2つのパーミッションがそれぞれ表示されているのが分かります。それぞれの項目右に「X」があるのを見ると分かる通り、ユーザは1つ1つの投稿系パーミッションを拒否することができました。

変更後

これら3つのパーミッションは今後は1つに統合され、ユーザとしては「Facebookに対して投稿するか否か」のみを気にすれば良いことになります。3つが統合されるため、3つのうちどれを要求しても、「Example App would like to post to your friends on your behalf.(Example Appがあなたにかわって友だちのウォールに書き込むことを許可します。)」という文言で表示されることになります。

まだ移行中のため、本家開発ブログで公開されていたキャプチャを紹介します。
latest

統合後はpublish_actionsパーミッションのみをユーザに対して要求することが推奨されています。

注意点

「Example App would like to post to your friends on your behalf.(Example Appがあなたにかわって友だちのウォールに書き込むことを許可します。)」という文言に変わると本家ブログでは紹介されていますが、友だちのウォールへの投稿に関して理解しておかなくてはならない点が1つあります。
それは、2013年2月13以降、ユーザの友だちのウォールに対しての投稿が禁止される点です。
今現在は移行期間のため、まだ友だちのウォールへも投稿できます。そのため、3つのパーミッション統合により、ユーザ自身のウォールにも投稿できる(publish_actions)し、ユーザ自身としてチェックインもできる(publish_checkins)、さらにユーザの友だちのウォールへも投稿できる(publish_stream)ということで、3つの権限のうちで一番影響力の強い権限に文言を合わせていると理解しています。2/13に友だちのウォールへの投稿が禁止されれば、この文言も変更されるのでしょう。

友だちのウォールへの投稿禁止については、「Open Graphアプリの規制強化 & 友だちのウォールへの投稿禁止」と「Open Graphアプリとウォール投稿が一部規制される詳細」を参照してください。
また、publish_actionsやpublish_streamの違いについては、「Facebook Night vol.7 発表内容まとめ 1:publish_streamとpublish_actions」を参照してください。

3. 認可ダイアログが2段構成に

さらに本家ブログ記事では、パーミッションの種類によって認可ダイアログが2段構成に分けられることが紹介されています。以下の通り、読み込み系のパーミッションと書き込み系のパーミッションで二段構成になるようです。
read write final
見て分かる通り、左側の1ページ目では読み込み系のパーミッション(一般公開されたプロフィール情報、友だちリスト、メールアドレスの取得)、右側の2ページ目では書き込み系のパーミッション(友だちのウォールへの投稿)に別れています。
ただし、認可ダイアログの2段構成はこれまでも同様に存在していました。詳しくは「Facebook Night vol.7 発表内容まとめ 2」をご覧ください。このエントリでは、kloutのケースを例に、必要なときに必要なパーミッションのみを要求する方針も紹介しています。ユーザ登録時にはサービス利用上の最小限のパーミッションのみを要求し、ユーザが利用したい機能によって都度パーミッションを追加要求するという方法です。これにより、利用しない機能の為のパーミッションまで要求し、ユーザに不信感を抱かれてしまうという事態を避けられます。
また、関連エントリとして「Open Graphに触れる 2:ユーザ認証と権限の認可」もオススメです。
さらに次のステップとして、認可ダイアログの完了時にユーザがどのパーミッションを許可したのかを把握したり、ユーザがfacebook.comの管理画面からパーミッションを剥奪してしまった場合にアプリ側で把握する手段を「Facebook Night vol.7 発表内容まとめ 3:Batch RequestとReal-time Update API」で紹介しています。

まとめ

以上が、「Providing People Greater Clarity and Control」で紹介されている内容です。パーミッションの項目や認可ダイアログの構成など諸々の仕様変更がありますが、どれも私がFacebook Night vol.7で発表した内容の延長だと感じています。つまり、認可ダイアログ自体の仕様やパーミッションの仕様を理解し、ユーザ登録ステップを簡潔にすることで、認可ダイアログのコンバージョンを底上げすることができるというものです。
認可ダイアログに関しては、ユーザ登録部分の実装後は振り返るキッカケがなかなかありませんが、この仕様変更はユーザ登録のステップを見直す良い機会だと思います。