如果要用“充滿魅力”一詞來形容當前流行的交互設計，那么首推創建Web應用程序。畢竟，當你最終聽到某人傾倒于產品的交互設計，難道不是在網上？（Okay，我承認iPod除外）。所有追求酷，追求創新的新項目都是聯機應用的。
盡管如此，Web交互設計人員還是不可避免地對創建桌面應用軟件的同事懷有一絲妒忌。桌面應用程序所擁有的功能豐富性和響應能力似乎是Web目前無法達到的。簡單地讓Web應用程序迅速蔓延，會在我們所提供的體驗和用戶從桌面應用程序獲取的體驗之間形成一道鴻溝。
但現在，這道鴻溝正被逐漸填平。讓我們看看Google Suggest。根據您輸入的內容，相關的條目便幾乎立即更新。我們再看Google Maps。利用光標，在刻度線上移動來放大地圖或者縮小，所有的一切幾乎都是即時的，完全不用等待頁面的刷新。
Google Suggest
和Google Maps就是這種新型Web應用程序的兩個例子，我在Adaptive Path上把這種理念稱為 Ajax。也就是Asynchronous JavaScript + XML的簡寫，它預示著Web可能發生一次重大的變革。
Ajax
的定義
Ajax
并不是一種新技術，它實際上是幾種已經在各自領域大行其道的技術的強強結合。Ajax由以下內容組成：
·???????????
基于標準化的XHTML和CSS；
·???????????
通過
XML
和XSLT
來進行數據交換和處理；
經典的Web應用程序模型工作方式如下：大多數用戶動作在界面上激發一個HTTP請求到web服務器。服務器做一些處理——獲取數據，處理數字，與現有的應用系統進行溝通——最后返回HTML到客戶端。這樣的模型適合于以超文本為基礎的Web應用程序，但作為一個強調用戶體驗的狂熱分子（
The Elements of User Experience
一書的擁護者），我們認為超文本造就Web成功的東西，卻并不一定滿足軟件應用程序的要求。
傳統的Web應用程序模型技術上來說意義非凡，但它并不適用于創建完美的用戶體驗。當服務器在做數據處理的時候，用戶在干什么呢？沒錯，他們在等待。一個任務所需的步驟越多，用戶需要等待的次數也越多。
顯然，當我們設計Web應用程序的時候，我們不應該讓用戶傻等。界面一旦加載完成，為什么還要因為程序需要從服務器傳輸一些東西而中斷用戶交互呢？實際上，用戶為什么要看到程序與服務器的聯系？
為什么Ajax與眾不同
Ajax
應用程序摒棄了“開—關—開—關”的交互形式，在用戶與服務器之間引入了一個中間件——Ajax引擎?？瓷先ピ趹贸绦蛏咸砑右粋€層面會減少響應，但事實上恰好相反。
不同于加載一個網頁是，用戶會話一旦建立，瀏覽器就加載一個Ajax引擎——由JavaScript編寫并通常放置在一個隱藏幀內。引擎的責任包括構造用戶操作界面以及與服務器的溝通。Ajax引擎允許用戶與應用程序的交互異步進行——無須直接訪問服務器。所以用戶永遠不會在服務器處理數據期間瞪眼面對一個白屏和沙漏圖標。
?
用戶動作的處理由傳統的表單提交來激發一個HTTP請求，變為Javascript調用Ajax引擎。給用戶的回應不用等到服務器處理后返回——比如簡單的數據校驗，在內存中編輯數據，甚至一些導航功能——都直接由引擎來處理。如果引擎需要從服務器獲取些數據——提交數據給服務器處理，加載額外的界面代碼，或者獲取新數據——引擎通常以XML格式激發一個異步的請求，用戶端完全沒有被中斷的感覺。
誰在使用Ajax
Google
在Ajax開發上投入了巨大的精力。去年Google推出的幾大產品
——
Orkut
、Gmail、Google Groups最終測試版
、
Google Suggest
和
Google Maps
——
都是基于Ajax的應用。其他還包括：有著很多備受人們贊譽特性的
Flickr
（http://www.flickr.com/）基于Ajax，Amazon的
A9.com
搜索引擎也使用了類似的技術。
這些項目證實Ajax并不是一個技術性的實驗品，它可以實踐在現實世界的應用中。它也不是一種只能在實驗室中運用的技術。Ajax適用于從簡單的單函數Google Suggest到非常復雜的Google Maps等各種規模的應用程序。
在Adaptive Path，我們已經基于Ajax的理念工作了好幾個月，我們意識到我們也僅僅是接觸到Ajax所能帶來的非凡體驗的一點皮毛。Ajax是Web應用程序的一個重要發展，并且其重要性還在逐步增長。因為許多開發人員已經熟悉Ajax所包含的技術，我們期望看到更多的組織能夠像Google那樣通過Ajax獲得更大的競爭優勢。
更進一步
創建Ajax應用程序所面臨的最大挑戰并不在技術上。Ajax的核心技術是成熟的，穩定并被廣泛應用著。這些挑戰在于：應用設計人員忘掉所有我們所熟知的網絡限制，去想像更寬廣、更深遠的可能情況。
接下來會很有趣。
Ajax
Q&A
2005
年3月13日
：自從Jesse發表了該文，他收到了不計其數的咨詢Ajax問題的信件，Jesse回復了其中有代表性的問題并整理成Q&A。
Q
：
是
Adaptive Path
還是Google發明了Ajax
？
Adaptive Path
是否協助開發了Google的Ajax應用程序
？
A
：
Ajax
并不是由Adaptive Path或者Google發明的。Google最新的產品是Ajax應用程序最具代表性的例子。Adaptive Path沒有參與Google的開發，但我們在為其他的一些客戶做一些與Ajax相關的工作。
Q
：
Adaptive Path
會出售Ajax組件或者
注冊Ajax這個商標嗎
？
我從哪里可以下載到它
？
A
：
Ajax
并不是一個具體的軟件或程序，它是一種理念——關于用合理的技術構建Web應用程序架構的思考。Ajax這個名稱和它的理念都不是
Adaptive Path
私有的。
Q
：
Ajax
只不過是XMLHttpRequest的別名嗎？
A
：不是。XMLHttpRequest只是Ajax的一個組成部分。XMLHttpRequest讓客戶端與服務器的異步通訊成為可能；Ajax是本文描述的一個整體理念，它不僅依賴于XMLHttpRequest，還包括CSS、DOM和其他技術等等。
Q
：
為什么你會起這么個名字？
A
：我們需要一個簡短的表示“Asynchronous JavaScript+CSS+DOM+XMLHttpRequest”的新詞來與客戶談我們的理念。
Q
：
與服務器
異步通訊的技術產生很多年了，Ajax何以稱為新理念？
A
：
Ajax
包含的技術被大量應用在現實世界中以至于改變了Web的基礎交互模式是一個新現象。Ajax是針對現在而言，因為這些技術離工業化應用還需要很多時間去開發。
Q
：
Ajax
是一個技術平臺或者架構嗎？
A
：都是。Ajax是一系列技術的無縫集合。
Q
：
Ajax
最適合于什么樣的應用？
A
：我也不知道。因為這是一個相當新的理念，就我們的理解而言，Ajax應用還處于初期階段。有時候傳統的Web應用程序模型可能更為適合。
Q
：
是否可以理解為Adaptive Path就是取代anti-Flash
？
A
：
完全不是。Macromedia是Adaptive Path的客戶之一，并且我們長期為Flash技術做技術支持。待Ajax成熟后，我認為對于具體的問題，Ajax有時候會是一個更好的解決方案，同樣有時候Flash也許做得更好。我們也有興趣探討兩者的結合。（比如Flickr，它結合了兩者）。
Q
：
Ajax
在易用性和瀏覽器兼容性上是否有限制
？Ajax是否會與后退按鈕沖突？Ajax與REST（雷達電子掃描技術）兼容嗎？Ajax的開發有哪些安全考慮？Ajax能為那些禁止Javascript運行的用戶工作嗎？
A
：
所有這些問題的答案，我只能說“可能”。已經有很多的開發者著手這些方面的工作。要評估Ajax的所有限制，我想還需要做很多工作，我們希望Ajax開發社區能揭示更多的信息。
Q
：
你所提到的Google的一些應用中實際上并沒有使用XML。我一定要在Ajax應用中使用XML或XSLT嗎？
A
：
不是，對于Ajax客戶端，XML作為數據交換的載體是支持最為完善的（XMLHttpRequest，DOM支持）。當然，你沒有理由不接受可以達到同樣效果的技術，例如
JavaScript Object Notation
（http://www.crockford.com/JSON/）或者其他類似的數據交換的格式。
Q
：
Ajax
應用比傳統的Web應用程序方便開發嗎？
A
：也不盡然。Ajax的應用不可避免要在客戶端運行復雜的JavaScript腳本。編寫復雜并且高效穩定的腳本并不是一件容易的事情，優秀的開發工具和框架能幫助我們接受這一挑戰。
Q：
Ajax應用程序總比傳統的Web應用程序程序更友好嗎？
A
：不一定，Ajax給交互設計人員更多的靈活性。能力越大，責任也越大。我們必須小心使用Ajax去改善用戶體驗，而不是把它弄得更糟。
posted on 2006-05-08 11:19
happytian 閱讀(96)
評論(0) 編輯 收藏