[&] Web Directions East 2009 (Cameron Adams)

WDE2009 | Web Directions East

Web Directions East 2009
---------------------------
Cameron Adams
『Google Wave の裏舞台』Making waves

Google wave
複数の人々が同時に。
コンテントの編集。コラブティブドキュメント。
Wiki スタイル。
最初にスタートする時には慣れないかもしれません。

"Google Wave Drip s With Ambition" - MC Siegler, Techcrunch

一ヶ月間に製品がリリースされ、その前にはビデオしかなかった。
ビデオのいいところは、いろいろな質問があった。
何ができるか、いろいろ想像してもらえた。
Google Wave を使う、いろいろなシナリオがあった。
注意深い楽観主義であった。教育を変えてしまうアイデアもあった。
Google Wave はテレポーテーションじゃないかといわれた。

このような形。
Google wave のストリーについて、
そのようにデザインしていたかを。

Googel Maps からスタート ラズをエンが Mapping アプローチについて。
地図にランドスケープ、あたらしいインタフェース、地図の確信であった。
google Map のアプローチが Google wave につながっている。

3つのエリアを１つにする。
１．CENTRALISEDすべてを一つのサーバに集める。だれがどこからでもアクセスできるように。
2. DOCUMENTATION ドキュメントについて。
3. Discussion

この三つのアイデアを革新的ではない。みっつとも見たことがあるもの。
ワープロも 20年前からあるもの。

ディスカッションも、古くからある。世界中の人が使ってきた。
特に人気が出てきたのはクラウド的サービス。
これらを連結させたサービスは無かった。
一つのところで、ドキュメントをサポートし、ディスカッションできる。
別々のものをただ張り合わせたものではない。
GOogle wave はシームレスな形で、３つを一つの体験にしてあげるもの。

いろんなコミュニケーションがオンラインで

マーケットは第四四半期はどうですか？という質問があったとする。
じゃあ、ミーティングでこれらのことを話すとしましょう。
４人とか５人の人がメールで返答してきた
もしかしたらプリントアウトして、さらに仕事を大変にするかもしれません。
もしかしたら、２回目のメールをする時にミスをしてしまうかもしれません。
ミーティングの際にはリマインダを送らないといけません。
議事録をかかなければいけません。
議事録を送らないと
議事録の間違いをチェックしないと。
議事録の中からまた戦略をかいたドキュメントをかかないといけないかもしれません。
最終的な戦略のドキュメントがやっとのことで完成します。
３種類から４種類のアプリケーションを使い、

Google Wave はドキュメントが中心にあって、皆で編集する形になる。
googel wave に参加者を追加していく。
自分たちのコンテントも入れていく。
共同でレビューをつくっていく。気にいらないところがあれば、編集できる。
議事録もすぐにでき上がる。
必要な人に伝えることができる。
ミーティングの後にすぐに活用できる。
皆でチェックし、編集・修正し、確認して、最終的なドキュメントができあがる。
同じオブジェクトに皆が関与できる。
すべて履歴が保存される。
どういうプロセスでできあがったかを履歴で見ることができる。

Wave は流体になって、すぐに流れていくことができる。
今まで入っていない人が急に chat に入ってくることもできる。
今までにないこと。
リアルタイムであること。
ロボットが Wave とインタラクションするようにプログラムを書くこともできる。
自分でタイプしたものを翻訳するロボットもある。

もう一つ面白いのは、ガジェットを組み込むことができる
ガジェットを埋め込むと、Sudoku を何人かで遊べる。
非常にパワフル。
ドキュメントだけではなく、アプリケーションになりうる。簡単！

"Google Wave : Finally, Innovation" - Waveomatica

Wave イノベーションがキーワード。
企業の武器として使われている。
経済学者は違う言葉を使うかもしれない。

AWESOMENESS として使うべき。
四つのエリアを説明します。

ETHICAL PRODUCTION
倫理的なモノづくりをする。

INSANELY GREAT
社会の人々が欲しいと思わせるものをつくらないといけない。

LOVE
クリエイターの「愛」
Apple Store の例のように。Apple が好きな人たち。

THICK VALUE
価値のあるものをつくらないといけない。
人々が利益を得られるようなもの。

AWESOMENESS の色になる。
インスパイアされるようなプロダクトをつくる。

インベーション = AWESOMENESS

Goole で働いている、三つのエリアがある。
一つ目は、新しいアイデア。 (jagolive)
IDEAS
考えを歓迎する風土。アイデアを使ってもらえる社風。
wave は３−４人でつくったプロトタイプから始まった。
ラリーとセルゲイに提案する時があり、
アイデアに共鳴する人を引き込んでいける。
自分が働く職場を信頼できることはアイデアをいかしていける。
アイデアを歓迎する文化を関係するには、
すべてのアイデア、会社をダメにするアイデアも聞かないといけない。
競合にはできないアイデア、企業をひっぱっていくアイデアが必要。
アイデアを最大限活用する。

EMPOWER
従業員への権限委譲。
20% ルール。一週間で１日好きなことをしていい。
従業員にたいして、権限委譲をしている。
新しいアイデアを思いついて、それに使える時間がある
そのアイデアをもとに行動する権限が与えられているということ。
いいだしっぺであれば、チームリーダーになれる。
新製品のような大きなものではなくても、新機能のようなものでも。
うまくいくようであれば、もっと人的資源も追加してくれる。
そこからどんどん進展していく。

RISK
リスクをとれないとイノベーティブなことはできない。
Google では小さなリスクをとっていく。
革新を共有して、最初は小さなものをつくって、
うまくいくことがわかってから、次にいく。
まずはプロトタイプから。１万ユーザー〜10万。１００万。
小さくすすんでいく。途中で問題があれば、撤退できるようにしていく。

