Twitterクライアントがこの先生き残るには

#twtr_hack@s17er

2013/2/1

自己紹介

@s17er / 佐々木シンイチ

Janetter for Android

Java / Python / JavaScript / etc...

Twitter API 1.1 2013/3/5

対応してますか？

エンドポイントの変更● 呼び出すURLが変わる

– http(s)://api.twitter.com/1.1

– 変更されているものも

● /blocks/blocking/ids → /blocks/ids

エンドポイントの変更● 廃止されるAPI

– クライアントの仕様変更が発生

● 他人がリツイートしたツイート一覧● 特定ツイートをリツイートしたユーザ一覧● タイムラインでリツイートを受け取らないユーザ一覧● ブロックユーザ一覧

検索ツイートの構成変更● 通常ツイートと同じになった

– 公式RTと非公式RTが区別できる

● ミュートしやすくなった● 検索と他のタイムラインの場合で処理をわけなくも

よくなった

レートリミットの変更● エンドポイントごとに回数制限

– 15分ごとに15回

– 例外的に15分ごとに180回叩けるものも● search/tweets● status/show/:id● user/lookup

15分に15回？● すぐにリミットに到達する

● 特にリストはヤバイ

– エンドポイントはリスト毎ではない● lists/statuses?list_id=

– リスト5個を同時に更新できるのは15分に3回● リストをたくさん管理している人は更新間隔長くなる

Display Requirement

https://dev.twitter.com/terms/display-requirements

Display Requirement● ツイート表示に関するルール

– 表示すべき項目が細かく規程– 相対時刻– 名前とscreen_name併記– リプライ、リツイート、お気に入り追加のボタン– リツイートの場合の表記

– Twitter Birdをタイムラインに表示

● 一行表示型が出来なくなる (tweenなど)

1.1に対応して待ち受けているもの

ユーザからのクレーム● screen_nameの左に@はいらない

● 時刻の相対表記は分かりにくい

● Twitterの鳥が邪魔

● 前のほうが見やすかった、何故変えた

● すぐにAPIの利用制限に到達する

クレームに負けずにサポート頑張りましょう

サポートの難しさ● 先行して対応したと言っても、

– 「他のクライアントでは出来るのに！」– 3/5までギリギリ待つほうが得策？

● API 1.1の変更やDRについて説明…

– 一般の人に砕いて説明するのめんどくさい– Twitter公式での説明は英語– あまりTwitterのせいにしすぎると逆に反感買う

● 解決できることではないので、結局「星一つ！」になる

それに耐えたとしても…

これ以上、ユーザーを認証できません

アプリごとのユーザ数制限● 新規参入の場合、10万ユーザまで

● 10万を超える場合は、発表時点(2012年9月頃)のユーザの二倍まで

– 制限に達するとそのアプリ(Consumer Key)でのユーザ認証が出来なくなる

– 一回認証していても、再認証不可

● アクセストークンを取得するAPIが使えなくなる● 再インストールしても再認証できないケースが

アプリごとのユーザ数制限● 到達したクライアントたち

– Tweetro (Windows 8)

– ShootingStar (Android)

– Twitcle (Android)

アプリごとのユーザ数制限● クライアントビジネスの終焉

– 新規参入にメリット無し

● ユーザ数の上限

● サポートコストはかかる

● 10万ユーザでうまくマネタイズできれば…

– 既存クライアントは既得権益にしがみつけ

アプリごとのユーザ数制限● 開発者のモチベーション低下

– 多くの人に使って欲しいから開発する

● 上限設定で先が見えてしまう

– これまでのTwitterとの信頼

● サードパーティと共に成長してきた● 信頼と文化の否定、別の価値観の押し付け

回避策はないか？● バージョンをたくさん作る

– 2013年春版、2013年夏版…

● 同じアプリばっか作るなってストアから怒られそう● そもそもTwitterの規約で禁じられている

– 機能ごとに無料版、100円版、200円版…

● source名どうするのか？● 100円版から300円版にアップデートする場合は？● せいぜい数種類が限界

暗黒面に堕ちますか？● ConsumerKeyのラウンドロビン

– ConsumerKeyをサーバで管理● アプリ内にキーを持たない

– ユーザ制限に到達した時点でキーを更新

ブラックです！もはや倫理の問題

一応iOSはなんとかなる● Twitter Framework (iOS SDK)

– ユーザ数の制限気にしなくていい● AppleとTwitterと喧嘩しない限り安心

– sourceはiOS

– 現状、REST APIしか使えない

● モバイルなら許容できる

– DMが扱えない

他のプラットフォームのサードパーティ製

Twitterクライアントは座して死すのを待つしかないのか？

サードパーティの排除● およそ二年前からTwitterはそういう方針を打

ち出していた

● 今更騒ぎ出した所で遅い

● 先見の明があれば足を洗っているはず

受け入れよう

世の中に不満があるなら自分を変えろ！それが嫌なら、耳と目を閉じ、口をつぐん

