重新設計 SGS 的七級導航系統：案例研究

SGS（前身為Societe Generale de Surveillance ）是一家全球服務組織，提供跨 14 個行業的檢驗、驗證、測試和認證服務。 SGS 的網站（連同 60 個本地化網站）主要宣傳該組織的核心服務，並提供對大量有用服務、補充內容和工具的訪問。 我們的目標是將 sgs.com 從僅桌面版轉變為響應式。

這帶來了一系列獨特的挑戰，尤其是在傳統導航系統方面，該系統在區域中的深度可達七層（分為兩部分），由大約 12,000 個單獨的可導航項目組成。

SmashingMag 的進一步閱讀：鏈接

• 設計案例研究：展示以人為本的設計過程
• 適應響應式設計
• 產品設計統一案例研究
• 75個有啟發性的案例研究——這就是我們建造它的方式

我們第一次看到和使用 SGS 的導航系統時的自然反應是，由於可導航鏈接和內容的龐大數量，信息架構 (IA) 肯定必須簡化。 然而，考慮到在該項目之前，導航已經針對搜索引擎和 IA 進行了優化，並且考慮到 SGS 為許多行業提供了廣泛的服務選擇（反映在內容量上），很明顯，重構 IA 不會成為解決方案的一部分。

簡單地說，導航樹的結構必須保持不變。 即便如此，這並沒有阻止我們對 IA 進行一些小的調整。 例如，“新聞、媒體和資源”和“SGS 辦公室和實驗室”被移到頂層，以提高知名度。 對於前者，重要的是更清楚地反映 SGS 定期發布新聞和舉辦活動。 對於後者，至關重要的是，它以及聯繫頁面可以從網站結構中的任何位置輕鬆訪問。 因此，關鍵問題是如何讓這樣一個龐然大物的導航系統在不同視口之間輕鬆轉換同時仍然可用？

制定項目政策

健康的客戶-設計師關係對於每個項目的成功都至關重要。 設定明確的期望並提供有效的指導不僅可以確保關鍵利益相關者始終保持專注，而且隨著項目的進展，各方之間的信任也會得到發展。 這個項目絕對是這種情況。 各方之間的合作以及對彼此角色和專業知識的相互欣賞確實非常了不起。

但是，為了確保各方保持專注，我們在啟動會議上製定了一些重要的指導方針和要求，我們也可以在這些指導方針和要求中發揮創造力（其中一些是我們堅持的，另一些是客戶堅持的）：

• 內容平價。 內容應該可以在每個設備和平台上訪問，並且在任何情況下都不應隱藏在移動設備上。
• 性能。 該網站的運行速度至少應比競爭網站快 20%。 這在決定每頁應該包含多少信息時特別有用。
• 可訪問性。 該網站必須遵守 WCAG 2.0 AA 級可訪問性指南。 由於公司的品牌，我們成功地實現了這一目標，除了邊緣顏色對比問題。
• 可用性。 內部團隊必須廣泛驗證概念並進行現場和遠程可用性測試。
• 不間斷的業務。 重新設計根本不應該破壞公司的業務。 顯然，任務不是優化公司的服務，而是優化網站，同時考慮到已建立的業務流程。 例如，我們可以自由優化 Web 表單，但 CRM 中的數據結構必須保持不變。

三大挑戰

建立了關鍵指南並且知道導航的重新設計不需要對 IA 進行重大改革，我們將重新設計細分為三個關鍵但相互依賴的活動集：

• 佈局放置。 這主要由內部團隊處理，我們提出改進建議並確保任何決定不會對新響應式設計的其他方面產生根本性影響。
• 交互性和可用性。 這些都是與 SGS 的設計團隊合作完成的。 通過電子郵件和現場研討會交流想法，並定期根據用戶、利益相關者和整體業務需求進行驗證。
• 性能。 這完全由我們處理，因為它更多的是技術挑戰，除了讓我們快速製作新的響應式網站外，不需要任何戰略決策。

佈局佈局

導航是頁面佈局的基本元素，無論網站的大小或複雜程度如何。 雖然當您處理如此大規模的導航系統時，屏幕外模式可能看起來很吸引人，但請記住，當導航對用戶不可見時可能會出現問題。

SGS 的設計團隊最初測試了各種概念，因為他們不僅要評估導航交互，還要與頁面的其餘部分建立適當的平衡並避免混亂。

