11/18/2009

[&] DESIGN IT Conference 2009 (Google UX)


DESIGN IT! : イベント

DESIGN IT! Conference
-------------------------------
立ちこめる暗雲 - Web サービスとクラウドコンピューティングにおける課題をかんがみる
Google UX Researcher - Donal Mountain
Google UX Designer - Braden Kowitz

注:UX専門家としての発表で、Google の公式見解では無い

1. クラウドはいつでも利用できます。
2. クラウドは安全に利用できます。
  書類をなくしたり、壊れたりしてデータを無くすことが無い。
  違うノートパソコンでもおなじ作業が続けられる。
  思い出を次の世代に残せる
3. クラウドはみんなで利用できます。
  クラウドは共同作業の場になります。
  FAX は、紙を送るだけで根本的な違いはない。
  クラウドは新しい方法で、ドキュメントをオンラインで一度に変更できます。

Challenges Ahead - この先に進んで行こう。
 どういった要因がクラウド化を妨げているのかを認識することが大切

DM: UX の仕事。ユーザーを理解する仕事をしている。
製品をどうやって使っているのかを理解する。
BK: いろいろとプロトタイプをつくって、ストーリーをつくっている。

さまざまな課題に対する回答があるわけではない。
シリコンバレーのさまざまなところで調べた情報を伝える。

1. Always Available : いつでもつかえる
2. Safe : 安全に使える
3. Collaborative : みんなで使える

世界の貧困に立ち向かう非営利団体、世界中で活動するのに
クラウドは最適な回答。
ガーナで活動していて、クラウドの持つ問題に直面。
インターネットにつながらなかったり、遅かったりする。
ネットの復旧を待たずに作業を続けなければいけない。
ガーナの回線速度は東京の 1/400
実はネットが必要なのはデータを送受信する時のみ。

このプレゼンテーション自身もクラウドに保存されています。
ネットにつながっていなくてもプレゼンテーションできなければいけません。

ネット接続が万全でもサービスの予期せぬ停止もありえます。

Challenge #1
Works offline
オフラインでも使えるように
オフラインアプリはつくることができる。現在は少々難しいが。
ブラウザの中に多くのデータを置かなければいけない。
オフラインで使いやすいブラウザ (Gears, HTML5)
ブラウザ自身がオフライン作業に適していない。

オフラインで稼働するウェブ
Gmail のオフライン版でできる作業とできない作業があることを認識してもらう。

1987年に登場した HyperCard はさまざまな利用方法で愛されたツールでした。
Apple は HyperCard の販売を停止したが、ユーザーにとっては大きな問題では無かった。

クラウドと比較してみます。
magnolia はブックマーク共有サービス。
magnolia はバックアップからの復旧がうまくいかず、サービス自体が停止してしまった。
これがクラウドアプリと、デスクトップアプリとの違いになる。

Challange #2
Data Portability
データポータビリティ
ユーザーはデータの所有権を持つべき。
データをまとめてダウンロードすることができる。
クラウドからローカルにデータをダウンロードするアプリがある。
違うアプリを使えるように。
iPhoto から LightRoom へデータを移行。
 ハードディスク上にデータがあるので、容易にデータを移行できた。
クラウドだったらどうする?
Picasa web から Flickr へデータを移行する時には悩むことになる。

サービスが Open APIをもっていれば、間をつなぐことができる。
情報の移行だけでなく、ユーザに選択肢をあたえ、満足感につながる。

手元に物理的にデータを持つことは安全に思える。
手元におきたいというのは人間的な欲求。
安全な感じはするが、新しいハードディスクの 2% は故障し、交換が必要となる。
米国ではあたらしいノートパソコンの 10% は盗難にあう。
ノートパソコンに飲み物をこぼすこともある。
手元にデータを置いたとしても、データの消失はありえる。

2. Safe : 安全に使える。
これがクラウドにおける大きな可能性「安全性」
データを手元に置くのは短期のプロジェクトでは良いが、長期的にみると良いことではない。
銀行とお金に似たようなこと。安全性の確保につながる。
大昔は手元に金貨を置き、人に預けるのはおかしいこと。
 これが現在のクラウドの状況。
時を経て、金貨ではなく、価値を表す紙幣に移行した。
近年では、オンラインで銀行口座をチェックするようになった。
お金を預けることによる安心感と同様にクラウドにデータを預ける。

すべては信頼を表している。
昨今、銀行が危機におちいった場合、現金を引き出して手元におこうとする。

クラウドにおける信頼性
例:100分の Gmail サービス中断
その間、多くの人がメールにアクセルできなかった。
また、ホワイトハウスのメールが停止したことがあった。
こういった問題は起こりえる。
クラウドはデータを保存していて、安全だと考えている。
多くの人がサービスが中断しないよう努力している。
この先 10年を考えるとサービスの中断は起こりえることである。
業界としてサービス中断にたいしてどう対応していくか。

ほかの重要な業界から得た教訓を取り上げてみましょう。
2008年 BA 38便、突然空から落ちてきた。
なんとか飛行場にたどり着いた。
「それでも僕たちはおなじ飛行機で東京に飛ぶ」
信頼して飛行機に乗ることができた。
なぜ命を預けるまで信頼しているのか?
航空業界は信頼が重要であると認識している。
事故に関する情報が公開している。情報の公開は信頼を生む。
航空機のブラックボックス:間違いから学ぶ。
クラウドも問題の原因解明、探求、共有で、クラウド業界の信頼性をあげることができる。

サービスが 100% 稼働していて、間違いがなくても、
信頼は努力して得なければいけない。
その一つが「パスワード」
もしパスワードを忘れてサービスを利用できないことは、ハードディスクが壊れるのとおなじ。
パスワードを他人が持った時は、ノートパソコンが盗まれたこととおなじ。
パスワードは UIの中で大きな課題。

Twitter 内部資料の漏洩。
ペイリン元副大統領候補のメール漏洩

Challenge #4
セキュアなアカウント
企業向けソリューションとして、1タイムパスワードのトークン
トークンは堅牢で安全な解決策である。

一般人へのソリューションとはいいがたい。
一般の人がどうやってパスワードの安全性を確保できるかは、大きな課題。

