[譯] 為企業應用設計更好的表格為企業應用設計更好的表格

<b>本文講的是[譯] 為企業應用設計更好的表格，</b>

<b></b>

企業應用通常很複雜，因為要展示大量的包含多種來源、模式和使用者資訊的資料。需要先浏覽一下複雜的圖表、使用模式和資料清單，才能了解控制台的功能。

設計企業應用程式最大的挑戰是來自在特定場景中工作與否的模式示例的缺乏。

由于大多數的企業應用程式都涉及與公司相關的敏感資料，是以很少有讨論設計企業應用程式時面臨的常見問題的執行個體。現有的模式庫深入讨論了每個元件如何運作工作，但是很少涉及何時使用它們。我們在設計庫中看到的模式通常過于簡單，而實際的企業應用程式在本質上資料和用例都更為複雜，這些模式并不起作用。

這些模式在模組化倉中沒什麼問題，但是一旦碰到複雜的工作流、特定範圍的使用者類型或者大規模資料時，就不能正常運作了。

下面是一個典型的企業應用界面。工作視窗裡大量的面闆上擠滿了密密麻麻的資訊，每個面闆所訓示的資訊又和螢幕上的其他選項息息相關。

如上所述，應用程式中最耗費空間的部分是表格。本文将幫助設計師根據具體情況來探讨表格的正确使用方法。

一種過去大多面向消費者應用的模式，在企業界竟然也非常有效，并被廣泛使用。然而也沒有什麼更好的方法，隻有表格能展示龐大的資料清單。表格的作用在于企業應用的性質能夠滿足使用者同時檢視多行資料、通過警報掃描、比較資料，以及按照使用者選擇的任何特定順序檢視資料的要求。

下面的這張圖檔看起來像是一個非常正常的表格，起初可能絲毫不會質疑它的可用性。但當你進一步使用它的時候，你會發現操作起來有點奇怪。

企業應用中非常普遍的表格。

也許會跳轉到使用者的個人資料頁。

第一個例子裡，第一列上的連結可能暗示着點選後會跳轉到使用者的個人資料頁面。雖然頁面說明不是很清楚，但也不難猜到。

但是下面這個例子就未必了，你能猜到點選下圖中的連結會跳轉哪裡嗎？

這似乎是某種與每行内容有關的代碼。以這種方式設定連結，會讓使用者感到困惑。

以上是一個來自企業應用程式的真實示例，點選連結後會将代碼複制到剪貼闆。但是這個操作不是很容易了解，應該避免這種意義不明的模式。

删除、移動、列印、導出等是非常常見的操作，特别是在同時處理多個項目時。大多數企業應用程式每行都會有一個操作，這樣設定有時很有必要，因為需要對某些特定行執行操作。話雖如此，其實大多數操作可以從表格的行中推算出來，成為頁面的不同部分。

要在一行中執行的操作位于距離辨別列最遠的最右邊的列，而在本例中，操作位于第一列。

一行中要執行的操作的距離不應該遠離識别列。通常情況下，這會導緻在錯誤行上執行操作。如若不然，使用者需要在識别追蹤行上花費過多精力，并努力避免點選操作到另外的行。這種模式很容易出錯，設計時應該避免。

每行都有一個 「删除」 操作。

在這個例子中每行都重複出現一個「删除」操作。想象一下，每行有 5、6 個重複的操作選項，會讓表格看起來非常混亂。不僅如此，這樣的表格中也不能同時删除多個選項，因為沒有辦法選擇進行多選。

現代企業應用的一個示例，表格裡每項之前都有一個複選框。

在同一時間、同一個表格裡，選擇并執行多個項目上的操作的一個好的模式是每行都允許被選中。選中後，工具欄出現在表格的上方或下方，可以進行要執行的操作。

在表格裡選擇多個項目後，有一個工具欄可以對所選項目執行操作。