決定概念

鑑於網站的複雜性，導航始終保持可見並告知用戶他們在樹結構中的位置至關重要。 我們不希望在 UI 中將導航分成兩部分，而是希望新的導航系統是無縫的（從頂層到底層）。 因此，它必須使用戶能夠輕鬆地上下瀏覽導航樹，以及橫向瀏覽主要部分。

為了測試和驗證所有這些組合，我們為八個初始導航概念中的每一個開發了一個原型。 原型證實了內部團隊已經懷疑的事情：就可用性、維護、跨屏體驗、視覺混亂和吸引力而言，最可行的選擇是將導航放置在大屏幕的側邊欄中，並顯示為小屏幕上的下拉菜單。 本質上，導航模塊在功能和視覺上都是獨立的，無論屏幕大小如何。

雖然我們將在一分鐘內專注於特定的交互決策，但值得指出的是，一旦原型概念經過測試和驗證，交互原型不一定要被丟棄。

智能原型

我們總是使用語義、可訪問和健壯的標記直接在 HTML、CSS 和 JavaScript 中開發原型，因為這樣我們通常能夠在設計過程的後期重用初始原型。 這意味著我們新導航系統的初始原型成為最終完整網站原型的基石，其中包括所有頁面模板和模塊。

在交付完整原型時，我們還確保為 SGS 團隊自動生成樣式指南。 通過讓 SGS 的設計團隊考慮設計和開發模塊，而不是完整的頁面，生成的樣式指南將需要很少的持續維護。 樣式指南本身引用了所有使用的獨特模塊，每個模塊都包含精確的描述、代碼示例和自動生成的指向使用它的頁面模板的鏈接。 我們選擇自動化任務和功能的技術是 PHP，但只要輸出是語義 HTML，就可以使用任何服務器端語言來實現自動化。 （我們為我們的原型開發了一個特定的文件系統框架，但這是另一個場合的主題。）在本文後面，我們將解釋服務器端腳本如何幫助我們維護和測試多個版本的導航。

儘管從語義、可訪問和健壯的 HTML 開始是至關重要的，但“內容優先，導航第二”的原則同樣重要，因為它可以幫助您考慮任何可能的未來異常。 在這個項目中，“內容第一，導航第二”的規則有一個例外：主頁。 根據分析，我們發現導航被視為主頁上最重要的元素，這意味著它必須位於頁面上的任何核心內容之前。

交互性和可用性

一旦決定設計和開發一個獨立的、與屏幕大小無關的導航模塊，就該專注於導航交互了。 考慮到我們在設計導航時採用了移動優先的方法，導航模塊本身不僅可以自然地在小視口中正常運行，而且還可以輕鬆擴展以在大視口中工作。

三個互動版本

由於導航的大小和嵌套級別的潛在數量，我們不得不消除一些更常見的移動導航模式作為選項——例如，選擇下拉菜單和優先級+模式。 我們專注於對導航的三個交互式版本進行原型設計：滑塊、手風琴以及手風琴和滑塊。 每個都有其優點和缺點，這自然影響了我們的決定。

手風琴

手風琴可能是移動設備上最常見的模式。 它逐步披露，隨著用戶在主題或操作中的進展，揭示更詳細的信息。 它還確保用戶不會不知所措，這就是我們想將其用作基線解決方案的原因。

以下是手風琴的優點：

• 用戶對它很熟悉。
• 用戶可以展開整個導航樹來預覽多個選項（畢竟七級導航可能有點讓人不知所措）。
• 它可以在沒有 JavaScript 的情況下工作，使用:target偽類。
• 開發它很容易。

手風琴的缺點：

• 深層類別的擴展祖先會將當前範圍推離屏幕頂部太遠，因此需要大量滾動。
• 七級導航需要所選視覺提示的七級，無論是七種基本顏色（灰色）、七級印刷層次還是七級縮進。

滑塊

這最初是我們最喜歡的解決方案，但它錯過了一個重要元素：允許真正橫向瀏覽主要部分。 如果用戶總是從主頁開始瀏覽就不會出現這樣的問題，因為他們會越來越熟悉主要部分。 但是，對於登陸導航樹深處頁面的用戶來說，這肯定是一個可用性問題。 例如，登陸第三層、第四層或第五層的用戶必須遍歷樹才能到達聯繫頁面。 無論用戶有多積極，遍曆七個級別都不是一件有趣的事情。

