在應用程式中使用 Ajax 的時機

在應用程式中使用 Ajax 的時機 謹慎決策，以避開常見陷阱並增強使用者體驗。

文檔選項 <tr valign="top"><td width="8"><img alt="" height="1" width="8" src="//www.ibm.com/i/c.gif"/></td><td width="16"><img alt="" width="16" height="16" src="//www.ibm.com/i/c.gif"/></td><td class="small" width="122"><p><span class="ast">未顯示需要 JavaScript 的文檔選項</span></p></td></tr> 列印本頁 將此頁作為電子郵件發送 討論 英文原文 層級： 初級 Jesse Skinner, Web 開發人員, Freelance 2008 年 3 月 18 日 Ajax 改變了編寫 Web 應用程式的方式。瞭解如何使用 Ajax 改進 Web 網站，同時避免糟糕的使用者體驗。 邂逅 Ajax 當 使用 Asynchronous JavaScript + XML (Ajax) 開發技術增強應用程式第一次出現在網上時，Web 開發人員肅然起敬。一夜之間，Web 網站和 Web 應用程式的潛在價值似乎變得無窮無盡了。過去，許多開發人員和使用者認為，Web 網站和 Web 應用程式只是其傳統型應用程式的一個粗燥、醜陋、複雜的版本而已。但見識了 Ajax 增強應用程式和 Web 網站之後，開發人員和使用者不約而同地意識到，在瀏覽器中可以做的事情超乎想象。隨著如今的 網頁瀏覽器擁有了處理進階文件物件模型（Document Object Model，DOM）指令碼和複雜層疊樣式表（Cascading Style Sheets，CSS）的能力，需要建立一種能夠更改、更新，以及通過與後台伺服器對話立即響應的介面，而 Ajax 給這一任務划上了圓滿的句號。但是，有時候由於太過興奮導致了使用者體驗不太理想。 Web 開發的遊戲規則已經改變了，許多開發人員一有機會就使用 Ajax 完成工作。許多網站甚至放棄了超文字標記語言 (HTML)（HTML），而轉為完全使用 JavaScript 構建網站。 創新與可預見性 Ajax 使 Web 創新成為可能，但同時增加了違背使用者意願的可能性。請記住，在向網站添加 Ajax 的同時，您也承擔著為使用者修複它引起的任何問題的責任。 如果問一般的 Web 使用者覺得 Ajax 技術怎麼樣，他（她）可能只會茫然的看著你。許多使用者都不關心他們使用的網站的構建技術。他們對好的使用者體驗更感興趣，即能夠儘可能輕鬆地完成所需的工作，至於應用程式的具體結構，就讓它安全地呆在後台吧。 本文分析 Ajax 的能力，同時探討什麼情況下使用 Ajax 將會弊大於利。希望您能從中獲得靈感，能以從未想過的方式使用 Ajax，也希望您不至於因為構建一個流行網站而瘋狂。 回頁首 擺脫重新整理 沒有比不停地重新整理 Web 頁面更加煩人的事情了。對於那些等著看自己是否贏得拍賣、關注比賽得分、密切關注天氣預報的使用者來說，Ajax 對這些類型 Web 頁面的增強可以極大地提高使用者體驗。 在 Ajax 技術出現以前，已經可以使用簡單的 JavaScript 代碼實現 Web 頁面的自動更新。但是，更新 JavaScript Web 頁面需要重新整理整個頁面。這就是為什麼 Ajax 技術在 Web 應用程式中的出現會對 Web 產生如此重大的影響。 用原來的方法重新整理頁面時，使用者無法與之互動。Ajax 頁面可以非同步地（Ajax 中的 A） 向 Web 服務器請求資料，使用者完全無法察覺後台正在處理事務。返回資料之後，只會更新部分頁面。 回頁首 Web 不需要即時 自 動更新部分頁面使使用者擺脫了重新整理之苦，但對 Web 服務器架構卻是一場災難。如果 Web 網站一天只有 1,000 個訪問者，Web 服務器也許還能夠應付。但是如果該網站的每個 Web 頁面每秒鐘使用 Ajax 重新整理一次，平均每個使用者開啟該頁面 10 分鐘，那麼該網站每天的頁面請求將暴增到 600,000 次。 為了避免 Web 服務器出現這種情況，開發人員一定要注意最小化更新頻率。如果知道資訊每隔幾分鐘才更新一次，可以嘗試將 Ajax 請求調整為相同的頻率。如果資訊每秒更新一次，則可以考慮在不損害使用者體驗的情況下儘可能延長重新整理間隔時間（比如，每 5 秒或 10 秒重新整理一次）。 還可以提供一個簡單的重新整理連結，只有在使用者需要時才觸發 Ajax 調用。這類似於瀏覽器的 “重新整理” 按鈕，但是，如果只需擷取一小部分資料，這種方法更加快捷，對 Web 服務器的要求更低。 回頁首 小變化，大影響 Ajax 的優勢體現在對頁面進行較小的修改和更新時。曾幾何時，即使是微小更新也需要重新整理整個 Web 頁面。藉助 Ajax 和 JavaScript 代碼，頁面能夠幾乎即時地進行更新。例如，可以讓頁面在添加新注釋時更新注釋列表、顯示一個關於最新條目的紙條，或者即時顯示進度條。 開 發人員的關鍵目標應該是增加可用性，也就是方便使用者。使用者在等待頁面做出反應時可能會覺得他們在浪費時間，在 Web 應用程式引入 Ajax 之前，許多使用者更傾向於使用傳統型應用程式，因為傳統型應用程式更加快捷，反應更加迅速。Ajax 增強消除了等待和滾動時間，它使 Web 應用程式的響應能力達到了許多傳統傳統型應用程式的水平。 回頁首 大變化，大災難 如果說對頁面進行小的更改可以增強使用者體驗，那麼大的改動（比如幾乎或完全替換整個頁面的內容）則可能讓使用者不知所措並導致不好的結果。 如果網站使用 Ajax 更新的速率過快，使用者可能會以為後退和前進按鈕以及書籤出現了問題。（Flash 網站與純 Ajax 網站一樣，也容易使人產生這種感覺。）使用者希望可以單擊後退按鈕返回上一頁或上一個視圖。更加不利於使用者體驗的是，當使用者再次單擊前進按鈕時，他們沒有回到剛才查看的那個視圖，而是回到了初始頁面，就像重新整理了 Ajax 網站一樣。 如 果使用者臨時載入了一個頁面，然後返回到剛才查看的網站，結果發現頁面已經變了，那麼他們可能會很失望。不幸的是，瀏覽器很可能將頁面載入為初始狀態，經常 丟失所有的更改。與此類似，如果使用者希望與他人分享某個網站的特定視圖或頁面，或者將一個頁面加入書籤，他們認為並相信只需要從瀏覽器複製 URL 並使用即可（目前確實如此）。 如果頁面的內容更改過多，使使用者感覺像是一個新的頁面，那麼還不如直接向他們發送一個新頁面。但是，如果開發人員確實需要使用 Ajax 更改頁面內容，最好使用 Ajax History 工具儲存後退和前進按鈕以及書籤功能。這些工具使用雜湊值（例如，“#tab3”）改變 URL，而無需載入一個新頁面。當使用者單擊後退或前進按鈕，或者載入一個加入書籤的 URL 時，JavaScript 代碼查看雜湊表並重建使用者希望的視圖。當然，這隻對支援 JavaScript 語言的瀏覽器有用。 回頁首 釋放 Web 頁面的資訊 您可能已經注意到了，Internet 還有另一個重要特徵：似乎可以訪問無限量的資訊，而無需在本地機器上進行複製。有了 Ajax，您可以構建一個與某個巨大資料庫（無論它位於全球的哪個伺服器）串連的互動介面，實現前所未有的功能。 Google Maps 就是這種 Ajax 應用程式之一，它集中體現了開發人員和使用者的想象力。在這個 Web 網站上，您可以瀏覽整個地球的地圖和衛星照片，而無需重新整理頁面。以這種方式釋放資料可能是 Ajax 最具價值的潛在用途。 在 Google Maps 出現之前，地圖網站已經出現了很多年，但是 Google Maps 是與眾不同的，因為 Ajax 所允許的介面是前所未有的。在傳統的地圖網站上，將視圖向西移動需要單擊一個連結。然後出現一個新頁面，它包含產生的調整後的地圖。所以必須等待頁面清 除，再次載入，然後滾動到該地圖。 這種糟糕的介面是由 Web 的根本局限性導致的。擷取 Web 服務器資料的惟一方式是訪問一個新的 URL，然後下載包含新內容的新 Web 頁面。如果希望查看當前視圖任何微小更改（比如向西移動一點），必須載入整個新地圖。由於 Ajax 允許在後台非同步擷取資料，因此無需清除和載入整個頁面。只需要載入地圖的資料和圖片片段。也可以為特定的地圖檢視窗產生 URL，但這不再是載入更多資訊的惟一途徑。 您可以使用 Web 頁面作為許多其他情境資料的介面。考慮一個分頁情境，比如查看分為很多頁的搜尋結果時。使用者介面控制項（比如上一頁和下一頁）不需要每次都載入整個新 Web 頁面。使用 Ajax，您可以非同步載入下一頁的結果，並相應地更新頁面。甚至可以預先載入下一頁，以便在使用者希望查看時立即顯示。 通 過文檔與資訊的分離，還可以加快速度並節省頻寬。大多數情況下，可延伸標記語言 (XML)（XML）或者 JavaScript Serialized Object Notion (JSON) 形式的未經處理資料比 Web 頁面的 HTML 表示形式要小，特別是頁面的剩餘部分（比如標題、導航、腳註尤其明顯）。 回頁首 將資訊留在 Web 頁面上 Ajax 開啟了從 Web 服務器擷取未經處理資料的方便之門，但這並不意味著您不再需要老式的 Web 頁面。使用者能夠通過 URL 訪問資料片斷很重要，因為這樣才能與他人分享。 Ajax 還能讓搜尋引擎抓取您的網站。針對搜尋引擎對網站內容進行最佳化不僅僅是為了將使用者吸引到網站中，它同時也是一個可用性問題。您也許通過搜尋引擎找到了大多 數要用的網站，也可能只使用大多數網站的一兩個頁面。如果網站提供的內容被隱藏在 Ajax 技術背後，那麼搜尋引擎將無法搜尋到，從而世界上大多數人都無法找到您的網站。因此讓網站的資訊可以通過傳統的 HTML 頁面瀏覽非常重要，即使還可以通過 JSON 或 XML 瀏覽。 回頁首 Ajax 可以拯救網站 Web 使用者介面通常能夠讓使用者在 Web 服務器上儲存資料，或者輕鬆建立、更新、刪除條目。 當然，這些任務總是能夠通過 HTML 形式實現，但是 Ajax 能更加便捷地在後台非同步發送資料。試想使用 Ajax 和 JavaScript 代碼簡化添加、編輯和刪除內容，它們使條目列表的管理變得更加簡單。還可以增強單個條目的添加，比如在訊息板上編寫，只需要使用 Ajax 向伺服器發送訊息，然後使用 DOM 指令碼將訊息立即添加到頁面。 回頁首 Ajax 可以毀滅網站 大多數使用者不希望 Web 網站使用 Ajax；很多使用者甚至從未聽說過 Ajax。因此，在使用 Ajax 設計頁面時，一定要確保程式與目標使用者能夠交流。例如，如果使用 Ajax 向伺服器提交一個表單或發送資料，則在發生以下動作時，應用程式必須與使用者進行交流： 正在發送或擷取資料時。此動作常常通過動態圖片指示，比如一個旋轉指標，或者通過短語 “Loading…” 或 “Saving…” 指示。 成功發送或擷取資料時。可以顯示 “Success” 訊息，也可以使用 JavaScript 動畫將使用者的注意力吸引到頁面的特定部分。 與 Web 服務器對話過程中出現錯誤或逾時。通常給出一條解釋訊息，提示使用者再試一次。 如果應用程式無法交流，則使用者將不知道到底發生了什麼事情。如果單擊 Form Submit 按鈕時什麼也沒有發生，則使用者會認為 Web 網站出了問題。如果應用程式無法提示發生了錯誤，則使用者一般會認為他們的操作成功。如果實際情況是沒有成功，那麼使用者的這種假設可能導致極度的失望，尤其 是花了很長時間完成表單內容時。如果應用程式在出現問題或逾時通知使用者，至少使用者還有機會進行複製粘貼，在本地儲存資料，從而避免了最糟的使用者體驗。 回頁首 尋找 Ajax 力量的平衡點 漸進式增強 —— 黃金法則： 為了協助確保應用程式的設計能提供最好的體驗，最好遵守漸進式增強黃金法則：首先不用任何 JavaScript 代碼開發，然後在網站開始運行後添加 JavaScript 代碼。 Ajax 使 Web 創新成為可能，但同時增加了違背使用者意願的可能性。請記住，在向網站添加 Ajax 的同時，您也必須為使用者修複它導致的任何問題。 漸進式增強 是一個 Web 開發戰略，它能確保所有的內容和功能可用於所有的瀏覽器，但是也支援更加先進的 網頁瀏覽器利用 JavaScript 編程和 Ajax 創造更好的使用者體驗。為了協助確保應用程式的設計能提供最好的體驗，最好遵守漸進式增強黃金法則：首先不用任何 JavaScript 代碼開發，然後在網站開始運行後添加 JavaScript 代碼。從根本上說，您構建一個基本的 Web 網站，讓實際連結和表單都指向真實的 URL。然後，使用 JavaScript 編程和 Ajax 更改這些連結和表單的功能。 例如，假設您希望有一個評論表單能夠使用 Ajax 提交評論，並能更新頁面以在合適的位置顯示評論，所有過程都不需要重新整理頁面。首先，像往常一樣構建評論表單，不使用任何 JavaScript 代碼，保證它能正常運行。接下來，向表單添加一個 JavaScript onsubmit 事件。表單提交時，使用 Ajax 將評論儲存到伺服器，使用 DOM 指令碼更新頁面。這樣一來，對於不支援 JavaScript 語言的 網頁瀏覽器表單也能運行良好，對於更先進的 網頁瀏覽器將會啟動並執行更好。 developerWorks Ajax 資源中心 訪問 Ajax 資源中心，這是一個一站式中心，包含用於開發 Ajax 應用程式的免費工具、代碼和資訊。在 Ajax 專家 Jack Herrington 維護的 活躍的 Ajax 社區論壇 中可能有您正在尋求的問題的答案。 有些 Web 網站完全使用 JavaScript 代碼和 Ajax 構建，我建議在任何情況下都應該避免這樣做。構建這樣的網站意味著將一部分潛在的網路人群排除在外，而且不僅僅是選擇禁用 JavaScript 語言支援的使用者。同時被排除在外的還有搜尋引擎，以及在 Web 上進行搜尋的人。此外，使用未經測試的裝置和瀏覽器訪問網站內容的潛在使用者也被排除在外。請記住，對於純 JavaScript 網站，最微小的 JavaScript 錯誤也會導致整個網站的損壞。如果有非 JavaScript 網站的支援，就可以確保不會阻擋任何潛在使用者（和潛在客戶！）訪問您的內容。 回頁首 結束語 Ajax 徹底顛覆了開發人員構建 Web 應用程式的方式，其結果可好可壞。重點在於要確保選擇在應用程式中包含的 Ajax 增強能提高使用者體驗。儘可能避免出現令人混淆的、不可預計的，以及讓人失望的情形。對於許多開發人員，這些決策可能關係著公司的成敗。 分享這篇文章…… 提交到 Digg 發布到 del.icio.us Slashdot 一下！ 參考資料 學習 您可以參閱本文在 developerWorks 全球網站上的 英文原文 。 Progressive Enhancement: Paving the Way for Future Web Design：在 hesketh.com 上查看此文，以瞭解更多有關漸進式增強 Web 開發策略的內容。 “Progressive enhancement with Ajax”：Jeremy Keith 撰寫的這篇文章也介紹了漸進式增強。 Unobtrusive Ajax （O'Reilly，2007 7 月）：瞭解開發 Web 時如何分離行為、內容和顯示。 developerWorks 技術活動和廣播：隨時關注這些領域的最新技術。 developerWorks Web 開發專區 中有大量關於 Web 2.0 開發的工具和資訊。 developerWorks Ajax 資源中心 包含不斷增多的 Ajax 內容庫以及各種有用的資源，協助您立即開發 Ajax 應用程式。 技術書店：瀏覽關於本文所述主題和其他技術主題的書籍。 討論 參與論壇討論。 developerWorks 部落格：查看這些部落格，加入 developerWorks 社區。 關於作者 Jesse Skinner 是一名自由的 Web 開發人員，致力於 JavaScript 和 CSS 的開發。他從加拿大移居到德國，主要研究如何使 Web 使用起來更加有趣，並解開了由來已久的 CSS 瀏覽器安全色性難題。如果想進一步瞭解 Jesse 或者閱讀更多有關 Web 開發的內容，請參閱他的部落格

 
轉自：IBM開發人員社區