3. Collaborative : みんなで使える。
新しいコラボレーションの形。
広がるコラボレーションの形。グーグルだけではなく数多くのサービス。
コラボレーションの良さはコンテンツを作り出すことにある。
文章作成だけでも難しいこと。Google Document
文章をつくるだけでもブラウザ上で行うには難しいこと。
 フォントや印刷の問題が難しいこと。
どうしてこれだけ苦労して、こういった問題が解決していないのか?
一つの要因:ブラウザはそのために設計されていないから。

Challenge #5
コンテンツ作成。
現状、オフラインでコンテンツを作成して、オンラインにアップロードするのが普通であった。
これからはオンラインで品質の高いコンテンツをオーサリングするのが普通になる。
将来は Web 上でビデオの編集、写真の画像加工などができるようになる。

ウェブは共有を簡単に共有にできる。
すべてが URL なので、URL を送るだけで情報を共有できる。
同時に共有するのは複雑なことである。
 個人情報を間違えて公開してしまうのは良くあること。

Challlenge #6
共有のコントロール。簡単、わかりやすく、必要な可能性を合わせ持つインタフェースをつくる。

まとめ
いつでも使える、安全に使える、みんなで使える。これがクラウドの価値。
クラウドのいいことばかりではなく、課題や挑戦も語りました。
みんなでクラウドコンピューティングに挑戦し、インターネットをいいものにしていきます。

11/13/2009

[&] Web Directions East 2009 (Deborah Schultz)

Deborah Schultz | Web Directions East



Deborah Schultz
Put People First『まずは人が重要!』
The Impact of the Social Web on Business
http://www.deborahschultz.com
-------------------------------------------------
これは HTML5,4,3,2,1 のことではないです。
デザイナー、デベロッパーとして企業のためにどう web サイトを用意するか?
橋渡しをする役。
Web に情熱をかけています。
P&G での経験もあります(広告)

実世界で人々がどう行動するのか?
旧来は物理的に近い位置にいる人としかコミュニケーションがとれませんでした。
新技術を活用になり、人々のコミュニケーションがかわり社会環境が変わってきました。

Flickr では写真をつかって体験供与する、写真を使って会話が広がる。

「インターネットにより人同士の会話が可能であった、
 マスメディアでは不可能なコミュニケーションが可能になった」
世界が変わりつつある。
どうやってチャンスが変わりつつあるのか。

But are these reelationships "real".
現実のモノなのか? 答えは [ YES ]
私の生活に多くの深みと価値を与えてくれています。
でもどのオンラインの連絡先がいつ手助けしてくれるのかわからない。

残念ながらビジネスというのは階層的な構造をしている。
かなり構造が分かれている。
We are organic and social
オンラインでももたらすことができる。
Social Web といのは個性の爆発でもある。
以前には考えられなかったようなチャンスが広がってきている。
チャンスの規模は大きい。
Twitter でスピーチの前に助けに求めたら、すぐに返答があったり。
このような情報の流れをスムーズに構造するのは何か?

visualcomplexity.com
さまざまな情報が表現されている。

考えようによっては、常にネットに接続している。
環境を構築する経済。
マスメディアの時代には無かったようなチャンスに恵まれている。
個人で実際に市場で買い物をする、昔に戻ったともいえる。

では、social web とは何?
私にいわせれば、古いコンピュータでもないし、数多くのサービスでもない。
技術そのものではない。
social media とは何?
アメリカ的なものとしては売りつけるものでは無い。「関係」なのです。
企業が顧客の存在なしにはなりたたないもの。

今われわれが生きているのは「関係」の社会。
関係の中からチャンスが生まれる。
グランドジェスチャーの終演。携帯電話の会社がいっぱいある。
こういった企業は自分たちの都合で顧客に対応する。
長い間、自分たちで販売したいものを売る。広告を出す。
関係ということになると違う。
ビジネスであれば、信頼の連続体。
どのようにお客様と新しくつながっていくのか。
新しいすばらしい考え方だが、どうやってやるの?
マニュアルは無い。
関係は皆違う。

参加型の Web
人として新しいデザイン的な考え方と人との関係構築のスキルが必要になる。

Organic vs Static
Emotion vs Data
Relationship vs Transaction
Continuum vs Grand Gesure
Relevance vs Chronology

単に時系列ではなく、自分が関心のあるものを見る。
有益なフィードバックを返してくれる。

新しい人のスキル

Listener
Connecor
Crinic
Partial geek
Detective
Catalyst
Diplomat
Juggler
Approachable
Intuitive
Inquisitive
driven by relationships

社会的な現実をまねしようとすれば。
いろんな人がいろんな方向を向いている。

A possible way to think about this

// デモンストレーション中

Let's Break it down

handshake (bow)
greeting
response
handoff
feedback
make me smarter about me

上記のことを、オンラインでやるとすると。

エンターキーを押す。
Web サイトに日付があれば、アップデートしていることがわかる。
 デザインの要素として必要なこと。
sign in する。
誰なのかということを認識してくれる。 DOPPLR のように。
DOPPLRはソーシャル旅行サイト
 1年に一回、PDFのドキュメント送ってくれる。旅行の履歴。
  どういうところにいったのか、どういう関係を構築したのか、
  わたしのことを教えてくれる。
 月までの距離の 25% も旅行した。関係趣向。非常にユニークで興味深い方法

Photojojo というサイト。写真共有サイト。
 オンラインで毎年 5000枚くらいの昔の写真から、ランダムに自分宛に送ってくれる。
 素晴らしいサービスだと思いませんか?感謝の気持ちを思い出させてくれる。

Handoff
旅行に行く時に、近くにすんでいる知人を紹介してくれる。

Esty
自分でつくったものを eBay 風に売り出すことができる。

エンターテインメント性は素晴らしい。

threadless
Tシャツのサイト。デザイナーTシャツを投票する。
Tシャツを示すだけでなく、そのTシャツを着ている人を見せている。

Pandra
ミュージックサイト。
オプションとして自動的にサービスを更新したいかどうかを聞いてくれる。
お客の時間を尊重してくれている。

Overnight Prints
楽しく表現する手法がある。
さまざまな名刺を印刷できるが、つまらない。

