記載されているdocumentationの和訳と、調べていて分かったノウハウを紹介します。we.ドキュメント全体の目次はこちらFacebook関連情報はFacebookページで共有しています。Likeといいね!ボタンプラグインの違いについて書きました。Likeは開発者独自の実装となる為、ボタンを自由にカスタマイズできます。反面、いいね!ボタンプラグインは設置が簡単でユーザによる認証も不要な反面、ボタンをカスタマイズすることができません。今回は以下の3パターンでの規約上の問題について、ボタンのデザインに絞って紹介します。Likeでいいね!ボタン画像を使ういいね!ボタンの仕様変更を見ると分かる通り、仕様変更後はビルトインのいいね!アクションもいいね!ボタンプラグインもFacebook上での挙動が同じになります。ビルトインのいいね!を自前で実装して、そのボタンに公式いいね!ボタンの画像を使い回しても良いのではないかと思ってしまいます。(同じいいね!なのだからユーザも惑わされないし。Likesドキュメントには以下のような記述があります。開発者は、クリックできるタイプのいいね!ボタンをデザインすべきです。ブランドガイドラインに従い、このいいね!ボタンはアプリのブランドを使うべきで、Facebookブランドを使ってはいけません。Likeアクションを実装する場合には、ボタンは自前でデザインする必要があります。いいね!ボタンのカスタマイズブランド情報センターには以下のように書かれています。「いいね!」ボタンの大きさは必要に応じて調節していただいて構いませんが、その他の変更は一切認められません(デザイン変更など)。今年5月2日の「エロサイトに「いいね」した人がエロサイトを見ていたとは限らない」で紹介されて話題になりましたが、いいね!ボタンプラグインを故意にカスタマイズしてユーザを騙すことができるようになってしまうので、その対応でもあるようです。ちなみに、下のキャプチャは去年の7月15日に私自身がハマった時のキャプチャです。まりぽさんより1年弱先に投稿しているわけですが、この罠に気付いたのは自分の煩悩のせいです。いいね!ボタン以外への利用また、いいね!以外の目的でいいね!ボタンの画像を使うのも禁止されています。2012でのツイートです。oklahomer@Gorleoneいいね!ボタンの画像をいじってシェアウィンドウへのリンクへ流用するの、デザイン利用のガイドラインに引っかかるから気をつけたほうが良さそう。LinksのURLを指定へリンクを貼り、それをクリックしてシェアさせるという解決方法が紹介されていて、それが利用規約に違反する恐れがありました。具体的には以下の通りです。15:59:35「いいね!」ボタンは、「いいね!」ボタンのソーシャルプラグイン機能に関してのみ、オンラインで使用できます。上記ルールがあるため、オンラインではいいね!ボタンプラグイン実装以外にはいいね!画像を使うことができません。シェアでもいいね!でも似た形でニュースフィードに流れるとは言え、いいね!の画像クリックでシェアさせるというのはユーザを騙しているということにもなるので、この実装はかなりマズいのではないかと感じています。SDKで取ってきてオシャレに表示する方法や、インサイトでいいね!ボタンの統計情報を見る方法などが具体的に紹介されているので、一度読んでみると参考になる点が多いです。Likeが追加され、モバイルアプリでも簡単にいいね!ボタンを実装できるようになりましたが、これに合わせ、既存のいいね!ボタンの仕様にも変更があるため、アプリによっては大きな影響があります。各変更の詳細は後述しますが、既存のいいね!に対する仕様変更で一番大きいと思うのは、いいね!されたウェブページを管理するためのFacebookページが作成されなくなる点です。これまでは、いいね!されたウェブページには管理者のみが閲覧できるFacebookページが与えられ、そのウォールへ書き込みを行うことで、いいね!したユーザのニュースフィードへ情報を流すことができました。Protocolでは以下のように紹介されています。Pageと同等の物になります。ユーザがページ上のLikeボタンを押すと、ページとユーザの間にconnectionが作られます。Interests"セクションに表示され、更新情報をユーザへ通知することが可能になります。og:typeにarticleを指定したページは対象外という制限がありました。一時的なコンテンツを象徴するURL(新着記事やブログ投稿、写真、動画など)はarticleを指定してください。websiteやblogはサイト全体を象徴するようにデザインされていますので、og:typeにwebsiteやblogが指定されているページは、通常、ドメインのルート部分にのみ存在すべきです。Protocolが実在するオブジェクトをサポートするようにデザインされていることを覚えておいてください。対象URLがコンテンツの一部であるなら(たとえばニュース記事や写真、ビデオなど)、og:typeにはarticleを指定すべきです。ブジェクトではないため先述の情報発信ができませんし、ユーザのプロフィールにも表示されません。website)をいいね!させることでユーザをこのウェブサイトのファンであると定義し、サイトの更新情報などをファンに対して通知するなどが可能でした。websiteのページが作成され(このog:type指定の是非はともかく。)、そこへ新規投稿があるといいね!したユーザのニュースフィードに通知が流れるという実装をした事もあったのですが、それができなくなります。(2012年8月15日追記:管理用のFacebookページを通常のFacebookページへと移行するオプションが追加されました。以下ドキュメント和訳に該当箇所を赤字で追記しています。)ユーザは自分の興味ある対象にいいね!する興味ある物事の最新情報は知りたいはずという前提で機能してたんじゃないかと思うんですが、ちょっと寂しいですね。Likeといいね!ボタンの大まかな違いは以下の通りです。Like:開発者が自由にボタンをデザインできる。実行にはユーザの認証が必要。いいね!ボタン:デザイン変更は規約上の制限がある。ユーザの認証無しにも設置できる。Migrationの和訳ですので、詳細はこちらを参照してください。Likeアクションリリースに関連して、いいね!ボタンプラグインの仕様を変更します。仕様が完全に移行するまでの間、今後90日の猶予期間内に、開発者はこの移行をテストすることができます。この移行により、以下の項目が変更されます。Likeアクションが実行できます。以前では不可能で、いいね!ボタンプラグインでのみ可能でした。Dialogを通じてpublish_actionsパーミッションを得る必要がありません。Graphオブジェクトに対して割り当てられていたFacebook管理ページは生成されなくなります。Graphオブジェクトをいいね!したユーザに対して告知をすることもできなくなります。APIの同等機能も廃止されます。既存の管理ページはFacebookページへと移行することができ、このページを通じて今後も更新通知を送ることができるようになります。この方法については後述します。Graphオブジェクトのog:restrictions:ageメタタグを埋め込むようにしてください。Migrationいいね!ボタンプラグインを利用しているサイトであれば、移行に際して以下の対応をすべきです。Graphオブジェクトページは、fb:app_idメタタグをしてください。設定できるので、app_idを埋め込んでアプリといいね!ボタンを紐づける必要がある)fb:app_idは、紐づいている特定のウェブサイトや製品のアプリケーションIDでなくてはなりません。Graphマークアップが必要になります。/>まだ管理ページからの告知機能を利用したい開発者は、以下のタグを含むようにしてください。Graphオブジェクトページに管理ページへのリンクが表示されます。いいね!ボタンに紐づく管理ページへのアクセスは、ここからでも可能です。その後、サイトや製品を表すFacebookページを別個に作成してください。ページをいいね!するようユーザに働きかけます。これにより、いいね!の移行完了後も新規Facebookページを通じてユーザとコミュニケーションを取る事ができます。既存の管理ページをFacebookページへと移行することも可能ですので、その方法は後述します。Graphオブジェクトに埋め込んで対応してください。これらのメタタグは年齢、国籍、content-typeを基にして、対象ユーザへのいいね!ボタン閲覧の可否、ニュースフィード投稿閲覧の可否をコントロールします。既存のいいね!ボタンのカウントが変わる事はなく、ここまでで紹介された変更以外の点で影響を受ける事はありません。Grpahオブジェクトのページでfb:app_idメタタグを指定しなくてはなりません。APIを使って再度Facebookにスクレイピングさせる必要があります。Migration"を設定します。Migration"は、すでにいいね!ボタンが設置されている場合はデフォルトでDisabledになっています。ここをEnabledに変更することで上記で説明した変更点を有効にできます。Disabledを切り替えることが可能です。Page移行後は、いいね!ボタン用の既存の管理ページは廃止され、いいね!したユーザへの更新通知目的での利用ができなくなります。APIのエンドポイントも同様に廃止されます。そのかわり、移行期間中であれば既存の管理ページはFacebookページへと移行可能で、これまでのいいね!の数も新しいFacebookページへと引き継がれます。いいね!ボタンの向き先もこちらへと変わります。管理ページをFacebookページへと移行する手順は以下の通りです。Page"というタイトルで下のキャプチャのように表示される部分に注意してください。Page"を選択することで、既存の管理ページをFacebookページへと移行できます。確認用ダイアログが以下のように表示され、移行完了後に行うことのレコメンドが表示されます。Facebookページへの移行が完了したら、それを正しく設定する為に以下のステップを踏むべきです。既存のいいね!ボタンのhref値をFacebookページのものに置き換える適切なページ名、カバー画像、プロフィール画像を設定するページの独自URLを設定する。詳細はこちらを参照してください。APIオブジェクトとFQLテーブルに仕様変更があります。Timezonesを有効にしたアプリに適用され、90日の猶予後には全アプリへと適用されます。TimeのUNIXタイムスタンプだったstart_timeとend_timeフィールドがISO-8601形式の表記に。定義されていたend_timeがそうではなくなる。読み込みEventオブジェクトoffset値無しのISO-8601形式で返されていたstart_timeとend_timeがISO-8601形式に。date_formatパラメータで返すフォーマットを指定できたが、できなくなる。定義されていたend_timeがそうではなくなる。書き込みUserオブジェクトstrotimeで変換できる形式ならば受け付けていたstart_timeとend_timeがISO-8601形式のみ受け付けるようになる。oklahomerFacebookがCrunchUpに参加カテゴリ開発ブログで、8月3日にTechCrunchが主催するCrunchUpにFacebookが参加することが発表されました。今年はf8の話題が全然でないなぁと思っていたんですが、これが代わりになりそうですね。扱うのは、プラットフォーム、モバイル、広告についての話題。オフィスアワーもあるので、Facebookの担当者と直に接する機会が持てそうです。eventbriteでチケット販売されていて、CrunchUpとパーティ込みのチケットのみ残っています(8:00現在)。APIやFQLでユーザの投稿一覧やフィードを取得しようとしていると、特にoffsetとlimitを使ったページングで上手く行かないことがあります。シェアボタン廃止前後のメモを探しているうちに、去年の春頃に自分でハマったときの記録が出てきたので共有します。去年3月の公式ブログ記事の内容を基にしてるので、現状どうなってるのかは試してないです。(常に最新状態に更新されるドキュメントと違って、ブログ記事だと後からのフォローが分かりにくいですね。ドキュメントも最新じゃないこと多いですが。APIやFQLでlimitを使って検索した場合、Facebook側では対象期間中の全件をまず取得し、そこから閲覧権限のあるオブジェクトのみを返すという動作をします。以下の画像は公式ブログからの引用ですが、途中で閲覧権限外のオブジェクトが間引かれているのが分かります。このため、上図のケースでoffset=3を指定しても返されませんし、limit=10でも10件は返されません。対応策として紹介されているのは、offsetの代わりにsince,untilとlimitを組み合わせて使う方法です。時系列に検索する場合は、取得したオブジェクト群の最後の1つのtimestampをsinceに指定し、逆時系列の場合はuntilを使います。1299634732ただし、since,untilとlimitを組み合わせた場合でも一件も返されなかい場合はあり、それが最後のページングだったのか、それとも対象全件が閲覧権限外だっただけでまだ残りがあるのか判別しなくてはならないという問題が残ります。その際には、limitの値を大きくして試すなどの方法が紹介されています。その際のヒントとして、閲覧権限をチェックして間引く前に検索できる最大件数(要するにlimitの最大値で、上図で言うと左の状態)は5000件だと書かれています。APIでこれらの対応が必要となるのは、以下のフィールドやコネクションです。videosFQLであれば、以下のテーブルです。直近1~2週間分のオブジェクトしか返さないことに気をつけてください。(この点は2012年4月30日更新のドキュメントで確認済みです。返され方が変わります動画の削除機能はドキュメントの誤りで、実はサポートされてませんでした。