滑塊優點：

• 層次分明。
• 動畫很流暢。
• 它遵循移動約定。
• 它相對容易開發。

滑塊缺點：

• 無法橫向瀏覽。
• 動畫效果不佳。

混合（手風琴和滑塊）

我們真的想保持滑塊的吸引力，同時仍然允許橫向瀏覽。 因此，我們開發了一種混合解決方案，結合了兩種導航模式的最佳元素。 順便說一句，這也是我們確定的解決方案。

混合優點：

• 可以橫向瀏覽。
• 動畫很流暢。
• 層次分明。

混合缺點：

• 它需要一些初步的學習。
• 它的開發很複雜，需要考慮許多活動部件。
• 它有一些性能問題。

如前所述，用戶應該能夠向上和向下瀏覽導航樹，始終知道他們來自哪里以及接下來導航會將他們帶到哪裡。 然而，這只是基本交互——為了開發一個可用的導航系統，我們必須解決很多額外的問題。

八種不同類型的鏈接

除了當前和祖先的導航項在設計上有所不同（謝天謝地，這是一種成熟的做法），我們通過幫助用戶了解他們在哪里以及他們正在探索什麼，進一步改進了導航和一般可用性。 幫助用戶了解當前頁面及其父級以及任何相關的子級關係是遠遠不夠的。 還需要採取其他重要行動：

• 能夠直接進入父頁面；
• 能夠預覽父級和子級，同時保持原始 URL；
• 快速了解他們當前的瀏覽位置，同時能夠探索導航。
• 快速了解他們在頁面上的當前位置。

注意：我們使用麵包屑導航來確保用戶始終清楚當前頁面位置。 因為我們想完全避免跳過關卡，所以麵包屑和導航中的信息必須一對一匹配，即使是偽關卡（即沒有實際頁面的關卡）。

上面的用戶需求導致了五種語義不同的導航項，帶有額外的幫助鏈接，允許用戶在不離開當前頁面的情況下上下遍歷樹。 您可以想像如此多的活動部件帶來的複雜性和相互依賴性。

動畫細節

導航中的所有元素都使用 CSS 進行動畫處理，每個動畫都有兩個不同的部分：

• 水平動畫關卡，
• 垂直動畫包裝。

首先，通過更改主包裝器的類來切換滑塊中的不同樹級別。 例如，封閉的導航包裝器有一個.depth-0類。 展開頂級項目時，類更改為.depth-1 。 當選擇該頂級項目中的第二級項目時，類更改為.depth-2 ，依此類推。 這會產生一組相當簡單的 CSS 規則，這些規則應用於單個元素——滑塊中的最高排序列表：

 .depth-1 .l-0.nav-open > ol { left: 0; } .depth-2 .l-0.nav-open > ol { left: -100%; } .depth-3 .l-0.nav-open > ol { left: -200%; }

在上面的示例中， .l-0對應於零級列表項，而.nav-open則在手風琴設置為open時切換。 這意味著open的手風琴列表項中直接子項的有序列表絕對偏移到負左位置。

其次，考慮到每個級別包含可變數量的列表項，任何兩個相鄰級別之間的轉換必須是平滑的。

為了實現這一點，我們確保始終有足夠的垂直空間讓水平動畫順利運行。 通過檢索即將進入屏幕的元素的垂直偏移量來計算和應用高度。 這意味著我們必須考慮總共四種可能的情況，但實際上只需要解決兩種情況，每種情況的執行順序略有不同：

• 短列表項到更長的列表項。 水平和垂直動畫同時開始。
• 長列表項到較短的列表項。 導航停止水平滑動後，垂直動畫開始。

兩個動畫同時啟動，但第二個動畫在 300 毫秒延遲後啟動，這正是第一個動畫的持續時間（在 CSS 中使用transition-duration屬性指定）。 造成這種情況的原因是，當多個圖層在“幕後”消失之前重疊時，功能較弱的設備上的動畫性能並不理想。 簡化的代碼如下所示：

 if (newHeight < oldHeight) { heightTimeout = 300; } else { heightTimeout = 0; } setTimeout(function() { $('.l-0.nav-open').css('height', newHeight); }, heightTimeout);

進一步的改進