Moo は同じ名刺印刷するサービスだがまったく違う。
flickr, facebook からの写真を自分の名刺に印刷する。
「生きて」いるページ。
簡単に説明している。
名刺が欲しいのは、印刷のことではなく、
自分をどう世界に表現したいのかを MOOは理解している。

適切なステップ

Think like a sociologist or ehonographer
いままでうまくいったことを繰り返しているのみ。

Be an observer first
まずは聞きましょう。客の人生に役立つ。ものを押し付けるのでは無い。
機械的な FAQ ではなく、人が答えて欲しい。

Join the lives of people vs. interrupting them
Find a "place' in the 'community' you are designing - be a part of it
Help users participate
Stand for something &offer value
Think constancy not episodic
Experiment:Listen. Rinse.Repeat

技術は絶えず変わっているが、
人間はそう変わらない。
世界に入って、人間関係を気づいてください。

http://slideshare.net/debs/
www.deborahschultz.com

Q. ソーシャルWeb のマイナス面に関しては?
A. 高校時代の人間関係に似ている。人気度に頼っている。
 何人の友達がいるかではない。
 私たちはそれよりも成長している。数ではなく感情が重要。
 目の前で無礼なことをやるよりも、Web でやることが容易である。
 オンラインでいじめは、人間性の悪い部分が見えてしまう。
 企業から見るとソーシャルメディアを怖がる。
 商品のことをオンラインで製品が最悪であることは
 困ったことではなく、対処できるので、チャンスである。
 ある意味で思いやりを感じる。
 けんかして仲直りする機会があるということ。
 six apart に関して、ブログが 24時間ダウンした時があった。
 本当に最悪なことがあった。皆が大きな声で文句を言った。
 彼らにオプションを与えることにした。
 1年間無料でサービスを提供することにしたら許してくれる?という質問をしたが、
 実は何が起こっているのかを知りたかっただけ。
 「透明性」が大切。透明性を維持すれば、謝る機会が常に与えられる。

Q. social web は 2010年にはもっと発展する。知識社会が結びつく?
  social web は今後どう発展していく?
A. social web はここから伸びるというものではない。
 空気のような存在。インターネットを活性化するという人もいる。
 socail web と知識社会とは同じものではなく一緒に伸びていく。
 ひとつはモバイル化、よりスマートな取り扱いができる。
 企業と顧客が一緒に商品をつくれるマーケティングの媒体になっていく。

Q. 今リーチの話があった。友人がたくさんいるのではない。
  生態系をたくさん持っていない人もいる。その違いは?
A. アーリーアダプター、影響力のある人が取り上げられがち。
 もっている影響力も大きい。それらの人はそのことを良く理解している。
 いったい自分たちがどういう話をしているのかを考えて対応している。
 新しいものである。
 ビジネスを考えれば、ソーシャルメディアによってコストは下げられるが、
 リソースを下げることはできない。
 広告をオンラインに投下する場合、全部バナー広告にするのではなく、
 マーケティングの予算などを、お客様とのソーシャルな関係構築を築くのに使うのが良い。
 オンラインのどこに広告を配置するのかを見極めようとしているのは無駄。
 ちょくせつ顧客とやりとりする方向に向かう。時間はかかるが拡張できる。

ソーシャルメディアのエキスパートは居ない。私もそう。

Q. 人に注目して、人と人がどうつながっていくのか。
 ビジネスというよりも人に注目してソーシャル web を展開していくことがわかった。
 今日ここに来ている人を見ると iPhone を持っていたり、情報リテラシーが高い人ばかりであろう。
 リーチへの課題は?

A. リテラシーのことについて質問されたのか、リーチに関して質問されたのかわからない。
 必ずしも美しい Web サイトや、iPhone うんぬんではない。
 正しいやり方でやることが重要。自分たちの顧客に応じた方法で。

 

[&] Web Directions East 2009 (Nicole Sullivan)


Nicole Sullivan | Web Directions East

Design Fast Websites - Nicole Sullivan


Nicole Sullivan
『高速ウェブアプリのためのCSSパフォーマンス』
------------------------------------------------------

今日は CSS アーキテクチャについて紹介します。
http://www.slideshare.net/stubbornella
@stubbornella

カスケードの基本について
高速なアーキテクチャ
エンタープライズサイズのスケールのため

カスケードを理解する。
BROWSER default Styles
すべてのブラウザが難しいスタイルシートを持っている。
さまざまな要素、デフォルト値をもっている。
そこにたくさんバグがあることもわかっている。
ブラウザごとにさまざまなバグがある。0じゃないのに0値だったり。
不必要なコードになりがち。
リセットコードを用いる。
開発の負担も軽減される。

CLASS ORDER

Borken!


同じメッセージが入っていて、わからない。

ORDER OF THE PROPERTY VALUE PAIRS
BROWSER IGNORES BITS ITDOESN't UNDERSTAND
理解できない CSS をブラウザが無視してしまう。
スペルミスの場合。color と colour など。エラーにならない。

ORDER of the RULESETS
大きな web サイトで何人で作業すると、
同じ定義が重なってしまう。

ORDER of the stylesheets
コンフリクトした場合、最後の定義が採用される。どれが勝つのか?
FROM the spec:
It Goes on...

実際に CSS の開発には、早く結論をださなければいけない。

ID AND CLASS
#nav p{color: red}
.nav p{color: blue}

INLINE STYLES
エクスターナルなものよりインラインのものが勝つ。
!IMPORTANT で強制する。

CSS INHERITANCE
インヘリタンスは親から子に継承される。

AGGREGATION OF RULES
くつかのクラス、それぞれのメッセージクラスのインタンス。

理解できればいろんなことができる。
スパゲッティコードになる。

CSS IS AWESOME

CODE IS TOO FRAGILE
新しい人に渡すと壊されてしまう。
専門家がわかっていることがわからないため。
成熟性が必要。
何回もコードを書いている。
web チームで使えるものだけを公開していく。
いい開発者はすぐにでてこない。

CODE RE-USE IS ALMOST NONEXISTENT
コードの再利用はしない。

FILE SIZE JUST KEEPS GETTING BIGGER

非常に複雑な CSSコードを書いてしまっても、
アーキテクチャの中に入っていかない。
非常にパフォーマンスの高いサイトでも数ヶ月で CSSが大きく、遅くなっていく。