大多數具有表格形式的清單項的企業應用程式都遵循這種模式。但是一些設計師也發現，因為表格的每行都有複選框，是以在視覺上有點混亂、令人不知所措。

在下圖中可以看到，Google 收件箱的模式是，隻有當滑鼠懸停在該行的最左側時，複選框才會顯示出來。另外，對于操作能力較強的使用者，可以使用 shift 快捷鍵同時選擇多個項目。這是在表格上實作操作模式的一個非常好的例子。

這種模式減少了視覺上的混亂，讓使用者可以思考如何實作多選。我也是嘗試了幾次後才找到一種可以多選的方法。

由于企業應用程式的資料量巨大，是以表格通常要運作多個頁面。設計師希望了解使用者是會通過翻頁來檢視資料，還是隻檢視第一頁顯示的内容。

如果表格不需要翻頁就能檢視資料，那這種企業應用的表格模式就是成功的。

如何實作表格不翻頁就能檢視資料呢? 優秀的過濾器和強大的搜尋機制。

使用者翻頁是因為他們正在尋找特定的資訊。是以在我們設計翻頁之前，必須提出一個問題

如何才能更快捷友善地在表格裡查找資訊？

一個很好的成功解決方案是在自然語境的上下文中設定過濾器。也就是說，基于目前螢幕上的使用者工作流程，過濾器顯示與目前場景最相關的選項。

例如，在這個示範應用程式中，根據使用者的不同工作流程階段出現不同的過濾器。也許很難實作，但是一旦成功，将是使用者體驗的一個偉大勝利。

什麼時候搜尋能夠起到幫助作用？

剛剛離開目前頁面的時候..

現在我們知道了如何考慮分頁設計，無論如何這是很有必要的。我最不能忍的一種分頁方式是下圖中呈現的項目限制：

這個系統每頁展示 10 條資料。

使用者在一頁中隻能檢視 10 條資料，必須要翻頁來檢視第 11 條。為什麼不能編寫程式來檢視表格下一頁是否隻有 1 到 3 條資料，如果是的話全部展示在目前這頁呢？或者可以做得更好一點，判斷條目少于 25 項不做分頁。這些并不難實作，隻是他們并沒有多加考慮。

翻頁後多選失效。

使用者勾選了第一頁的三個選項，然後去勾選第二頁的前四個選項，邏輯上來說，他點選删除按鈕時，這 7 項會被全部删除。但是實際上并不會發生，因為分頁時跨頁面保留使用者選擇的資訊實作起來技術挑戰難度較大，成本也很高。

表格中有分頁時，選擇全部項目是另一個挑戰。使用者隻可能選擇目前視圖中的所有項，或者選擇完整清單中的所有項。

分頁時選擇全部項目可能會很混亂。

上面的例子裡，使用者先選擇了目前頁面上的所有選項，然後在整個清單中選擇了全部 3000 個選項。分頁操作後，勾選的資訊失效了。這又是由于分頁技術的局限性，因為從工程技術角度來看，保留選擇記憶的成本很高。

無限滾動或者延遲加載的效果又如何呢？

許多應用程式目前正在從全部分頁模式轉型到 Facebook 或 Twitter 風格的無限加載資訊模式。對此，設計師們各執一詞。對我個人而言，一個「加載更多」按鈕效果最好。

在目前加載的表格最後增加一個「加載更多」按鈕。

這隻會加載目前視圖中的内容，如果使用者主動執行加載更多地操作，則會加載出更多内容。

本文并不是一個設計表格的絕對正确的建議指南，隻是一個設計表格時常見問題和解決這些問題的方法的集合。如果你有任何關于設計表格的補充建議，希望你能來信一起讨論。

我是 Adhithya ，舊金山 OpenDNS 的産品設計師。

<b>原文釋出時間為：2017年7月25日</b>

<b>本文來自雲栖社群合作夥伴掘金，了解相關資訊可以關注掘金網站。</b>