Resilient web design の要約

Jeremy Keith 氏による Resilient web design の個人的要約

0. Introduction

• ウェブデザインの歴史を振り返る
• 過去からよいアイデアとアプローチを見つけてほしい
• 過去を振り返ることで未来を見通す

1. Foundations

• 人類の文明の歴史は、累積的な努力
• テクノロジーは孤立して作成されるのではない
  • グーテンベルクの印刷機はワイン醸造のスクリュープレス技術の転用
  • QWERTY キーボードは機械的な部分の衝突可能性を減らすために配置された
  • 時計が時計回りなのは北半球の日時計に由来する
  • フロッピーのサイズが 3.5 インチなのはポケットに収まるように
• 過去のエコーが現在も引き継がれる
• Tim Berners Lee がウェブをつくった
  • CERN における情報管理の課題を解決するツールとして生み出された
  • このときもうインターネットは存在した
    • 電信のための海底ケーブル（のちの電話信号に転用）
• インターネットの思想
  • 国防機関から資金提供を受けて研究がはじまった
  • エンジニアの理念は自由言論運動と共通していた
    • 核攻撃より検閲をおそれていた
  • 分散化
  • ダムのないネットワーク
  • レイヤードアーキテクチャ（トランスポート層）
• ハイパーテキストの発明
  • Vannevar Bush - As We May Think
  • Ted Nelson - Xanadu
  • Tim Berners Lee - Information Management: A Proposal
  • HTML のシンプルさが成功の秘訣
• HTML の歴史
  • CERN は SGML 的なフォーマットを使っていた
  • 既存の語彙にもとづいて HTML を作り始めた
  • HTMLの最初のバージョンには 21 個の要素
  • WorldWideWeb ブラウザと Line Mode Browser の互換性問題
  • 「ブラウザソフトウェアはこのタグを無視する場合があります。」

2. Materials

• 不明なタグを見つけてもブラウザはエラーを発せずコンテンツを表示する
  • この挙動こそが HTML の発展に寄与した
• マークアップには意味がある
  • 著者が遭遇するであろう状況を説明するために作られた
  • 特別な力を持った要素がある
    • a 要素、input 要素、select textarea button
  • 内包するコンテンツを説明する役割の要素がある
    • p, li, …
    • ブラウザは、その意味をあらわす視覚的なヒントとともに表示する
      • 段落は前後に空白を。リストアイテムはリストマークを。 \
  • 初期の HTML はブラウザ視覚的な指示を与える要素がたくさんあった
    • big, small, center, font, …
    • このころの HTML は、意味の語彙ではなく視覚的な説明言語になりかけていた
• Håkon Wium Lie が CSS を提案した
  • selector { property: value; } のスタイルを開発した
  • 不明なセレクターはエラーを起こさず、無視する（HTML の態度と同じ）
• 1996年に David Siegel が Creating Killer Websites という書籍を出版した
  • spacer.gif, テーブルレイアウト
• CSS が使われなかった原因の一つはブラウザのサポートの欠如だった
  • IE と NN は互換性がなかった。独自の HTML 要素を発明していた
  • Web Standard Project の旗のもとに集ったウェブデザイナーたちのロビー活動の結果、CSS サポートされた Mac IE5 がリリースされた
  • CSS Zen Garden
• システム間の結合
  • 密結合は、設計が高速のかわりに、回復力にかける
  • 疎結合は、設計は大変だが回復力がある。システムの一部だけを交換できる
  • spacer.gif やテーブルレイアウトのハックは HTML と CSS の密結合だった
• マテリアルオネスティ
  • ある材料をほかの材料の代わりとして使ってはならない
  • テーブル要素をレイアウトに使うことはマテリアル “ディス” オネストである
  • スタイリングに CSS を使うことはマテリアルオネストだ
  • 四隅に背景画像を配置するより border-radius を使うほうがマテリアルオネストだ
• David Siegel は懺悔している

3. Visions

• デザインは制約下で機能する
  • インクの色と数、皮紙の重さ、寸法、
  • グーテンベルクが印刷を発明してもデザインパターンは引き継がれた
    • ドロップキャップ、カラム
    • グリッドシステム、スケール
  • ページは制約で、グリッドシステムはページに順序を課す方法
• ウェブにおける制約
  • ブラウザーウィンドウは自由だった
  • テーブルレイアウトの時代に、設計者はウィンドウサイズを知っているふりをした
    • 640px -> 800px -> 1024px
    • ウェブデザイナーは 960px が理想的な幅だと決めた
    • 合意幻覚があったかのようだった
• A Dao of Web Design - John Allsopp (2000)
  • 新しいメディアは前任者を模倣する
  • Creating Killer Websites はウェブ用DTPだ ウェブには印刷ページの制約がないことを受け入れ、この柔軟性のために設計する必要がある