HOW TO ARCHITECT CSS
オブジェクトオリエンテッドな CSS
CSSさらにパワフルにしていく
違いは?
今までは括弧の中だけを見ていた。
どのようにセレクタを選ぶかが重要。

TERMINOLOGY CAN BE CONFUSING
クラスといっても CSSなのか Java なのか。サブノートという意味なのか。
できる限り、何を意味しているのか示す。

OOCSS
wiki.github.com/stubbornella/oocss

HEDDINGについて
デザイナーは何を意図しているのかをつきとめる。
エレメントを再利用する。
いろいろなパーツを持ってくる。

AVOID DUPLICATION
二度手間を避けるようにする。
いいツールは無い。
ほとんど同じようなモジュール、ほとんど差異がないようなものを省く。
同じサイトの中では使わない方がいい。ほとんど違わないことに意味はない。

場所の依存性を減らすこと。
依存性をどう解決するのか。
sandboxing した。パフォーマンスの問題があった。
どういものなのか?
FUNCTION AREA() がある。
エリアの範囲内に戻す。
Heading のたとえに戻ると、意味のある大きさと色を保つ。
グローバルに定義されていないと、ページごとに勝手に設定してしまう。
グローバルカラーを定義できたとしても間違いがある。
ロケーションで別な定義づけされて使われてしまう。
黒い文字が必要なのであれば、モジュール内での色を定義する。
一貫性が保たれない。ルールの上にルールを重ねてしまう。

コードの意味と、デザインの意味が一致しない。
その欲求をどうバランスをとるか。
90% のユーザーはビジュアル側しかみないので、尊重しなければいけない。
似たようなものが無いのかどうか、デザイナと調整する。
もっとヘディングが必要ならクラス化を考える。

REFLOWS (and rendering time)
パフォーマンスのオタク的に心引かれるもの。
CSSサイズと HTTP のリクエストを考えると、reflow は同じレベルに無い。
reflow にあまり時間をさくのではなく、http リクエストやファイルサイズに対応した方がいい。

不必要な reflow が起こる理由はいくつかある。
ブラウザによって変わる。

Toggle classes as low in the dom tree as possible
Aboid setting multiple inline styles.
Apply animations to elements that are position fixed or absolute
Trade smoothness for speed
Avoid tables for layout
Avoid javascript expressions in the CSS(IE only)

CSSベストプラクティス

古くなったルールを使い回すよりも、複製する方がまだ良い。
デフォルトバリューを定義する。
避けたいのはエレメントをスタイリングすること。
どのルールにも同じ強さ、力関係をもたせる。
どのルームも同等に同じ権限があり、ルールに関してはファイルのどこにあるのかが違うだけ。
順番だけで優先順位がわかるように。
チームで取り組むときに作業が簡単になる。だれかと力比べをしてはいけない。
ブラウザ固有のルールを使わなければいけない場面があれば、別につくる。
場所にも気をつける。どこで対応するのかを考える。
やりすぎない。定格に合わせすぎない。なるべく抽象的なものにする。
なるべく小さな機能クラスをつくってもデザインにいかされない。
SINGLETON も避ける。つくっても意味がない。一つのエッセンスだけにする。
できるだけオープンな状態に。ID はキープする。スタイリングには使わない。
MIXINSを使う。to avoid repeating code.
ENCAPSULATION カプセル化。直接アクセスされず、変更されないように。

http://stubbornella.org
nicole@stubbornella.org
@stubbornella
groups.google.com/group/obuject-oriented-css

Q. CSSのフレームワークを使っていてパフォーマンスをもっと役に立つものに変えるためには?
A. いろいろ話は聞いています。ファイルのサイズに関してはとても気にしている。
560 バイト多くても 700バイト、
別な余分なものを入れないようにしている。
簡単な例としては、ページが三つに分割されているとする。
必要であれば、コードを 1/3 反復すれば良い。

Q. MULTIPLE StyleSheet , 複数のファイルを使っている時、どのように影響を与えるか。
A. CSS を一つのファイルにまとめるのが良い。キャスケードは良くない。
 開発環境がよければ、実際にプロジェクトの人で分かれたファイルを
 ツールを使って、まとめるのが良い。
 別のファイルがあって、通常のスタイルシートと同じように統合すれば良い。

開発ツールがまだ発展途上
別のオブジェクトでまとめた方がいい。
コンベショナルスタイルシートを使う。大変だと思う。

■おまけ CSS Wish List



CSS WISH , W3C にむけてつくったプロポーザル
CSS は素晴らしいです。もっと良くなります。
さまざまなパターンが反復されています。
hex 値で設定できるようにして欲しい。

ぜひ欲しいものの PROTOTYPE
mod/inner/hd/bd/ft の構造で、ラウンドコーナーを表現。
@prototype .mod の設定ができる。
allowd nested childern
prototype の修正ができるようにする。
MIXINS クラスネームをつけたくない時。clearfix など。
margin top の bottom, height - corner, hight の設定
非常にシンプルに。コーナーを丸くするのが少ないコードで。イメージを取りこめるように。

#SlideShare を直接フルスクリーンで投影してプレゼンしてたのが印象的。

[&] Web Directions East 2009 (Douglas Crockford)

Douglas Crockford | Web Directions East

Web Directions East 2009

Ajax Security - Douglas Crockford


Ajax Security - Douglas Crockford
--------------------------------------
http://crockford.com/codecamp/ajaxsecurity.ppt

有名なセキュリティの話題。

The SAMY Saga (MySpace 2005)
JavaScript と CSSを隠した。
その結果 勝手に Friends リストに付け加えられていた。
アカウントの数が倍増していった。
名乗り出た。
その結果重罪となった。
SAMYさんは悪い人ではなかった。
サーバーからは、悪さをしていることがわからない。
制御を与えてしまう。
トランザクションの中で、ユーザーのリクエストなのか、機械からのリクエストなのかわからない。

ブラウザは上記のようなことを避けることができない。
web スタンダードは、これを避ける方法には動いていない。
これは新しいことではない
cross site scripting は 1995 年からの、基本的は問題。
セキュリティの問題、ブラウザで対応できているわけではない。
Web として必要十分というレベルにいつの日か到達することがあるのだろうか?