DESIGNING INNOVATION

PATTERNS
デザイナーであるからには新しいパターンを扱わなければいけない。
何かと何かを比べて、何がうまくいくのか、以前うまくいったのは何なのか。

Web のデザイナーとして実績をつみかさねていくと、パターンが蓄えられる。
建築や、テキスタイルのパターンを Web デザインにいかしていくことができる。
心の工具箱から、一番いい道具を出していくことができる。

何か問題があった時にアプリケーションの機能をつくりたいときに、
そのパターンにあうものを探す。
まずは２つの分野で比べる。
どれだけ発見できるのか、人が新機能を見たときどれくらい認識できるのか。

もう一つは効率性。
その機能を知っているひとが、どれだけ使えるのか。

よくあるテキストボックス。
そこにテキストボックスがあれば、そこに入力すればいいことがわかる。
一見してすぐ使うのかがわかる。
効率性も高い。

このパターンを何かほかにあてはめられうのか？
テキストボックスがブラウザの上の方にあれば、検索ボックスになる。
そのようなパターンを一つの領域からほかの領域にいかせる。

ラベルつきのテキストボックスは効率に関しては下がってくる。
このパターンをあてはめようとすると、期待するほどの効率は無い。
Safari 風検索ボックス、ラベルが無くてもアイコンがあれば、検索できることが理解できる。
見つけやすさも高く、効率もいい。下がった効率を回復させることができる。

graph上のどの位置にするのか考える。
一年に１回しか使わないのか、一分に１回使うものなのか、
それによってパターンが決まってくる。

ちょうどいいもの。
iPod はさまざまないい要素がある。
MD player は旧来のパターンが活用されている。
MP3 player は数千曲が入っているので、旧来のパターンは使えない。
ドラムマシンでは、ジョグダイアルで音を探す。
さまざまなデータが入っている中から探せる。ハイエンドオーディオを参考にした。
効率が高いかというと、まだまだ。

wave の中ではどうやっているのか？
メッセージが３つあったとする。
メッセージ１から入ってくる。
ほかの人が wave に入ってくる。
E-mail できないことは、別のスレッドから続けることができる。
ブランチをつくることができる。
かなり長いリプライになってくる。
どのメッセージにどう答えればよいのか？
すべてのリプライにメッセージを返すのではうまくいかない。
実際にどのメッセージに返答しなければいけないのかわかりにくい。
すべてにたいしてリプライボタンがあるではうまくいかない。
こういった会話はかなり複雑になる。
実際にデザインする時に簡単に使わなければいけない。
　Continue というボタンをつくったが分かりにくい。
　Indicator をつくった。次のメッセージがどこなのか
その方が効率性は高いが、発見性は低い。
簡単に使うことができて、すぐに見つけることができるのか？

Discoverability vs. Efficiency

User Testing
このデザインができた。
革新的なデザインはかなりのテストが必要。
初めてのものをどうテストするのか？どうやって適切なものを見つけ出すのか。
最終的には、たくさんの人がこのデザインを好きになってもらえるのか？
E-mail でもメッセージングでもないものをどうテストするのか？

新しい Facebook のデザイン。
なんでデザイン変更するのか怒った人がいる。
何もしなければ、何も発展しない。

"Change is good, And change makes us angry" - Ben Parr, Machable

実際に変更かけることは最終的にはいい結果がまっている。
ヘンリフォードがいうには、
人はもっと速い馬が欲しいといった。
ユーザーテスト 18月かかった。

まだ製品としては立ち上げていない。
18月としては製品のテスト期間としてはまずまず。
実際に商品として出す前に 18月必要であった。
チームが 50人くらいいた。
何がうまくいかないのかを話し合った。
プロダクトにアクセスできるよう準備しなければいけない。
どのように活用できるのか、もう一度確認し、発見する。

まだユーザが難しいと思うことに対応しなければいけない。
当然編集する時間、ドキュメントクライアントはどうだろう？
チャットがある、ドキュメントがある、それがもともとのアイデア。
何かをしなければ、革新性はもてない。
疑問に思うことはあるかもしれない。
あまりにやり過ぎると、危ない目にあるかもしれない。
新しいものを出すと、慣れるための時間が必要になる。
気をつけなばいけないのは、重要なものを見逃さない。
古いものがなくなって、混乱を招くかもしれない。
ユーザーが気に入ってくれればいい。
基本がきちっとしていなければいけない。

ユーザーの体験。
「wave はがっかりだった。しばらくやってみたら、
まだ wide リリースになっていないので、がっかりした」cole camplese

wave は世界を広げたと思う。
我々にとって怖いプロジェクトでもある。
100% ユーザに問題がものにはできない。
製品を使ってもらって、体験してもらうしかない。

「最初から新しいものは難しい、
　最初は半分くらい、その後広げていけばいい」 - Richard Gabriel

どれぐらい人々が気に入るかは出してみないとわからない。
使わない人や、気に入らない人もいるかもしない。
60億の一部に気に入ってもらえればいい。
出る杭は打たれる。
我々は非常にすばらしいことをやれば、批判はついてくる。

Twitter, 始めはだれもついてこなかったが、
今は皆が受け入れている。
wave も twitter のようなもの。

wave クライアント、プロトコルとしてリアルタイムでメッセージを交換する、
オープンソースの wave プロトコルでリアルタイムにコミュニケーションする。
より良い wave クライアントを誰かが使うかもしれない。

wave クライアントがたくさんでてくるかもしれない。
たくさんの wave クライアントのための種をまくしかない。
すべてのコミュニティが wave を背景として成長して欲しい。

ぜひ皆さんも自分たちのアイデアをまいてほしい。
11/27 wave Hackason が開催される。