Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

0 views

Published on

  • Be the first to comment

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

  1. 1. Twitterクライアントがこの先生き残るには #twtr_hack @s17er 2013/2/1
  2. 2. 自己紹介@s17er / 佐々木シンイチJanetter for AndroidJava / Python / JavaScript / etc...
  3. 3. Twitter API 1.1 2013/3/5
  4. 4. 対応してますか?
  5. 5. エンドポイントの変更● 呼び出すURLが変わる – http(s)://api.twitter.com/1.1 – 変更されているものも ● /blocks/blocking/ids → /blocks/ids
  6. 6. エンドポイントの変更● 廃止されるAPI – クライアントの仕様変更が発生 ● 他人がリツイートしたツイート一覧 ● 特定ツイートをリツイートしたユーザ一覧 ● タイムラインでリツイートを受け取らないユーザ一覧 ● ブロックユーザ一覧
  7. 7. 検索ツイートの構成変更● 通常ツイートと同じになった – 公式RTと非公式RTが区別できる ● ミュートしやすくなった ● 検索と他のタイムラインの場合で処理をわけなくも よくなった
  8. 8. レートリミットの変更● エンドポイントごとに回数制限 – 15分ごとに15回 – 例外的に15分ごとに180回叩けるものも ● search/tweets ● status/show/:id ● user/lookup
  9. 9. 15分に15回?● すぐにリミットに到達する● 特にリストはヤバイ – エンドポイントはリスト毎ではない ● lists/statuses?list_id= – リスト5個を同時に更新できるのは15分に3回 ● リストをたくさん管理している人は更新間隔長くなる
  10. 10. Display Requirementhttps://dev.twitter.com/terms/display-requirements
  11. 11. Display Requirement● ツイート表示に関するルール – 表示すべき項目が細かく規程 – 相対時刻 – 名前とscreen_name併記 – リプライ、リツイート、お気に入り追加のボタン – リツイートの場合の表記 – Twitter Birdをタイムラインに表示● 一行表示型が出来なくなる (tweenなど)
  12. 12. 1.1に対応して待ち受けているもの
  13. 13. ユーザからのクレーム● screen_nameの左に@はいらない● 時刻の相対表記は分かりにくい● Twitterの鳥が邪魔● 前のほうが見やすかった、何故変えた● すぐにAPIの利用制限に到達する
  14. 14. クレームに負けずにサポート頑張りましょう
  15. 15. サポートの難しさ● 先行して対応したと言っても、 – 「他のクライアントでは出来るのに!」 – 3/5までギリギリ待つほうが得策?● API 1.1の変更やDRについて説明… – 一般の人に砕いて説明するのめんどくさい – Twitter公式での説明は英語 – あまりTwitterのせいにしすぎると逆に反感買う● 解決できることではないので、結局「星一つ!」になる
  16. 16. それに耐えたとしても…
  17. 17. これ以上、ユーザーを認証できません
  18. 18. アプリごとのユーザ数制限● 新規参入の場合、10万ユーザまで● 10万を超える場合は、発表時点(2012年9月頃) のユーザの二倍まで – 制限に達するとそのアプリ(Consumer Key)での ユーザ認証が出来なくなる – 一回認証していても、再認証不可 ● アクセストークンを取得するAPIが使えなくなる ● 再インストールしても再認証できないケースが
  19. 19. アプリごとのユーザ数制限● 到達したクライアントたち – Tweetro (Windows 8) – ShootingStar (Android) – Twitcle (Android)
  20. 20. アプリごとのユーザ数制限● クライアントビジネスの終焉 – 新規参入にメリット無し ● ユーザ数の上限 ● サポートコストはかかる ● 10万ユーザでうまくマネタイズできれば… – 既存クライアントは既得権益にしがみつけ
  21. 21. アプリごとのユーザ数制限● 開発者のモチベーション低下 – 多くの人に使って欲しいから開発する ● 上限設定で先が見えてしまう – これまでのTwitterとの信頼 ● サードパーティと共に成長してきた ● 信頼と文化の否定、別の価値観の押し付け
  22. 22. 回避策はないか?● バージョンをたくさん作る – 2013年春版、2013年夏版… ● 同じアプリばっか作るなってストアから怒られそう ● そもそもTwitterの規約で禁じられている – 機能ごとに無料版、100円版、200円版… ● source名どうするのか? ● 100円版から300円版にアップデートする場合は? ● せいぜい数種類が限界
  23. 23. 暗黒面に堕ちますか?● ConsumerKeyのラウンドロビン – ConsumerKeyをサーバで管理 ● アプリ内にキーを持たない – ユーザ制限に到達した時点でキーを更新 ブラックです! もはや倫理の問題
  24. 24. 一応iOSはなんとかなる● Twitter Framework (iOS SDK) – ユーザ数の制限気にしなくていい ● AppleとTwitterと喧嘩しない限り安心 – sourceはiOS – 現状、REST APIしか使えない ● モバイルなら許容できる – DMが扱えない
  25. 25. 他のプラットフォームの サードパーティ製 Twitterクライアントは座して死すのを待つしかないのか?
  26. 26. サードパーティの排除● およそ二年前からTwitterはそういう方針を打 ち出していた● 今更騒ぎ出した所で遅い● 先見の明があれば足を洗っているはず
  27. 27. 受け入れよう
  28. 28. 世の中に不満があるなら自分を変えろ!それが嫌なら、耳と目を閉じ、口をつぐん で孤独に暮らせ!
  29. 29. 結論● Twitterの方針変更を待とう – 待てるのならば● ビジネスでやるのはやめよう – 限られたユーザ、ニッチを攻めるならアリ● 趣味でやろう – 悪ノリしてBANされてもネタになる
  30. 30.
  31. 31. それでもTwitterクライアントを 作りたい
  32. 32. これからTwitterクライアントを作る上で 考慮したいポイント
  33. 33. タイムライン● リアルタイムでのタイムライン更新 – Streamは公式Webでは使えない ● 専用アプリの強み – モバイルはRESTのほうがよい – あまり流速が速すぎると読めない ● 適度にさっぴく ● 同じRTは一定時間表示しない ● 表示ユーザの調整(グルーピング)
  34. 34. ユーザのグルーピング● 今まではリストで振り分けていた – リストにはStreamがない – レートリミットにより実用でなくなる● ミュートユーザー機能 – ピンポイント – リムーブの代わり(大人の事情) – グルーピングとはちょっと違う
  35. 35. ユーザのグルーピング● レーティング、タグ付け – 状況に応じて、特定タグユーザを表示/非表示 – 星3つ以上のユーザだけ表示 – 俗に言う「タブ分け」に近い ● 一つのタブで切り替えるか、複数タブで見るか の違い – そのグルーピング情報を共有できると便利 ● TweetMarkerみたいなゲートウェイサービス
  36. 36. ホットな話題を追いかける● トレンド – ニュース性 ● トレンド一覧だけでなんとなく何が起きてるか分かる – 勢いとかランキングとか ● クライアントで集計● その日のトレンド – API廃止されてしまった – 独自集計● タイムライン内のトレンド – ハッシュタグ大喜利とか興味無い人とか
  37. 37. 雑音排除● 目にしたくない言葉 – ワードでミュート● スパム、BOT – sourceでミュート● 初見でも目にしたくないユーザ – 思想が違う人 – いろいろ面倒と感じる人 – アイコンでミュート – ワードでミュートされたらそのユーザもミュート
  38. 38. 知能的な情報集約● 興味ある人のツイートを集約 – フォローしている人の発言を効率よくまとめる ● フォロー=興味ある – どうでもいい呟きは弾く – たくさん出る話題、URL、RTをまとめる● その日の話題になったツイートも集約 – トレンドに上がった発言をまとめる● クライアントだけの領域ではないんじゃないの? – ただAPIを叩くだけじゃ生き残れないのではないか
  39. 39. コミュニケーション● 返信 – in_reply_to付き – 引用返信 – 複数返信● DM – もう必要性が薄い? ● Twitter自身、不要と思っているフシが – LINEとかSkypeとかFacebookに任せようか● ふぁぼ – なるべく近寄らないようにしよう
  40. 40. RTと言及● 公式RTによるデマ拡散 – RT制限回数を設けては? ● 人の口には戸は立てられぬ ● 代わりにWebとかでやるだけ ● 公式にある機能の制限は反発を生む – クライアント側で受け取るRTの制御
  41. 41. RTと言及● 非公式RT問題 – 会話が追いかけづらい ● in-reply-toつけると公開範囲が狭まる – USの”replies=all”で、フォロワーへの返信を全部取る ● 有名人をフォローしているとその人への全リプライが流れて くるので負荷が高くなる ● in-reply-to付きでも、@の前に文字があれば全員に公開 – 公開返信として機能化しては ● 返信の種類多すぎる… – 話題にするとたいてい荒れる ● 機能を削除すると炎上 ● 思想が無いなら、そのままでいい
  42. 42. RTと言及● 言及 – 返信する必要は無いけどあるツイートに言及したい ● はてブのコメントみたいな感覚 – RTしてから「◯◯と思う > RT」 ● RTとの連続性が切れるからよくない – ということを言った人がこないだ炎上した – パーマリンクがあればその内容を展開 ● 公式Webだと展開される
  43. 43. 場の共有● 実況 – リアルタイムな流れに参加 ● テレビ ● スポーツ ● Ustream – 一体感 ● バルス
  44. 44. マルチアカウント● 諸刃の剣 – ユーザ数制限がある以上、無制限には出来 ない ● 気にしなければそれでもいい● 業者でなくても10個以上使う人はいる● UserStreamを使う場合、ネットワーク負荷に 注意
  45. 45. Twitterそのものについて
  46. 46. 信頼● 安定して使えるようになった – 昔はよく落ちた ● 落ちるとクライアント作者にまず文句が行く ● 猫がサーバ直してた ● API Status見る機会減った● 日本では完全に定着 – テレビで普通にその名が流れるようになった – 東日本大震災で信頼度が上がった● プラットフォームとしての確立
  47. 47. 心配事● マネタイズの問題 – どこかに買収される危惧 – やっぱり無くなって欲しくはない ● 代わりが無い – 有料API – 広告ツイート● 使いにくくならないで欲しい – DRによる多様性の排除が、ただの競合の排除 だったということでありませんように
  48. 48. まとめ● 作る自由も作らない自由もある● 引き際を考えておく● どうせならTwitterにパクられるもの作ろう● 楽しんで作ろう
  49. 49. 最後に
  50. 50. 最後にこれだけ言わせて「足あと」はないわ…
  51. 51. ご清聴ありがとうございました

×