已經面臨一系列複雜的相互依賴關係，我們在測試導航時意識到還有改進的空間。

首先，由於網頁字體有時會比頁面的其餘部分加載稍晚，因此導航中原本應該在一行中的一些文本字符串會在網頁字體完全加載之前擴展到第二行。 例如，頂級部分鏈接“新聞、媒體和資源”在以後備字體呈現時分為兩行。

因為一切都必須非常緊湊（因為我們必須為滑動動畫使用絕對定位），唯一的解決方案是在加載網絡字體後重置受影響元素的高度。 這是使用由 Bram Stein 為 Adob​​e Typekit 和 Google Fonts 開發的 Web Font Loader 完成的。

 WebFont.load({ custom: { families: ['FONT_NAME_1', 'FONT_NAME_2'] }, active: function() { // recalculate things here }, timeout: 5000 });

注意：您是否注意到我們如何使用 5 秒超時？ 在我們的測試中，我們發現這是讓它在我們的基準“良好 2G”（每秒 450 KB）連接上工作的最佳點！

其次，因為我們決定有條件地加載導航節點以提高初始加載性能（下一節將詳細介紹），我們希望用戶知道有多少導航項可用，以防出現延遲在加載導航樹的一個分支。 我們通過重複一個類似於文本字符串的佔位符背景圖像來做到這一點。

最後，在請求導航分支之前，我們在 DOM 中使用 JavaScript 附加佔位符代碼。 這使 DOM 盡可能乾淨。

 element.append('<ol class="nav-loading"><li class="nav-placeholder"></li></ol>'); $.get('NAVIGATION_BRANCH_URL', function(data){ // replace the loader with the branch element.find('ol').replaceWith(data); });

表現

如果您還記得，我們​​在該項目中的主要目標之一是讓網站的性能至少比競爭對手的網站好 20%。 我們不僅實現了這一目標，而且在這樣做的過程中，我們還幫助 SGS 顯著降低了整體頁面重量和加載時間。 看一下以下前後統計數據：

您知道 12,000 個鏈接等於 3 MB 的 HTML 嗎？

這是正確的！ 當我們第一次在原型中渲染完整的導航樹時，它總共有 3 MB 的裸 HTML。 沒有頁眉、頁腳和內容——只有包含 12,000 個單獨鏈接的導航樹。

在重新設計之前，每個頁面都包含核心導航樹，每個行業頁面還包含一個行業特定的導航樹，作為一個單獨的模塊實現。 然而，桌面優化的設計使得核心或行業特定的導航不僅難以在小視口上使用，而且也難以維護。 這就是為什麼重新設計的主要目標之一是將樹整合到一個單一且易於維護的模塊中。

探索提高性能的選項

為了徹底測試導航的三個交互式版本中的每一個，並評估它們的性能，靈活的測試環境是必不可少的。 這將使我們能夠快速進行更改，並維護並發版本，以便我們可以輕鬆地將它們相互比較。

考慮到完整導航樹的大小（最多 7 級深度和 12,000 個可導航鏈接），能夠測試導航樹的部分以及完整的樹本身非常重要。 SGS 的內部開發人員能夠從他們的內容管理系統將完整的導航樹導出為 CSV 文件，這使我們能夠創建一個易於配置的 PHP 函數來輸出完整的樹或它的一部分，這取決於我們需要什麼去測試。

我們的 PHP 函數還簡化了導航樹結構的 HTML 維護，因為前面提到的鏈接標記和類名可以在一個地方輕鬆更改。 使用服務器端語言來避免重複代碼聽起來很明顯，但創建這種類型的環境不僅是一個受歡迎的補充，而且實際上是關鍵任務，因為它是敏捷實驗和測試的先決條件。

有條件地加載鏈接

我們提到我們必須有條件地加載導航節點以提高初始加載性能。 然後需要回答的問題是，最初應該加載多少導航樹，以後應該加載多少，以及何時加載？ 在測試和比較不同導航樹分支的權重和大小，以及研究現有直播網站上的用戶行為後，得出了一些有趣的結論。

首先，只對一種行業感興趣的訪問者很少訪問其他行業。 一旦瀏覽了他們選擇的行業類別，每個訪問者通常會繼續瀏覽其他幾個頁面。

其次（正如我們最初所想的那樣），行業特定的分支造成了大部分的性能開銷。 當我們完全刪除行業分支時，HTML 減少到 70 KB，比 3 MB 好多了！ 儘管如此，這意味著 14 個行業分支中的每一個都在 300 到 500 KB 之間。 當我們進一步分割每個服務分支時，我們發現每個後續級別的平均大小約為 24 KB。

雖然我們知道可以通過優化類名和通過 JavaScript 添加 DOM 節點來進一步減少 HTML（稍後會詳細介紹），但我們仍然必須確定在 300 左右啟動單個 HTTP 請求是否最好500 KB 或在每個級別發起大約 24 KB 的 HTTP 請求。 最初，似乎每次用戶在導航樹中進一步向下移動時發送一個 24 KB 的請求會更有益。 然而，考慮到網絡延遲通常是網站性能的最大瓶頸之一，這將導致通過網絡發送多個 HTTP 請求，這遠非理想。 預測任何行業分支的負載也沒有任何意義，除非用戶通過將鼠標懸停在行業鏈接上顯示意圖。

由於導航的複雜性和鏈接的數量，以下安排提供了迄今為止最好的折衷方案：

• 默認情況下在 HTML 中加載前三個級別。
• 顯示意圖時使用 JavaScript 加載行業導航，使用mouseover事件檢測到。
• 緩存加載的分支以加快連續頁面加載的加載速度。

更深頁面的邏輯有些不同，因為導航需要在不啟用 JavaScript 的情況下訪問。 因此，如果用戶（甚至是搜索引擎機器人）登陸深層頁面，則會發生以下情況：

1. 在 HTML 中渲染前三個級別以及當前頁面的祖先分支和頁面兄弟，從而允許用戶輕鬆訪問父頁面、祖先頁面和兄弟頁面，同時還能夠按照相同的邏輯訪問網站的其他部分。
2. 用 JavaScript 加載當前分支，並替換最初加載的當前頁面的祖先分支。

優化 HTML

如果你真的想優化你的 HTML，所有非必要的項目都必須卸載到 CSS 和 JavaScript。 我們嚴格修剪除有序列表、列表項及其各自鏈接之外的所有內容。 所有非必要的鏈接（即導航輔助）也從 HTML 中刪除，並使用 JavaScript 重新插入到 DOM 中（因為無論如何如果沒有 JavaScript，它們就無效）。 這些非必要的鏈接使用戶能夠做幾件事：

• 打開下一個級別（在內部，我們將這些稱為“擴展器”）；
• 上升一個級別（我們將這些稱為“支持者”——表明缺乏想像力）。

雖然生成的 DOM 仍然很大，但導航輔助工具不再需要通過網絡單獨傳輸。

最後，我們進行的最後一項優化是減少類的數量，以及縮短類名的長度； 例如， .very-long-class-name變為.vlcn 。 雖然後者產生了最大的收益，但這種優化很難證明是合理的，因為它通常不會顯著修剪 HTML 文件的大小，更重要的是，它會降低代碼的清晰度，從而可能使維護更加困難。 但是，即使從 12,000 個列表項中的每一個中刪除一個字節，也使其成為一項值得的練習和可接受的權衡。

結果？ 40 KB 左右的初始 HTML（壓縮和通過網絡傳輸時為 8 到 9 KB），每個行業 200 到 300 KB 的 HTML（壓縮和傳輸時為 15 到 25 KB）。

結論：邊際收益很重要

我們喜歡用體育界的一個類比：將每一件小事改進 1% 會顯著提高性能。 這適用於我們在 SGS 項目中所做的事情及其複雜的導航。 通過專注於更精細的細節，對每個細節進行一點點改進，我們顯著降低了導航的複雜性並縮短了加載時間，同時保持導航對用戶的吸引力和吸引力。 本來可能是一場噩夢和難以破解的難題變成了一個技術和交互相關的解決方案，足夠靈活以適應進一步的改進。

最重要的是，不斷進行原型設計、研究選項和完善最佳解決方案的設計過程被證明是非常有效的——以至於它為內部團隊在開發其他產品時應用相同的基本原則提供了一個強有力的案例在組織中，更不用說它會幫助團隊繼續完善和優化新的導航系統。 沒有一個 Web 項目是真正完整的； 待辦事項清單上總是有更多的事情。 這完全沒問題，只要我們不斷測試、完善並為用戶提供最佳體驗。