• 道具
  • Photoshop はもともと画像操作を目的としていた
  • Dreamweaver も WYSIWYG のアイデアに従っていた
  • どんなデザイナーでも使うツールの組み込みバイアスに引っ張られる
• ウェブデザインの分野は複数の仮定の上に成り立っていた
  • 960 ピクセル幅のレイアウトを表示できる画面がある
  • ブロードバンドインターネットアクセスがある
  • 最新のプラグインがインストールされた最新のブラウザが使われている
• iPhone が常識を変えた
  • 小さなディスプレイ
  • 低速のモバイルネットワーク
  • インストールされないプラグイン
  • ウェブの本質に立ち返らせた
• iPhone への最初の対応はセグメンテーションだった
  • モバイル用、PC 用のウェブサイトを別々に提供する
  • このやり方はスケールしなかった
  • One Web という理想に立ち返らせた
• 2010年4月、Ethan Marcotte がResponsive Web Design のアイデアを公開
  • この時点で必要なテクノロジーはそろっていた。
    • fruidgrid, fruid images, media queries
    • これらの手法をまとめて名付けたことで考え方を一変させた
• Luke Wroblewski「モバイルファースト」
  • コンテンツに優先順位がつくられた
  • 小さな画面で機能すれば大きな画面でも構築できる
  • 残されたコンテンツは堅牢で復元力がある
  • 一方で、モバイルデバイスに関する想定に縛られることも回避すべきだ
• ウェブにおけるマテリアルオネストが求められるようになった
  • 画面サイズ、帯域幅、ブラウザの機能について、信じられるものがなにもない
  • コンテンツだけが残っていた
  • 制御の放棄は品質の放棄とは違う
  • ウェブでのデザインにまつわる未知を知ることで柔軟で媒体に忠実なものづくりができる
• Long Live the Web: A Call for Continued Open Standards and Neutrality

4. Languages

• ロバストネス原則＝ポステルの原則
  • ARPANET を開発していた Jon Postel
  • “Be conservative in what you send; be liberal in what you accept.”
  • ブラウザがHTMLやCSSを処理する方法と一緒
• JavaScript
  • 1996年に Brendan Eich が10日で作った
    • Mocha -> LiveScript -> JavaScript
  • ロールオーバーとフォームバリデーションで使われた
    • 現在は :hover や required 属性などで実現可能
    • ソリューションは命令型言語で作成され、時間の経過とともに宣言型に移行する
  • 広告業界は広告用のウィンドウ表示に使った
  • サイト間の追跡にも使った
• ウェブアプリ
  • HTML や CSS が宣言的なのに対し JavaScript は命令型
  • 宣言型のエラーへの寛大な態度は JavaScript には引き継がれない
  • 厳格だった XHTML 2.0 は実現しなかった一方、同じく厳格な JavaScript が使われている
  • HTML は部分的なレンダリングが可能。JS は完全なダウンロードが必要。
  • Stuart Langridge - Everyone has JavaScript, right?
• ウェブはプラットフォームではない
  • ソフトウェア環境と同等ではない。Android/iOS/Flash
  • クロスプラットフォームである
  • プラットフォームは、ソフトウェアの制御されたランタイム環境を提供する
  • ユーザーがそのランタイム環境を持っている限り、設計されたものを正確に取得できる
  • ウェブの場合、人によっては 80 か 90% かもしれない。またある人は 20% か 30% かもしれない。
  • ウェブは連続体だ
• ウェブは無秩序で予測不可能だ

5. Layers

• イギリスの建築家フランク・ダフィーのアイデア - shearing layers
  • スチュアート・ブランドが６つに拡張した
    1. Site - 建物の物理的な場所は、地質学的な時間スケールでのみ変化します。
    2. Structure - 建物自体は何世紀も続くことができます。
    3. Skin - 数十年ごとに、外面の表面が刷新されたり、新しい塗装が施されたりします。
    4. Service - 配管と配線は10年ごとに更新する必要があります。
    5. Space plan - 壁とドアのレイアウトは時々変更される可能性があります。
    6. Staff - 部屋の家具の配置は、毎日変更される場合があります。
  • 同様のアイデアがウェブ上の作品にも適用できる
    • ドメイン名は地質学的サイト
    • 反対側はウェブ上のコンテンツ（もの）を時間・分・秒単位で追加更新できる
    • 中間には HTML,CSS,JS の構造、表示、動作のレイヤーがある
  • これらの層は疎結合だが完全に独立しているわけではない
    • CSS や JS は HTML の上に。HTML は HTTP の上に。HTTP は TCP/IP の上に。
• 構造のプレゼンテーションの分離
  • 同じコンテンツを複数の方法で提示できる
  • 利用者のニーズに応じてプログレッシブエンハンスメントされる
  • 状況に対して排他的な態度ではなくインクルーシブに