で孤独に暮らせ！

結論● Twitterの方針変更を待とう

– 待てるのならば

● ビジネスでやるのはやめよう– 限られたユーザ、ニッチを攻めるならアリ

● 趣味でやろう– 悪ノリしてBANされてもネタになる

完

それでもTwitterクライアントを作りたい

これからTwitterクライアントを作る上で考慮したいポイント

タイムライン● リアルタイムでのタイムライン更新

– Streamは公式Webでは使えない● 専用アプリの強み

– モバイルはRESTのほうがよい

– あまり流速が速すぎると読めない● 適度にさっぴく● 同じRTは一定時間表示しない● 表示ユーザの調整（グルーピング）

ユーザのグルーピング● 今まではリストで振り分けていた

– リストにはStreamがない– レートリミットにより実用でなくなる

● ミュートユーザー機能

– ピンポイント– リムーブの代わり（大人の事情）– グルーピングとはちょっと違う

ユーザのグルーピング● レーティング、タグ付け

– 状況に応じて、特定タグユーザを表示/非表示– 星3つ以上のユーザだけ表示– 俗に言う「タブ分け」に近い

● 一つのタブで切り替えるか、複数タブで見るかの違い

– そのグルーピング情報を共有できると便利● TweetMarkerみたいなゲートウェイサービス

ホットな話題を追いかける● トレンド

– ニュース性● トレンド一覧だけでなんとなく何が起きてるか分かる

– 勢いとかランキングとか● クライアントで集計

● その日のトレンド– API廃止されてしまった– 独自集計

● タイムライン内のトレンド– ハッシュタグ大喜利とか興味無い人とか

雑音排除● 目にしたくない言葉

– ワードでミュート

● スパム、BOT– sourceでミュート

● 初見でも目にしたくないユーザ– 思想が違う人– いろいろ面倒と感じる人– アイコンでミュート– ワードでミュートされたらそのユーザもミュート

知能的な情報集約● 興味ある人のツイートを集約

– フォローしている人の発言を効率よくまとめる● フォロー＝興味ある

– どうでもいい呟きは弾く– たくさん出る話題、URL、RTをまとめる

● その日の話題になったツイートも集約– トレンドに上がった発言をまとめる

● クライアントだけの領域ではないんじゃないの？– ただAPIを叩くだけじゃ生き残れないのではないか

コミュニケーション● 返信

– in_reply_to付き– 引用返信– 複数返信

● DM– もう必要性が薄い？

● Twitter自身、不要と思っているフシが– LINEとかSkypeとかFacebookに任せようか

● ふぁぼ– なるべく近寄らないようにしよう

RTと言及● 公式RTによるデマ拡散

– RT制限回数を設けては？● 人の口には戸は立てられぬ● 代わりにWebとかでやるだけ● 公式にある機能の制限は反発を生む

– クライアント側で受け取るRTの制御

RTと言及● 非公式RT問題

– 会話が追いかけづらい● in-reply-toつけると公開範囲が狭まる

– USの”replies=all”で、フォロワーへの返信を全部取る●有名人をフォローしているとその人への全リプライが流れてくるので負荷が高くなる

● in-reply-to付きでも、@の前に文字があれば全員に公開–公開返信として機能化しては

●返信の種類多すぎる…– 話題にするとたいてい荒れる

● 機能を削除すると炎上● 思想が無いなら、そのままでいい

RTと言及● 言及

– 返信する必要は無いけどあるツイートに言及したい● はてブのコメントみたいな感覚

– RTしてから「◯◯と思う > RT」● RTとの連続性が切れるからよくない

–ということを言った人がこないだ炎上した

– パーマリンクがあればその内容を展開● 公式Webだと展開される

場の共有● 実況

– リアルタイムな流れに参加● テレビ● スポーツ● Ustream

– 一体感● バルス

マルチアカウント● 諸刃の剣

– ユーザ数制限がある以上、無制限には出来ない

● 気にしなければそれでもいい

● 業者でなくても10個以上使う人はいる

● UserStreamを使う場合、ネットワーク負荷に注意

Twitterそのものについて

信頼● 安定して使えるようになった

– 昔はよく落ちた● 落ちるとクライアント作者にまず文句が行く● 猫がサーバ直してた● API Status見る機会減った

● 日本では完全に定着– テレビで普通にその名が流れるようになった– 東日本大震災で信頼度が上がった

● プラットフォームとしての確立

心配事● マネタイズの問題

– どこかに買収される危惧– やっぱり無くなって欲しくはない

● 代わりが無い

– 有料API– 広告ツイート

● 使いにくくならないで欲しい– DRによる多様性の排除が、ただの競合の排除だったということでありませんように

まとめ● 作る自由も作らない自由もある

● 引き際を考えておく

● どうせならTwitterにパクられるもの作ろう

● 楽しんで作ろう

最後に

最後にこれだけ言わせて

「足あと」はないわ…

ご清聴ありがとうございました