何か脆弱性があった場合、新しいバージョンで直していくことができる。
時間がたつにしたがって、解決していく。
ブラウザにあたらしい機能が付け加えられると、
それだけ脆弱性が付け加えられているということでもある。

新しい機能の問題。
意図した結果にならない場合がある。HTML5もそう。
前提としてブラウザのセキュリティモデルにまだ問題がある。
徐々に修正していっても、最終的に十分ということにならない。
むしろ、有害な原因をたくさんためてしまっている。
開発者としては、完全なセキュリティの知識を持たなければいけない。
現在のセキュリティのすべての理解を求めるのは無理。

Web はこのままダメになってしまうのでしょうか?
Flash も Silverlight は、オープンではない。
Web は正しい方向にどこよりも近づいていると考えている。

どこに問題があるのか?
 標準に間違いがあった。
 "We will add security in 2.0”
 バージョン 2.0 でセキュリティ機能を追加するというのは間違い。
 そういう態度が間違い。
 セキュリティこそが一番最初から考慮しておくべき。
 後付けはできない。
 後から欠点をのぞくのは難しい。
 
暗号技術やセキュリティに誤解がある。
暗号化すれば、セキュリティが向上するわけではない。
DLNA の場合、パソコンにウィルスが入った場合、家電にまで影響を及ぼすこと。
もし予防できないのであれば、自分たちでやるしかない。
暗号化技術を使って、解決するというアプローチ。本来的には正しくない。

アイデンディテイ。
 誰がソフトウェアを書いたのか、信頼できるのか?
 システムが危険なことが起きそうだと予期しているか?
 ユーザーに認証を求めても、ユーザーは理解できない。
 質問の目的もわからず、理解できない。
 
いろいろなプログラム、早く処理しなければいけない時、
二つの検疫を入れていかなければいけない。
OS側、ユーザー側
タイムシェアリングや時分割、何人もの人が同じシステムを使う。
お互いのプロセスをわけ、リソースは共有。
いい方法だが、問題としてはユーザ同士のコラボレーションができない。
メインフレームの時代が終わってパーソナルコンピュータの時代がきた。

プログラムは意図的にインストールされているもの。
使い方、動き方が変化していくもの。
Web 経由でもさまざまなものがインストールされている。
ユーザ側の検疫と、プログラム側の検疫をわけている。
ブラウザ側も混乱する。複数のサイトがあった場合。
ページの中広告や、Widget や Ajax ライブラリなどが、サイトと同じ権限をもってしまう。

Turducken  ターキーと、ダックと、チキンがレイヤー化されていて、
何を食べているかわからない。

Web 2.0 の問題ではなく 1995 年からずっとあった問題。
根本的な問題は解決しておらず、マッシュアップが増えれば増えるほど問題になっていく。
mashup は XSSアタックになりうる。
広告があるページにあるだけで、あまり良くないこと。
JavaScript としてはセキュアな言語として使える。
新しいモデル。

Object Capabilities
http://erights.org/talk/

相互の監視によって、お互いに被害を与えないようにして情報をやりとりする。
A から B にインタフェースを提供し、インタフェースの部分でデータを送る。
リファレンスの仕方に制限を与えることによって安全なモデルができる。

By Creation.
By Construction.
By Introduction.

最終的には情報を隠すことを考えたり。
リファレンスは無かったことにはできな。ファセットを使う。

Facets

Very expressive.
Easy to construct.
Lightweight.
Power Reduction.
Revocation.
Notification.
Delegation.
The best OO patterns are also capability patterns

セキュアな用件がそろっている。
ケイパビリティが良いのが理想。
Ajax ライブラリでやっているようなこと。

W3C は逆の方向に向かっている。
HTML5 はセキュリティの問題がカバーできていない。

広告の問題。
ECMAScript の部分。Caja ライクなセキュリティ。

Q. Caja とは?
A. Google Caja, JavaScript を安全な JavaScript に書き換えるもの。
 コードをチェックし保証するもの。問題を発生するものではない。
 Yahoo! でも使っている。どんどん Caja を使うシステムが増えてくるであろう。
http://code.google.com/p/google-caja/

Q. スクリプトに署名するのでは?
A. 署名があっても機能しない。アイデンディテイの混乱を招き、
 不要の権限を与えてしまう。ユーザーに許可を聞いても意味はない。
 攻撃者にたいして攻防策にならない。
 ケイパビリティーこそが鍵になる。

Q. HTML5 は大きくなりすぎている
  別の解決方法はあるか?
A. いろいろやっている、web sand box (Microsoft)など
 Y! はモデルに関して、かなりの経験がある。
 次のバージョンに何が必要なのかわかっている。
 初期の FORM の形にもどって、もういちど洗い出しが必要。
 考え方を変えるしかない。
 これをやることによって、Web開発者にとってはもっと安心・安全できる環境になる。
 ECMA スクリプトの方でやっている。MS,Google らと協力して作業している。
 ミーティングが始まった。
 どういうのが一番いいのかという知識を広める。実際に形にしていこうという作業。

A. JavaScript で Dojo, jQuery などライブラリがある。
  それらのフレームワークは安全だと考えている?
Q. フレームワーク自体は現在安全では無いです。
  Dojo はかなり安全だと考えています。
  Dojo をそのまま使ってしまうと安全なシステムとは言えない。

Q. ECMAScript 5 でかなり難しい問題解決する。
A. Caja はゲストオブジェクトがグローバルオブジェクトにアクセスできない仕組み。
  JavaScript ではいろいろな方法でグローバルオブジェクトにアクセスできてしまう。
  ECMA5 でより良くなっていく。パフォーマンスの部分も良くなっていく。
  まだ DOM でラッピングしなければいけず、パフォーマンスの問題も含む。

Q. Google オープンソーシャルは?
A. OpenSocial は Caja を使っている、非常にいい方向だと思う。

[&] Web Directions East 2009 (Christian Crumlish)

Christian Crumlish | Web Directions East



Web Directions East 2009

Christian Crumlish
『社会的なウェブインターフェイスの設計』Designing social interfaces
-------------------------------------------------------------------------------

Web Directions East 2009

