表格中的操作設計

大多數情況下，列表中的每一排是一個item，每一個item都會有一些基本的操作，例如刪除，編輯，查看詳情。網上有各種各樣的設計列表樣稿，但是總體來說，有以下幾種比較典型的操作設計方案。在真實的產品設計中，也常會有以下幾種方案的結合體出現。

方案一：每一排都顯示具體的操作

這種方案一般比較適合各種各樣比較簡單直觀的操作設計，支持各種用戶不需要查看item detail，直接就可以根據列表上的信息做出快速的判斷并且高頻發生的操作。

Pros

操作的discoverability很高，對于新用戶來說，所有操作一目了然

對于high-frequency的操作，用戶只需要one-click就可以完成具體的操作

Cons

信息過載。尤其是舉的例子里，要是這個list非常長的話，頁面將會非常擁擠。而且這些按鈕因為視覺特征比較明顯，造成了不必要的distraction

擴展性不強。畢竟列表長度有限，操作要是繼續增加，遲早都會需要group到一個下拉菜單里去

誤操作率相對較高。同樣因為列表上的空間有限，一般操作只能放下icon，再加上幾個icon之間距離非常近，很容易一不小心就點錯了。對于危險系數比較高的操作，千萬不要采用這種設計。

方案二：只有在鼠標hover, 或者點擊某個具體按鈕之后現實操作

這種方案將操作隱藏起來，比較適用于一些操作比較risk較高，操作非常多而導致無法再列表上完全顯示，或者操作不常發生的情況。

Pros

信息密度低，可以幫助頁面突出更加重要的信息，例如Item name，item status。待用戶發現需要進行操作時，再顯示操作選項

對于risk比較高的危險操作，例如停止一個正在運行的server，這樣的做法提高了操作門檻

Cons

如果很多情況下，用戶在不需要查看詳細信息只需要通過列表就可以對項目進行操作時，這樣的設計會增加用戶的點擊次數。

操作的discoverability較低，用戶需要鼠標移到表格的某一行上，或者需要點擊一個右側的icon，才可以看到全部可行的操作。

方案三：支持multi-row action，用戶選中多個item，并且在列表上方進行統一操作

這種方案適用于用戶經常需要多個文件進行同時管理的情況。

Pros

對于用戶經常需要批量管理的列表有幫助

Cons

實現成本相較于單行操作較高，如果只有assumption，沒有真實的用戶數據佐證，產品團隊不會去開發這樣的操作。

如果不同的項目，可以支持的操作不同，邏輯會比較復雜

目前google drive的列表, gmail, dropbox都是采用這樣的設計，用戶可以對多個項目進行批量操作。其中唯一的不同是，gmail需要用戶專門點擊checkbox，來選中某一行，而google drive和dropbox是直接點擊這一行就可以選中。我猜這樣的設計主要是因為對于email來說，更多的use case是用戶查看詳細內容，所以把最簡單的操作(也就是點擊一整行)留給了這個行為，而點擊checkbox才可以選中這封郵件;然而對于文件管理系統來說，用戶更多的操作是對文章進行管理，所以點擊行就可以選中整個文件。

表格中的信息設計

列表的信息設計，也就是table header的確定，在明白了用戶在這個頁面的主要目的之外，我會主要明確三點：1)為了幫助用戶identify這個item必須要放的信息 2)可以方便用戶直接從列表頁面去的各個二級頁面的信息 3)其他需要強調的信息。把這些列出來之后，再根據真正的用戶需求進行刪減。大部分的信息呈現都比較straightforward，其中有一點值得討論的是關于item status的展示。很多列表都會有各種各樣的status顯示：例如Gmail用字體粗細來顯示已讀和未讀，也有一些dashboard用tag+文字或者改變整行背景來直接表示不同的狀態，有的會把status放在列表第一列，也有會把status放到中間。有的會把status抽象成icon，也有的是直接用文字呈現status。

不同的使用場景和用戶需求會對Status呈現有不同的需求。對于我而言，我一般會問自己三個問題：用戶來這個列表，對于status的glancibility有多強的需求，他們是否特別需要知道整個列表的overall performance?列表中有多少Status，是否都有well associated icon可以對接，還是需要自創icon去表示特定的狀態?用戶是否會在意某個特定的status，例如突然某個server down了，或者某個信息沒有發送成功?

一般來說，顏色可以解決glancibility的問題。給一整行增加背景顏視覺表達上，又強于單個status的顏色，可用于強調某個特定的狀態。(這樣的設計，需要使用得非常謹慎，因為這個特殊狀態基本在第一時間吸引了用戶全部的注意力)

如果狀態比較少并且較為常規時(例如‘成功’和‘失敗’)，可以直接用icon來表達。如果status比較特殊的話，用文字可以表達得更加清晰明確。

如果用戶在列表頁面更多的是做列表管理，那把狀態欄放在第一列是比較可行的。如果用戶主要是為了尋找某個特定的item，則可以把status放到中間，而把item name放在第一列。

Pagination V.S. Endless scroll

Pagination：分頁來展現全部的列表項目。

Pros

分頁是一種非常符合用戶認知邏輯的歸類方式。它可以幫助用戶從一個很長的列表中定位某個特定的項目。

Cons

每次到達頁面底端時，用戶需要點擊之后才能到下一頁，對于一些瀏覽性的表格來說，點擊顯得比較多余。

Endless scroll：用戶觸底之后，頁面自動顯示load more，然后呈現出更多信息。

總體來說，endless scroll在列表上適用的情況較少(至少我還沒想到~)，因為列表一般而言更加強調邏輯性，并且需要定位具體的項目。

Pros

適用于一些瀏覽性的列表，用戶更多得在獲取信息，例如pinterest的信息流(不過這個也不能算列表)，用戶可以不需要點擊就獲取更多的內容

Cons

Endless scroll，顧名思義就是很難讓用戶有一種結束的感覺，對于一個列表來說，用戶常常會不知道自己還有多少沒有看完，導致在精神上比較有負擔。畢竟“Reaching an end point provides a sense of control”

一般比較難定位一個具體的項目位置。

最近關于列表設計的思考就是這些。當然還有很多其他的沒有涉及到，例如在列表中是否需要以及如何做in-table edit，列表和數據可視化的互動，如何區分列表的filter, search以及sort的功能。

下次有機會深入設計到這些的時候再來補充吧!