如何構建複雜的 Web 表

想像一下，您為數據研究人員設計了一個系統。 或能源管理應用程序。 或者玉米交易商的儀表板。 也許你現在正在設計類似的東西。 在所有提到的情況下，人們都會期待桌子。 不是那些來自設計靈感網站的花哨的，而是具有數百個單元和復雜交互的 Excel 怪物。

在這種情況下，設計師面臨許多挑戰。 例如，將設計與現有的前端框架相匹配，或者與破壞佈局的“不舒服”數據作鬥爭。 我們將通過以下步驟克服這些問題：系統化需求、原子化和定義交互。

1. 系統化需求

因此，您已經採訪了目標受眾並了解了他們的需求和需求。 現在是時候拼湊研究結果並將其轉換為界面結構了。 例如，一位用戶說，“我需要了解我的數據如何影響應用程序的其他部分。” 或者在觀看另一個人使用舊軟件時，您會注意到他使用快捷方式並且根本不觸碰鼠標。 這是什麼意思？

第一個用戶的話是關於輸入驗證和提示的。 您需要考慮將警報或幫助信息附加到表格中。 或者開發一個有意義的顏色系統。 這取決於領域和心智模型。 觀察第二個用戶的工作可能表明您需要設計所有可通過鍵盤訪問的操作。 您可能需要考慮比“ Cmd + C ”和“ Cmd + V ”更深刻的快捷方式。

以下是一些觀察-假設對。

• “我需要一次輕鬆地操作幾十個項目。”
  允許單元格多選？ 添加複選框以選擇多行？
• “現在我們以這種方式進行所有計算。” [顯示 Microsoft Excel ]
  Excel 對這個目的有效嗎？ 我們可以藉用哪些功能？
• “我們能不能事先知道這個名字是否已經在服務器上。”
  即時數據驗證？ 錯誤消息或自動更正？
• “通常我會輸入這些信息。 這很一般。 ”
  建議默認值、默認值或模板？
  

結果，您將獲得一份人們的需求和願望的清單。 開放式問題有助於找出真正的需求並過濾掉突發奇想：

“什麼可以幫助你更快地工作？ 什麼能讓你的選擇更容易？ 此功能如何影響您的工作效率？ 如果你不能做 X 會有什麼變化？”

下一個是什麼？ 現在是時候為您的表格構建邏輯框架了。 它包含和能夠做什麼的方案。 如果您直接進行線框圖或原型製作，您將踏上無休止的重繪和與遺產作鬥爭的邪惡道路。

以下是您可能開始的示例。 它是特徵樹。 任何表格的基本構建塊都是一個單元格。 單元格合併成行和列，它們可以具有不同於單獨單元格的特定特徵。 最後，我們討論了表格的重要補充，例如帶有按鈕、鍵盤命令和處理錯誤的頂部欄。

功能樹可以防止您進行額外的工作，並有助於專注於重要的事情。 組織良好的功能樹對開發團隊也很有幫助。 他們可以將計劃的功能與可用的前端庫相匹配，並找到將設計轉化為代碼的最佳方法。

在我的一個項目中，我們使用了 Angular Material 框架。 不幸的是，Angular 表格太簡單了。 我們找到了一個支持我們的功能但有一個限制的 ag-Grid 庫。 它無法擴展行並將子行放入其中。 在我們投入任何精力並調整設計之前，我們已經揭示了這個問題。

簡而言之

• 開始構建一個複雜的表格，收集並確定用戶需求的優先級。 考慮一個非表格解決方案，例如圖表。
• 繪製一個樹形圖，將所有需要的功能係統化。 將其用作製作視覺效果的計劃。

推薦閱讀：陳慧靜的 Web 上的表格設計模式

2. 原子化

因此，定義了需求和功能，並且您知道技術限制。 是時候模擬你的桌子了。 基本上，原子方法是先設計小的 UI 組件，然後組裝更大的組件。 我們將逐漸從像字體和顏色這樣的基本粒子轉移到像標題或列這樣的大模塊。 我特意為模型選擇了嚴格的野獸派風格，這樣我們就可以專注於功能，而不是外觀。

字體、顏色、圖標

這些部分可能已經由您使用的設計系統或 UI 框架定義。 如果您為現有產品創建表格，請檢查其調色板、字體和圖標是否滿足表格需求。 在下圖中，我展示了表格框架、線條、填充和文本所需的一些灰色陰影。 紅色和藍色色調代表警告錯誤破壞性和活動啟用選擇的東西。 文本樣式用於區分主要和次要信息、標題和正文。

電池和配件

