１．安裝
Windows 安裝請參考
默認安裝為c:/usr/ 。可以執行如下文件，以便啟動snmp agent：
snmpd
會提示需要配置snmpd.conf。
No log handling enabled - turning on stderr logging
Warning: no access control information configured.
It's unlikely this agent can serve any useful purpose in this state.
Run "snmpconf -g basic_setup" to help you configure the snmpd.conf file for this agent.
NET-SNMP version 5.5
不必使用提示中的命令，因為此命令引用了perl，但是perl的對應模塊無法跑起來?？磥韕erl要完蛋的傳說并不是空穴來風。
snmpd.conf可以自己創建到/usr/etc/snmp/snmpd.conf內。
２．修改配置文件
配置之前的說明：我在網上看到的所有配置都是com2sec，group，access這三個配置，但是從默認的snmp.conf文件中有一段話：
沒必要使用 com2sec/group/access配置，使用ro(w)user，ro(w)community結合合適的views，就可以覆蓋大多數需求了。
2.1 配置監聽地址
snmpd默認監聽本地IP的UDP161端口，等待snmp請求
agentAddress udp:161
藍藍設計( m.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
2.2 配置視圖(view)
格式：view viewName type oid[mask]
參數說明:
viewName : view名稱
type : 有兩個值：include和exclude(包括或者排除)
oid：可以訪問的oid(mib子樹)
[mask]：對oid的掩碼 (可選參數)
案例：
view systemonly included .1.3.6.1.2.1
2.3 配置共同體(community)
格式：ro(w)community communityName source
參數說明：
rocommunity定義一個只讀權限的共同體，rwcommunity定義一個讀寫權限的共同體
rocommunity6或 rwcommunity6表示監聽IPv6。
communityName：共同體名稱
source：可以訪問的IP地址范圍，默認為”default”，即任何IP都能訪問。
可選參數：－V viewName 限制共同體只能訪問viewName下的節點
實際配置文件
agentAddress udp:161
view systemonly included .1.3.6.1.2.1
rocommunity public default
3. 測試
修改完配置之后，重啟snmpd：
snmpd
連接測試：(該節點表示獲取主機內存大小)
snmpwalk -v 1 -c public localhost .1.3.6.1.2.1.1.1
SNMPv2-MIB::sysDescr.0 = STRING: Windows DESKTOP-70OA76Q 6.2.9200 Professional
得到類似以上的結果，就說明snmpd配置成功。
配置MIB庫
Windows版本的snmp自帶有很多MIB，位于C:\usr\share\snmp\mibs
因此可以對OID和MIB name做互相轉換：
snmptranslate -On SNMPv2-MIB::sysDescr.0
.1.3.6.1.2.1.1.1.0
snmptranslate .1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0
添加自己的mib
之前的筆記有提到自己創建的一個定制mib文件
https://github.com/1000copy/tbit-guard-snmp/blob/master/tbit.mib
可以把它加入到C:\usr\share\snmp\mibs目錄內，文件名無所謂。然后為snmptranslate加入選項 -mALL ，表示加載所有在此目錄內的mib文件：
snmptranslate -m ALL .1.3.6.1.4.1.66666
你應該看到如下消息，表明mib加載成功：
tbitinc::tbit
詳細的說明如下：
-m MIBLIST
指定一個用冒號分隔的MIB模塊列表（不是文件），以便為這個應用程序加載。 這將覆蓋（或增加）環境變量MIBS、snmp.conf的內容。指令mibs，以及硬編碼到Net-SNMP庫中的MIBs列表。如果MIBLIST有一個前導的'-'或'+'字符，那么所列出的MIB模塊將被加載到默認列表之外，分別位于該列表之前或之后。
否則，將加載指定的MIB，而不是這個默認列表。特殊關鍵字ALL用于加載MIB目錄搜索列表中的所有MIB模塊。 每一個名字不以". "開頭的文件都會被解析為是一個
MIB文件。
-M DIRLIST
指定一個以冒號分隔的目錄列表來搜索MIB。 這將覆蓋（或增強）環境變量MIBDIRS和snmp.conf指令mibdirs。
以及硬編碼到 Net-SNMP 庫中的默認目錄 (/usr/share/snmp/mibs)。
如果DIRLIST有一個前導的'-'或'+'字符，那么給定的目錄會被添加到默認列表中，在這個列表的目錄之前或之后進行搜索。
分別進行搜索。 否則，將搜索指定的目錄，而不是這個默認列表。
請注意，列表中出現在后面的目錄要比前面的目錄優先。 要避免搜索任何MIB目錄，請將MIBDIRS環境中的
變量為空字符串（""）。
請注意，使用-m選項或mibs配置指令指定的MIB將從-M選項（或等價物）列出的目錄中加載。
mibfile指令采用的是指定MIB文件的完整路徑，所以不需要在MIB目錄搜索列表中出現。
很多時候，設計師需要在公開場合借用幻燈片演示設計作品，或者給客戶展示的設計方案，又或者是需要在文章當中，展示作品，選取配圖。如果你希望你的展示和演講更加具有吸引力，那么可能需要針對這些視覺素材進行處理，讓你的觀眾或者讀者，被內容吸引，被信息打動，能夠 Get 到你所要表達的東西。
今天這篇文章，梳理了 20 個對關于幻燈片/演示文稿的處理技巧和經驗總結，希望能夠幫到你。
在創建任何用來展示的幻燈片之時， 你首先要搞清楚一個問題——你的目標或者目的是什么。明確了這一點，才能做好下一步的設計。
除了了解自己的目標，你還要搞清楚你的觀眾或者你的受眾是做什么，有什么特征，對什么感興趣，會具備什么樣的動機，這樣你在設計的時候，才能夠更加具有針對性。如果是甲方，那么甲方是什么樣的人？你是否要提供一個具有代入感的故事，在最后再進行報價是否合適？搞清楚觀眾，后面的問題你就有答案了。
如果你的幻燈片準備得過長，那么最好大概每20分鐘就需要中斷，適當休息一下，或者調整演示內容的媒體形態，讓你的聽眾可以借此修整，并重新集中注意力。
講故事能夠更好地同用戶建立聯系，保持用戶的參與感，集中注意力。如果用戶無法集中注意力，那么你的展示和設計做得再好都沒有用。你可以參考一些常見的、有效的敘事框架，拿捏好關鍵的因素：
關鍵角色：客戶、用戶、組織、團隊等；
核心問題：挑戰、痛點、風險等；
框架指南：產品、公司、服務等；
完整歷程：解決問題的愿景、具體執行計劃等；
抵達成功：光明的未來、最終的成就等；
這意味著，如果你的幻燈片當中的內容，下面的觀看者無法在 8 秒內消化，那么它可能就失去效果，并且用戶會快速分心。
幻燈片要簡短，不要讓它像書本一樣堆滿信息，你應該提供最快速有效的簡短展示，減少文字，增加輔助的視覺效果，幫助用戶集中注意力。
如果你的文本內容無法進一步增減，那么你需要做的就是梳理出它的層級關系，讓字體的層級來輔助觀看者更快 Get 到其中的信息。我們習慣于快速掃視，而不是逐字閱讀。
凸顯重要內容，控制好字號大小，排版結構，讓觀看者能夠清晰閱讀內容。過于鮮艷的色彩會產生視覺頻閃，對比度過低會讓可讀性極差。
在實際的展示的過程中，展示者在電腦上看到的，和最終在大屏幕上演示的內容是不一樣。演示給下面觀眾的內容一定要簡約直觀，而更多的輔助信息只需要顯示在展示者自己的電腦上，作為提示即可。
提取最重要的信息點，使用更大的展示性的字體來呈現，這是有助于讓這些信息脫穎而出的，而不是簡單地、沒有篩選地鋪陳出來。
信息圖和簡單的數據展示有著極大的差別，信息圖所展示的信息更易于被觀看者理解和吸收，使用信息圖還能讓整個展示過程更加視覺化、富有創意。
我經常會聽到這樣的要求：「這套幻燈片只能有7個頁面，同時我們不能刪除任何內容?！?
千萬不要將內容塞到固定數量的幻燈片當中，那是沒有任何意義的。一套用來演示的幻燈片的數量應該是可以增刪的，它們的數量取決于你所要展示內容的多少，以及呈現的方式。對于絕大多數的展示和演講而言，20~30 張幻燈片是一個合理的數量。
留白是制作幻燈片時最容易被忽略的元素，通常而言，我在修改幻燈片的時候，將留白的空間放大三倍，視覺上的呼吸感就正正好好。
好的圖片素材，通常會有著相對充沛的感情和自然的敘事。在你的幻燈片當中，需要采用更加富有真實感的照片，以營造真實的敘事感。不幸的是，這種設計知易行難，絕大多數的圖庫所提供的照片都缺乏這種應有的真實感。當然， Unsplash.com 所提供的照片，相對而言會好一些，而且是免費的。
影響幻燈片視覺樣式的因素有很多，主題、受眾、品牌等等等等，都會有影響。但是不論情況如何，你都應該讓整個幻燈片所采用的字體、圖標、配色、插畫的樣式始終保持一致。其中，最常用的方法是定義整個幻燈片的模板，來協助你保持一致性。
不要把幻燈片用信息全部填滿，可以在其中插入一些可以幫助觀看者「中場休息」的幻燈片，它可以起到過渡作用，也可以幫助觀看者不用一直緊繃著情緒。
轉場動效和動畫可能會成就你的整場演示，也可能讓它淪為一場災難。我的建議是，盡量讓動畫和動效微妙一點，讓它們緊貼內容，對信息提供支撐，而不是喧賓奪主。
對于較長且復雜的演示，讓觀眾看到進度條，了解整個演示的進程是非常有必要的，當他們感受到演示的進程，就能體會到掌控感和安全感。
做好幻燈片之后，一定要自己排練一下整個過程，走一遍之后會讓你對于整個演示過程中，哪里有問題，哪里要改進有更清晰的認知。借助排練來排查問題，迭代展示，非常有必要。
當然，設計幻燈片和設計 APP、網頁是截然不同的，但是設計思維層面上，這幾個領域確實完全相通的。你可以借用各種設計規則和方法來將幻燈片設計得更加合理優秀。
文章來源：優設 作者：Taras Bakusevych
藍藍設計( m.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
在B端產品中，數據主要通過表格的形式展現。本文是我從實際工作出發，結合項目和過去經驗對于復雜業務類的表格設計的一次總結。
表格（Table），又稱為表，是用來收集、整理、組織、分析數據的二維矩陣。它既是一種可視化交流模式，又是一種組織整理數據的手段。
通常表格的組成元素以及相關元素會有多個部分，筆者根據自己設計表格的工作經驗將表格概括為容器、篩選區、功能性按鈕、表頭、表體以及底欄等六個部分，其各個部分包含的相關元素如圖所示。
容器：包含表格的所有內容。
篩選區：包括搜索和條件篩選。方便用戶快速查詢定位數據，一般位于表格上方。
功能性按鈕：比如常見的[新增]按鈕和各種批量操作按鈕。
表頭：說明數據的內容，可以包含篩選、排序等功能。
表體：包含行和列數據，按列可以分為多選列、數據列、操作列。（多選列=多選框；數據列=呈現業務展現需要的信息；操作列=針對單行數據的操作按鈕，比如管理、編輯信息等。）
底欄：包含數據量、單頁條目、總條目、分頁等，底欄數據也可以放置在表格頂部。
1）幾種常見的風格樣式
a.網格型：表格有均勻而明顯的分割線，邊框單元格比較明顯。
b.水平線型：僅顯示水平線可減少整個網格的視覺噪聲。
c.斑馬條紋型：隔行交替使用不同底色來區分數據。
d.自由形式：移除所有分割線，通過盡可能減少視覺噪聲來創建極簡外觀。
2）關于樣式的選取技巧
網格型：對于數據之間的關系緊密（列信息較多而沒有足夠空間用留白來分割信息）且有對比關系的。
水平線型：它能顯著減輕表格在垂直方向的視覺重量，提升用戶進行大量數據對比時的速度。因此對于所有數據集大小，此樣式都是最常見的。
斑馬條紋型：每行交替使用不同的顏色背景是幫助用戶在閱讀時保持其位置的另一種好方法。對于較大的數據集，建議使用此樣式，在較大的數據集中，交替模式將很清晰，并且不會引起特定行突出顯示的混亂。
自由形式：對于小型數據集，如果用戶在閱讀時不需要幫助就可以保持位置，則建議使用此樣式。
信息內容的有效傳達是表格設計的本質，就表格本身而言應該是隱型的，應該讓用戶注意力聚焦在核心內容上。所以，邊框的顏色應非常淡，不能妨礙快速瀏覽。
表格是為可讀性而生的，一個結構清晰的布局能大大提升用戶對信息的接收速度和理解程度。因此，設計易讀，易掃視，易比較，易操作的表格結構是表格設計的首要目標。
下面我將以公司財務中臺的表格改版為例，逐步說明表格中每個結構的設計。
這是改版前后樣式對比圖：
篩選區可以看作表格的導航，由搜索和篩選這兩部分組成。一般搜索和篩選會同時出現，但是兩者一般很少同時使用來對數據進行定位。搜索更多的是對單一或者包含某個字段的的數據來進行定位；篩選則是用來查詢一類數據。
根據MECE分析法，篩選區可以有以下的表現形式：
常用搜索少用篩選，若篩選項多，可以選擇隱藏篩選項，篩選少可以展示出來；
搜索和篩選都常用，可以將搜索和篩選都展示出來；
常用篩選少用搜索，篩選和搜索同時展示；
篩選和搜索都不常用，展示搜索隱藏篩選。
1）搜索
在樣式上，搜索可以分為簡單搜索、標簽搜索、高級搜索等三類。
簡單搜索：由一個搜索框和一個按鈕組成?？梢暂斎胍粋€或多個條件進行搜索。
標簽搜索：在簡單搜索的基礎上加上標簽，即先選標簽，在輸入搜索內容。
高級搜索：即點擊更多展開其他搜索條件，減少了更多條件對用戶的干擾，但降低了易發現性。
2）篩選
根據篩選的位置，可以分為標簽篩選、表頭篩選兩類。
3）案例小講堂
對于數據集較大的B端系統來說，往往篩選條件比較多，都將其展示出來會導致空間占比過大，影響了用戶對表格信息的獲取。下面以我公司的財務中臺為例，講講如何優化篩選區，希望對大家有所啟示。
3.2.3 版本中篩選區樣式
篩選條件全部展開，目的是讓用戶對信息進行快速的查詢、過濾，以快速準確完成目標任務。但業務復雜，數據集過多少，篩選條件也相應增加（空間占比大），看起來非常冗余，不利于快速定位目標。為了平衡掃描、查詢、過濾、分析等這些操作，復雜業務的表格區篩選需要進行一定的優化處理，這樣才能滿足滿足業務需求同時，又符合用戶心智模型。
方案A 整齊劃一
整合篩選項，采用表頭篩選+標簽篩選的樣式，縮減篩選區的頁面空間占比。
討論結果：雖然這個方案使篩選區的空間占比縮小，整體頁面也看似整潔不少。但表頭篩選在復雜的業務系統中存在幾個弊端：
a.數據集往往很龐大，表格不能展示所有字段，往往采用列固定的形式來呈現數據的完整性。以財務中臺為例，高頻篩選功能已被遮擋（如上圖），篩選前需先對表格進行橫向滾動，無端增加操作；
b.應無法展示全部字段，用戶無法清晰的感知到篩選了哪些內容，增加認知學習成本；
c.表頭中的屬性并不是都可以進行篩選，用戶不可感知哪些可以篩選，需要滑動表格檢索。
方案B 強調主次關系
采用展開式的標簽篩選樣式，對不常用的篩選項做隱藏處理。但因業務場景的復雜度，高頻篩選功能還是很多，沒有解決本質的問題，如下圖：
方案C 分狀態展示（逐漸呈現）
在方案B的基礎上進行了優化。提煉與流程相關的狀態，按步驟顯示，每一步只顯示當前需要關注的內容，如圖：
狀態的提煉過程
1）整理每個單據的狀態，理清關系
結合業務流程可以很明顯的注意到，單據只有通過了審核才能收款，只有收款才能進行核銷。狀態是一種遞進關系（審核 ?? 收款 ?? 核銷）。
2）結合財務人員的工作流，提煉出單據的以下幾種狀態，之前存在到問題（表格中單行數據的操作不一致），也得到了完美的解決。如圖：
1）按鈕的表現形式
建議在復雜系統設計中使用圓角矩形的按鈕樣式。
理由如下：
a.人眼處理圓角更容易（認知負荷說）
Jürg N?nni（Visual Perception的作者）表示，視網膜中區處理正圓形的時候是最快速的，而處理邊邊角角的時候則比較費力，大腦處理的速度也較慢。于是，長得圓潤的圓角矩形相較于一般矩形，對于使用者來說就容易接納許多。
Barrow Neurological Institute （巴羅神經病學研究）的研究也顯示，一個物體的顯著度與邊角的角度呈線性變化，銳角相較于鈍角要顯得更明顯突出。換句話說，角度越尖銳，物體就看起來越明亮；而越明亮的物體就越難以直視。
如上圖所示角度越尖銳，看起來越顯眼，在視覺上也比較令人感到明亮，不適，大腦的認知符合也越高。
b.使相似的內容更容易被區別
舉個例子，如下圖所示，即便間距相同，B 排的圓角矩形辨識度還是明顯比A 排的矩形高。
這是為什么呢？
首先，第一眼看過去的時候，A 排的矩形整體是連在一起的，中間找不到斷點。而B 排矩形，因為有圓角的關系，所以斷點很明顯。
其次，兩種矩形的視覺聚焦：A 排由于直角的關系，視覺聚焦向外推，整體的效果比較發散。這會使得第一眼看過去的時候，容易分不清楚哪一條邊框屬于哪一塊矩形。反之B 排因為圓角收攏的關系，視覺聚焦向中心推，區塊就比較容易區別開來。
綜上所示，圓角矩形是非常有效率的容器，在復雜場景業務中（存在很多種功能型按鈕），按鈕采用圓角矩形樣式最提效。
這里要注意，圓角不是越大越好
在相同面積中，按鈕的可操作區域隨著圓角的增大而遞減，因此在同等尺寸下的按鈕中，小圓角的按鈕明顯比大圓角的按鈕更容易操作。
同時在實際業務中，按鈕常常被當作原子與下拉框聯動組成下拉菜單控件。如若使用半圓按鈕則無疑增加了下拉框的設計難度并且匹配起來也會略顯突兀。
2）批量操作按鈕的位置思考
來看個舉個例子（針對財務中臺批量操作的優化方案）
現存問題
方案A 信息前置
批量操作按鈕全部展開不做折疊處理，信息前置來降低認知成本，方便用戶記憶。
討論結果：對于復雜業務來說，會有很多批量操作功能，按鈕很多，造成頁面擁擠，進而影響用戶操作體驗；一個位置出現2個主按鈕樣式，不推薦。
方案B 沉浸式操作體驗
對于一開始不可用的批量操作按鈕進行隱藏，勾選激活狀態，顯示在篩選區。
討論結果：方案B的阻斷性強 — 無法兼顧批量操作和數據篩選功能，無法滿足復雜系統的場景操作。
方案C 上內容下操作，前2個方案的優化
不做隱藏，類灰布置于底部。勾選觸發操作條件，未做勾選時，用戶點擊時給出引導操作提示
為什么選擇方案C？理由如下：
首先，根據古騰堡原則，用戶的在做表格操作的時候，視覺流是左做到右，從上到下，方案A和方案B的視覺落腳點在表格的上方，顯然是不符合眼動規律的。
其次，批量操作的功能屬于財務中臺的核心功能點，隱藏不是第一選擇，而是類置灰的特除處理（在按鈕旁給提示信息）
2.3表頭設計
表頭在能夠概括的情況下，盡量簡練、準確，一般可根據上下文關系來進行減短簡化，以達到節省表格頭部空間和減輕視覺壓力的作用，讓用戶注意力聚焦在數據本身。如果精簡后的生僻字段難以自我解釋，可以跟一個釋義標識，鼠標懸停時出現該字段的詳細解釋，同時滿足新手用戶、普通用戶以及專家用戶的需求。
在數據的對齊方式上，有以下3個建議：
a.文本左對齊
b.數字右對齊
c.表頭與信息內容對齊方式一致
文本左對齊，符合正常的心智模型（閱讀習慣從左到右）；表頭與內容對齊一致，則是為了簡化和降低視覺噪音，以便更好的獲取數據信息。數字右對齊，有利于數據間的對比。
要注意的一個細節，例如，當列數＝2的時候，由于列與列直接的間距過大，導致兩者的關聯性較弱，如圖：
這時又該如何處理？
為了增強列與列之間的相關性，當鼠標hover在行的時候，產生高亮。這種方式可能不是最優的，但目前只能想到這種方法，如果讀者有更好的想法歡迎留言。
2)數字的字體選擇
建議選用：Helvetica Neue、Helvetica、Arial、sans-serif.
蘋方在數字字符上，不同數字寬度不一致，導致千位分隔符不在一條線上。而Helvetica Neue數字等寬，千位分隔符有序的排列在一條線上。所以，選擇Helvetica Neue作為數字字體的首選字體。數值上下對比的時候，相同位置的數字在同一條豎線上，更加容易對比。
3)對操作項進行“解耦”處理
在財務中臺系統中，常常由于權限的不同或者單據狀態不同這兩種原因，使得每行的數據擁有不同的操作項，如下圖所示：
存在的問題：
當信息過載，操作項這個list非常長的話，頁面將會非常擁擠；
文字按鈕因為視覺特征比較明顯，造成了不必要的分散注意力；
誤操作率相對較高，同樣因為表格空間有限，當操作區非?？拷?，很容易一不小心就點錯了。
針對這個問題所出的解決方案，如下：
方案A 下拉框樣式
討論結果：下拉框中可能存在不同操作，同樣避免不了誤操作這個問題。
方案B 錯位顯示
討論結果：首先，這樣的設計浪費大量的屏幕空間；其次，浪費開發工作量！因為在列表中實現一系列權限判斷和操作，在詳情界面中往往還需要再開發一次相同的權限判斷和操作；再次，不同單據可能存在操作順序不一樣，上下移動鼠標會存在不同操作，用戶代價非常高。
方案C 以不變應萬變
回歸『一個界面一個用戶任務』的原則，列表中的單行數據只保留[查看]或[管理]操作，所有其它的單獨操作都去往該單據的詳情界面完成。
討論結果：從開發的角度上看，此方案界面高度解耦，功能迭代方便，節約開發工作量；從認知成本上看，列表界面操作高度一致性，利于養成用戶習慣；從操作效率上看，在詳情頁用戶會明顯確認目標單據，幾乎不會誤操作； 同時此方案節約了大量屏幕空間，更有利于用戶對信息的獲取；
4)關于表格中套表格的解決方案
場景：在財務中臺中，有這樣一種用戶，需要對表格內的數據進行對比并編輯。
來看看之前的頁面：
這樣處理的不足點：
1.在查看和編輯信息時，無效的信息太多。降低了獲取信息的效率；
2.切換單條數據時，頁面出現跳動，無法快速檢索到相對應的信息；
對此，在3.3.2版本中，我們對其做了相應的優化。運用側視圖（快速視圖）的方式來呈現信息。一旦選擇一個單據，它就會從側面彈出的。
這個方案，它可以保持上下文，易于使用，即使是在垂直滾動視圖中顯示大量字段的情況下也效果良好。同時信息呈現的地方是固定的，利于檢索，查找。
5)行高的制定方法
開始之前首先明確一下開發是怎么實現行高的。
從上圖可以看出，開發在實現設計稿時，通常是按照行高來寫的。
因此，表格行高=文字行高+上下間距。其中，文字行高可以設定為字號的1.2~1.8倍，上下間距可以設定為字號的1~1.5倍。
行高影響每行信息的易讀性。除了上述的做法外，還有以下2種做法，來保證各場景下獲取信息的效率與易讀性。
做法1：不同分辨率使用不同行高
設計兩套不同的行高，在大分辨率下顯示較高的行高，給數據間提供更多呼吸的空間；在小分辨率下顯示較小的行高，使一屏內可以看到更多的行高。Gmail就是這樣設計的，如下圖所示：
做法2：自定義行高
自定義行高為興奮需求，可以提高用戶的用戶體驗。所以我們可以視表格的具體情況來設計設置行高的形式，可以放置在設置按鈕里，也可以在外部按鈕較少的情況下展示出來。
2.5底欄設計
最后是表格的底欄，底欄也是不可缺少的一部分，承載的作用主要是告訴用戶數據條數以及當前位置。分頁的設計是根據不同的場景進行選擇最優的設計方案。在不需要定點跳轉的場景，建議建議刪除跳頁，刪除多于的功能，使頁面簡潔、清爽。
表格中經常會出現空數據或無數據的情況，留白處理會給用戶造成一定的困惑和誤解，是系統沒有加載出來嗎？明智的做法，是無數據時用「-」來填充顯示，數據為零時與上下數據單位、小數點相同的0來顯示。
盡量減少視覺符號的使用，因為視覺符號可能會使你的用戶界面復雜，產生難以理解的內容。去除不必要的視覺干擾，例如不必要的圖標、無規律的色彩等。
當列表中數據過長時，我們需要根據屏幕寬度調整列表展示方式，超過列表默認寬度的內容可以省略，通常用...表示，鼠標移入后出現氣泡展示全部內容。
位置：建議展示在上方，因為我們的閱讀順序是從上到下，鼠標向下移動時不會被上面的氣泡遮擋住。氣泡面積不宜過大，根據屏幕尺寸控制在一定比例，一版不超過內容區的四分之一，展示不下的內容可以在氣泡中增加滾動條。
感謝閱讀！本文結合了實際項目經驗對表格設計做了一次總結，在具體項目中，你可能需要根據產品特性和用戶需求進行調整。如果你還有什么好的想法和建議，可以在評論里留言討論。
文章來源：站酷 作者：Hi_Nick
藍藍設計( m.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
單頁面應用特征
假設： 在一個 web 頁面中，有1個按鈕，點擊可跳轉到站內其他頁面。
多頁面應用： 點擊按鈕，會從新加載一個html資源，刷新整個頁面；
單頁面應用： 點擊按鈕，沒有新的html請求，只發生局部刷新，能營造出一種接近原生的體驗，如絲般順滑。
SPA 單頁面應用為什么可以幾乎無刷新呢？因為它的SP——single-page。在第一次進入應用時，即返回了唯一的html頁面和它的公共靜態資源，后續的所謂“跳轉”，都不再從服務端拿html文件，只是DOM的替換操作，是模（jia）擬（zhuang）的。
那么js又是怎么捕捉到組件切換的時機，并且無刷新變更瀏覽器url呢？靠hash和HTML5History。
hash 路由
特征
類似www.xiaoming.html#bar 就是哈希路由，當 # 后面的哈希值發生變化時，不會向服務器請求數據，可以通過 hashchange 事件來監聽到 URL 的變化，從而進行DOM操作來模擬頁面跳轉
不需要服務端配合
對 SEO 不友好
原理
hash
HTML5History 路由
特征
History 模式是 HTML5 新推出的功能，比之 hash 路由的方式直觀，長成類似這個樣子www.xiaoming.html/bar ，模擬頁面跳轉是通過 history.pushState(state, title, url) 來更新瀏覽器路由，路由變化時監聽 popstate 事件來操作DOM
需要后端配合，進行重定向
對 SEO 相對友好
原理
Html5 History
vue-router 源碼解讀
以 Vue 的路由vue-router為例，我們一起來擼一把它的源碼。
Tips：因為，本篇的重點在于講解單頁面路由的兩種模式，所以，下面只列舉了一些關鍵代碼，主要講解：
注冊插件
VueRouter的構造函數，區分路由模式
全局注冊組件
hash / HTML5History模式的 push 和監聽方法
transitionTo 方法
注冊插件
首先，作為一個插件，要有暴露一個install方法的自覺，給Vue爸爸去 use。
源碼的install.js文件中，定義了注冊安裝插件的方法install，給每個組件的鉤子函數混入方法，并在beforeCreate鉤子執行時初始化路由：
Vue.mixin({
beforeCreate () {
if (isDef(this.$options.router)) {
this._routerRoot = this
this._router = this.$options.router
this._router.init(this)
Vue.util.defineReactive(this, '_route', this._router.history.current)
} else {
this._routerRoot = (this.$parent && this.$parent._routerRoot) || this
}
registerInstance(this, this)
},
// 全文中以...來表示省略的方法
...
});
區分mode
然后，我們從index.js找到整個插件的基類 VueRouter，不難看出，它是在constructor中，根據不同mode 采用不同路由實例的。
...
import {install} from './install';
import {HashHistory} from './history/hash';
import {HTML5History} from './history/html5';
...
export default class VueRouter {
static install: () => void;
constructor (options: RouterOptions = {}) {
if (this.fallback) {
mode = 'hash'
}
if (!inBrowser) {
mode = 'abstract'
}
this.mode = mode
switch (mode) {
case 'history':
this.history = new HTML5History(this, options.base)
break
case 'hash':
this.history = new HashHistory(this, options.base, this.fallback)
break
case 'abstract':
this.history = new AbstractHistory(this, options.base)
break
default:
if (process.env.NODE_ENV !== 'production') {
assert(false, `invalid mode: ${mode}`)
}
}
}
}
全局注冊router-link組件
這個時候，我們也許會問：使用 vue-router 時， 常見的<router-link/>、 <router-view/>又是在哪里引入的呢？
回到install.js文件，它引入并全局注冊了 router-view、router-link組件：
import View from './components/view';
import Link from './components/link';
...
Vue.component('RouterView', View);
Vue.component('RouterLink', Link);
在 ./components/link.js 中，<router-link/>組件上默認綁定了click事件，點擊觸發handler方法進行相應的路由操作。
const handler = e => {
if (guardEvent(e)) {
if (this.replace) {
router.replace(location, noop)
} else {
router.push(location, noop)
}
}
};
就像最開始提到的，VueRouter構造函數中對不同mode初始化了不同模式的 History 實例，因而router.replace、router.push的方式也不盡相同。接下來，我們分別扒拉下這兩個模式的源碼。
hash模式
history/hash.js 文件中，定義了HashHistory 類，這貨繼承自 history/base.js 的 History 基類。
它的prototype上定義了push方法：在支持 HTML5History 模式的瀏覽器環境中（supportsPushState為 true），調用history.pushState來改變瀏覽器地址；其他瀏覽器環境中，則會直接用location.hash = path 來替換成新的 hash 地址。
其實最開始讀到這里是有些疑問的，既然已經是 hash 模式為何還要判斷supportsPushState？是為了支持scrollBehavior，history.pushState可以傳參key過去，這樣每個url歷史都有一個key，用 key 保存了每個路由的位置信息。
同時，原型上綁定的setupListeners 方法，負責監聽 hash 變更的時機：在支持 HTML5History 模式的瀏覽器環境中，監聽popstate事件；而其他瀏覽器中，則監聽hashchange。監聽到變化后，觸發handleRoutingEvent 方法，調用父類的transitionTo跳轉邏輯，進行 DOM 的替換操作。
import { pushState, replaceState, supportsPushState } from '../util/push-state'
...
export class HashHistory extends History {
setupListeners () {
...
const handleRoutingEvent = () => {
const current = this.current
if (!ensureSlash()) {
return
}
// transitionTo調用的父類History下的跳轉方法，跳轉后路徑會進行hash化
this.transitionTo(getHash(), route => {
if (supportsScroll) {
handleScroll(this.router, route, current, true)
}
if (!supportsPushState) {
replaceHash(route.fullPath)
}
})
}
const eventType = supportsPushState ? 'popstate' : 'hashchange'
window.addEventListener(
eventType,
handleRoutingEvent
)
this.listeners.push(() => {
window.removeEventListener(eventType, handleRoutingEvent)
})
}
push (location: RawLocation, onComplete?: Function, onAbort?: Function) {
const { current: fromRoute } = this
this.transitionTo(
location,
route => {
pushHash(route.fullPath)
handleScroll(this.router, route, fromRoute, false)
onComplete && onComplete(route)
},
onAbort
)
}
}
...
// 處理傳入path成hash形式的URL
function getUrl (path) {
const href = window.location.href
const i = href.indexOf('#')
const base = i >= 0 ? href.slice(0, i) : href
return `${base}#${path}`
}
...
// 替換hash
function pushHash (path) {
if (supportsPushState) {
pushState(getUrl(path))
} else {
window.location.hash = path
}
}
// util/push-state.js文件中的方法
export const supportsPushState =
inBrowser &&
(function () {
const ua = window.navigator.userAgent
if (
(ua.indexOf('Android 2.') !== -1 || ua.indexOf('Android 4.0') !== -1) &&
ua.indexOf('Mobile Safari') !== -1 &&
ua.indexOf('Chrome') === -1 &&
ua.indexOf('Windows Phone') === -1
) {
return false
}
return window.history && typeof window.history.pushState === 'function'
})()
HTML5History模式
類似的，HTML5History 類定義在 history/html5.js 中。
定義push原型方法，調用history.pusheState修改瀏覽器的路徑。
與此同時，原型setupListeners 方法對popstate進行了事件監聽，適時做 DOM 替換。
import {pushState, replaceState, supportsPushState} from '../util/push-state';
...
export class HTML5History extends History {
setupListeners () {
const handleRoutingEvent = () => {
const current = this.current;
const location = getLocation(this.base);
if (this.current === START && location === this._startLocation) {
return
}
this.transitionTo(location, route => {
if (supportsScroll) {
handleScroll(router, route, current, true)
}
})
}
window.addEventListener('popstate', handleRoutingEvent)
this.listeners.push(() => {
window.removeEventListener('popstate', handleRoutingEvent)
})
}
push (location: RawLocation, onComplete?: Function, onAbort?: Function) {
const { current: fromRoute } = this
this.transitionTo(location, route => {
pushState(cleanPath(this.base + route.fullPath))
handleScroll(this.router, route, fromRoute, false)
onComplete && onComplete(route)
}, onAbort)
}
}
...
// util/push-state.js文件中的方法
export function pushState (url?: string, replace?: boolean) {
saveScrollPosition()
const history = window.history
try {
if (replace) {
const stateCopy = extend({}, history.state)
stateCopy.key = getStateKey()
history.replaceState(stateCopy, '', url)
} else {
history.pushState({ key: setStateKey(genStateKey()) }, '', url)
}
} catch (e) {
window.location[replace ? 'replace' : 'assign'](url)
}
}
transitionTo 處理路由變更邏輯
上面提到的兩種路由模式，都在監聽時觸發了this.transitionTo，這到底是個啥呢？它其實是定義在 history/base.js 基類上的原型方法，用來處理路由的變更邏輯。
先通過const route = this.router.match(location, this.current)對傳入的值與當前值進行對比，返回相應的路由對象；接著判斷新路由是否與當前路由相同，相同的話直接返回；不相同，則在this.confirmTransition中執行回調更新路由對象，并對視圖相關DOM進行替換操作。
export class History {
...
transitionTo (
location: RawLocation,
onComplete?: Function,
onAbort?: Function
) {
const route = this.router.match(location, this.current)
this.confirmTransition(
route,
() => {
const prev = this.current
this.updateRoute(route)
onComplete && onComplete(route)
this.ensureURL()
this.router.afterHooks.forEach(hook => {
hook && hook(route, prev)
})
if (!this.ready) {
this.ready = true
this.readyCbs.forEach(cb => {
cb(route)
})
}
},
藍藍設計( m.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
你平時填寫過的最復雜的表單是什么？調查問卷還是文檔信息錄入？如果一個表單字段內容巨多，結構多變，填寫耗時耗力，那你將如何設計你的表單，使之體驗更佳？
1. 業務復雜，功能較多；
不知道大家是否看過法律合同之類的文件，多則好幾籮筐，少也有厚厚一疊，類似的文檔如果進行線上結構化，勢必要同樣要花費巨大的人力去填寫表單，完成基礎信息的錄入工作，同時，由于錄入的時間不確定，流程不明確等問題，也制約著表單的填寫。
2. 流程較長，操作繁瑣；
多個不同表單之間的互有關聯又相互區別，填寫的時候需要來回查看以確認信息，查閱和填寫相互并行，操作繁瑣。
3. 字段較多，關聯項較多；
幾乎每一個字段都有對應的關聯項，每個單選字段的不同項決定不同的內容，同時，由于字段數量，層級劃分不明確，會使填寫的人失去定位，產生迷惑。
1. 內容分組，分步填寫；
根據業務內容分級，合理運用顏色、間距、字體大小、卡片層級等進行信息分級
2. 實時保存，避免數據丟失，提供草稿功能，避免任務中斷；
3. 字段分組，示意結構，聯動項隱喻；
4. 信息自動帶入，節省時間；
一般表單是與某項功能掛鉤的，信息會在多個入口錄入，因此在填寫長表單的時候，如果能從系統中自動獲取到數據，就可以自動為其填充，可根據業務場景，判斷是否讓其修改和更新。
5. 提供二次編輯功能，防止信息輸入有誤；
一般的長表單在涉及非審批流的時候，可以讓其無限二次編輯，如果是處于審批流，則需要根據業務場景限制其編輯次數或者限定其編輯規則（草稿可編輯，一旦提交則不可編輯）。
6. 提供多人協作編輯功能；
如果一個長表單，需要多個不同的業務域的人來填寫，那么需要協同編輯，并實時顯示編輯的人員信息，同時，為了避免信息丟失和編輯錯亂，在同一個表單下，同一時間應該限制只允許一個人進行編輯，等其提交完后，可允許其他人進行編輯。
7. 實時檢驗；
前端實時校驗字段輸入規則，后端統一校驗信息交換規則。
比如對于數字輸入框的校驗、電話號碼的校驗、身份證號的校驗，應該在前端實時完成，在鼠標離開焦點區域或定位到下一個字段的時候，提示其填寫有誤，這樣做的目的是減少后續修改的次數，在長表單下，統一提示其填寫錯誤會是一場災難。
在點擊保存并填寫下一步或點擊提交信息的時候，就需要跟后端交換數據，驗證錄入的信息，如果不匹配，則提示錯誤，并從上至下定位至相應的錯誤字段。
8. 做好填寫引導功能；
要通過多種方式，引導表單的填寫，
在開始填寫之前，簡要說明該表單的業務目標，大概需要花費的時間等；
開始填寫后，關于每個字段的特殊說明，都需要標注出來，重要的要顯示在頁面上，不重要的就收起在注釋符號中；
填寫的過程中，切記不要到最后才告訴用戶哪里出錯了，重要的信息一定要提示到位，否則一旦出錯，前功盡棄；
填寫完成后，引導其下一步的操作，或者返回至列表。
9. 詳情頁也需要注意信息分級
表單填寫完畢后的產出物就是詳情頁，詳情頁是需要瀏覽的，因此在設計詳情頁的時候，應該本著讓用戶瀏覽方便的原則去設計，需要注意以下幾個點：
結構清晰。是指不要將內容一股腦的全堆在頁面上，要做好信息的分類，同時，注意規劃頁面的層級。
設置快捷導航。如果一個表單是長且復雜的，那么其對應的詳情頁也會變得復雜和冗長，因此在頁面的右側或者頂部設置合理的快捷導航是很有必要的。
1. 提供快速返回頂部的按鈕；
快速返回頂部按鈕的使用要注意場景，如果你的頁面比較長，且沒有分組瀏覽的導航，那就需要設置快速返回頂部的按鈕，但是在存在分組瀏覽導航和頂部懸浮標簽的情況下，不建議使用快速返回頂部的按鈕，因為在填寫表單的時候，使用快速置頂的場景比較少。
2. 提供分組模塊收起展開功能；
當一個模塊混雜著各種信息的時候，單純的模塊分組已經無法處理它的復雜度了，因此需要收起高頻且信息量大的模塊，可以合理的減少頁面的復雜度。
3. 步驟提供信息填寫完成度提示；
步驟條可以單純的作為步驟指示器使用，也可以作為一個表單完成度的提示區域。
4. 重要說明性文字盡量顯示而非收起；
在填寫大量字段的表單時，閱讀表單內容和填寫表單同樣耗時耗力，如果我們將所有的提示信息隱藏在提示符中，一般情況下，用戶不會去查看，但是如果去挨個查看提示信息，則會多花費一個步驟去點擊或者懸停來查看提示信息，浪費了大量的時間，因此如果涉及到重要的提示信息，請直接展示在字段的后面，不要隱藏起來。
5. 產品內組件應該規范統一；
在后臺產品上，關于組件的規范統一，想必是人盡皆知的設計原則，無論是各類平臺型設計組件，還是各個公司自造的設計組件，保持統一和規范對產品設計有著重要的作用，在這里不贅述組件應該怎樣規范統一，因為無論是Ant Design還是其他設計語言，都有詳盡的關于組件的定義方法，我在這里講述一個產品設計更高層面或者更深層面的原因：
組件的規范統一并不僅僅是為了省時省力，而是為了使用戶在使用的過程中達到認知上的統一和行為上的統一，在進行高頻次的操作后，界面的流程或者組件樣式已大致在用戶腦海中形成固定印象，因此在操作相同類的流程時，用戶會有更多的掌控感，試想一下，如果你在操作人事相關的流程后，去填寫績效部分的內容時，發現一個迥異的界面或者彈窗，你肯定覺得這是不是哪里出錯了，甚至會懷疑這是否是同一個系統，目前大多數公司的管理系統經過多次縫縫補補，內部的跳轉邏輯已經異常感人，界面風格也大放異彩，但是使用起來卻無從下手，深感迷茫。
因此大到界面樣式，小到間距大小，產品設計的規范和統一應該是最基礎又不可缺少的原則。
6. 龐大的信息錄入，表單內部要分步填寫，外部可拆分成不同的表單分別填寫；
對付復雜的表單，你需要解決的主要問題并不是填寫方式或者頁面設計，而是信息分級和結構拆分，解決了這個問題，基本上就解決了業務問題，其余部分就跟我們常用的表單一致。
將復雜度降低并不意味著減少頁面的信息，而是通過設計師合理的信息劃分，降低視覺上的復雜度和流程上的復雜度，這樣才會達到當前場景下的「最佳解決方案」。
隨著互聯網信息化的深入發展，復雜是避免不了的，我知道大家都推崇簡潔的設計，但那只是對視覺和樣式的定義，而非對信息的定義，我們所處的世界是復雜的，行業更是復雜的，信息的復雜度與日俱增，想要處理復雜的信息，就需要從復雜中尋求規律，這規律與業務息息相關，
藍藍設計( m.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
按鈕在界面設計中，屬于最基礎的元素部分組成，按鈕設計的精致，整個頁面的品質也會上升不少的檔次。今天給大家分享這篇文章，主要講解在設計按鈕時我們應該考慮哪些因素，包括視覺上，有哪些萬能的方法及公式，能夠正確的制定按鈕的設計標準，來提升整個設計的系統性。
在設計按鈕之前，需要先理解按鈕起到的代表含義。什么地方該加按鈕，什么地方不加按鈕，在系統化設計思路中需要非常有講究。通常按鈕在頁面，主要起到以下三點作用：
1. 某一類型的功能操作
這種比較常見，如一些控件形態的按鈕，比如加減、折疊、展開，下拉等。這類按鈕會起到一些功能形態的作用，常用于交互場景。所以在這類按鈕設計中，應當弱化按鈕形式，重點強調功能，突出主體信息。
2. 下一步的明確指引
當頁面內容信息過多后，用戶容易失去信息焦點，從而忘記下一步操作。信息種類越多，用戶權衡的時間就會越久，用戶選擇罷手及跳出的幾率也會越大。所以這個時候，在合適的地方增添按鈕，能夠很好的引導用戶進行下一步操作，提升整體操作的成功率。其次從體驗層面，也一定程度能起到頁面動線的引導作用，比如下方的一組卡片，在增添了按鈕后行動點很明確，非常有點擊欲望~
3. 固定習慣，明確心理預期
當用戶知悉某個按鈕能指向某個操作，或者獲取某類信息后，長期以往用戶就會形成使用這個按鈕的習慣，這樣對提升復訪及固定心智是非常有效果。
所以如果你認為你負責的產品或者是內容，能持續為用戶帶來價值，那么在頁面的關鍵節點，不如將按鈕設計的更醒目。這樣用戶下次再看到這個按鈕時，固定習慣會引導他持續的點擊。
這里我不以按鈕的長相來區分按鈕的類型，如漢堡按鈕或者別的什么的，意義不大。我主要還是想通過以按鈕的功能區分，來劃分類型，這樣大家理解起來更為清晰。
1. 功能性質按鈕
這類按鈕見到的最多，我們常用的APP里，大量都充斥了這類按鈕，這類按鈕會起到重點的功能交互，幫助用戶得到TA想要的信息。其次樣式上面，其實圓形的點擊欲，會更強一些，看起來也更利于點擊。而方型的按鈕，則顯得更為正式、嚴謹。
公式：如果是圓形按鈕，圓角的半徑=高度的50%比較合適，而如果是方按鈕，邊角的小圓角半徑控制在15%以下比較合適，我個人喜好用10%。
2. 聚焦大按鈕
這類按鈕通常見于一些核心頁面的強指引，比如登錄、注冊、提交表單、或者是保存，等對頁面全局進行操作的一些按鈕。需要注意的是，這類按鈕只適合對頁面全局進行操作，而且頁面中大按鈕的數量不宜超過2個，信息盡量需要保持聚焦。
公式：基于@2x，這類大按鈕的高度≥72px是比較合適的，通常的尺寸有 80px、88px、96px，大家可以根據產品面向的人群來定高度，如果頁面面向的人群較為廣泛，我建議采用 88px 或者是 96px 的這種大號版本，畢竟操作起來更為方便。
3. 吸底按鈕
這類按鈕的優先級，在整個頁面屬于最高，頁面的所有信息，都將聚焦在這個按鈕中。由于按鈕是吸底的，所以會一直浮在頁面上，不受頁面篇幅影響控制。
需要注意的是，吸底按鈕一定是頁面最重要的功能，或者是整個頁面的下一步指引，比如淘寶的立即購買，或者是餓了么、美團的立即下單，又或者是常見的充值界面。
公式：基于@2x，吸底的高度≥80px是比較合適，常見的尺寸有88px、100px、112px ，按鈕的大小可以根據內容來定，建議高度保持在72px以上比較合適。這里需要注意的是，吸底的按鈕，需要產出兩套設計稿，一套為常規稿，一套為iPhoneX的適配稿。iPhoneX底部控件的區域高度為68px，所以iPhoneX設計稿的吸底高度=常規設計稿吸底高度+68px
另外在設計按鈕的時候，也別忘了補充按鈕的多個狀態的設計稿。常見的狀態，有以下四種：
1. Normal-正常態
這個為按鈕的正常顯示態，就是正常頁面中的顯示效果。
2. Hover-懸浮態
這個為按鈕的懸浮態，一般只會出現在使用鼠標的時候。當鼠標指針停留在按鈕時，按鈕發出的特殊反饋，則為懸浮態。這類形式在移動端交互中無作用，所以移動界面設計中不需要考慮這個狀態。
公式：正常情況 Hover 態增加 10% 黑色就可以，原理如下
3. Pressed-點擊態
這個為按鈕的按壓態，就是按鈕在被點擊或者是按壓后的效果。
公式：在APP設計中，點擊后的效果我們設一個標準值讓開發實現就好了。常用的值有按鈕減少20%的透明度，或者增添20%的暗度，這兩個都可以。通常我建議在亮色上的按鈕，使用暗度疊加（增添20%的黑色），在暗色上的按鈕，則使用透明度減少（透明度改為80%），實現效果原理參考 Hover 態那張配圖
4. Disable-禁用態
當信息未填充完整，或者是某類條件未到，按鈕會出現不可點擊的狀態，處于禁用形式，這個時候，按鈕就會呈現禁用態。這個禁用態無論是web還是app，很多場景都會用到，所以建議設定一套標準的設計規范，避免重復定義這個效果。
公式：禁用態尺寸及大小不變，僅使用色值做區分。建議使用灰色或者是不透明色，常用的禁用色有#CCC或者#999，需要盡可能把樣式做弱，避免用戶做無效的點擊。
在目前移動互聯網設計中，雖然按鈕的種類很多，但風格變的逐漸統一，更多都是色值及細節上的差異。從大的風格來看，按鈕還是分為這這幾種類型：扁平化、輕擬物、重擬物及游戲按鈕。
1. 扁平化按鈕
這類按鈕我們設計用的最多，信息簡潔，操作方便，形式追隨功能。這里也給大家分享一下我在設計扁平化按鈕的一些經驗，比如高度寬度，以及陰影的色值。
公式：按鈕高度，這個通常是文字字號的2.4倍然后取4的倍數整數，比如字號是24，那么按鈕的高度=57.6，離4倍數最近的是56，所以高度=56，圓角=10%的高度，取整后是6px。
另外如果覺得不合適，也可以單位往8遞增或者是遞減即可，例如 56、64、72、80、88 px
按鈕寬度：如果不是那種全局按鈕，通常按鈕的寬度=最多容納字數的寬度+按鈕高度，就好啦。還是以上面那個例子為例，按鈕高度=56，文字寬度=96，那么按鈕的寬度=56+96=152
2. 輕擬物按鈕
這類按鈕近幾年變的非常流行，甚至QQ、淘寶，都開始大面積使用，因為這類按鈕在保持信息簡潔的同時，仍然有較強的點擊欲，視覺上面也能夠增添頁面的品質感。
公式：漸變方向，建議采用水平漸變，重色在右側，輕色在左側更為合適。陰影色值我之前就寫過，不知道大家還記得么，陰影顏色=按鈕顏色的 Alpha50%，x=0，y=按鈕高度的20%，模糊值=按鈕高度的50%，擴展=按鈕高度的 -15%，高級又簡單，完美！
如果覺得這個彌散陰影太大的同學，也可以自己手動簡單調整下，不礙事。（這個公式僅適用于Sketch，用PS的同學，也可以按照這個邏輯自行研究一下）
另外說一句，實際上這個陰影公式并沒有什么很多的依據，大多數都是我個人原創總結出來的，簡單好用。比如下面的這些按鈕的樣式，用了公式后的效果大家可以自行感受~
3. 重擬物及游戲按鈕
在一些營銷頁面中，按鈕的樣式通常需要做的比較游戲化。游戲化的按鈕，大部分會采取游戲場景中的元素，再采用擬物的手法，來進行打造。
通常游戲化的按鈕，需要重點幾個部分組成，學過素描的同學應該會知道，立體的物體，通常會有幾大特征，分別為高光，亮部，暗部，投影及反光。那么如果我們需要繪制一個在營銷或者游戲場景中使用的按鈕，只需要保證這個按鈕有高光，亮部，暗部，投影及反光的這些特征，然后飽滿一點就，立馬就可以出效果啦。
當然，我舉的這幾個例子都是最基礎版本，如果你想做的更豐富一些，那也是沒問題的，這個可以case by case 來定。
這個沒有太多的公式可以總結，更多的是看設計師的基礎美術水平啦~~
在寫這篇文章的時候，突然刷到了一套新擬態的控件設計風格，有種眼前一亮的感覺。雖然這套設計視覺上很有層次很好看，不過感覺短時間之內，比較難大面積推廣，因為開發實現起來還是會比較耗費成本。
我把源文件保存下來了，對這個感興趣或者好奇這種效果如何實現的同學，可以下載源文件研究~~ sketch、psd、Figma 格式都有。
文章來源：優設 作者：UX小學
藍藍設計( m.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
| 章節名稱 | 地址 |
|---|---|
| Vue.js教程-安裝和HelloWorld | https://coderhqf.blog.csdn.net/article/details/107574556 |
| Vue.js教程-Vue項目的目錄結構和.vue文件的構成 | https://coderhqf.blog.csdn.net/article/details/107621070 |
| Vue.js教程-Vue基本指令 | https://coderhqf.blog.csdn.net/article/details/107677588 |
| Vue.js教程-組件化開發 | https://coderhqf.blog.csdn.net/article/details/107783664 |
版權聲明：本文為博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接和本聲明。
與傳統PC桌面不同，手機屏幕的尺寸更加小巧操作，方式也已觸控為主，APP界面設計不但要保證APP功能的完整性和合理性，又要保證APP的功能性和實用性，在保證其擁有流暢的操作感受的同時，滿足人們的審美需求。
接下來為大家介紹幾款手機appui界面設計
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
（以上圖片均來源于網絡）
藍藍設計( m.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
更多精彩文章：
還記得2019年4月上映的復仇者聯盟4么，漫威電影宇宙的第三階段結束了，電影很精彩，但最令人震撼的是先導版的電影海報！就是那個「五彩斑斕」的黑～
從設計上看，海報的設計師是把光運用到極限了，通過逆光和環境塑造出了酷+神秘的視覺感受。光是一切視覺表現的基礎，是構圖和傳遞調性的關鍵，也是視覺表現重要的組成部分。所以今天就和大家聊聊啥樣的光是一個牛X的光以及如何塑造一個合格的光影？
常見形式1-聚光
△ 圖片來源：小米米家臺燈1S
聚光是最常見光，也是在設計中用到最多的光，通常在塑造一個物體的時候就會用的到。
因為聚光的原因，場景更像個舞臺，凸顯「主角」的存在。具體的原理可以根據下圖去理解。
常見形式2-自然光
自然光其實就是陽光，理論上講其實光源是太陽也是聚光，但由于光源太過于龐大，無法真正的聚焦，所以就把這種光當成一種泛光源就好。在產品設計中也會經?？吹筋愃频墓庠闯霈F，比如行為召喚按鈕：
因為不需要強有力的表現和氛圍的營造，所以通常產品設計中更需要自然光來作為核心光源，通過泛光源去統一控制產品的光影體系就好（發布的 Mac OS – big Sur 的整體光源同樣是自然光，下文會講到）。
常見形式3-逆光
坦誠的講逆光也是聚光的一種，只不過由于角度特殊，呈現的視覺效果也非常不一樣，所以就單獨把逆光拿出來說一說。當畫面需要逆光來營造氛圍的時候，只需要在固有色上加上黑色蒙板和邊緣的高光就可以大概塑造出一個處于逆光的物體了。
小米是典型的逆光氛圍營造高手，但萬變不離其宗，依舊可以從海報里看到相同的方法。
△ 圖片來源：小米傳播物料
通?，F實中的光源并非那么理想，光線的復雜超出肉眼所見。所以我們在繪制的過程需要注意到，可以適當的抽象。舉個例子，自然光是普照的，所以我們抽象為四個小光源平均分布，依次打到物體上：
在他們疊加的部分可以清晰的看到，1是最重的，2其次，3再次。按照這個辦法就可以獲得光影的層級關系，在繪制輕擬態的圖標或者運營活動中更加細膩。
△ 圖片來源：09UI設計工作室-陌陌直播禮物設計
所有的光影其實都是幫助主體塑造體積感，一個合格的立體圖形必須具備：高光/過度色/明暗交界線和反光這四個基本屬性。
然后需要一點超現實主義的手法，把太陽光過濾下，從「赤橙黃綠青藍紫」的色調里提取跟主體和諧的顏色（通常是補色），營造出介于真實與玄幻之間的美妙效果hiahia～
然后再在投影上加一點點色彩傾向，一個完美的黑八就出現啦～按照這種方法，你可以試著去嘗試更多的物體/場景。（下圖是筆者作品「插著紅旗的地球」hiahia）
影響主體的除了光影之外就是材質了，近年來的三大巨頭apple/Microsoft/Google的設計都在材質上下足了功夫，蘋果的毛玻璃，微軟的亞克力和谷歌的「紙」。
從趨勢上看，材質的引入對產品中拉開層級關系上有巨大意義，以往的設計僅僅是通過光影和焦距來拉開關系，這兩個維度在少量的疊加界面中還能有效果，但到了復雜的多窗口互壓互疊里就不是那么奏效了，所以鐵子們要善于運用材質區分產品顯示的優先級。
△ 圖片來源：Eric Hoffman – Big Sur Mac Icons
△ 圖片來源：JIAJIE – WeSing Live gift
圖標好壞除了造型之外最重要的就是質感了，通常圖標也就是4種形式（如下圖），類似蘋果的系統圖標和抖音直播間禮物的圖標都是最后一種形式。
但如果僅僅是這樣就太水了，既然都說了是干貨預警，那就要拿出哥們看家的本領～此圖是大家關注公號后就會收到的推圖，主體就是一個POI的圖標加上微信的對話框和代表干貨的小星星營造出的氛圍。
刨析下這個圖，三個發光體和底下的投影，通過上文的講解依次繪制完成～
之后就到了amazing的時刻了，打開photoshop找到「濾鏡-模糊畫廊-場景模糊」設置幾個key-point，調試模糊值和透明度/亮度，最終完成對光影的塑造。
空氣中的灰塵相信大家都不陌生，這種情況多數是一束光影從窗戶里射入后，在光的折射下把平時看不到的灰塵統統照了個遍。
如果你是mac用戶一定熟知keynote里的動畫效果「轟然墜落」，這個效果是在模擬物體振動后彈開周圍灰塵，非常震撼。在PPT的設計中你也可以同樣借助光和霧來營造你想要的效果，下圖是我在做工作總結的時候為了凸顯Q4工作采用的辦法。
光影輕擬物在產品設計中的應用面還是很廣的，比如：圖標、數據可視化、插圖等等。而在大量扁平設計時代適量使用會顯得很出彩，當然再好的教程也比不上大家多動手試試練練，所以鐵汁們行動起來咯~
文章來源：優設 作者：Nana的設計錦囊
藍藍設計( m.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
藍藍設計的小編 http://m.skdbbs.com