asp 设置table 间距_B端后台表格（table）如何设计
(全文共計6908字，閱讀約需要17分鐘)
引言
目前在一家制造業軟件提供商工作，經手的軟件產品大多以承載數據信息為主，為保留原有的底層數據邏輯且兼顧開發工作量，整體界面需要復用度高，拓展性強，故而大部分界面皆以表格進行展示。
1. 可承載大量同類信息及數據，且結構簡單，分類清晰，便于用戶瀏覽；
2. 橫向關聯縱向對比的信息處理方式，幫助用戶快速了解并簡單分析信息的差異性、關聯性等；
3. 對于大量數據信息，在保留現有視覺結構的條件下，可直接使用其他通用功能件，進行搜索、篩選、編輯、批量操作等其他自定義選項操作；
4. 表格中各列內容相對獨立，可根據業務需求或用戶關注點的不同進行自定義調整。
一般來說，表格組件內功能復雜(常用功能有：單對象操作、排序、多選、翻頁、抽屜展開、合計等；特殊場景還需支持：單元格編輯、單行編輯、調整展示列、多層級嵌套、分類等)為提高效率，一般會根據需求找到合適的組件內嵌至頁面中。后臺界面通用的功能很多，兼顧視覺和代碼一致性，會直接使用一種前端框架進行開發。
在我入職該公司之前，所有產品都是前后端未分離的，僅能根據原有的界面進行樣式的優化，涉及到交互和用戶體驗優化的部分十分抗拒且表示難以實現，與新老同事多次溝通后，領導決定實行前后端分離，考慮UI框架的選擇。
1. UI框架介紹
目前國內主流UI框架且個人工作過程中接觸使用過的有：
以及其他不太常用的框架(鏈接跳轉至表格組件)：
真正投入開發時，一般只會考慮主流的三種，資深前端D同學說：學會三框架走遍天下都不怕。
不常用的框架有些UI視覺也不錯，國外用【Vuetify】比較多，交互豐富，基本上所有的操作都會給一個過渡的動效。【Ext】比較有年代感了，以前公司用的就是這個2.0版本，現在的新版本樣式其實也不丑。【飛冰】整體樣式和【Ant design】差不多；【layui】的組件看起來有些單調，基礎后臺界面個人覺得還是比較能滿足的。
—
作為設計師，個人比較喜歡使用【Ant design】資源很全，下載的sketch源文件基本能滿足大部分通用功能，很多控件(比如：各類選擇器、穿梭框等)的視覺與交互體驗也相對較好，可直接復制組件粘貼至設計稿中。
但前端同學更傾向于【Element】組件封裝簡單容易修改，對于沒接觸過框架的同學也方便上手無障礙。【iView】的組件封裝過于嚴密，且收費，不太喜歡用。而威名赫赫的【Ant design】雖也支持Vue但Vue版本的表格列寬不可拖拽，必須設置寬度，鎖定列時，內容太多易導致表頭留白等不算是坑的麻煩，且需要看大量文檔適應，學習成本較高。
—
通過綜合考慮，項目組決定使用【Element】。
2. 主流框架內【Table】組件對比
① UI樣式對比：
各官網示例出的默認組件樣式有些許區別，【Element】與【iView】直接列出了不同給的樣式類型， 而【Ant design】是結合功能綜合展示的。樣式皆可根據相對應的參數進行修改，前端同學在開發過程中可直接按照設計稿的標注進行修改樣式即可。個人認為如果風格一致，直接使用組件默認樣式也是可行的。
截取各官網中 Table 的基礎界面樣式，如下圖：
由上圖可以大概看出，三種表格內列寬的定義是不同的。實際工作中，后臺不同數據字段的表格，會出現特殊的極少數列(2-4個)、或多數列(超過10個)，實現起來并不能跟設計稿一樣完美好看，web端后臺界面，除了根據柵格系統進行模塊區域劃分。部分組件化的交互需要同開發溝通，定義一個基本規范，且最好能兼顧全局大部分場景。
未進行前后端分離時，我出了一版基本的表格樣式規范。整理需求發現幾乎所有的表格都有序號與復選操作，故而直接整合至基本用法中。如下：
當使用組件時，并不需要設置間距等規范，可直接選擇一種一般不會有太大問題。更多的是關注表格中承載的數據字段類型。比如：
文本字段：可點擊的字段、普通文本類、數字字母等，此類長短參差不齊的，最好給出左對齊；
既定字段：日期、時間、部分枚舉類等，字符數一致且較短的，可與表頭標題居中對齊；
特殊字段：金額、狀態標簽、類型標識等業務性較強的，可根據相關特性與閱讀習慣確定其對齊方式。
不論何種對齊方式，都需要考慮到該字段可能存在的極端情況。比如：普通文本若超長，可在鼠標hover狀態時將該單元格展開列出全部字段信息。或以tips形式，跟隨鼠標位置展示全部信息。
當數據信息平鋪且單一時，直接使用表格的基礎用法，也能滿足需求，視覺與交互能夠滿足大眾審美和習慣即可，一般不會有太大的問題。上家公司是做類C端門戶網站的，后臺管理系統直接用【Ant design】作為數據統計信息展示完全足夠，運營同學使用時也表示還算滿意。
但B端后臺界面除了承載信息，還有很多相關的操作與處理。公司的產品供給制造商使用，數據文檔量大且類型繁雜，并且相互間有不同的關聯關系。很多情況下需要重新根據需求設計，且為了兼顧開發工作量盡可能的在設計上找到折中方案。這就要求最好能夠從框架組件中衍生出來，最少的修改滿足更多的需求。
② 組件功能對比：
因我們已確定使用【Element】故而以下所有的對比，以此框架中的 Table 組件功能為基準，進行功能有無與相關差別性的部分比較。
在后臺開發的實際工作中，以上的功能基本可以滿足所有需求。其中【Ant design】【iView】的示例組件中部分上表未列出的功能也相當實用，比如：【Ant design】可編輯單元格與單行，在后臺表格中是個體驗非常好的功能，簡化用戶操作；【iView】可自定義導出表內數據也很常用。
需要注意的是：
無論什么樣逆天的交互樣式與功能需求，開發同學都能夠完美解決。此處列出僅為了設計師了解熟悉相關組件，在工作中能夠更好與開發協作，盡量減少開發同學的工作量。畢竟在一個為傳統制造業提供軟件的企業，相比于底層數據處理與接口的聯調，前端樣式展示就顯得無足輕重了，甚至很多人認為夠用就行，這也是設計工作較難推進的一點。
由上對比看來【Element】與【Ant design】功能基本一致，但其相同的功能也會存在一定的差異，此處不過多贅述，功能相似的基本上都大同小異。至于具體樣式與交互方式，可以根據個人審美或企業需求綜合選擇。當我們在工作中遇到該框架中沒有的組件，又正好發現某個組件剛好能夠完全滿足需求時，也可以考慮將其嵌套使用。
作為公司第一個且唯一一個設計，老同事們并不理解需要給設計師何種需求原型與文檔。很多時候，我收到的需求就是一堆屬性項名稱，一張紙質表格，一句話，或者一個功能名稱。在沒有任何業務閉環與字段說明，并且明確了最好以表格形式展示的情況下。為了趕工期，大多數時候只能腦補需求后直接進行組件的選擇，與開發和業務人員溝通后，再來基于組件功能進行設計，相當于需求、設計、開發并行的工作流程。
下面例舉出最近部分工作案例，供大家參考。大致從需求分析、組件選擇、以及設計落地三個方面進行適當說明。(涉及到公司專項業務的部分會使用其他文案替代)
1. 報銷單
當時收到的需求就是一張報銷填寫的單據，需要粘貼各類發票給財務的那種，類似下圖：
主要以長途交通費為主，其他相關費用標明事由金額即可，后附上發票。線上填報時項目組確認不需要上傳發票照片，即不用上傳附件。而其他的補助等相關信息皆可由表單或其他流程直接帶進來，并且各類金額匯總由后臺自動獲取。故而表格內需要設計的僅有費用相關的說明，且我司取消了同城出差與補助，基本上長途費用就成了主要內容。
添加任一行內容，必須完成時間、出發地到達地、交通工具、金額。很明顯需要Table組件支持單行編輯，并且可添加多行。而【Element】示例的組件中，并無相關展示，但下載的UI資源中有相關的樣式，可以將表單樣式與表格樣式結合使用。
與開發溝通后，決定使用該組件。編輯框直接嵌套【Element】框架中的表單樣式，最終落地的設計稿如下圖：
其他相關的費用通過另一組表格進行展示，沿用長途交通費的表格樣式，給出一個默認的狀態，供開發參考。盡量用最少的界面展示最全的狀態，當然，也需要在評審時提醒開發同學注意。此處我們點擊添加一行后，直接聚焦在新一行的第一個編輯框中，該功能雖常見，但若不出交互動效展示給前端，很可能會被忽略，故而設計稿出完還是需要加以一定的設計規范與交互說明。
報銷單的編輯樣式完成后，領導及用戶的反應都比較好。且該 Table 組件在后來的報價單、組織成員、二維表屬性等功能模塊復用率很高。
2. 項目管理
制作該功能的時候，收到的需求僅有幾十個屬性項，整個業務閉環與字段說明全都沒有。
前期與相關的業務同學溝通多次無果，因為他也沒有收到明確任務目標且不太了解產品需求規劃，所以我根據自己做項目的經驗初步梳理了整個流程，并且給出了部分字段說明讓他了解后完善。
通過梳理流程閉環與相關字段的確認，并且要求以表格的形式展示。可大致整理出表格設計需要著重考慮的幾個功能：
1.所有關鍵屬性項必須展示在表格中，則存在橫向滑動，需要支持固定表頭與豎列；
2.階段展開是任務，且任務下存在子任務，則表格支持樹狀結構展示；
3.階段與任務的屬性項不同但同一表格內展示，則會存在部分單元格為空；
4.相似字段樣式需要進行區分，單元格樣式需要自定義；
5.完成后上報的任務，可修改部分字段，需要支持單元格編輯，并且最好能篩選與批量審核。
以上所有需求【Element】官網的 Table 示例中并無可滿足的組件。但所有功能都是支持的，故而我們可直接使用，前端同學設置對應參數即可。
部分表單屬性項較多，不過大多字段不長，且需要固定列，所以我選擇帶邊框的樣式；樹形結構，支持多選。基本上為以下幾種功能進行組合使用：
其中，單元格的編輯雖在官網示例中未給出樣式，但資源中的展示有一版如下所示：
個人認為該交互操作略顯繁瑣，故而沿用了報銷單類似的編輯操作。根據需求的不斷完善與組件的確定，也能夠大概出一版界面供開發先行，至于未確定的字段與數據處理等相關需求，直接讓后端同學接口控制即可，主要表格的落地稿如下：
① 項目：該表格一般樣式用法，沒有過多的操作，主要就是相關字段的展示，部分數據需要進行區分，增加識別度即可。
比較常規的組件用法，重點在于各字段的展示方式要進行區分，并且根據各狀態的不同，其中的字段會有一些相應的變化。比如：
多個時間相關字段：持續時間、開始/結束時間、驗收時間等。要想提高各字段的識別度，可以將字段的樣式進行一定變化，并不一定要使用純文本樣式。可增加icon進行識別，根據狀態判斷需要展示的文案類型等都是比較好的方式，并且當界面滑到右側字段時，也可以一眼看出該行項目的狀態，無需再左滑查看狀態列。
② 階段任務：該列表比較復雜，且根據不同的用戶權限，列表上方的按鈕和表右側操作列也有所區別，此處僅給出表內通用設計進行展示。
階段和任務分屬兩個不同的對象，在此列表中。默認僅平鋪展示階段，故表頭所列的屬性項以階段為主(此處考慮到部分字段的重要性，將任務“優先級”也展示了出來)；非任務屬性項的則以通用的“-”進行標識。共有屬性比如：“狀態”，則通過不同的標簽進行區分。
任務列表與該列表樣式基本一致，僅屬性項的差異，特殊字段樣式也根據其業務特點進行了不同的字段展示方式，此處不過多贅述。
③ 工時上報與審批：與任務列表的屬性項沒有太多差別，報工列表底部增加了工時的合計(此功能在【Element】示例組件中有展示樣式)，然后去掉了結構層級，所有的任務進行平鋪展示。
但我上報的列表與領導審核的列表功能存在一定的差異：審核的列表可進行編輯。一般來說審核工時與上報的工時沒有差別，為了減少審核的工作量，可在列表上方進行篩選后，全選批量通過審核，無需單個操作。故而此類別右側的操作改為“修改工時”直接在單元格內進行修改。
當然，編輯單元格的交互并不至這一種；也可參考【Ant design】中編輯單元格功能，hover展示編輯框，單擊后直接可編輯。
無論是項目、階段還是任務，確定好了表格組件后，設計師基本上無需進行重復設計。可以花更多時間研究業務特性。以此界面為例，我其實最后輸出的僅有各屬性項的字段樣式與相關說明而已。比如：
1. 三類對象的狀態標簽是否可以共用、有些屬性需要重點標出的，標簽樣式與之前的是否重復；
2. 功能色(常規、成功、警示、提示、靜默、失效等)的使用是否規范統一；
3. 看似同類字段：開始時間、計劃開始時間，后臺邏輯是否一致，可用同一樣式；(比如：項目開始需要走審批流程，定義啟動流程的時間為開始時間。階段的計劃開始時間是創建者手動填寫，無需再走流程。故而兩字段樣式有所區別。)
雖然很多時候用戶不一定能夠注意到其中細微的區別，并且會一定程度上增加開發同學的工作量。但最終的呈現出來的效果，遠比全部使用純文本樣式展示要好看的多，且體驗也會更佳。
3. 零部件結構
該界面制作時，需求明確，且有原來的部分界面做參考，主要是增加了搜索需要匹配關鍵字并高亮單元格。然后根據現有的組件進行樣式交互的優化。
設計上比較簡單，按照需求遵循相應的規范直接給出相關的樣式即可。只不過整體更改了原有的交互方式，將表內帶有的結構剔除，放置左側以樹結構展示。因涉及到部分業務，不方便截圖整個界面，零部件的結構相當復雜且存在很多關系，界面功能不過多介紹。
在后臺表格的設計中，除了表格內的操作(一般放至最右列)，還有其他的很多操作按鈕與篩選項等等。框架【Element】和【Ant design】都將其放置在表格左上方，且原界面布局基本如此，我沒有做太多修改。
當然，還有很多后臺界面設計，未進行模塊劃分，且操作較少，整個界面基本上為表格平鋪的，可直接將按鈕以icon展示，同標題一行，對齊右側。如下圖：
除以上列出的部分，還有一些其他類型的表格設計，比如：
1. 相關文檔列表，抽屜展開更多詳情信息，一般情況下直接選用框架內的 Table 組件也能夠滿足需求，展開的詳情根據不同的文檔類型有所區別而已；
2. 與某對象相關聯的其他對象，根據關聯類型進行分組，直接增加一行分組標題，在左側給出icon進行標識，且可控制其展開或收起。配合其他篩選組件一起使用也是很常見的；
3. 將多個對象進行對比，更改表頭與屬性項的排布方式：左側為屬性項名稱，上方為對象標識名稱。可根據需求，進行移除或添加對比的對象，可將相同項與不同項的表行底色進行區分。
以上涉及的業務內容較多，暫不逐一展示效果圖。僅給出部分樣式：
不同對象的屬性不同，字段與對比的方式會存在一定差異。上圖為系統中用的最多的一種樣式。屬性項存在分組，可展開折疊，并且能夠在對比前通過篩選進行控制，當對比數據量過大時，可以很好的優化性能。當然，也可以全部對比后再篩選，主要看業務信息量，并與開發同學溝通，綜合制定最優的交互方式即可。
后臺界面對業務呈現與實用性要求更高，特別是我司負責制造業數據的管理，整體特點就是表格、表單占據界面的大部分，需要在眾多的信息中更快找到目標對象。
提高開發效率的同時需要根據各企業的特點，進行產品定制。故而在開發之前，整個項目組人員都需要或多或少的了解業務。作為設計人員，在沒有產品經理的情況下基本就是承上啟下的角色，對于表格相關的設計需要注意以下幾點：
1. 充分了解業務，包括該階段是否實現的內容、以后可能增加的內容等，考慮使用表格是否合理；
2. 確定界面的基本功能字段以及交互方式，梳理完成該業務的整體閉環；
3. 熟悉各框架基本內容，與前端溝通表格內功能實現的難易程度，確定組件；
4. 設計時，盡量使用原子設計法與透明度法則，可以更好的進行全局樣式和交互的把控；
5. 展示高保真的表格時，充分利用圖層樣式，能夠更好統一表格的色彩，文本等；使用組件，可自定特殊的單元格字段樣式，尤其是枚舉類字段；
6. 通用表格的輸出，可直接將源文件圖層樣式等上傳至藍湖，加以文字說明，非常方便。
后面有空會總結一下后臺設計規范與組件圖層樣式的使用。以上僅為個人近期大量表格設計的小小心得，也是第一次做此類后臺系統設計，不足之處希望大家評論處指出，共同成長。
小編：@Kerr Xu
原作者：@xyz946494
作者已經授權本公眾號發布
更多閱讀1.視覺和交互都必須知道的交互設計模式2.2018設計師超詳細面試指南3.產品設計心得-視覺篇4.扁平描邊插畫嘔血教程5.老司機教你3步解析品牌設計6.【只言片語01】設計的邏輯7.【只言片語02】設計中的加載8.【只言片語03】無效的用戶測試9.【只言片語04】體驗設計雜談10.【只言片語05】app中5種形式的地址選擇11.交互輸出文檔12.用戶體驗設計師的8個關鍵問答由于微信官方將公眾號文章的推送規則作出了新的改動(現在已經不是按照發布時間排序)如果大家還想看到應謀鬼計的文章準時出現，一定點擊文章右上角的“...”將應謀鬼計設為星標?，也要多點點右下角的「在看」哦～點我，這里這里
總結
以上是生活随笔為你收集整理的asp 设置table 间距_B端后台表格（table）如何设计的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 夏至未至祭司的画是谁画的啊？
- 下一篇： webpack打开项目命令_webpac