當表原子準備好後，我們可以繼續處理分子——不同類型的細胞。 首先，重要的是事先考慮每個元素的正常、懸停和活動狀態。 然後進入clicked、disabled等狀態。

在我的一個項目中，我們有八種類型的細胞具有自己的相互作用。 最簡單的是文本和數字單元格。 在我們的案例中，允許使用非數字內容填充數字單元格，例如“N/A”（未應用）和“N/C”（無控制）。 這是該領域的特殊性。 下拉菜單和日期選擇器更複雜，並且有子元素。 最後，我們有代表行內命令的表格單元格。

單元格可以有工具提示、輸入提示、錯誤消息、佔位符等附件。在這個階段，它們是靜態的，但設計者應該稍後指定它們如何顯示的邏輯（動畫、延遲等）。

行和標題

設計單元格時，您可以製作行並查看各種組合是否可以很好地協同工作。 有一次我設計了一個具有復雜編輯邏輯的表格。 一些屬性是由用戶提供的，而其他屬性是自動計算的或使用默認值填充的。 下面是一行中只讀和可編輯單元格的混合。

請注意，將鼠標懸停在只讀和可編輯單元格上時，光標是不同的。 單擊它們會觸發選擇一行或進入可編輯單元格的編輯模式。

在下圖中，您可以看到人們可以選擇一行或多行：

現在是時候考慮表頭了。 根據我的經驗，控制列標題長度並堅持一行通常是不可能的。 即使團隊中有一位優秀的作家，你也不會讓所有的文字都簡短。 有些表格需要較長的技術標題或本地化。 短語在英語中是單行的，在希臘語、德語或匈牙利語中可能變成兩行或三行。 因此，我展示了不同的變體：

基於數據的軟件的用戶通常需要排序和過濾。 它可以幫助他們在大量數據中找到有價值的信息。 排序和過濾的挑戰是將排序控件和過濾框與其他標題元素（列標題、度量單位等）結合起來。

與表格單元格不同，過濾框通常在右側有“重置”圖標，以便用戶可以明確禁用它們並查看未過濾的內容。

在我的示例中，有三種類型的過濾器框。 字母數字過濾器支持按字母和數字進行搜索。 它支持通配符——未知數量的未知字符。 例如，如果我鍵入45*A1 ，它可能會導致顯示具有45A1 、 45982A1B 、 45A109B和096445-A1 。

通配符是一個棘手的功能，因為它們取決於人們的習慣。 當我為技術專家設計表格時，我們將星號 (*) 分配給未知數量的未知符號。 對於保險分析師，我選擇了傳統的 SQL 符號——百分號 (%)——因為他們已經習慣了。 至於下拉過濾器，它在一定數量的互斥文本選項、數字或數字範圍之間切換。

日期選擇器過濾器有一個日曆，其工作方式與它的單元格等效。 允許用戶手動輸入日期並從日曆中選擇是很好的。 如果他們知道他們在搜索什麼，那麼輸入比點擊要容易得多。

更重要的一件事是自動格式化任何有意義的輸入，而不是用“無效格式”錯誤來打擾人們。 在我的一個項目中，我們允許輸入諸如01/25/2017 、 6.12.17和September 4 2016等日期，並且還可以僅按月或年過濾。

列

複雜表的常見功能之一是固定列。 通常，包含關鍵信息（例如元素名稱或狀態）的列是不可滾動的。

儘管表格列應該巧妙地適應內容大小，但它會在文本被截斷時發生。 在這種情況下，調整列大小很有幫助。 用戶可以拖動列邊緣並查看長內容。 他們可能還需要壓縮不重要的列或帶有短文本的列。

處理長文本字符串的另一種方法是按最長的內容拉伸一列，或者將其包裝並放在多行上。 第一種方法對於或多或少相似的文本字符串效果更好。 如果看到完整的內容對人們來說比保持表格垂直緊湊更重要，那麼第二個效果會更好。

在我的一個項目中，我們定義了列的最小寬度，以防止表格大小調整不當。 根據內容類型，我們禁用了在特定寬度後面的擠壓列。

頂欄

什麼是表？ 單元格、列、行。 此外，複雜的表格通常有一個頂欄。 與其他組件一樣，頂部欄由較小的元素構成——標題和命令。

下面，我收集了我們在其中一款產品中使用的各種狀態的命令列表。 我們有用於明顯隱喻的圖標命令，例如plus = add / create 、 trash bin = remove 、 arrow = move 。 非通用命令（例如，assign、archive、balance）需要明確的文本命名。 此外，一些命令伴隨著一個下拉菜單。

現在我們可以嘗試組合不同的元素，看看它是否有效。 這裡有些例子。

當然，這不是功能和元素的最終列表。 它因項目而異，可能包括其他內容，例如：

