夜フクロウの作者さんがからまれてた RT 問題を考えてみる

私は Twitter クライアントに夜フクロウを使わせてもらってるのですが、RT の仕様に準拠した修正に誰かが噛みついていた模様。詳しくはこちら
ややこしい問題だったとはいえ、フリーソフトの開発も大変です。ユーザーはフリーダムですからねぇ……


非公式 RT は自身のポストの中の文字列で処理していたお手軽仕様*1ですから、その用途は設計者の意図とは別に多岐に渡ってしまっていたはずで、その全てを公式が網羅せず策定してしまえば、まあ、「いやオレの使い方と違う! 何で出来なくなったんだ!!」とか「公式こそが絶対正義!」とか、阿鼻叫喚の混乱が発生しますねぇ……Twitter も例に漏れなかった、と。
システム屋さんはよーく知っているはなしかと思いますが、システム化の段階でどっかの意見だけ聞きながら「えいやっ!」って決めた仕様は、たいてい後々各方面から叩かれて仕様変更の要求の嵐に呑まれる、と。……南無。


と、悲嘆に暮れていても仕方ないので(たまにはシステム屋さんらしく)ちょっと細かく非公式 RT の使われ方を分析してみました。

RT を周知のために使っていたよ!

この用途は公式 RT が完全にサポートしているモノですね。
公式 RT は非公式 RT とは異なり

  • 元ポストの保全(ソース元への到達容易性)
  • 不要ポストのフィルタリング

もサポートしており、この用途についてはかなり優れた仕様に落ち着いているのではないでしょうか。

RT を同意の意味を込めて使っていたよ!

実質的には「弱い Favorite」のような感じでしょうか。もっと手軽に Favorite されるようになればいいものでしょう。
とはいえ「そう利用されていない」という事実を踏まえれば、もっと Favorite してもらえるように Favorite アクションに応じて何かを TL に残す「事も出来る」ような機能強化がいいかもしれません。
公式 RT でもいけるような気もしますが

  • Favorite する人は発言者に近いはず
  • Favorite は当人に伝わるのが最も嬉しいもののはず

と考えれば、公開 TL ではなく Replay な動きがいいかもしれません。

RT はその話題に関して触れる時に使うものだよ!

Replay 使える局面では Replay で済むはずのところですが、Replay が届くのとは異なるクラスタ(Replay より広いクラスタ)に発言したい場合もあります。つまり、その話題に関わるグループに一時的に混ざりたい場合、もっと人をこの話題に巻き込みたい場合ですね。
多段 RT の原因もこのあたりにあるんじゃないかと思うのですが、フォローしたりされたりする関係まではちょっと……でもこの話題については混ざりたい、もっと話を聞きたいという感じ。飲み会とかで、知らない人とたまたま話があって、話が弾んでいる状態とでも言いましょうか?
そして、他者を巻き込む、という点で話題の流れを分かってもらえる事が重要ですから、会話が長々と引用される、という形になるわけです。

で、これの実装ですが

  • 要件からすると、関連する tweet が「一覧することもできる」ようにできればいいはず
  • 公開 TL 上は当人の発言だけに収めた方が簡便なはず
  • 発言の TL を別に組み上げる事を出来るようにしないといけない

ですから

後付けハッシュタグを作る

Twitter には一時的に発言をクラスタに所属させる機能としてハッシュタグがありますから、これに統合するのが自然といえば自然です。ただ、一時的な話題にどうナイスなハッシュタグを振るのかは難しそうです。

ジョインするタグを別に作る

togetter のように特殊な TL を発言しながら編纂・表示できるようにする。ある tweet がジョインされたらその元の tweet のジョインリストに加わって行くような仕様?
in_reply_to_status_id のリストのようなものを返す API 用意するからクライアント側で何とかして、とかの無茶振りでもギリギリいいかもしれません。


システム屋さんの頭で思いつくのはこんなところでしょうかねぇ。後は工数を見積もって4倍して……(ぇ

*1:RT は生まれが Twitter クライアントのカスタム的なものだったようです