整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
exceljs是一個讀取，操作和編寫電子表格數據和樣式到XLSX和JSON，從Excel電子表格文件逆向工程設計的項目。之所以稱它最強，是因為它的功能強大，簡直就是專門為Excel打造的前端處理插件，到目前為止，筆者還尚未見過比這個更強大的前端插件，由于其強悍的前端處理能力，這就意味著有很多操作將減輕服務器端壓力，而且性能更加出色！
https://github.com/exceljs/exceljs安裝我們當然是首選npm
npm install exceljsvar workbook = new Excel.Workbook();workbook.creator = 'Me';
workbook.lastModifiedBy = 'Her';
workbook.created = new Date(1985, 8, 30);
workbook.modified = new Date();
workbook.lastPrinted = new Date(2016, 9, 27);// 將工作簿日期設置為1904日期系統
workbook.properties.date1904 = true;“工作簿”視圖控制Excel在查看工作簿時打開多少個單獨的窗口。
workbook.views = [
{
x: 0, y: 0, width: 10000, height: 20000,
firstSheet: 0, activeTab: 1, visibility: 'visible'
}
]var sheet = workbook.addWorksheet('My Sheet');用addWorksheet函數的第二個參數設置工作表的選項。
// 創建一個紅色標簽顏色的工作表
var sheet = workbook.addWorksheet('My Sheet', {properties:{tabColor:{argb:'FFC0000'}}});
// 創建一個隱藏網格線的工作表
var sheet = workbook.addWorksheet('My Sheet', {properties: {showGridLines: false}});
// 創建一個第一行和列凍結的工作表
var sheet = workbook.addWorksheet('My Sheet', {views:[{xSplit: 1, ySplit:1}]});使用工作表id從工作簿中刪除工作表。
// 創建工作表
var sheet = workbook.addWorksheet('My Sheet');
// 使用工作表ID刪除工作表
workbook.removeWorksheet(sheet.id)// 迭代所有sheet
// 注意：workbook.worksheets.forEach仍然可以工作，但這個方式更好
workbook.eachSheet(function(worksheet, sheetId) {
// ...
});
// 按名稱獲取表格
var worksheet = workbook.getWorksheet('My Sheet');
// 按ID獲取表格
var worksheet = workbook.getWorksheet(1);。。。。。。以上只是部分文檔中的介紹，感興趣的小伙伴可以移步Github直接查看詳細的文檔，完整功能了解可參考下一個標題
PS：提供了中文文檔
雖然以上功能還不能包括了Excel的所有功能，但也已經相當的豐富了！
在之前的文章中曾介紹過另一個不錯的前端Excel插件，感興趣的可以去看一看，exceljs擁有這么豐富的功能，如果你想開發一個功能強大的Web電子表格，不妨多嘗試嘗試！
前我主要深耕于B端設計中，深知B端表格設計與C端有很大的不同，無論是表格的展示形式以及承載內容上都有非常大的差異。而現在網上有不少關于表格如何設計的文章，但要真正落到實處的少之又少，因此今天我們就來聊聊表格，探討一下B端表格究竟應該如何設計。
由于表格組件類型復雜，因此分為上下兩篇，上篇主要講基礎知識點，下篇主要針對交流群中的20個問題進行解答，歡迎持續關注～
在我們B端表格頁中，由導航、篩選、表格幾大模塊構成，因為表格面積占比最大，頁面呈現最為重要，會直接影響用戶的使用體驗。
在我們對表格的設計思考過程中，需要注意兩項原則：易讀與易用
前者是提升使用者在表格瀏覽時的體驗，主要是從信息密度、色彩分隔、以及視覺節奏三個方面去理解；后者是使用表格時的操作感受，比如快捷操作、多數據編輯等方面去理解。無論是B端的任何頁面，表格都是必不可少的部分。
想要把這三種形式講透，需要將數據的形式結合起來說，我會從展示形式、數據結構、前端標簽 三個方面去解釋三者的區別。
表單擁有一對一的數據結構，能夠讓用戶明白數據間的對應關系。同時使用表單的門檻最低，擁有更合理的錄入形式，比如在常見的問卷調查、登陸注冊都是采取表單的形式。
在前端展示方面，表單采用的標簽一般會包含：text、password、radio、checkbox、button、submit、reset、image、file等屬性，我們也要針對不同的屬性進行相應的設計區分。
列表能夠將數據在一列中井然有序的展示，保持數據的有序與整潔。列表擁有一對多的數據結構，能夠讓用戶理清一條數據下的多個對應關系，并且多個對應關系是相互并列。比如在常見地待辦事項、走查清單中里，就是使用單維度數據進行排列。
在前端展示上，列表中的標簽分為有序與無序。
? 有序列表：即有順序的列表，其各個列表項按照一定的規則排列定義，前端標簽上采取<ol><li>的結構。
通常有序列表一般為數字序號（1、2、3、4...）或者字母序號（a、b、c、d）
? 無序列表：無序列表的各個列表項之間沒有順序級別之分，為并列關系。前端標簽上采取<ul><li>的結構。
在多維度的數據分析中，你是永遠的逃離不了表格，使用多維度數據進行統一的結構化展示，讓用戶清晰的看到在同一主題下的多條數據的對比，使數據能夠進行多維度的展示，保證數據的完整性。
在前端的方面，表格中都是采取 <table> 標簽進行展示，同時表格中的行與列分別用 <tr> 與 <td> 標簽，我們通常說的表頭，則為 <th> 標簽。但要注意，在前端眼中表格永遠沒有列的概念，列都是每行拼接而成。
正式開始之前，我們先定義一下表格～
表格是一種常見的信息展現形式，它是所有B端組件中信息展示密度最高，同時涵蓋了B端的所有場景，因此是B端設計中的一個重要的組件。
在我們常見的B端產品改版中，除了對頁面流程調整以外，更多就是圍繞表格而展開的一系列優化。因此表格的設計，做為B端設計師的基礎能力之一，也是檢驗一個B端設計師是否合格的關鍵因素。
表格屬于形式十分單一的組件，對于沒有經驗的設計師來說，會認為能夠調整的地方實在太少，往往在思考層面就會有所不足。對于一個B端表格來說，它需要具備數據瀏覽、數據新增、數據操作、數據統計，因此功能多而全，很難思考解決問題思路。
通常設計師設計單個組件，都會有較好的全量意識。而到了多組件的聯動時，就會出現問題。
比如在表格中，除了表格本身，還會有搜索、篩選、視圖、分頁等操作，如果不對多組件的交叉使用進行思考，也會缺少對于這些場景的設計。
在表格中，會承載多種多樣的字段類型，而每一個字段類型都會有相應的差異。形式的不同落到表格上就會有不同的呈現形式，在關鍵數值的處理上，也會差強人意。因此看上去簡單的一個表格，其實會有很多需要設計的點。
而深入到表格的內部中，你會發現能做的遠遠不止于此，如果剛開始沒有對表格進行梳理，那么你在設計的過程中，對于反復出現的表格將束手無策，為了讓大家能夠對表格有更深的理解，我將表格進行系統的拆解，結合實際案例，能夠讓表格更淺顯易懂。
首先問大家一個問題，你覺得表格一共有幾個部分組成，分別是什么？給大家五秒鐘時間思考～
5
4
3
2
1
～
在我看來，表格一共分為五部分：
概括整個表格的內容信息，讓用戶一眼就知道該表格的用途是否符合自己心中的預期。
在實際場景中，除了通過標題文字去的形式之外，你還可以為每一個表格去設計不同類型的圖標，這樣能夠讓用戶看到圖標就能聯想到內容，這也是現在無代碼開發平臺常見的處理方式。
但在工具欄的排列方式會有非常多的講究，在市面上的操作區域一般可分為單行與雙行的狀態，可根據自身產品要求的特點進行隨意的變化，會在文章后半部分具體講到工具欄的設計思路，這里就不再過多贅述。
概括每列的主要信息，在用戶使用表格中，起到數據解釋作用，讓數據能與之進行匹配，使用戶能夠看懂數據。同時在表頭處會擁有一些操作，比如凍結、篩選、排序都會放置于此，因此需要進行留意。
承載用戶的每一條數據，也是整個表格的核心。單元格的大小行高都會直接影響用戶使用表格的體驗，單元格的設計上也會有很多設計思路，在后半部分也給他家提供了我自己的看法，與大家進行探討，在這個就先按下不表。
嚴格意義上講，分頁是不屬于表格當中，但當數據超過用戶所設定的閾值時，就需要使用分頁拆解數據，所以分頁和表格是經常聯系在一起的。分頁一共有：基礎型、迷你型、完整型三種類型。
而如何進行跨頁的操作，一直都是分頁在B端中的難點，需要有好的思路與邏輯，在分頁模塊中與大家聊聊。
你知道表格類型的多少決定你了設計表格的下限。
雖然在大多數業務場景中都是使用基礎表格，但在B端產品中業務的多樣性使得很多特殊的表格有它獨特發揮的空間。
我發現在我的B端交流群都有著類似的問題，他們不知道表格還存在這么多的類型，這時候你與別人之間的認知的差距就是你設計優勢所在。
基礎表格是根基，是由行與列的單元格組成。在使用層面上能滿足用戶多維度查看數據的需求。因為大家都很熟知，在這一章節并不是主角，我們就不做過多贅述。
當表格中的數據為包含與被包含的結構時，可采取樹形表格。
通過逐級大綱的形式來展現數據間的層級關系，讓整個信息結構變得一目了然。這一表格形式常出現于項目管理工具中，比如 Teambition、Tapd、飛蛾都有這樣的設計。
作為騰訊最重要的項目管理工具，在產品設計之初，就考慮到類似情況，你能夠在Tpad單列數據編輯點擊入口，創建子數據，這樣在項目管理的場景下，有著較為友好的交互體驗。
前段時間，Teambition正式成為阿里旗下的辦公套件，而釘釘的云釘一體化，或許證明這樣龐大的市場仍然還要等待時間的挖掘。期待資本對于B端行業的更多動作
我們回到設計上，Teambition在9月份經歷的改版，變化很多，有機會可以總結一個改版分析分享給大家，作為一個項目管理軟件，Teambition也擁有樹形表格的這樣一共功能，它的添加入口出現在每個數據詳情頁的最下方，同時在視圖層面，也可以篩選展示為：所有任務、僅父任務、僅子任務四種場景，更能滿足用戶的需求～
當一條主數據下有多條數據結構不同的關聯數據進行嵌套時，這時候就可以用子表格進行創建。它能夠對主數據進行更加細致的解釋，詳細的了解主數據中數據的含義。從表象上看，就是在一個表格中還能嵌套另一個表格。
比如在對某集團對旗下子公司的銷售表格中，它能夠通過嵌套子表格的形式，將每一個子公司下的銷售人員的銷售記錄進行記錄，從而能夠更加細的了解到每一個公司、每一個人員的具體情況。
在國外報表中，這類表格很少出現，而在中國的報表中，嵌套子表格算是一種不折不扣的中國式報表。
當然這里我們依舊可以深入理解，比如在兩個表格之間，用戶是通過什么樣的方式建立一個父子的關系？表格中當父數據刪除時，子數據如何處理？設計上對父子之間的關聯有著何種限制，這都是我們需要思考的，因為這里牽涉到業務實在太多，我也無法抽象出一個規律供大家學習，因此只有具體問題具體分析。
當一個表格里面有多條數據在同一個小范圍的維度進行展示時，它就是交叉表格。從表象上看，就是表頭有很多分組進行區分，因此它也叫做表頭分組。
它能夠通過硬拆分將數據進行切割，但是這樣數據的易讀性就是有很大的差距，比如在2010-2020公司年度收支表格中，需要同時展示每一年份的收入、支出與利潤，使用交叉報表能夠讓用戶一眼就是看清數據，而基礎表格卻不行。交叉表格也算是中國式表格中的一種，能夠滿足具體業務上的需求。
當一個表格里面有多種圖表數據進行展示時，他就是圖表表格。
在對一些項目做定制化開發時，這是十分常見的場景。用戶點擊某一數據后，直接跳出數據的統計圖，方便用戶進行對比。同時這一功能也可以通過儀表盤這樣的功能去解決，也就說到國內最愛做的數據可視化。
這是很多人都會忽略的一個點，主要是大家對于表格的理解各不相同，也沒有具體的文章對于表格尺寸有個非常明確的限制，在這里分享一個我常用的數據點，用于判斷表格設計的優劣：表占比。
表占比：表占比是指在1920x1080的屏幕大小下，表格占整個頁面的比例 即：表格面積 / 頁面面積 = 表占比
這里需要指出，這里的表格面積是指，表頭+單元格+分頁（不包含工具欄）
在我對十幾款主流B端軟件的總結分析中，驚奇的發現大多數產品「表占比」都是在65-70%之間，而一些不注重交互設計上的產品則會有所偏差。
那為何65-70%是一個更為合理的數據？
因為只要在頁面中出現表格，就代表這個頁面一定是以表格作為核心。而表占比低于65%，代表頁面中的表格不處于內容的核心，你需要重新審視這個頁面所需要傳達的功能。
如果表占比高于80 %，則代表表格出現面積過大，要考慮用戶是否能夠接受如此大的占比。
因此，設計的合理性來說，占比在65-70%之間能夠保證數據展示的合理性，同時這主要是針對CRM產品，大家可以使用這個占比去衡量自己設計的B端產品～
當然這樣的情況并不是一塵不變的，B端最大的魅力便是業務邏輯，我們來看一個看起來像是反面的例子：在銷幫幫中，表占比為：61.2% ，看似是一個并不合格的成績，而且數據十分異常，讓我想要深挖，為何會如此的低。
通過進一步的分析，發現銷幫幫是一款與釘釘生態深度綁定的產品，其產品只能通過釘釘軟件進行使用，而釘釘本身默認并不是1080px的寬度，用戶打開并且全屏的尺寸偏小。默認尺寸大小的不同，最終讓銷幫幫選擇去滿足業務而犧牲表占比去換取更多的功能。
因為在B端的工具欄的設計中，市面上缺少思路與方法的指導，會出現非常多的問題，因此我展開講講工具欄的設計，就不出單獨系列進行講解～
首先，對于工具欄，不同的產品，會對它有著不同的定義。比如在Apple MacOS 系統當中經常提到的Toolbars和Toolbar Items；又或者是Microsoft 產品中采取的Ribbon設計模式。在設計底層思路上截然不同，平臺級產品思路與定制化產品思路存在很多截然不同的做法，我們今天簡單聊聊大家遇到過多的表格工具欄設計，不做深挖～
在表格工具欄的設計中，信息分區與頁面透氣是非常重要的兩個設計核心。
信息分區：
因為工具欄是由標題、篩選、搜索、視圖、新建等操作組成，而功能間的區分是工具欄設計的一個關鍵。
當一個工具欄中，需要將如此多的元素進行組合排列時，必然會有其排序的規則，這時我們就可以通過親密性原則，對工具欄中的信息進行相應區分
在設計的親密性原則中，我們可以將功能相近的工具放在一起，比如：搜索與篩選都是數據過濾的操作，應該放在同一分區；
同樣，工具欄也會存在一些功能點不太相近操作，我們就應該通過分區將其間隔開，比如在下圖中，每個功能都將其用線條區分。
當然，在信息的去區分上，也有強弱兩種不同的方式，一種是通過線條直接分割；另一種是將工具欄進行空間上的區分。因此可以通過信息區分去檢查你的工具欄設計是否合理。
內容呼吸：
在一個定制化項目中，設計師一定要讓自己的頁面具有呼吸感。在B端業務中，信息量本身就已經足夠龐大，而頁面的中的疏密關系就顯得尤為重要。
通常列表都承載著繁雜、冗余的數據，是一個信息集中的密；工具欄作為與表格關聯的上部分，呼吸感便成為表格的重要因素。通常在表頭處要將空間盡量分散開，這樣才能滿足整體的疏密關系。
經常看到一些十分冗雜的表頭，甚至它喪失了表頭的真正含義。在實際情況下，盡可能明確、簡單的講出表頭的內容，以免造成表格的宣兵奪主。當然也會存在一些專業術語，這時候，給一個Tooltips再合適不過。
在表格中，單元格的行高是一直都是一個難以控制的變量，因為行高會直接控制表格中的信息密度，而信息密度永遠是一個無法量化的元素。而在我們設計過程中，需要采取盒子模型的方式，讓你的設計更加落地。
知識點補充：盒子模型
從前端開發而言，單元格是一個最為基礎的盒子模型。而HTML中的所有元素都可以看作是一個盒子。而我們所設計的頁面也正是由這個樣的原理去還原出來。
Margin(外邊距)：清除邊框外的區域，外邊距是透明的。
Border(邊框)：圍繞在內邊距和內容外的邊框。
Padding(內邊距)：清除內容周圍的區域，內邊距是透明的。
Content(內容)：盒子的內容，顯示文本和圖像。
a.單元格內容
內容一般為文字、圖標、頭像等等，而對于數據中你想要格外突出的內容，這里稱為關鍵數據標識別。從盒子模型的角度來看，它就是當中的Connect，但單元格內容中，一般會有一些處理技巧：
關鍵數據標識：
用戶在使用表格時，會經常去留意一些關鍵的數據。比如數據的狀態、變化的多少…
如果在系統中，你能夠很明確知道用戶想要了解的數據時，便可在關鍵數據上進行標識。這樣能夠幫助用戶快速定位到自己想要的信息，減少數據尋找所化的時間。但如果你對關鍵數據標識出現誤判，這條數據便是一條十分干擾的數據，因此在這里的設計，需要慎重考慮。
比如在飛書的成員與部門中，對于賬號狀態就是一個關鍵數據的標識，一方面用戶可以快速了解到已經激活的成員，另一方面對于未激活狀態的進行突出展示，同時給予用戶未激活后的再次發送提醒的操作，是對用戶使用的優化提升。但，如果將不重要的數據進行標識，例如手機號，那么這將會是一個令人痛苦的設計。
人員角色展示
人員角色展示在表格中十分常見，通常會是以用戶名稱+頭像的形式展示。
但在真實場景的表格中，頭像需要給予默認的形式，比如釘釘、飛書就是以用戶“姓”作為頭像的默認值，而在多個人員角色展示時，就需要考慮特殊情況，無論是極值省略展示與獲取全量數據中，都需要我們進行設計上的處理。
進度條
進度條是屬于關鍵數據的一種，它所涉及到的功能與圖表表格類似，能夠更直觀展示數據的占比，方便用戶對于多條數據間的值進行判斷。進度條常見于“容量、使用量”的數據中。
表格空白處理
表格中經常出現空數據的情況，而表格的留白對于用戶而言會造成一些困擾，特別存在與頁面中的大面積留白，感覺像是數據沒有加載出。因此在表格空白數據處理上，可以使用“-”來進行默認展示。
b.單元格行高
單元格行高一般由：文字大小、文字行高、左右上下邊距共同組成。
從盒子模型的角度來看，它就是其中的Padding。因此行高的確定，是由上方四個條件共同組成。
文字大小：一般出現在表格中的文字大小都在12-16px之間，通常13、14px最為常見，建議大家設計也在此范疇內。
文字行高： 行高是一行文本垂直方向的高度，這個高度和字高無關，文字內容水平居中。可設置為字號的1.2-1.8倍，文字與分割線間距離可以設定為字號的1-1.5倍。
邊距（Padding）：表格中的邊距分為左上右下四個方向，而左上右下恰好就是對應前端去編寫Padding代碼的順序，在對頁面驗收時，便可采取這樣的形式。
單元格行高可配置：單元格行高直接影響著信息排列的密度，而在實際業務中，真正落地也有著不同的做法。
在對定制化項目的開發中，通常會設計一套設計師認為更加合理的單元格高度，一般為32px-56px區間內，而在很多通用化產品中，存在多個設備屏幕分辨率的差異，為了讓每一個分辨率下的產品都能夠有較好的展示效果，于是乎將選擇權交給用戶，在表格左下角會設置舒適、標準、緊湊三種高度來滿足需求，使得表格更加落地合理。
總結：整個單元格的行高，就是由這三部分組成，它們的嵌套與組合，所形成了單元格的行高
c.表格分割
在表格設計當中，每一條線都有著它存在的意義。
當表格中展示橫線；隱藏縱線。
用戶的橫向閱讀體驗更佳，強調一條數據的完整性，能夠讓用戶進行快速的對應。
當表格中展示縱線；隱藏橫線。
用戶的縱向閱讀體驗更佳，強調數據上下間的對比，能夠讓用戶找到同一緯度數據下的對比。
比如在一個組織架構的成員列表中，我相信大家都設計過類似頁面，同樣的設計方式，我一個采取展示橫線、一個展示縱線，結果明顯，我成員需要閱讀完整條數據，因此橫線會更加合理。
當然，在我們日常的設計中，展示橫線的場景顯然會更多，但我們日常使用時，數據對應的場景還會更多這是需要有更強的設計形式：
d.行、列凍結
當表格的行與列的數量過多時，會導致一屏展示不下，而表格中的關鍵信息與操作是需要在任何時候都展示，這是采取行、列凍結，能讓用戶快速觸達。
表頭凍結：通常出現在垂直滾動時，通過固定表頭的信息，能夠讓用戶閱讀時對應不同的數據，使用戶更好理解數據。
首尾凍結：通常出現在水平滾動，通過固定首列的主屬性字段以及尾列的數據操作，來滿足用戶對于一列數據的認知，從而使用戶進行快速操作。
在對分頁設計的分析中，我們需要對分頁中的元素進行拆解，才能明白分頁的類型所帶來的不同。
表格信息：會展示表格信息當中的數據總量、更新時間、默認排序方式等...
數據總量主要展示用戶需要瀏覽的內容的總量；常見于管理后臺搜索、篩選符合條件的數據記錄時，搜索結果頁通常會展示這個信息，這讓銷售人員在操作時有心理預期。
更新時間主要是展示用戶當前表格所操作時的日期時間；常見于金融類產品中，他們對于表格中數據的時效性尤為關注，這樣可以方便用戶對表格數據中的有效性進行判斷
默認排序方式主要是展示表格中是按照哪一個字段進行的排序；通常這種做法多出現于表頭直接展示icon，但對于可配置化的產品而言，隨著列數的增多，你越來越找不到你想要的默認排序方式，因此在表格的固定位置展示，就再好不過（記住，只針對特定場景）
頁面展示數量：結構為「X條/頁」
它能控制每個頁面展示多少條數據；當在系統中有很多數據時，你可以直接通過「頁面展示數據 * 分頁總數」 直接算出整個表格的數據總和。
上一頁和下一頁翻頁：分頁中基本組成元素通過用戶點擊上一頁、下一頁的按鈕，實現表格的翻頁功能。翻頁通常會根據場景不同，去省略翻頁中的不同元素，比如在下面馬上那個講到的三種翻頁類型，但是上一頁和下一頁是絕對不可省略的。翻頁也如同你翻書一樣，可以進行對數據的逐頁閱讀，遵從用戶之前的使用習慣。
當前頁碼：當前頁碼說明了頁面中數據當前所處的位置，方便用戶進行翻頁的操作。
相鄰頁碼展示：相鄰頁碼通常展示前后兩頁，比如你在第6頁時，頁面需要展示：4、5、6、7、8；但頁碼在第1頁時，就需要展示：1、2、3、4、5；頁尾同理。
更多分頁：當表格數據過多時，就需要使用分頁，同樣，當分頁過多時，我們需要進行處理，就是省略，采用更多分頁，去展示多余的分頁情況，當用戶需要查看更多的分頁，點擊更多圖標即可。
總頁數：代表大概會有多少頁此類數據，通過使用總頁數才能讓用戶知道
總頁數說明了內容一共有多少頁，就像一本紙質書有總頁數，一本有聲書有總時長；通過這個元素，用戶才能了解內容的多少，對整理內容有個把握。
頁碼跳轉：頁碼跳轉幫助用戶從當前頁面跳轉到其他某個頁面；比如用戶在搜索了某件商品，按銷量排序，這時瀏覽到了第15頁，滿意度越來越低；于是打算從前5頁選一個，這時就能通過頁碼跳轉快速跳轉到第1-5頁了。
簡潔型：
當分頁數量較少時，通常在7頁以內，就只有最基礎的展示：上一頁、分頁數量、下一頁。
迷你型：
當頁面空間不足或者降低分頁的視覺影響時，可以采用迷你型，主要為當前頁/總頁數，可以直接跳轉到某頁面。
完整型：
當表格數據較多，為了滿足更多的用戶需求，可以根據需求選擇分頁類型。比較完整的分頁還包括如下功能：顯示總數、調整每頁顯示條數、直接跳轉到某頁。完整型的雖然滿足各種功能需求，但是所占空間較大，所以我們要根據自己的需求合理拆分使用。
分頁固定：
在表格中使用分頁，除了選擇合理的分頁類型外，我們還需要注意當數據過多的時候，是否要固定分頁。這個需要根據需求來決定，如果用戶翻頁很頻繁，表格數據又特別長，就可以考慮分頁固定在底部，免得每次用戶翻頁都要跑到表格的最底部才能分頁，還可以在表頭也放迷你型分頁。但通常在設計表格的時候就沒有固定，也很少使用表頭分頁，所以根據需求來定。同樣按鈕的設計也會存在類似的情況。
另外就是當數量過少時，只有一頁或者無數據的時候，我們是不需要分頁的，這個時候最好去掉分頁，展示在這里沒有什么意義了。但很多時候我們設計沒有做區分，開發也就不管了。
老讀者都知道，我會反復去強調“場景”這一概念（比如在導航菜單、篩選、彈窗、圖標中經常提到這一詞），因為你只有明白用戶真正的業務場景，才能夠真正的明白用戶的痛點。我們回到表格中，在表格的場景主要分為五類不同場景：數據瀏覽、數據新增、數據操作、數據統計與通用場景。我會通過不同場景的梳理分析我們在不同場景中存在那些優化點，可以進行深入探討。
在數據瀏覽的場景中，本質上是對大量數據進行尋找與確認。用戶需要在此場景下進行高效準確的數據查找。而伴隨著用戶的尋找，就需要使用表格當中的工具進行輔助查找，比如篩選、搜索，這些工具的出現，都能夠幫助用戶進行數據的清洗，使得用戶想要的數據能夠快速的被找到。
比如：我們公司的銷售人員在每天早上，都需要去 check in 今天自己所要跟進、回訪的客戶，銷售人員就會通過表格中的各種工具，去幫助銷售人員找到自己想要的那部分數據。
常見行為及設計點：
數據篩選瀏覽：通過自己對數據的一定了解，結合各種篩選條件，配合得到用戶想要的篩選結果。
數據多選：用戶可以通過多選，為他尋找的數據進行標記，方便之后的操作。
數據新增本質上是將復雜的數據結構，通過系統字段類型的相應規則，錄入保存到系統中。這也就我們常說的增刪改查的“增”
比如：銷售人員在對新增的客戶進行登記時，需要登記公司名稱，聯系人，聯系方式，跟進記錄等等。且需要不斷更新跟進記錄，因此銷售人員在表格上的新增是一個非常高頻操作～
數據操作分為對單個數據的操作、單行數據的操作、多行數據的操作三種情況
單個數據的操作，就是我們常見的快捷編輯，可以點擊快捷編輯按鈕，對單個數據進行錄入，
為何需要快捷編輯，在銷售使用場景中，使用表格去編輯一條信息是一個循序漸進的過程，比如在對客戶進行溝通時，數據的不斷更改，跟進內容也在不停修改，導致用戶需要每次進入用戶詳情點擊編輯之后才能進行操作，而在表格內進行快捷編輯直接滿足實時編輯的需求，在交互層面上這是一個非常OK的需求
但落到開發層面上，就意味著要在用戶進入表格中去判斷權限，才能讓用戶知道是否能夠點，點擊過后需要判斷字段屬性，明確該字段是與哪些字段進行聯動
單條數據主要通常會采取兩種路徑進行操作：進入用戶詳情頁界面，對一整列數據進行編輯，這種情況通常都需要多個數據進行處理，因此進入編輯頁面更容易尋找，同時也是最為正常的一種做法
多行數據操作主要采取多選過后的操作方式：當用戶想要對多條數據進行操作時，就需要對多個數據進行checkbox 的勾選，從而滿足多行操作的需求
數據統計主要針對用戶需要審查分析。目的是在通過大量的數據分析去得出自己的某一些結論，由于關注的數據會有主次之分，數據與數據之間也會有內在聯系，用戶會更加跳躍地掃視頁面，而且會更加反復地審查數據。例如，銷售人員需要查閱本月的銷售情況，進入到商品銷售明細表中，分析本月的經營狀況，若其中某些商品
了解了表格的使用場景過后，針對不同的場景，在設計上它的思路就會有所不同
使用上就會有不同的設計思路。由于篇幅原因，我們主要了解了表格的基本形態，如果對于表格的場景還不太清楚，我會在下篇中與大家通過20個問題，了解B端表格中究竟應該如何設計～
我是CE青年
一個2 B行業的2B設計師
我們下篇文章再見
聊B端表格設計中大家的問題
在上一篇文章，我們講到對于表格而言你所要具備的基礎知識點，沒有看過的同學建議先看完上篇再看下篇～
今天咱們落落地，因為表格十分重要，我也在自己的 B端學習交流群 里進行了一次問卷調查，將大家對于表格的問題做了相應整理總結，大致分為10問，分享出來，與大家進行交流
下面的10問都是大家常見的表格問題，同時也給出相應的解決方法，都是個人官觀點，歡迎大家入群一起討論～
首先在確定一個單元格的寬度時，我們需要對所有的字段類型進行最小寬度的設定。通常最小寬度是根據 「表格字段」 內容寬度的決定，不同的內容寬度也會不盡相同
地址字段：算是 B端產品經常出現的一個字段，由于地址非常不可控，長短會有非常大的差別
成員字段：成員字段單獨拿出來講是因為成員目前的成員字段展示會出現三種流派：純文字型、頭像文字型、頭像型。在成員字段設計中需要考慮單個與多個的情況
日期時間字段：日期時間是一個典型的可控字段，因為格式原因，其寬度能夠被精確掌握，也因此可以做較為多形式上的創新。小Tips：在數字的對齊上，可采取 Helvetica 字體，這樣能夠保證用戶查看數據時，整齊更加容易辨別
通過上訴的字段舉例，大家會發現字段寬度無外乎就是幾類情況，通常也會對其寬度大小有所預判，也因此能夠有所了解，咱們將字段寬度梳理出來后，需要最后落實到文檔中，也就是將字段的寬度進行記錄，在后面開發實現中會十分有用
如果拿到上面類似需求時，我建議大家不要著急上手做，先試著去分析“如果我是該產品用戶，真正需要哪些字段，理由是什么？”這樣的方式對于你而言有兩點好處：
將需求分析清楚后，我們便可著手去做。在面對數據過多的字段展示時，我們通常都是采取「信息層級」的方式來讓多個字段合理展示，雖然方法都是相同，但是在設計形式上，還是有三種不同的方式
當橫向數據過多時，為了避免字段的隱藏，只有拓展縱向空間。無論你是使用疊層、銜接，都是將多個同一維度的數據，進行縱向拓展
比如你需要在一行去展示：發貨時間、發貨地點、發貨人以及物流信息，如果想讓用戶直接了當的看到所有信息，疊層、銜接都能夠達到目的。雖然形式上比較平鋪直敘，但直接在B端往往能取得不錯的效果
多層展示讓數據平鋪直敘，主次展示讓數據有了輕重
通常在表格中，一列多條數據必定會有主次之分，然而在B端的表達方式上也會有較大的區別
強弱化：將主次的信息通過粗細、大小、深淺等處理方式進行簡單弱化，形成信息層級，這種方式能夠在短時間內快速設計，適合新手入門進行信息的快速區分
標簽化：在將主次信息區分后，對次要信息進行標簽形式的處理，雖看上去是一個設計形式的轉變，但通常很多輔助信息都是內化為產品的特定狀態，可減少字段頭部的內容寬度，同時便于產品形成一套自身產品的標簽體系
符號化：將特殊字段設計為特定的符號，在對表格進行簡化的過程中，將諸如狀態、電話、性別之類的屬性進行符號化，并且可展示當前是否填寫的狀態，一方面將用戶是否填寫該信息，你可一目了然的看到，同時針對這些次要信息，這樣可以提升展示效率，極大降低用戶閱讀所需要花費的時間，同時當用戶Hover就可展示符號下的信息，也便于用戶閱讀
我舉一個實際工作中的例子，在我們自身產品的「OS系統」中，會針對客戶開通產品線的八個產品。對于我們而言，就需要展示客戶名稱、客戶等級、余額、開通產品等20+個字端進行展示，我們便采取了上面三種不同的方式，并且OS端作為小部分銷售用，使用標簽、符號對于系統而言認知成本會變低，按鈕快速點擊，產品就可快速開通，使用會更加合理
「OS系統」：主要目的是針對銷售在與客戶溝通時，需要查看客戶的信息、開通相應的產品，并且在為其推薦產品后能夠進行快速開通
隱藏展示并不屬于上面的兩種形式，主要是將大量的非重點信息進行折疊收起，提供一個較深的細節入口來隱藏掉信息，常見有下拉、浮層、提示框、彈窗…
這種方式雖然用數據更為簡潔，但是會有一定的認知成本，因此使用時需要多家注意，比如在網頁端的淘寶訂單中，也使用同樣的方法將訂單的物流信息進行收納，使信息更加整潔
在B端產品實際工作中，對于很多控件的問題，我們可以從開發實現的角度去尋找答案
比如我們想要確定表格整體的寬度，就可以從 HTML 的 table 標簽中去尋找，而寬度其實就是 table 標簽的 width 屬性，你可以在 w3school 這類基礎前端教程中找答案，有任何疑問都可以嘗試在上面進行搜索研究
我們回到表格，其實表格寬度 width 是包含有Pixels、%兩種不同的屬性值
同時可以明確告訴大家，兩種方式是可以混合使用，也就是我們常說的「表格固定寬度」與「百分比寬度」混用
當表格最小寬度小于字段總和寬度，根據設計方式的不同，可采取不同的解決辦法
這里我再解釋一下為何避免橫向滾動
對于所有的鼠標用戶而言，橫向滾動都是極為痛苦的，因為正常鼠標橫向滾動是需要用戶按住 「Shift + 滾動」 才會使表格進行滾動，但在我接受到的眾多用戶吐槽中，很多用戶只會選擇使用鼠標對橫向滾動條進行拖拽，因此橫向滾動條不能因此，同時很多用戶也不知如何正確查看橫向的內容，所以如果你做的不是一個aPaaS平臺，盡可能減少用戶橫向滾動的場景
當表格最小寬度大于字段總和寬度，便可采取百分比的形式
這樣表格的寬度可以跟隨屏幕寬度進行變化。這里設計師可以進行偷懶，因為在現有較為成熟的框架中，對于表格寬度大于字段寬度都做了等比例的拉伸，因此在這里無需過于糾結
當表格寬度需要有預設固定寬度時，你便可采取百分比 + 固定寬度的形式，這種方式可以解決表格信息隱藏過多
因為在表格中，不是所有的字段都需要寬度進行自適應，比如在一些操作、狀態等字段中，本身系統就能過對其寬度進行預知，為了減少對于其他字段的隱藏，便可采取固定寬度
這種方式也可以解決表格寬度不夠所帶來的困擾，固定寬度通常為操作、狀態等能夠預知其長度的寬度類型，在設定上盡量在系統中的寬度保持一致，固定寬度的使用有好有壞，常見于表格中尾部的操作。如出現在表格中部，在較長的頁面中進行展示也會帶來許多較差的展示形式
表格最小寬度
表格主要適配到的最小寬度，這一步驟通常的設計系統的初期就要完成，一方面可根據自己項目目前情況，按照導航寬度等固定尺寸確定最小的表格寬度，這樣在處理最小尺寸時，可以有一個明確的邊界，同時能與開發同學進行理解溝通
很顯然，它們的使用意義并不相同想要了解兩者的區別可以先明確兩者的功能
復選框（check box）：選擇表格當前及其以下的數據，是數據選擇的一種表現方式
樹形結構收折箭頭：主要在「樹形表格」中，起到展開數據與收起數據的功能，為了方便父與子的數據都能夠在表格中得以呈現
不知道「樹形表格」可以看《B端設計指南 - 06表格上》
但在實際情況中，會出現同時存在兩種方案，我在一個樹形結構中，既需要對結構中子數據的勾選，同時又需要讓用戶對單個條件中的數據進行勾選，這時就需要「顯一隱一」，對于用戶高頻使用的的一種方式，進行常駐展示，同時在 Hover 上去后，進行展示，這樣可以避免兩個復選框帶來的認知迷茫
很多設計師都缺少對小屏幕的處理方式，那么小屏幕的尺寸是多少，最小多少算小屏幕，這是我們首先需要明確的
我們分析一下市面上共有共有多少小屏幕尺寸，數據來自百度流量研究院2020年10月份的數據
如果我們把 1920 x 1080 以下的分辨率都定義為小屏，則有39.55% 都是小屏幕用戶
而針對不同的小屏，我們首先需要確定分辨率的下限，這里一般建議大家可以根據用戶自身的使用場景去分析，比如針對銷售的場景，會有許多外出上門拜訪的銷售，這時候就必須考慮到筆記本的小屏幕用戶，一般做到 1440x900 兼容、1280x720 能用即可
1440x900 兼容，通常會針對主要頁面去設計，如果產品中，該分辨率下的用戶較多，可提出針對該分辨率情況進行單獨適配，簡單優化頁面布局來兼容空間不足的問題
1280x720 能用，我說說我實際工作的思路，我們可以通過前端代碼屏幕縮放，將小分辨率的屏幕縮小，因而能看見更多的內容。通常做法是將1440px以下的尺寸，進行 Zoom 的90%的縮放，這樣能夠在電腦上看到更完整的信息，但同時也會有相應的缺點，由于整體縮放，需要檢查前端代碼對于整體縮放有沒有進行適配，需要對頁面進行再此走查，同時網站內容都會相應縮小，算是一個迫不得已的方式
在表格中，操作的展示方式首先分為以下幾種：
將所有操作進行整齊排列，一般是一個操作對應一列，當有操作缺失時，展示為空
這種方式能夠讓用戶直接了解到操作的缺失，但反復的出現會造成表格視覺上的冗余，適合列數較少的表格使用
將所有操作按照一定的預設排列順序進行平鋪
這種方式能夠適應B端的大多數場景，將操作都簡單平鋪出來雖然看上去簡單粗暴，但是在實際工作中，也是一種不錯的處理方式
將所有的操作按鈕收起到 “更多” 里面，并且用戶點擊后展示操作選項
這種情況常見于當前系統的操作按鈕不可控或重要程度較低時，隱藏能夠盡可能讓頁面進行統一，達到高效整潔的目的。與此同時，隱藏式也會有很多問題，隱藏操作后用戶不能立刻知道我能有哪些操作，對于一些高頻操作而言便是一個噩夢
因此采用隱藏式需要我們對功能上進行相應的取舍，才能滿足目前對于設計上的統一
將所有的操作進行隱藏，當用戶鼠標懸停時進行展開所有操作
這種方式能夠最大程度上滿足用戶快速查看與編輯的需求，但是在實際使用中，用戶的初次使用門檻較高，需要有一定的學習成本
將主要的操作進行展示，次要的操作進行隱藏
這種方式能夠盡可能滿足業務上對于高頻操作時的需求，同時在設計上，能夠將多余的操作進行隱藏，使得設計出的頁面能夠更加統一有效
表格中用戶的操作也會有多選的存在，因此也需要你去分別到底的用戶單挑數據操作的場景多還是用戶對于多條數據的場景多，需要有所分別。如果是在多選場景較為多時，應首要注意多選時的操作優化，可犧牲單條數據所需要應對的操作
上面六種辦法，你可以根據你的實際情況進行對應的處理方式，具體可以看我的視頻講解
這涉及到規范究竟應該如何去表達，其實每一位設計師對于規范的做法也不盡相同，但是要保證你做的規范與前端之間，能夠達成相同的默契，這樣對于我們而言，才有規范的真正價值，這里我分享一下我是如何給交代一個表格
首先，我們需要交付的需求一共幾個：
通常是一份Excel表格，里面記錄了系統中所有字段的常規寬度，前端可以根據寬度情況進行百分比的縮放，當然你也可以標注在設計稿中，方便前端進行開發，避免在文檔之間反復橫跳
設計稿本身只需要展示一些簡單的邏輯，同時盡可能的考慮清楚不同角色、不同狀態下，你的設計稿所要呈現出的邏輯，方便在設計評審的與大家進行探討，同時可以出一個簡單的調研、分析的文檔，方便大家提前閱讀，更能清晰的明確業務、功能上的需求點
因為在設計稿中，有很多需要文字與前端進行溝通的地方，比如這里的交互說明、邏輯表述等等，我通常會在設計稿的下方用單獨標注處設計所需要注意的點，同時給出相應的邏輯方便前端進行理解， 同時對于其他同事接手你的工作時，也有更多的幫助
由于國內的使用場景與國外有很大的不同，也就造成國內的很多產品對于移動端都格外的重視，因此本身表格就過于復雜，移植到移動端就會存在大量的問題，要想真正了解其背后的原理，我們先了解一下「桌面端與移動端的布局思路」
先普及一個知識點，什么是「響應式布局」、什么是「自適應布局」
響應式布局：是指網頁（一套前端代碼）同時能兼容多個終端，根據每個終端分辨率大小自動調整尺寸
我舉個例子，響應式布局就是將所有元素進行變形、隱藏，但是對于元素的布局等并沒有實質變化，因此響應式大多出現在官網的場景中，這樣的適配更輕量簡單，不會有太多的困擾，比如常見的：飛書、神策、Eagle、藍湖的官網都是采取響應式的方式進行開發
對于設計而言，響應式一般是先完成對桌面端的設計后再考慮對于移動端的適配，是一個元素由多到少的設計過程
自適應布局：是指網頁（多套前端代碼）能夠同時滿足多個分辨率的終端，并且多個終端之間布局差異較大
舉個例子，公司需要設計一個桌面端、Pad端、移動端的三端產品，而且每一個端的布局方式都有著截然不同的思路，而需要滿足這樣的布局場景的最好的辦法就是自適應布局，通過判斷::分辨率、設備ID::，來進行布局的修改，比如語雀都是采取自適應的方式
了解完響應式與自適應后，我門先看看移動端表格最具代表性的 Excel 文檔產品是如何適配表格。目前調研了WPS\Office\石墨文檔 \騰訊文檔\飛書，這五大產品
對于傳統類文檔產品而言，表格要做到的就是能夠滿足用戶的預期。雖然在整體設計上幾個產品都及其類似，但是在細節的處理上，各個產品卻不盡相同
初始大小：
在單元格初始大小中，明顯感受 Office的初始單元格大小最小，我猜測可能與Office通常承載的數據量過大有關，但對于國內的其他文檔類型產品而言，在初始大小上，顯然是讓用戶更易讀每一個單元格內的內容
信息錄入：
在信息錄入的場景下，騰訊文檔會提供錄入狀態的放大，這樣錄入體驗明顯更加友好，具體細節如下圖
值得一提的是，在所有新建場景中，只有WPS在我新建完成表格過后，便立刻彈起輸入框，讓我對需要新建表格的內容進行輸入，顯然這樣的體驗會更加連貫
但在B端實際工作中，處理移動端的交互方式通常會采取一下四種模式：
保留表格現有的表現方式，將表格直接展示出來。看起像是并沒有做任何適配，但在移動端中，這也不失為一種合理的做法。因為在頗具代表性的文檔產品中，也同樣如此，而且表格中的操作行為已經深入人心，他們只需要根據自身對于表格的認知，在移動端做出相應的判斷即可，不需要太多思考，但當直接展示遇到大量數據時，這樣處理還是會有點捉襟見肘
由于直接展示相對來說閱讀體驗并不友好，便在此基礎上進行優化產生了凍結跳投，將表頭與第一列（通常第一列數據為關鍵數據）的數據進行固定，讓直接展示的數據能夠形成對應的關系，滿足用戶閱讀表格時的基本需求
將表格中的數據進行視圖上的切換，形成 “標題 + 數據” 這樣一一對應的關系
這樣處理的方式，可以直接展示表格中的數據，讓移動端的表格像一行行表單一樣。但是直接展示List 在國內的實際場景中使用比較少見，對于較少的數據有比較好的效果
卡片模式主要是將表格中的一些關鍵字段在通過對應的關系實現一個卡片展示一行數據，用戶想要了解數據全貌，可以點擊卡片，進行數據全貌的查看分析，這類做法也是國內移動端常見的做法
在傳統的Excel表格中，快捷編輯是最常用的一個狀態，當用戶觸發去編輯表格中的數據，便可實現在表格內的編輯操作，這一交互行為在B端的表格場景中也得以保留。但設計中的細節還有很多需要直接注意的地方
首先，表格的快捷編輯分為兩個步驟，「進入編輯狀態」以及「提交編輯數據」，因此在這兩種狀態下，我們都需要設計不同的方式
雙擊觸發主要還原 Excel 用戶操作的習慣，用戶雙擊單元格即可實現編輯單元格內數據的操作，看似沒有問題但是在實際工作中這類方式反而并不常見，究其原因共有兩點：
按鈕觸發在我看到的眾多的B端軟件中是最為常見的，通過表格右側的按鈕，提示用戶該數據是可被編輯狀態。同時當用戶點擊編輯按鈕后，直接進行編輯
按鈕觸發比起雙擊觸發會更加克制，在操作之前用戶就可知道該條數據自己能否編輯，也能提前給用戶自己的預期。同時點擊按鈕進行觸發，雖然看上去相對繁瑣，但是能夠傳達出更加清晰的操作行為，也未嘗不是一種更加優秀的做法
在輸入場景中：當用戶輸入完成后，點擊空白區域
在選擇場景中：用戶選擇一個后，自動收起下拉菜單
在進行提交時，無論成功與否，都會進行提示，但是在選擇場景中的多選需要格外注意，這里的提交方式會有些特殊，在實際場景中，aPaaS產品大多都采取這樣的方式，比如Teambition、明道云等等…
當使用按鈕編輯后便可以連續使用按鈕提交，這樣面對用戶多選時，也可更加明確，選擇了多條數據后點擊提交便可提交數據
Q：市面上已經有 Ant Design 如此成熟的 B端設計框架后，你是選擇直接使用，還是選擇自己造一個輪子？
A：當我看到如此的評論后，內心也是十分復雜的，我先說說我自己的看法
商業設計往往并沒有那么簡單，首先關于開源的「中臺框架」并不只是有Ant Design一家，而我們拿它與Element進行比較，也會發現有很多不同的地方。而大家有去思考為何會有這些不同點嗎？ 我想答案大多是否定的
開源確實是非常棒的一件事，我也是其中的受益者，同時也非常感謝在Ant Design 中的貢獻者，但即使是 Ant Design 也在2018年圣誕節的時候發生了不可控的黑天鵝事件（2018年Ant Design 圣誕節按鈕彩蛋），讓許多使用Ant Design 的前端工程師被迫加班，我也在當天被負責人反復 Call 到（因為他以為是我們如此設計的）因此使用自己獨立的框架也代表著將風險掌握在自己手中，使用現有的框架其實是為了「降本增效」，但成本并不是一個項目需要思考的唯一因素，對于很多企業來說安全也是一個重要的因素
最后并不是所有的組件Ant Design 都會提供，企業級產品會有很多自身個性化的需求，因此當你走都不會時，如何去跑呢？我自己更愿意把 Ant Design 當作是一本參考書，當你有疑問時你可以翻開看看
當然任何事情都是有成本的，在小團隊中 Ant Design 確實能夠在項目初期實現快速搭建，一定程度上提升了后臺產品的設計下限，而它的上線還是需要我們一起去努力
我是CE青年，
一個2B行業的 2 B設計師～
如果覺得不錯，歡迎點贊支持～
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