Christian Crumlish
『社会的なウェブインターフェイスの設計』Designing social interfaces
-------------------------------------------------------------------------------
Yahoo Desing Patterns Library の創始者
design.yahoo.com
@mediajunkie

オライリーにも訳書の要望を入れている。日本語版も出るとうれしい。

ショーシャルインタフェースについて。
新たなインタフェースがでてきたときには、人は受け入れずらい、とまどう。
電話がいい例。
最初は使い方がわからない。なぜ電話が必要なのもわからなかった。
その場に居ない人となぜ話さないといけないのかわからなかった。
そのうちみんな気付いてきた。

アメリカでは携帯電話の使い方のマナーが悪い。
昔は人に電話するのではなく、家に電話して、取り次いでもらっていた。
携帯電話は場所ではなく、相手のポケットに電話している。
電話は個人にもとづいている。
電話が変わってきたころのことを覚えている。
携帯電話は声が大きくなりがち、お互いに大きな声でやりとりしてしまう。
携帯電話に関して、まだエチケットが確立していない。
Web インターフェスに関しても、ソーシャルなものであれば、同じ問題があてはまる。
慣れるには時間がかかる。

ソーシャルデザインパターン
このプロジェクトではさまざまなパターン、プラクティス、インタフェースのデザインを行う。
ソーシャルデザインのプロセスは目立っている。
社会的な要素を組み込んでいかなければいけない。

Pave the cowpaths
どこに動物のあるく道ができる?
道ではなく、ショートカットで歩きたい。
うまく道の作り方ができていない。
Web のインタフェースを使うとき、期待された使い方をしていない。
間違って使っていると、無理やりコントロースするのはよく無い。
ユーザがどう使っているのかを見て、それをサポートするべき。
ユーザの振る舞い、それを取り入れていくのがいい。
Twitter での使われ方など、ユーザが発明したこと。ReTweet もその例。
ソフトのインタフェースでシンタクスを有効に使う。
Twitter でやっていることはユーザーの中で広まっている。
@???? でユーザのプロファイルに飛んでいく。
ユーザが実際に行っている言動を理解して、必要な機能を提供する。

dogster というイヌ好きのサイトがある。catster もある。
ソフトのもともとのビジョンとしては、ソーシャルサイト、写真をシェアすることができる。
ペットの写真を貼り付けることができる。
Web サイト、ペットの写真があるのであれば、それをいかせばいい。
ペットの詳細サイトとして発展していった

Talk like a person
人のように話す。

どのように使えばいいのか、使うことによってわかる。
お互いにわかりあえるような言語を使っているのか?専門用語ではなく。
たとえば、銀行であれば、ビジネスライクである必要があるが、
ソーシャルサイトであれば、人を呼び込むようなフレンドリーな分かりやすい言葉で。

話し方、
 How to talk like a person
Conversationnal voice
self deprecating error messages
ask questions
your vs my
no joking around

通常会話調というとカジュアルである。
どの世界でも会話調という表現がある。コミュニケーションとして正しい方法がある。

エラーメッセージ、ユーザが間違っている気持ちにさせてはいけない。
コンピュータの側が間違っていることを示す。
常にユーザーではなく、サイトのオーナーに責任があると見せなければいけない。

実際の世界では質問すると当然回答がえられる。
いうべきことを聞きたい。質問することによって関係性を深めていく。

所属するところではない、個人が自分考えていること。
所属には関係ない、ほかの人が関与することではない。
個人的なもの。
ソーシャルな経験のなかでかかわっている人のこと。

ジョークを入れるには注意が必要。
会話っぽくすると、ジョークを入れようと考えてしまうが....
リスクがある。ユーモアの感覚は一般的に面白いと思ってもらえても、
そうでない人が必ず居る。
混乱してしまったり、わからない人も。
ソーシャルな環境では注意が必要。

Play well with others
ほかの人ともうまくやる。

パターンを使う、慣れているものを取り入れる。標準を取り入れる。
新しいもの、改善を付け加えてもいい。

レゴがいい例:
ブロック自身は再利用可能、標準のもの。

Embrace open standards
Share data outside of the bounds of your application
Accept external data within the sphere of your application
Support two way interoperability

標準を取り入れる。
データが外でも使えるように。
外部のデータも受け入れる。
双方向でインターオペラビリティが大切。データのポータビリティが大切。

Learn from Games
ゲームから学ぼう

若い世代はかなりゲームを楽しむ。
スタンダード、楽しみをわかっている。
ゲームに慣れた世代がすぐに使えるようにするのも大切。
アイデアをゲームデザインに学ぶのも重要。
ソーシャルデザインはつくったら終わりではなく、変化していくもの。
建築からルールを学べる。
いつなにをやるかといったことが始まっていく。
価値のある空間をつくって、ユーザに育ててもらう。
リズムがあるところで、思ってもいなかったことさえも実施してもらえる。

Game Nverending いつまでのできるゲーム。
このゲームは非常に成功したソーシャルゲーム。Flickr のもととなったもの。
ゲームからソーシャルな体験につながっていった。

Respect the ethical dimension
倫理的な部分を尊重する。

何かうまくいかないとサービス提供者の責任になる。
どれだけの倫理観、価値観があるか。
判断していかなければいけない。
ビジネスと天秤にかけて、どれだけ倫理観を持たないといけないか考える。
決まりは無いが。

推奨できないもの。
tagged.com
メールアドレス、パスワードを入力しないといけない。
そうすると、アドレス帳にある人全員にメールを送ってしまう。
8000万以上の人が登録したが、いったいどれだけの人がイライラしたのか。
勝手にワナをかける。見えづらいチェックボックスで承認させて。

96 のパターンがある。

人のアイデンディテイのパターン
人の活動に関するパターン
コミュニティのパターン
 上記3つがソーシャルスペースになる。

Give.....
人々にどのように情報を与えるか。

MIT の pasnona , カラフルな色で、characterizing してくれる。
同じ名前だと、すべての人がミックスされる。
アイデンディテイをはっきりしないといけない。
自己をどうやってみるか。
どうシステムに入ってもらうか。
評判のパターン。どれくらい利用しているのか、信頼できるユーザなのか?

