昨日のSIGHCIのメモです。

最速インターフェースの研究と実践： ライブドア mala氏

まず、自己紹介を兼ねて概論

• ブログ「最速インターフェース研究会」
  • WebのUIの進歩の停滞に対する批判を込めて名付けた

• 自分の肩書きは「インターフェースエンジニア」
  • よいUIを作るために「実体験に基づいたチューニングをしている」
  • 自分で使ってみる
  • ユーザの反応を見る
  • 欲望に忠実に作る
  • 作業としては、perl, html, jsの記述

「実のところ、プログラミングに詳しいと言える自信はないし、デザインのことも深くはわからないが、一人で一通りこなせる（完成品を作れる）という点は自分の強み。

よいUIを作るための作業は横断的。割り当てられた仕事をするだけの人ではダメ。」

作品紹介

• 2ch最速検索
  • キーボード操作だけでスレッド検索
  • まだAjaxは使っていない
  • 「めくり型」UIの実験
  • スクロールしながら読むより、ページ単位で切り替えた方が読むのが速いのではないか
  • 「めくり型」は、DHTMLがあってこそ実現できた

• Wikiエンジン「Mirrorman」
  • jsを活用したWikiクローン
  • 組み込みチャット付き
  • 自分以外に誰が見ているかがわかる機能

• ブログタイトル検索

• Amazon最速検索
  • JSONP使用（当時としては先進的）
  • アサマシでけっこう儲かりました

• Google Autopager
  • ページの最下部までスクロールしたら、自動的に次のページを継ぎ足す
  • 設計思想
    • ページの最下部までたどり着いたユーザーは、次のページを見たいはずだ
    • ……本当に？
    • 今のページを消して次のページに移動してしまうと、その予想が万が一間違っていた場合のコストが大きい。今のページを残して「継ぎ足す」方式なら、そのコストは限りなく小さい
    • ほとんどのユーザは、「次へ」をクリックするコストに気づいてすらいない。 そのコストに気づけるかどうかが重要

• ブログ全文検索
  • データを全て送りつけて、クライアントサイドで検索
  • 人間の書いたテキストの量なんて大したことない

• ここでGreasemonkeyの紹介
  • （ここを読んでいる方は知っていると思うので、略）
  • LDRize や AutoPagerizeの紹介なども

• JSでQRコード生成
  • お遊び。

• Google Readerクローン
  • Google Readerとかいうのが出てきたので真似してみた
  • Lensのアイテムをクリックすると、勝手にスクロールするところが面白い。同じところをクリックしているだけで次々読める。
  • LDRのマイフィードにも反映。

(注: 当時、Google ReaderはLensと呼ばれるUIを採用していましたが、現在は廃止されています)

• ここでlivedoorに入社

ここまでニートだった。Greasemonkeyのおかげで、ニートでもUIの開発ができる。サーバ等を運営する資金力は要らない。

「livedoor Reader」

• LDRの思想
  • 速く読める
  • たくさん読める

• LDRの統計情報
  • アクティブユーザの購読数 平均231Feeds
  • 中央値 132Feeds
  • 501件オーバーの人が10%もいる
• 一般的なユーザ
  • japan.internet.comによると、5Feeds以下が50%？　……らしい

• なぜ、そこまでこだわるのか？
  • 大量に読むことで、コミュニケーションのヒントになる。「きのうこんな記事を読んだ」「こんなコメントを書かれた」等、共通の話題になる。
  • もし、それがないと…　「いい天気ですね」「お元気ですか」　凡庸な会話に終始する。
• 現在のコミュニケーションのベースは、2chや有名サイトなどの、誰かがセッティングした「場」
  • ROMが多い。
  • 2chは一つの板あたり500-1000スレッド。これは、ぜんぜん足りてない。漏れている話題がある。みんなが流行に走る。
  • 流行に走るのはつまらないという中二病的動機
  • ブログを取り巻く技術が進化すれば、自分のブログをベースにコミュニケーションができる。
  • ブロク検索エンジン、ソーシャルブックマーク等。
  • 「大量に読めるツール」を使うことで、誰が何を書いているかちゃんと把握できる。「自分の場所」同士がつながる。「場」＝「有名サイト」依存からの脱却。

• コミュニケーションを増やす方法
  • 1. 効率の良い出会いを提供する
  • 2. 大量の情報をインプットしてマッチする確率を増やす
  • LDRは 2. のアプローチ。「情報を大量に集めてふるいをかける」賢いネット世代を作りたい。
  • サーバでフィルタするんじゃなくて、あくまで人間が手元で振り分ける。

LDRの技術面

• 概要
  • キーボード
  • 先読み，キャッシュ
  • 思考を妨げないUI

• キーボードショートカット
  • 「j」キーに隠された、ちょっとした工夫。本文が短い場合は、ページ下部にわざと余白を入れ、見出しの位置を無理矢理ページの最上部に持ってくる。
    
  • 注視点を動かさずに見出しを見られる。
  • 実は「とほほ」がヒント → http://www.tohoho-web.com/js/other.htm#objScreen

• 先読み
  • Bloglinesを使っていた頃は、遅延を気にしながら操作していた。現在のページを読み終わる前に、手動で先読みする癖が付いた。
  • LDRでは、先読みを機械でやる。「次へ進む」動作の高速化。一瞬の「間」も許さない。

• キャッシュ
  • 「前へ戻る」動作の高速化

• 「ピン」でまとめ読み。
  • ロード時間の短縮

• 思考を妨げないUI、左ペイン（マイフィード）の特徴
  • 単純なフォルダ分けだと、今並んでいる順番以外で読むのが面倒。
  • LDRではソート/分類の方法を切り替えられる。読む順番を好みで決めて，ソートを機械にやらせる。
  • 次に読みたいフィードを探す手間を省く。

• ところで、みんな設計通りに使っているのか？
  • キーボードを使ってないユーザー 55%
  • 平均を見ると、キーボードを使っているユーザーは、使っていないユーザーの倍購読している

• 自分は、現在3742件
  • ちゃんと使えている。
  • 人間の能力の限界には達していない。ソフトがよければ何千件でも読める。

余談

• Bloglinesの次期版について
  • やっぱり先読みしていない。
  • 入力に対してなんか変化がすぐ返ってくるけど、全て完了するまでは遅い。
  • 体感速度重要。「ロード中」のアイコンが一瞬で返ってきても嬉しくない。
  • ユーザーは待ち時間をあきらめている。開発者が気づかなきゃいけない。

• ユーザーのリズムを大事にする
  • 速すぎず、遅すぎず。リズムにマッチする工夫。livedoor Readerの「ウェイト調整機能」はその実験。
    

• CLI、コマンド指向
  • プログラマの特権だったものを一般の人にも（強引に）広めよう

• 目的に特化する
  • 誰でも使える　は正解だろうか？
  • 10%の人に100%マッチする製品がたくさんでてくると、100%の人に50%マッチする製品は生き延びる余地がなくなる。
  • 特化しなくては生き延びれない。
  • ソフトウェアの世界は、特化戦略をやりやすい。現実世界（ハード）は、コストの問題もあってバリエーションに限りがあるが、ソフトウェアならその制限はない。

• APIを公開せよ
  • はてなグラフの例
  • デザインをかわいくする？ 有名人に使わせる？　→常套手段だが、失敗
  • APIを公開したことで、手で入力する手間が省け、可能性が広がった。

• プロトコルが確立されると選択肢が広がる。
  • RSSってなんでうれしいの？ → LDRで読める！
  • 「食材を独占し、料理がまずいレストラン」　料理がまずいことではなく、食材を独占していることを批判せよ。「俺が作ってやる」