• 按多列排序；
• 可定制的一組列（能夠切換它們）；
• 可擴展行（父行可以有子行）；
• 用於過濾和搜索的邏輯運算符（“and”、“or”、“else”等）。

如果您猶豫要設計哪些功能，哪些不設計，這裡有一個很好的原則。 這是奧卡姆剃刀，或簡約法則。 如果現有實例滿足需求，設計師不應創建新實例。 您應該“削減”用戶在未定義的未來理論上可能需要的令人討厭的功能。 理想情況下適合一百種情況之一但在其餘九十九種情況下無用的功能也是如此。

整桌

當所有構建塊都準備好後，您可以為各種目的組裝幾張桌子。 這是一個發現不一致的機會。 我最常處理以下三種類型。

只讀表

構建最簡單的表類型，因為它只顯示原樣數據。 沒有過濾或編輯選項。 排序或行層次結構可能有助於分析大量數據。 這樣的表格用於顯示數據，告知人們某事。

搜索表

單元格不可編輯，標題有過濾框和排序控件，可以選擇行。 從我的實踐來看，這樣的表格有助於在大範圍內查找、比較和選擇一個或多個項目。 例如，從目錄中篩選出六千種不相關的工具中的五種，然後選擇一種需要的工具。

可編輯表

所有或部分單元格都是可編輯的。 通常，沒有過濾，因為行的順序可能是自定義的。 此類表通常帶有工具欄，並允許對行執行操作。

簡而言之

• 從最小的組件開始，然後逐漸轉向更大的組件。 最後，模擬整個事情。
• 事先考慮每個組件的所有可能狀態。
• 使用奧卡姆剃刀原則來保持元素的數量最少但足夠。

推薦閱讀： Alla Kholmatova 的設計系統

3. 定義交互

對於像表格這樣複雜的界面部件，構建塊是不夠的。 設計師應該考慮“遊戲規則”並設計視覺部分背後的邏輯原則和約定。 我將描述一些您需要考慮的典型事情。

數值數據

表格中的數字應該有多少位小數？ 一、二、五？ 最佳精度水平是多少？ 我根據用戶做出正確決定所需的準確性做出決定。 在某些職業中， 10932.01和10932.23之間的波動很重要，而在其他領域，數字14和15並沒有真正的區別。

這是我的團隊在復雜的工程產品中使用的數字數據規則的示例。

• 長度
  兩位小數（57.53 m，3.16 km）； 空格用作千位分隔符 (403 456.56 m)。
• 重量
  兩位小數（225.08 kg，108.75 t）； 空格用作千位分隔符（12 032.17 kg）。
• 錢
  兩位小數（9.45 美元）； 逗號用作千位分隔符 ($16,408,989.00)。
• 直徑
  三位小數（10.375 厘米）； 不需要分隔符。
• 緯度和經度
  八位小數（26.4321121）； 減號用於西經和南經 (-78.05640132)。
• 默認
  對於上面未列出的單位——兩位小數（32.05 g/m³，86.13 C°）。

我們考慮的另一件事是保存在服務器上的“真實”數據與界面中的“近似”數據之間的差異。 該系統在所有計算中都使用了具有數十位小數的極其精確的數字，但人們並不需要一直看到它。 因此，我們決定顯示上述小數位數，並僅在表格單元格處於活動狀態時才顯示完整數字。 例如，工程師可以輸入134432.97662301 ，一旦他按下Enter ，表格就會顯示134 432.98 。 再點擊一次，工程師又會看到134432.97662301 。

輸入驗證

與前面關於數字的項目不同，驗證僅對可編輯表很重要。 它有兩個方面。 首先，將輸入的數據限定為有效或無效的規則。 其次，有助於糾正無效數據的消息或自動修復它的機制。 通常，驗證規則過於復雜，無法在模型或原型中反映出來。 因此，設計人員可以以文本或流程圖的形式記錄它們。

這是我曾經使用過的消息模板示例。 尖括號中的文本是動態的，來自計算引擎或數據庫。

• 應大於number measurement unit 。 Optional explanation 。
• 應小於number measurement unit 。 Optional explanation 。
• 應該在number 1和number 2 measurement unit之間。 Optional explanation 。
• 最小值應小於最大值。
• 最大值應大於最小值。
• 最小值和最大值不應相等。

命令

在啟用和禁用工具欄命令時，帶有工具欄的可編輯表通常需要一組規則。 這些狀態可以取決於選擇行的事實、所選行的數量、所選行的位置或內容以及其他條件。 以下是記錄此類邏輯規則的眾多方法之一。