ユーザーカード、プロフィールの簡単なサマリ。
ユーザーカードは長いプロフィールの濃縮バージョン。
汎用的なアイデア。
friendfeed や flickr の例。その人の詳しい情報も、簡単に見ることもできる。

社会的な目的を考える。
単に登録してもらうだけではない。

Wha't your social object?
何か対象物が必要。

キャラでもモノでも、趣味でもいい。
グループ化していって、話が盛り上がる。
最初はそうやろうと思っていたわけではないが Fake もいい。
本名の重要だが、Fake な人間も機能している。

ウクレレが好きなのだが、Twitter で反応がもらえたりする。
やりとりができると、反応がある。人間は人間について語るのは難しいが、
対象物があると、話題が盛り上がりやすい。
飛行機に乗るときにはいつもウクレレを持って乗ると、
話題作りができる、対象物があると、人と人のつながりがうまれる。

対象物だけではダメ、なにか活動を、
集めなければできないものが、ソーシャルに重要。
1から多数への一方通行のメディアではない。

フィードバック、好き、嫌い、星をつけてレーティングできる。
いいのか悪いのか評価ができる。
人がいて何かオブジェクトがあり、レビューがあれば、交流がうまれる。
コミュニケーション、双方向のやりとりは、その後にあるもの。
直接コミュニケーションするよりも、
ものを介したほうがきっかけになりやすい。

コラボレーション。
協力関係。
一緒にオブジェクトを作り出す側にまわる。
すぐには必要ないかもしれないが....

ツール。どうやって対応するかのツール。
成功しているソーシャルサイトは、みんながそこに登録している。
そこから個別なものが発生する一つの生態系。
その中でたくさんの活動が行われている。
 検索したり、フィルターをかけたり、ツールが必要になる。

ソーシャルオブジェクトに関してはダグが利用できる。
レーティング、フィードバックのパターン。
Yelp の例。
Yehoo! Movies の例
A,b,c,d,e,f 学校での成績の付け方と同じ。A-, A+ とか。

Share This というパターン。
SHare this in the wild の例
Facebook の例

人と人のつながりによって、たくさんのことがおきる。
コミュニティである必要は無く、コミュニティとソーシャルは一緒ではない。
自分のカルチャーをつくって、何かをおこなう集団。
コミュニティは夢をもっている。
コミュニティは個人個人だけではなく、オーナーがいる形態。
コミュニティ自身が世界をつくれるもの。
Gently moderate
謙虚に動く必要がある。ルールをもって秩序正しく。

友人へのコネクション。分類するかもしれない。
コミュニティのマネジメント。
現実の場所。実際の世界と結びつけをする。
実際にあったときに本当の結びつけができる
関係性の強さを持ち込む。
文書にまとめるには限りがあるが。

Adding Friends パターン
Dopplr の例

Circles of connections パターン
カテゴリわけ。
Plaxo の例
Flickr の例

Public Conversation
Twitter の例

実際の世界でイベントを開いてもらおう。

Geo パターン。
場所で人がさがせる。
Geo in the wild (WHere for iphone)

まとめ (サイト参照)

アンチパターンは?
 いいアイデアに見える、実際は問題が発生するもの。
Cargo Cult
DOnt' break email
password anti-pattern
ex-boyfriend bug
potemkin village

