- 原文: ajax: a new approach to web applications
- 著者: Jesse James Garrett
- 訳者: kentaro
- ライセンス: Creative Commons Attribution ライセンス
現在のインタラクション・デザインにおいて魅力的であると評されうるのは、どちらかといえば、Web アプリケーションを創造することであろう。つまるところ、あなたが、Web 上にないインタラクション・デザインについて誰かがあれこれいうのを聞いたのはいつのことだっただろうか（あぁ、iPod を除くとしての話しだが）。全てのクールで革新的なプロジェクトは、オンラインにある。
にも関わらず、Web におけるインタラクションをデザインする者たちは、それを手助けすることはできず、デスクトップソフトウェアを作っている我々の仲間たちに対して少しばかりの羨望を感じるだけだった。デスクトップアプリケーションは、Web には手の届かない豊かさ・応答性を持っているかのように思われている。Web が急速に拡大することができた要因となった単純さは、我々がもたらすことのできる体験と、デスクトップアプリケーションのユーザが得られる体験との間にズレをももたらすことになった。
しかし、両者の溝もやがて埋まりつつある。Google Suggest を見よ。キーをタイプするのにあわせてほとんど即座に候補が提示されるその様を、じっくりと観察するがいい。今度は Google Maps を見てみよう。地図をズームインする。カーソルでつかみ、地図をあちこちに少しずつスクロールしてみよう。再び、ページがリロードされるのを待つことなく、全てはほとんど即座に起こる。
Google Suggest と Google Maps は、我々がこのサイト Adaptive Path で Ajax と呼んでいる、Web アプリケーション開発における新しいアプローチの実例を示している。Ajax とは “Asynchronous JavaScript + XML” の略称であり、Web において可能であることの本質的な変化を表している。
Ajax の定義
Ajax は技術そのものではない。それは、それぞれに繁栄している様々な技術を、新しいやり方で強力に組み合わせることなのだ。Ajax は次の技術の組み合わせである。
- XHTML と CSS を用いた、Web 標準に基づくプレゼンテーション
- Document Object Model によるダイナミックな表示と相互作用
- XML と XSLT による、データの変換や操作
- XMLHttpRequest による、データの非同期的な取得
- それらを JavaScript によって結びつける
旧来の Web アプリケーションの動作モデルは以下の通りである。たいていにおいて、インタフェイスに対するユーザの操作により、Web サーバへのリクエストが発生する。Web サーバは、データを取得・解析し、旧式の様々なシステムとやりとりするといった処理を行い、それからクライアントに対して HTML ページを返す。それは、ハイパーテキストを媒介するという Web の元々の用途に適合するモデルではあるが、”The Elements of User Experience” の愛読者なら知っているように、ハイパーテキストにとって都合がいいからといってそれが必ずしもソフトウェア・アプリケーションにとってもいいものであるというわけではない。
図 1: 伝統的な Web アプリケーションモデル（左）と、Ajax モデル（右）との比較
旧来のアプローチは多くの技術的な意義を生み出してきたが、しかし、優れたユーザ体験を生み出してきたわけではなかった。サーバが何か処理を行っている間、ユーザは何をしているのか？ そう、ただ待っているだけだ。そして、タスクのあらゆる段階において、ユーザは何かを待っているだけなのだ。
はっきりしていることは、もし我々がアプリケーションデザインのために Web を一から作り直すとしたら、ユーザをただぶらぶらと待たせるようなことはしなかっただろうということだ。いったんインタフェイスがロードされたら、アプリケーションがサーバとのやりとりを必要とするたびに毎回、ユーザとのやりとりが止まってしまう必要があるだろうか。それどころか、アプリケーションがサーバとやりとりするのを、なぜユーザがいちいち見ていなければならないのか。
Ajax はどのように違うのか
Ajax アプリケーションは、Web アプリケーションが本来持つ「開始 - 終了 - 開始 - 終了」というやりとりを、ユーザとサーバとの仲介者 - Ajax エンジン - を導入することにより、取り除く。それは、反応を鈍くする要因となるアプリケーションにもうひとつのレイヤーを加えることのように見えるかもしれないが、事実はその逆である。
セッション開始時に、ブラウザは Web ページを読み込むかわりに、JavaScript で記述され、通常は隠されたフレームに埋め込まれた Ajax エンジンを読み込む。そのエンジンは、ユーザが目にするインタフェイスをレンダリングすることと、ユーザの利益のためにサーバとコミュニケートすることとの両方を担う。Ajax エンジンにより、サーバとのコミュニケーションから独立して、ユーザとアプリケーションとが非同期にやりとりすることが可能となる。その結果、ユーザは、サーバが何かをしているのを待ちながら空のウィンドウや砂時計のアイコンを散りばめることは決してないだろう。
図 2: 伝統的な Web アプリケーションにおける同期型のやりとり（上）と、Ajax アプリケーションにおける非同期型のやりとり（下）
通常であれば HTTP リクエストを発行するユーザによるアクションは、代わりに Ajax エンジンを呼び出す JavaScript のフォームを受け取る。ユーザのアクションに対するレスポンスの中でも、簡単なヴァリデーション、メモリ上でのデータの編集、ナヴィゲーションといった、サーバへ処理を返す必要のないものについては、エンジン自らが処理を行う。ユーザへ応答するために、サブミットされたデータを処理したり、インタフェイスを生成するコードが追加で必要になったり、新たにデータを取得したりするためになにかをサーバに任せる必要があったりした場合に、ユーザとアプリケーションとのやりとりを失速させることなく、エンジンは、通常は XML を用いて、非同期にリクエストを発行する。
Ajax を用いているアプリケーション
Google は Ajax のアプローチに対して、莫大な投資を行っている。昨年来導入された Google のプロダクト（Orkut や Gmail、最新のベータバージョンとしては、Google Groups、Google Suggest、Google Maps）は Ajax アプリケーションである（それら Ajax 実装の根幹を知るには、”Gmail Agent API - Mail Notifier - Address Book Importer * Johnvey.com” (Gmail)、”Chris Justus - Server Side Guy: Google Suggest Dissected…” (Google Suggest)、”as simple as possible, but no simpler: Mapping Google” (Google Maps) といった優れた分析にあたるように）。他には次のようなものがある。人々に好まれる様々な特色を持つ Flickr は Ajax に多くを依っているし、Amazon の A9.com の検索エンジンは、同様のテクニックを応用している。
これらのプロジェクトは、Ajax が単に技術的な意味を持つのみならず、現実のアプリケーションにとって実践的であることを示している。それは、研究室でのみ動作するようなもうひとつの技術などではないのだ。Ajax アプリケーションは、Google Suggest のようなたったひとつの機能を持つ単純なものから、複雑で洗練された Google Maps のようなものまで、どんな規模のものにも適合しうる。
Adaptive Path においてここ数ヶ月、我々は Ajax を用いた制作を行ってきたが、Ajax アプリケーションがもたらし得る豊かな相互作用、応答性の表面をなでているに過ぎないということに気づいた。Ajax は Web アプリケーションにとって重要な開発手法であり、その重要性はますます大きくなっている。これらの技術をどのように利用すればいいかを知っている開発者はたくさんいるのだから、Ajax のもたらす競争力によって優位に立っている Google に続く組織がもっとたくさん現れることを、我々は期待している。
前進せよ
Ajax アプリケーションを創造することにおけるもっとも大きな挑戦は、技術的なものではない。Ajax の核となる技術は成熟・安定しているし、よく知られたものだ。むしろ、そのチャレンジはそれらアプリケーションのデザイナにとってのものである。Web の限界について我々が知っていると思っていることを忘れ去ること。そして、もっと広く、豊かな可能性に思いを馳せること。
それはきっと楽しいことだろう。
Ajax Q & A
2005 年 3 月 13 日追記: Jesse のエッセイを公開して以来、Ajax について非常にたくさんの質問を読者からいただきました。この Q & A では、それらのうちもっとも一般的な質問について Jesse が回答します。
Adaptive Path が Ajax を発明したのですか？ それとも Google？ Adaptive Path は、Google の Ajax アプリケーション開発の手助けしたのでしょうか？
Ajax を発明したのは、我々 Adaptive Path でも Google でもありません。Google の最近のプロダクトは単純に Ajax アプリケーションのよくできた例であるということです。Adaptive Path はGoogle の Ajax アプリケーション開発には携わっていませんが、他の我々のクライアントに対しては Ajax 関連の作業を行っています。
Adaptive Path は Ajax 関連コンポーネントの販売をしたり、あるいは、商標登録を行っていたりするのでしょうか？ それはどこからダウンロードできますか？
Ajax は、ダウンロードできるような何かではありません。それは、ある種の技術を用いた Web アプリケーションのアーキテクチャについての考え方、つまりひとつのアプローチなのです。
Ajax は、XMLHttpRequest の単なる別名なのでしょうか？
違います。XMLHttpRequest は、Ajax という方法の単なる一部分に過ぎません。XMLHttpRequest は、サーバとの非同期的なやりとりを可能にするコンポーネントです。我々がこの記事全体で述べている総体的なアプローチとしての Ajax は、単に XMLHttpRequest のみでなく、CSS や DOM その他の技術に依存するものです。
なぜこのアプローチに名前をつける必要があると考えたのですか？
クライアントと打ち合わせをする際に、”Asynchronous JavaScript+CSS+DOM+XMLHttpRequest” よりも短い何かが必要だったからです。
サーバとの非同期的なやりとりをする技術は、何年も前からありました。Ajax の何が新しいのでしょうか？
実際のアプリケーションにおいて、Web の基本的なインタラクションのモデルを変えるために、これらの技術が顕著に使われていることが、Ajax の新しい点です。それらの技術や、最も効果的な使い方についての業界内の理解はすでに時間をかけて進展しており、Ajax はいまやすでに定着しています。
Ajax はテクノロジのプラットフォームなのでしょうか？ それともアーキテクチャのスタイルなのでしょうか？
両方です。Ajax とは、その両方を特定の方法で用いる技術の組み合わせです。
Ajax はどのようなアプリケーションに適しているのでしょうか？
われわれにはまだわかりません。Ajax は比較的新しいアプローチであり、Ajax をどこに適用するのが一番いいかということについて、我々の理解はいまだ初期段階にあります。従来型の Web アプリケーションモデルが最も適したソリューションであることもあります。
この記事は、Adaptive Path が 反 Flash であることを意味するのですか？
まったくもって違います。Macromedia は Adaptive Path のクライアントですし、我々は長いこと Flash を支持しています。Ajax が成熟するにつれ、時には Ajax がある問題を解決する上でよりよい方法となり、またある時には Flash がそうなることを期待しています。また、その両方を用いている Frickr のように、それらの技術をミックスする方法を模索することにも関心を持っています。
Ajax には、アクセシビリティやブラウザ間の互換性における重大な制約があるのでしょうか？ Ajax アプリケーションは「戻る」ボタンを使えなくしてしまうのでしょうか？ Ajax は REST と互換性がありますか？ Ajax 開発において、セキュリティ上考慮すべきことはありますか？ JavaScript を無効にしているユーザにとっても動作する Ajax アプリケーションを作成することは可能なのでしょうか？
それら全ての質問に対する答えは「そうかもしれない」です。すでに多くの開発者たちがそれらの懸案事項の解決に取り組んでいます。さらにたくさんの解決すべき制約が Ajax には残されていると思いますし、この先、Ajax の開発者コミュニティがそれら同様の課題をもっと明らかにしていくことを期待してます。
あなたが引き合いに出した Google のいくつかの例は、XML をまったく使っていません。Ajax アプリケーションにとって、XML と／あるいは XSLT は必須なのでしょうか？
いいえ。XML は Ajax クライアントがデータの出し入れをする上でもっとも発達した手段であるということであり、しかしそれは、同じような効果を得る上で、JavaScript Object Notation のような技術や、あるいは相互にやりとりするデータを構造化する似たような方法を用いることができないということではありあません。
Ajax アプリケーションは従来型のアプリケーションと比べて開発するのが容易でしょうか？
必ずしもそうではありません。Ajax アプリケーションは、クライアント上で動作する複雑な JavaScript のコードと切っても切れない縁にあります。それらの複雑なコードを効率的に、かつ、バグのないよう作成することは、簡単な課題ではありませんし、そのようなことにチャレンジするには、よりよい開発ツールやフレームワークが必要です。
Ajax アプリケーションは従来型のアプリケーションとくらべて、常によりよい体験をもたらすのでしょうか？
必ずしもそうではありません。Ajax はインタラクションのデザインを担当する者に、さらなる柔軟性をもたらします。しかし、我々が力を得れば得るほど、それを行使するにはより細心の注意を払う必要があります。我々は、ユーザ・エクスペリエンスを低下させるのではなく、高めるために Ajax を用いるよう気を付けなければなりません。
著者について
Jesse James Garrett は ユーザ・エクスペリエンス戦略部門のディレクタであり、Adaptive Path の設立者。2005 年、彼は “The Elements of User Experience” に関するセミナーを Boulder、Sydney、Seattle、そして世界中で行うだろう。
本文書について
本文書は、Jesse James Garrett 氏による “ajax: a new approach to web applications” を、Creative Commons の Attribution ライセンスに基づき、訳出したものです。
本文書の訳には、誤っている箇所が多々あると思います。また、日本語的にうまく訳せない、あるいはわかりにくいところは、激しく意訳しています。しかし、話のおおよその流れについては外してはいないと思いますので、細かいことは気にしないでください。
ちなみに「覚え書き@kazuhi.to: DESIGN IT! 1日目」によると、 Ajax は「エイジャックス」と発音するとのことです。また、taka 氏による下記リソースも合わせて参照してください。
- javascriptによるRIAの構想：ajax [要約]
- Ajax Q & A [全訳]
以下に、本文書のデータを示します。
- 著者: Jesse James Garrett
- 訳者: kentaro
- 初稿公開日: 2005-02-22
- 最終更新日: 2005-05-17
This work is licensed under a Creative Commons License.