• ウェブサイトはすべてのブラウザで同じに見える必要はない
  • HTML のベースラインがあってこそ、最新の CSS を試すことができる
  • ポステルの法則と CSS の緩やかなエラー処理モデルのおかげ
  • 誰もが同じデザインを体験するわけではないことはバグではなく、ウェブの特徴
    • 新しいブラウザ⇔古いブラウザ
    • 大きい画面⇔小さい画面⇔画面なし
    • 高速接続⇔低速接続
• JS のエンハンスメントには feature detection が必要
  • ブラウザの検出ではなく、機能の検出
  • もし機能があればエンハンスするが、else ステートメントはない
• サポートと最適化は違う
  • プログレッシブエンハンスメントは、すべての人にコア機能を提供することを意味する
  • プログレッシブエンハンスメントで実装されている場合、特定の機能がなくても、ロードに失敗しても問題ない
  • 新しい機能のサポートを古いブラウザにまで適用する必要はない

6. Steps

• スクロールとタップを楽しみにして朝起きる人はいない
• X線透視図
  1. コア機能を特定する
  2. 可能なかぎりシンプルなテクノロジーを使用して（HTML 同等物を見つけて）、その機能を使えるようにする
  3. エンハンスする
• コア機能の特定
  • ニュースサイトの場合、ニュースにアクセスできることこそがコア機能
  • パズルやリアルタイム通知は大事だろうけれども
• コア機能を利用できるようにする
  • URL を付与し、HTML ファイルをつくる
  • 適切な HTML 要素でマークアップする
• エンハンスする
  • クラス名を付与し、CSS を適用する
  • 広い画面のレイアウトを定義する
  • JavaScript でふるまいを設定する
• メッセージの送受信のケース
  • HTML のフォーム要素を用いる
  • フォームの送信をインターセプトし Ajax を使用する
  • WebSocket を使用してサーバーからメッセージを受信する
• 写真共有のケース
  • File API を利用する
• ワードプロセッサのケース
  • コア機能：作成する、共有する、編集する
  • 技術：textarea 要素（作成・編集）と URL（共有）
  • エンハンス：キーストロークによるスタイル適用、リアルタイム保存、複数人編集、オフライン作業などなど
• 地図コンポーネントのケース
  • コア機能：場所を表示する
  • 技術：その場所の住所をテキストで表示する
  • エンハンス：スライドスケール、静的画像、パン可能地図、Geoloaction API を使った現在位置からの距離、動きをトランジション化したり…
• サイトナビゲーション
  • コア機能：リソースへのリンク
  • 技術：ハイパーリンク
  • エンハンス：off-canvas ナビゲーション、スライド、スワイプ、フェード、…
• ウェブサイトはすべてのブラウザでまったく同じに見える必要はない

7. Challenges

• WWW はそのシンプルさが何度も批判された
  • 「CSS レイアウトは、大規模で複雑なプロジェクトには拡大されないではないか」
  • 「レスポンシブデザインは、大規模で複雑なプロジェクトには拡大されないではないか」
  • 「プログレッシブエンハンスメントは、大規模で複雑なプロジェクトには拡大されないではないか」
• プログレッシブエンハンスメントは、すべての人にすべてを提供しなくてはいけないことではない
  • 大事なのはコア機能
  • これは優先順位付けがとても重要な理由
  • コア機能が可能なかぎりシンプルな技術で利用可能であるかぎり、より世親的な機能をレイヤリングできる
• 何事も最初は時間がかかる
  • CSS レイアウトによるコーディングも、なれないうちは時間がかかった
  • レスポンシブデザインも、なれないうちは時間がかかった
• ウェブ標準もレスポンシブデザインも、最初は抵抗感を持っていた人々にも最終的には採用された
• プログレッシブエンハンスメントのメリットは実証が難しいことがある
  • ペイオフは予期しない状況で発生する
  • 目に見えない品質
  • 同じ理由で、誰を説得する必要もなく始められる
  • “it’s easier to ask forgiveness than it is to get permission.”
• ツールとの衝突
  • WYSIWYG エディタ、グラフィックデザインアプリ、CMS、JS フレームワーク
  • 自分の哲学と一致するアプローチを採用するツールを用いること
• 私たちが確信できる唯一のことは不確実性
  • 未来が予測できないことを認め、受け入れる
  • 将来に配慮した方法で考え、行動する
  • ほかの人が同じことをするのを手助けする
• ウェブデザインの歴史で行われてきた仮定たち
  • 誰もが幅 640ピクセルのモニターを持っている
  • 誰もが Flash プラグインをインストールしている
  • 誰もが幅 800 ピクセルのモニターを持っている
  • 誰もがマウスとキーボードを持っている
  • 誰もが 1024 ピクセル幅のモニターを持っている
  • 誰もが高速インターネットに接続している
• 今は別の仮定に置き換わっている
  • 電話では決してやりたくない活動がある
  • すべての電話にはタッチスクリーンがある
  • だれもが電話を急いで使っている
  • 誰もが JavaScript をサポートしている電話を使っている
• 未来は不明だ