Designing Social Interfaces (O'reilly)

[&] Web Directions East 2009 (Andy Clarke)

Andy Clarke | Web Directions East



Web Directions East 2009
Andy Clarke『壁を壊せ』
--------------------------------

Walls Come Tumbling Down
Andy Clarke

資料の日本語は Google Translate で翻訳しました。

イギリスにあるデザインスタジオ。
デザインワークフローのいかし方。
学んだことも著書にまとめている。
Web デザインワークルフロー(訳本)
DVD も何本かでている。

常に Web デザインの仕事ばかりではない。
プラスチックのファクトリーでも働いたことがある。
この初期の仕事の製造のプロセスからもさまざまなことを学んだ。
経済不況の時代、時間を節約したい、お金も節約したい、
一番重要なところに費やしたい。

創造性は不可欠な要素である。
より多くの要素を想像する。
web デザインのワークフローを見直す。
よりクリエイティブになる時間の使い方。
Web デザインがどういうものなのか、誤解がある。
web デザインの取り組み方は製造業のやり方でやられている。
印刷などと同じになっている。
よりクリエイティブになるには?
クライアントや、上司とのやりとり

あたらしいワークフローのやりかた
ブラウザ内でのデザインをする。
 Photoshop ではなく、ブラウザの中で。

 設計改善のワークフロー
 設計はブラウザで、
 節約する
 設計システムの無いサイト

システムをデザインし、モジュール型で再利用できるもの。

時代遅れのワークフローを破棄する。
イギリスで始めにデジタルカメラをとったのは、自分かもしれない。
デジタル写真というのが写真のありかたを変えるのか?
製造業のプロセスを踏襲していた。
非常に非効率で、時間もお金がかかるプロセスのまま、
すべてのプロジェクトにあてはまるものでは無い。

現在の Web デザインは Photoshop で静止画像を作り、みせる。
その後、開発者がコードに直している。
そこで初めてブラウザ上でどう見えるのかがわかる。
実際はブラウザ間でどう見え方が変わるか、それだけのテストの部門があったりする。
この作業自体が無駄。

プロセスのあり方を考えないといけない。
いちだんかい 戻って考える。
開発者側はデザインを解釈して HTML/CSS 具現化する。
デザイナーは Photoshop でデザインして、ブラウザで表現できないことの腹をたてる。
今よりももっといいプロセスをつくっていけるはず。

皆さんに提案したいのは、デザイナー側とコーダー側でやりとりして、
時間を無駄にしない、クリエイティブに時間を使う。質の向上にも貢献できる。

ブラウザ内でデザインすることで、非常に短期的なフォーカスで仕事をしていける。
集中してできる。断片的にもデザインできる。
自分がいいと思ったものを見せて、改善していくというプロセス。
グループで作業するにも向いている。
やりとりをしながら細かい修正していくことができる。
クライアントやりとしりながらできる。
短い時間で大きな進捗が得られる。

その場でインタフェースを変えれば、すぐ修正し、すぐ見られ、試行錯誤できる。
ユーザーも巻き込んで進めていくことができる。
相手のオフィスの中でも短い時間で作業できる。

このプロセスの間にクライアントにも大きくかかわってもらう。
以前はクライアントへ一番のプランを一方的に提案するばかりであった。
デザイナーは多くの場合、クライアントのせいにしたがる。
クライアントが文句をつけるのは、作業にかかわりたいという欲求を満たすために
ものをいっている場合もある。
最初からクライアントにかかわってもらい、密にかかわってもらうことによって、
理不尽が要求がこの場合おきない。
フラットな静止画像を見せることで終わらない。

設計はブラウザで。

まずコンテンツありき。
デザインというのは決して機能しか決まっていない段階で決めるべきではない。
双方向に様子を見ながら、Web 上でプロセスを進めることができる。
静止画を見せるだけでは、動いている Web サイトをつくることはできない。

Internationalist Magazine
このプロジェクトでは何をやっているのか?
オープンデザインプロセス。すべてのプロセスにかかわっている。
フロントエンドも、ユーザービリティも、HTML/CSSも。
実際にテンプレートを作り CMSとうまく調和できる形で。
35のテンプレートが実際にある。
アーティクルのページもあり、表紙もあり。
これを 3週間で提供した。
実際にやっている作業はスピードがあった。
お金は無いが、短期間でもっとやって欲しいと考える。

古いワークフローでは、たくさんの静止画像をつくってしまう。
ワークフレームとか、静的なプロセスはまだはびこっている。
もちろん悪いといっているわけではない。
たとえば、色を変えるとか、位置を変えるとかは、非効率。

なぜわれわれはブラウザを使わないのか?
実際に本当に必要なものを使う。
もっと流れがあって、効率性のある、問題点を解決するもの。
どうやって流れのある流動的な操作を提供するのか?
ブラウザでテストすれば、もっと速いプロセスを回せる。
Photoshop の場合、時間がかかりすぎる。
HTML/CSSだとすぐ見られる。修正できる。
デザイナーはクリエイティブな作業をできなければいけない。
最終的にどのように見えるのかを提示する。
 モックアップで、何種類かの見栄えを提示するばあい、
 マウスオーバーなど動きのあるデザインを静的な画像でうまく見せることはできない。

クライアントもデザインのインタラクションに関与することができる。
実際に初期の段階から作り込むことに意味がある。
クライアントに、静的なデザインを見見せることを止める時がきた。
静止画を見せるのはもう古い考え方。

問題は静止画に関して、クライアントがゴーサインを出してしまうこと。
クライアントがそこで決定してしまうのには問題がある。

Web サイトが、すべてのブラウザで全く同じように見えることは必要ですか?
その答えは「No」
すべてのブラウザで同じ経験ができれば良い。
ここを間違えると、最終的に間違った道になってしまう。

とにかく Web サイトで同じように見える方がいいという観念がまだ残っている。
すべてのブラウザで同じでなくてもいいことがなかなか理解してもらえない。
別に壊れたわけではない。
違うということは壊れているわけではない。
見方とか経験とか、技術的な経験も違う。
時々、ベースレイヤーを共通に。
ブラウザによる違いをテストしておく必要がある。
ソリューションごとに時間がかかる。
Web のアクセシビリティをどこまを取り入れるのはプロジェクトによる。

タイポグラフィーについて。
たとえばスタイル的に、最初のパラグラフで大きめのフォントを使うとき。
古いタイプのブラウザだと対応していない表現がある。
それでも十分満足できる。
少し読みやすく調整する。
iPhone 対応にする時
少し派手にする部品もあり。
いろんなブラウザを使っている人には見えない部分もあるかもしれない。
装飾的に使っているものは見えなくてもいい。
微妙なシャドーなども、
ブラウザで SHadow をサポートしてしないものもある。
でも、何かが抜けているということには気付かないものがある。
気付かない人の方がおおいはず。
box shadow,どのブラウザでもできるわけでも無いがいい。
デザイナーはすべて同じに見えないことを理解する。
クライアントに説明することは難しいが。

CSS はいくつかのモジュールに分かれている。
すべての古いブラウザが、新しい CSSをサポートすることはありえない。
すべてのブラウザで同じように見せるために時間を使わない。

一番最新のブラウザのためにデザインをしていい。

Selling Universal IE6 CSS to clients
クライアントに IE6 対応に時間を使うか、クリエイティビティに時間を使うのか選べばいい。
一歩進めるために一番最新技術をつかって、Web で何ができるのか、
より先に進めるために、デザイナーも成長が必要である。
業界として共通のパターンを作り、価値を付け加えるように、
最新のアプローチを使うべきと伝える。

ぜひ、どのようになるのか、考えて欲しい。
仕事のためになにをして、何をさし示すのか?

http://twitter.com/malarkey
stuffandnonsense.co.uk
forabeautifulweb.com
transcendingcss.com

Q. 日本ではあまり事例として見られないが。イギリスでは普通に行われているのか?

A. イギリスでも普通ではない。
  クライアントに理由づけを説明するのを考える。説得しなくていい。
  自分のやり方を押し付ける。携帯でも見えることで説得できる。
  予算的にも増えるコストもない。
  ブラウザ間で同じように見えることには価値がないことに気付く。
  あと三年すればこの考えが一般化する。

[&] 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つのエリアを1つにする。
1.CENTRALISEDすべてを一つのサーバに集める。だれがどこからでもアクセスできるように。
2. DOCUMENTATION ドキュメントについて。
3. Discussion

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

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

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

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

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 は3−4人でつくったプロトタイプから始まった。
ラリーとセルゲイに提案する時があり、
アイデアに共鳴する人を引き込んでいける。
自分が働く職場を信頼できることはアイデアをいかしていける。
アイデアを歓迎する文化を関係するには、
すべてのアイデア、会社をダメにするアイデアも聞かないといけない。
競合にはできないアイデア、企業をひっぱっていくアイデアが必要。
アイデアを最大限活用する。

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

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

DESIGNING INNOVATION

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

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

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

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

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

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

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

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

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

wave の中ではどうやっているのか?
メッセージが3つあったとする。
メッセージ1から入ってくる。
ほかの人が 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 が開催される。