如果要用“充滿魅力”一詞來形容目前流行的互動設計,那麼首推建立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;
通過DOM(Document Object Model)實作動态顯示和互動;
· 通過XML和XSLT來進行資料交換和處理;
使用XMLHttpRequest通過異步方式擷取資料;
使用JavaScript來整合以上所有的技術
經典的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去改善使用者體驗,而不是把它弄得更糟。