所以，我們有一張桌子，裡面有一些化學品。 它具有“添加行”、“上移”、“下移”、“刪除”、“重新計算”和“設置”等命令。

這裡是命令狀態的描述。 事實證明，它們的可用性取決於一個或多個條件。

下一步是定義每個命令的結果。 例如，當我選擇兩個遠程行並單擊“上移”時會發生什麼？ 或者點擊“重新計算”的結果是什麼？ 所有這些問題都應該得到回答或至少事先考慮。

容器和響應性

表格將如何放置在界面中？ 例如，它會佔用現有容器內的一些空間還是一個單獨的模塊？ 這些問題的答案完全取決於產品，最好預見可能的問題並徹底定義原則。

當我設計 Web 應用程序時，我通常會考慮至少三種類型的表容器。 最典型的情況是一張大桌子是屏幕的中心，並且佔據了盡可能多的空間。 這樣的表格可能沒有自己的標題，因為整個屏幕都專門用於處理表格。 中小型表格可以成為儀表板的自主模塊以及圖形、圖表、方案等其他項目。 在這種情況下，表格的頂部欄起到卡片標題的作用。 最後，在大型企業應用程序中，表格通常存在於彈出對話框中。 應該有明智的指導方針，以免對話因內容過多而崩潰。

在 UI 環境中放置表格的另一個方面是可用的屏幕區域。 大多數企業應用程序主要用於桌面。 桌子響應僅限於簡單的拉伸和擠壓行為。 通常，具有大量行和少量列的表格佔據 100% 的可用寬度。 結果，單元格在屏幕上均勻分佈，並且可以顯示更多文本而不會截斷換行。 另一方面，柱之間通常會出現巨大的間隙，這與鄰近的設計規律相矛盾。 這就是為什麼一些應用程序使用行之間的線條或白底灰色斑馬著色來使信息更易讀的原因。

更好的方法是定義合理的默認寬度並在需要時允許手動調整大小。 對於閱讀表格，最好在右側留一些空白區域而不是列之間的間隙。

如果一個表同時包含許多行和列，水平和垂直滾動是不可避免的。

複雜表的關鍵本質是大，從而提供數據的鳥瞰圖。 不幸的是，我無法說出在智能手機屏幕上使用大表格的真正好方法。 Excel 和 Google 電子表格在小屏幕上失去了作用，儘管有處理小表格的有效方法。 例如，將一張桌子轉換為一組卡片。

可訪問性

即使是一張特別光滑漂亮的桌子也可能成為用戶的噩夢。 因此，遵循可訪問性原則非常重要。 Web Content Accessibility Guidelines (WCAG 2.0) 有一章是關於表格的。 大部分材料都是關於正確編碼的； 然而，設計師也有很多事情要考慮。

以下是可訪問性方面的主要設計考慮因素。

• 給一個標題並準備一個簡明的摘要。
  視障用戶應該能夠理解表格的概念，而無需對其所有單元格進行語音處理。
• 注意字體大小。
  儘管網絡沒有官方的最小尺寸，但 16 px (12 pt) 被認為是最佳尺寸。 此外，用戶應該能夠在不破壞整個佈局的情況下將其增加到 200%。
• 為有色盲的人測試顏色。
  文本和控件應該與其背景有足夠的對比。 顏色比 3:1 是最低要求（越多越好）。 此外，顏色不應該是標記事物的唯一方式。 例如，錯誤消息不應僅依賴於紅色文本，警告圖標將為色盲用戶提供額外的線索。
• 避免小的和模棱兩可的控制。
  如果可點擊組件至少為 40×40 像素，則它們被認為是觸摸友好的。 由圖標表示的命令應帶有標籤或具有工具提示和替代文本。 設計師不應過度使用圖標，因為用戶可能無法正確理解複雜的隱喻。

您還可以使用在線工具來檢查可訪問性，例如 Wave。 它不僅會發現可訪問性問題和功能，還會直接在頁面上突出顯示它們並解釋如何修復它們。

簡而言之

• 內容統一和格式化也是設計師的工作。
• 超越“事物”、界面元素，考慮用例和常見模式。
• 當內部的所有內容都一致且兼容時，就該考慮它如何適應界面的其餘部分了。

結論

我們剛剛完成了構建複雜表的過程。 不同的項目需要不同的方法，但有一個通用的原則。 設計師應該讓所有元素以任意組合方式協同工作。 這就是為什麼最好先收集需求並先製作小塊。 當然，一旦你有一些可點擊和現實的東西，就立即與用戶進行測試。

延伸閱讀

• “原子設計”，布拉德·弗羅斯特
• “設計更好的數據表”，Andrew Coyle
• “重構 UI”，Adam Wathan 和 Steve Schoger