整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
Nativefier 是一種命令行工具，可以用最少的配置輕松地為任何網(wǎng)站創(chuàng)建桌面應(yīng)用程序。它是由 Electron 引擎生成的可執(zhí)行文件（.app .exe 等），能夠運行在Windows，MacOS和Linux平臺。
GitHub頁面：https://github.com/jiahaog/nativefier
這里我以 Windows 10 LTSC 1809 作為演示，首先需要安裝Node.js，最新版本默認集成了npm，進入官網(wǎng)下載并安裝到計算機。下載地址：https://nodejs.org/zh-cn/
安裝好 Node.js 之后，還需要設(shè)置全局變量，因為加載極為緩慢，這里我們使用淘寶源來進行操作會快上不少。找到系統(tǒng)屬性 – 高級 – 環(huán)境變量 – 新建用戶變量。變量名：ELECTRON_MIRROR 變量值：http://npm.taobao.org/mirrors/electron/
接下來就到了安裝 Nativefier 的環(huán)節(jié)，只需在cmd命令提示符中輸入 npm install -g nativefier 即可完成安裝。
最后，就可以用 Nativefier 來生成你想要的桌面應(yīng)用程序了。例如要為https://www.smbinn.com創(chuàng)建桌面應(yīng)用程序，只需在cmd命令提示符中輸入 nativefier “https://www.smbinn.com” 生成后的程序默認在C盤用戶文件夾。
最終效果如下圖所示
于每天日常的工作需要，我需要接觸大量的外文資料，因此，一個好用的翻譯工具必不可少。得益于 Google 在翻譯上的優(yōu)秀表現(xiàn)，將它作為我的主要翻譯工具使用也是無可爭議。但是在使用中經(jīng)常會發(fā)現(xiàn)，web 端的頁面總是會在不經(jīng)意間被手滑關(guān)掉，要用的時候找了一會才發(fā)現(xiàn)需要重新打開。
此外，想要在工作時間更好地進行「摸魚」，用電腦肯定會比用手機更安全。
有了這兩個需求，我尋找了數(shù)款能夠?qū)?Web 轉(zhuǎn)換成 Mac app 的工具，但在體驗之后都發(fā)現(xiàn)會有這樣那樣的小問題，有一些甚至無法工作或是生產(chǎn)的 app 無法打開。
直到我發(fā)現(xiàn)了它 —— nativefier。
nativefier 是一個基于 Electron 的命令行工具，完全開源，沒有 UI 界面，且無需安裝任何 app，只需要通過一行簡單的代碼，就可以輕松地將任何 Web 頁面打包成可以在桌面運行的 app，并且支持在Windows，Mac 甚至是 Linux 系統(tǒng)上運行。
P.S. 作者是一位在 Google 工作的軟件工程師，似乎是一位華人。
目前，nativefier 在 Github 上已經(jīng)獲得了 2.14 萬個 Star。
使用 nativefier 的過程非常簡單，但需要提前準備一些東西。這里我以 macOS 作為演示，其它平臺大同小異，可以參考網(wǎng)上的其它教程。
首先，我們需要安裝 Node.js。你可以通過到 Node.js 的官方網(wǎng)站下載之后進行安裝，但我這里更推薦使用 Homebrew，這樣就可以在一個終端 app 里搞定全部的事情。
如果你還沒有安裝 Homebrew，可以通過下面這一條命令在終端進行安裝。
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
更多關(guān)于 Homebrew 的使用，可以參考這篇文章。
安裝好 Homebrew，就可以安裝 Node.js 了。在終端內(nèi)輸入：
brew install node
如果因為某些網(wǎng)絡(luò)原因安裝緩慢，可以試試換成國內(nèi)的鏡像源。跑完進度后，可以在終端中輸入 node -v 和 npm -v，測試一下版本，出現(xiàn)版本號即說明安裝成功。
有了 Node.js，我們就可以來安裝 nativefier 本體了。同樣是在終端，輸入下面的命令：
npm install nativefier -g
如果提示權(quán)限不足，可以試試在前面加上 sudo：
sudo npm install nativefier -g
搞定。接下來，我們就用 nativefier 來制作一個 app。
最簡單的使用方法，只需要用 nativefier 加上一個你需要轉(zhuǎn)換成的網(wǎng)站地址就可以了。例如：
nativefier "https://www.sspai.com"
第一次運行會下載 Eletron 框架，可能會慢一些。
命令執(zhí)行完畢后，會生成一個大小在 120 - 150M 左右的，名為「 ---darwin-x64」的文件夾。如果你沒有更改運行地址，那么會默認出現(xiàn)在你的個人文件夾中。
點擊進入文件夾內(nèi)，就能看到剛剛制作好的 app 了。將這個 app 拖入到應(yīng)用程序文件夾中，它就會出現(xiàn)在 Lanchpad 里。
一個網(wǎng)頁打包的少數(shù)派 for Mac app 就做好了。
上面的這個方法，會自動抓取網(wǎng)站的名字和 Logo 來作為名稱及 app 圖標。但有時，nativefier 也會「翻車」（比如上面 app 名字顯示成了「--」），這時候就需要我們自定義 app 的名稱。可以用下面這條命令：
nativefier --name "在這里輸入 app 名字" "http://www.sspai.com"
注意，這個 app 名字不支持中文。如果你想要更改中文的 app 名稱，可以在 nativefier 制作好的 app 上直接更改，再拖入到應(yīng)用程序文件夾中。
不過，nativefier 有個小瑕疵：由于有些網(wǎng)站的圖標或 logo 形狀不好看，又或者太丑、分辨率太低，導(dǎo)致有些時候生成的 app 圖標無法令人滿意。
這個問題其實也有解決辦法。nativefier 提供了一個 --icon 的參數(shù)，只要我們準備一張 png 格式的圖片，就可以應(yīng)用成圖標了。
如果你不太明白上面在說什么，你也可以手動進行替換。提前準備好一個 icns 格式的圖標，并命名為「electron.icns」，然后在生成好的 app 上右鍵點擊「查看包內(nèi)容」，進入「Contents - Resources」，將我們準備好的圖標放到里面替換原來的圖標即可。
例如，我這里就用 Sketch 為 Tinde 和小特畫了一個和 macOS Catalina 原生風(fēng)格類似的高清圖標 ，然后再用 Image2icon 轉(zhuǎn)換成 icns 格式，替換之后，就沒有這么強烈的「像素風(fēng)」了，違和感也降低了不少。
這個頁面里有 4 個 app 都是用 nativefier 生成的
除了這些之外，nativefier 還提供了很多可供選擇的參數(shù)，例如是否要限制 app 窗口的寬高、是否顯示菜單欄、、是否在關(guān)閉時推出、是否開啟 flash 支持等等，你可以在終端直接輸入 nativefier 或 nativefier -h 來查看，或者是閱讀官方的 API 文檔 來學(xué)習(xí)。
哦對了，nativefier 制作的 app，甚至還支持調(diào)用系統(tǒng)的推送。例如將微信網(wǎng)頁版打包成 app 之后，有新消息來時，一樣也能夠收到新消息通知。
好了，nativefier 就給大家介紹到這里，我要用剛打包好的 app 去摸魚了。
輯導(dǎo)語：在產(chǎn)品設(shè)計中，細節(jié)之處有時隱含著許多值得思考的地方。Web表單界面設(shè)計便是如此，比如標簽設(shè)計中，哪種標簽對齊方式更好？標簽?zāi)┪灿质欠裥枰用疤枴O(shè)計師應(yīng)該如何解決這些細碎的問題？本篇文章里，作者就Web表單設(shè)計中的“冷知識”進行了總結(jié)，一起來看一下。
當我們設(shè)計Web表單時，往往用最直覺的設(shè)計經(jīng)驗本能驅(qū)動我們?nèi)ソ鉀Q一些看似在界面設(shè)計中最簡單的問題，但每每到細微之處，又會有無數(shù)疑問從細節(jié)中冒出來給我們的設(shè)計造成困擾。
例如：在表單界面Label（標簽） 和 Input（輸入框） 上下還是左右排列合理、Label要不要加冒號、輸入框到底多寬合適等等……
以上這類問題看起來并不影響用戶完成任務(wù)，很久以來也少有人關(guān)心這些細微之處會不會對用戶有什么影響。
以至于，我表達想寫一篇探究這些細節(jié)的文章時，同事會偷笑說：你都開始研究標簽?zāi)┪惨灰用疤柫藛帷淞恕媸莻€冷知識！
確實如此，這些偏門、細碎的內(nèi)容，鮮少有人會去留意和思考。因此我在寫下這些分享內(nèi)容時期望可以達到目標是：“冷知識雖然冷，但有用”。用我了解的這些表單設(shè)計冷知識：啟發(fā)你的冷思維、引出你的熱思考。
話不閑聊，我們開始討論第一個問題。
有個表單細節(jié)不知道你有沒有想過，標簽?zāi)┪彩欠褚用疤枺?/p>
這個問題在我前團隊發(fā)生過激烈爭論，有同事說：“不要加，占用間距，而且沒人會留意它……”,也有人說：“要加，從含義上講，冒號的作用就是提示上下文或總結(jié)上下文的停頓。加上之后能更好表示標簽與輸入域的關(guān)聯(lián)…….”。
聽起來好像都有些道理，那到底誰更對呢！
首先，我們追溯一下 Web 發(fā)展史，早期可訪問性核對清單中通常堅持要標簽帶冒號，因為屏幕閱讀器一度必須依賴各種技巧才能理解標記不明的表單。
而隨著技術(shù)發(fā)展，Web表單使用“l(fā)abel”標簽（tag）可以做正確的標記，那么屏幕閱讀器就能通過標記（markup）把標簽（label）和相應(yīng)的字段對應(yīng)起來則無需再借助冒號。
不過在客戶端又有些意外！曾經(jīng) Windows Vista 指南中明確要求使用冒號， Mac Aqua 也有此要求但規(guī)則會稍靈活一些。
這種情況是因為某些情況下屏幕閱讀器在桌面環(huán)境與可閱讀源代碼的網(wǎng)頁標記相比會遇到一些困難，桌面環(huán)境不會直接顯示代碼。也是這個歷史原因，造成 Vista 和 Aqua 各自都有大量其標簽包含冒號的歷史表單。因為實在沒有必要把它們?nèi)扛牡簦钡浇裉炜蛻舳说谋韱我琅f延續(xù)這一規(guī)則。
通過Web發(fā)展史我們明白表單標簽帶冒號的產(chǎn)生是為了解決早期屏幕閱讀器的識別，如今的屏幕閱讀器技術(shù)已轉(zhuǎn)變?yōu)樽R別標簽的底層代碼，無需借助這種形式了。所以從這點來看要求標簽帶冒號已經(jīng)站不住腳了。
那從情感角度分析標簽帶冒號的是否對用戶體驗有影響呢？
回到最開始，我和同事們的爭論……
先簡單說下答案，無任何影響！
在《Web表單設(shè)計·創(chuàng)建高可用性的網(wǎng)頁表單》中，作者（卡羅琳·賈雷特）曾經(jīng)做過大量的表單測試，最終證明從未有一名用戶談?wù)撁疤柺欠癯霈F(xiàn)，即使是有些在其他環(huán)境中很介意標點符號的人似乎在線上表單中也未曾注意到。
從以上兩個角度不難發(fā)現(xiàn)，無論是從技術(shù)發(fā)展還是情感體驗，都證明可不必要求表單帶冒號；因為可用性訪問清單不再有這樣的要求，用戶研究也證明幾乎沒有人會留意表單冒號是否出現(xiàn)。
這樣的結(jié)論，看似表單帶冒號是失敗了……但這并不妨礙它作為一種習(xí)慣或傳統(tǒng)延續(xù)至今，無論在客戶端還是Web設(shè)計系統(tǒng)中仍然常見。例如：蘋果電腦的Mac系統(tǒng)，國內(nèi)阿里的Ant Design Web設(shè)計系統(tǒng)。
因此，得到以下幾點建議：
在表單中標簽與表單域的對齊方式，如果你的團隊已有明確的規(guī)范和使用場景，你只要拿來主義即可。可如果某天由你主導(dǎo)定義一個新的表單規(guī)范時，不知道你會不會重新考慮哪種標簽對齊方式更好，怎樣區(qū)分使用場景！
通過科學(xué)實驗發(fā)現(xiàn)，無論是在眼動儀的熱圖，還是在許多可用性測試的觀察結(jié)果中，用戶在填寫網(wǎng)頁表單時視線主要集中在輸入框的左側(cè)。他們的視線幾乎不會落到輸入框的右側(cè)，甚至都不會瞟上一眼。
以此為基礎(chǔ)，我們在網(wǎng)頁表單設(shè)計中有3種最常見的標簽對齊方式：頂對齊標簽、右對齊標簽和左對齊標簽。你可能會說還有混合對齊標簽、內(nèi)聯(lián)標簽、圖標標簽等，這些確實存在但并不是最核心的幾種對齊方式，它們基本是在這3種形式上變化，不脫離本質(zhì)。
下面我們逐個分析一下。
馬泰奧·彭佐從2006年7月進行眼動研究發(fā)現(xiàn)，從標簽移動到輸入框只需50毫秒。比左對齊標簽快了10倍，后者需要500毫秒；比右對齊標簽方式快2倍，后者高達240秒。能迅速填完頂對齊標簽表單的原因之一，是因為眼球只需要在標簽和輸入框之間進行上下單向運動。
1）優(yōu)勢
最利于減少表單填寫時間（標簽和輸入框位置最為靠近）；用戶視線固定，動線一直向下（清晰的完成路徑）；節(jié)省大量橫向空間（可用于以多種方式組合的相關(guān)輸入框）。
2）劣勢
占用額外的垂直空間（如果可提供使用的垂直屏幕空間較小，應(yīng)當謹慎使用頂對齊標簽）；建議使用輸入框50%至75%的高度作為相鄰輸入框間距。
3）適用場景
希望用戶快速填寫表單，完成任務(wù)；同時，當輸入項存在主次之分時，對標簽擴展性要求高。
如果要盡量減少表單占用垂直屏幕空間，右對齊能提供快速完成時間。馬泰奧·彭佐的眼動研究發(fā)現(xiàn)，專家用戶和新手用戶掃視（眼睛運動）右對齊標簽表單的標簽和輸入框的平均時間分別在170毫秒和240毫秒，而填寫完成時間比左對齊快2倍。
1）優(yōu)勢
標簽與輸入框相鄰（方便快速填寫）。
2）劣勢
右對齊布局造成左側(cè)不齊，影響了快速游覽表單的效率問題；若標簽文字寬度變寬，右對齊還存在靈活度問題。
3）適用場景
既要減少垂直空間，又要加快填寫速度的場景。
在頂、右、左三種方案中，左對齊表單填寫速度最慢。因為左對齊表單解析問題時眼球定位次數(shù)最多，用戶一般情況下都能將左對齊布局中的標簽和輸入框聯(lián)系起來，只是花費時間較長。根據(jù)馬泰奧·彭佐的研究，典型掃視時間為500毫秒，很長說明用戶經(jīng)歷了沉重的認知壓力。
1）優(yōu)勢
容易游覽標簽；占用垂直空間較少。
2）劣勢
標簽和輸入框的相鄰間距增大；適合于用戶不熟悉表單要收集的數(shù)據(jù)或問題無法分成易處理的內(nèi)容組，左對齊標簽游覽表單問題會更容易。用戶只要上上下下閱讀標簽左欄，不會被輸入框打斷。
3）適用場景
表單中存在較多的復(fù)雜或敏感信息，希望用戶放慢速度、仔細思考（在一些注冊類表單中較多使用）。
單從效率角度看，頂對齊標簽>右對齊>左對齊，但是根據(jù)應(yīng)用場景，效率快并不是我們選擇標簽對齊方式的唯一的指標。
因此，得到以下幾點建議。
如果你希望用戶放慢速度，仔細思考表單中每個表單項，左對齊標簽是個好選擇，特別是含有大量可選輸入框或高級設(shè)置的陌生數(shù)據(jù)時。
而頂對齊標簽在一些國際化產(chǎn)品的表單設(shè)計時，會有更好的延展性。
至于，右對齊標簽雖然與表單域聯(lián)系緊密，便于用戶填寫，但是要考慮好標簽的長短不齊如何解決。能否精簡標簽內(nèi)容，以及確定好表單與界面的邊距。
許多表單設(shè)計中，有個常見問題：是否應(yīng)該標記必填字段？如果表單中的大多數(shù)字段或全部都是必填的，我們是否仍然應(yīng)該標記它們？
先簡單回答：是肯定的，用戶有時需要通過必填標記來評估工作量，了解輸入信息量的最低限度。我會在下面具體解釋原因。
通常，設(shè)計師會覺得每個必填字段都有一個標記是重復(fù)的、丑陋的、占空間，而且干擾界面，甚至可能看起來很擾亂（有認知負擔！）。因此通常采取以下一種或兩種策略：
1）用戶一般不喜歡閱讀表單頂部說明。不難想象，用戶不太可能閱讀表單頂部的說明。表單字段需要自給自足，畢竟，每個字段都有特定指令——它的標簽，為什么用戶需要閱讀其他任何東西來填寫它呢？
2）即使用戶閱讀了說明，也可能忘記。你可能會說：用戶閱讀了頂部的說明，怎么就會忘記——這么簡單的事情？
的確容易忘記，特別是當表單很長或填寫表單被打斷時（這種情況在移動端很常見）。即使用戶記得，但這占用了工作記憶，增加了認知負荷。換句話說，你讓用戶完成任務(wù)更難了。填寫表單本身對用戶來說就相當有挑戰(zhàn)性——為什么要讓它更具有挑戰(zhàn)性？
3）用戶必須掃描表單以確定是否為必填字段。不難發(fā)現(xiàn)，無論是否在表單頂部包含說明，結(jié)果都可能相同，用戶會忽略或忘記。他們會掃視表單，找到一個標記為必填或可選的標識。
而且有些用戶甚至不會費心去環(huán)顧四周，他們只會做出假設(shè)。他們會想——“嗯，郵箱——不需要我的郵箱吧？先空著呢”。即使用戶沒有留空，也不得不暫停來思考一個字段是否需要填寫，減慢交互速度并使過程看起來更長、更乏味。
想要解決以上問題很簡單：標記所有必填字段。盡量明確和清晰展示每個必填字段，并標記它。當然，就像有些設(shè)計師所說：界面出現(xiàn)大量必填標識（紅色星號*）確實會增加視覺噪聲。甚至重復(fù)的星號 * 會帶來一些認知恐慌。但相比之下，兩害取其輕，這些負面因素是輕微的。
這里包含至少有兩種方式：星號*（紅色）和“必填”提示。星號*在網(wǎng)頁上已經(jīng)很常見，用戶熟悉其含義。優(yōu)點是它不占用太多空間，也看起來與標簽文字足夠不同，所以使用它。
可以使用其他標記形式嗎？當然可以，但是最好遵循市面上常見的形式（雅各布定律），這樣更符合用戶認知。
星號應(yīng)該在字段標簽之前還是在字段標簽之后？
這不一定有實際影響，但將其放在標簽之前的一個原因是，只需掃視標簽的最左邊字符，就能輕松定位必填哪些字段。
星號*是一種視覺標記，應(yīng)當仔細考慮表單中的標識位置。標識在標簽左邊能指引用戶迅速瀏覽界面，并判斷出必填項。如果在右側(cè)由于輸入框形式、長度各不相同，標識和輸入框?qū)R會導(dǎo)致難以瀏覽和判斷。
雖然這不是強制性的，但標記可選字段確實減輕了用戶思考：如果沒有這個標識，用戶要環(huán)顧四周，并根據(jù)其他標記字段推斷該字段是可選的。如果“非必填”在字段標簽旁邊，那該任務(wù)會變得更容易。不描述可選字段，這沒問題，但這樣做會是一個很好的額外幫助。
登錄表單很短，一般由兩個字段組成：用戶名和密碼，這兩個字段總是必填的。如果使用星號*，標記這些字段的成本很低，并不會出錯。但是，絕大多數(shù)用戶都使用過很多登錄表單，他們是知道要登錄需要輸入郵箱/用戶名和密碼的。所以，在登錄表單中，可以省略這種形式。
而在注冊表中不標記必填字段是危險的。注冊表單因產(chǎn)品而異——不同公司在創(chuàng)建帳戶時需要不同類型的信息。它不僅僅包含用戶名和密碼，所以請標記所有必填字段（包括用戶名和密碼）。
因此，提出以下幾點建議。
基礎(chǔ)前提，盡量去除任何不需要回答的問題，特別是涉及到用戶隱私的內(nèi)容。可以更容易讓用戶填完表單。
為了增加表單填寫的機會，請盡量減少用戶需要付出的努力和他們需要記住的信息。有很多方面有助于解決這些問題，但標記必填字段（以及可選字段）是最容易的方法之一。
先給出答案：這是肯定的！
在《選擇的悖論》一書中，作者巴里·施瓦茨討論了生活中選擇過多的影響。并提出策略應(yīng)付無處不在的過多選擇。他特別敘述了智能默認的能量——即在滿足多數(shù)人需要的地方放置選擇——來幫助人們做出明智的選擇。
而在Web表單中也有很多地方能利用智能默認減少不必要的選擇次數(shù)或輸入，加速表單完成過程。所以，只要合適就在表單域中預(yù)先為用戶填寫你認為他們想要的輸入值。
通過提供合理的默認，能有效節(jié)省用戶時間，就是這么簡單。應(yīng)用分擔了用戶思考或輸入答案的工作。填寫表單永遠不是一件有趣的事情，如果這個模式能把表單填寫的時間減少一半，用戶會非常感激。
你可能會問：默認值不是用戶想要的，誤導(dǎo)用戶怎么辦？
在設(shè)計有默認值的表單域時，你要思考默認值是否是大多數(shù)用戶可以接受的答案，如果不確信可以先去做一下用戶調(diào)研，了解用戶的心聲。
就算默認值真的不是用戶想要的，至少你也為他提供了一個示例來告訴用戶答案應(yīng)該是什么樣子的。這一點也可以節(jié)省用戶幾秒的思考時間——或避免一條錯誤信息。
但并不代表所有的表單域都要給出默認值，我們只是盡可能的讓用戶節(jié)省時間。
如何使用：
在第一次向用戶顯示表單時，用一個合理的默認值預(yù)先填寫文本框、組合框或者其他控件。也可以使用用戶之前提供給應(yīng)用的信息來動態(tài)地給出默認值（例：通過身份證自動識別出生日期；利用郵編，推導(dǎo)出對應(yīng)省/市）。
如果只是因為你覺得不應(yīng)該留下空白的輸入域，那么不要使用默認模式。只有當你有理由確信絕大部分用戶，在絕大多數(shù)情況下，不會修改這個取值時才提供默認值——否則，這將會給用戶帶來額外的工作！
有一個容易被忽視但實則舉重若輕的問題，表單中輸入框?qū)挾热绾卧O(shè)定？
在表單設(shè)計中，對于 Checkbox、Radio 等控件，很明確必須跟隨內(nèi)容自適應(yīng)處理。但對于Input、Select等你會不會產(chǎn)生困惑，是定寬處理還是跟隨內(nèi)容更好。
不知道你是否試圖這么理解過？輸入框作為用戶填寫信息的主要方式，其表現(xiàn)形式是否可以提供給用戶填寫表單的有用線索。
唐納德·諾曼的著作《設(shè)計心理學(xué)》中詳細講解過心理暗示方面的內(nèi)容。而寬度的變化就是一種有效暗示。
在真實場景中，大部分輸入框是存在理想長度的，那么就應(yīng)該向用戶暗示所需輸入內(nèi)容的長度來減輕判斷負擔。
下圖就是典型案例，一個實際不需要花多少錢的金額輸入框在左圖中進行等寬處理，反而容易誤導(dǎo)用戶對輸入金額的判斷，造成一種不安全感。
表現(xiàn)形式要為用戶填寫提供有用線索，采用不同長度的文本框提供了暗示；這種暗示是一種有用線索，當輸入框長度長短不定時，用戶會很自然地思考為什么這樣；填寫輸入框時會自然考慮這些線索。
請注意！保證暗示效果的同時，不要設(shè)定太多的寬度，反而會讓表單顯得凌亂；太少又會讓表單看起來都像四四方方的盒子。最佳方法是找到適合產(chǎn)品的最佳模度值和數(shù)量。
什么是模度值和數(shù)量呢！
落在具體設(shè)計上要先梳理產(chǎn)品中常見的表單類型，然后設(shè)置一個默認寬度。以此為基礎(chǔ)來有規(guī)律的增加長度，并考慮清楚它們的適用場景；從而定義出不同的模度，最終制定出整潔有序的模度規(guī)范。這樣就可以讓一線的設(shè)計師們跳過部分繁瑣磨人的細節(jié)思考，快速搭建出合適的表單寬度并合理有效。
本篇文章更多是從表單設(shè)計中的一些冷門內(nèi)容，即易忽略的一些設(shè)計點在展開討論，利用問題加案例的形式對表單設(shè)計進行剝離拆解，沒有系統(tǒng)地、成本成套的來分析表單的構(gòu)成和交互細節(jié)等等。因為這類內(nèi)容講的人太多了，我也認為講的要比我精彩。
所以，我把講的內(nèi)容稱為“私房菜”，更多是我總結(jié)了日常工作中會遇到的表單設(shè)計疑問和思考，幫助大家換一個口味來品味表單設(shè)計，大家可結(jié)合文章中給出的建議作為參考去靈活應(yīng)用。
同時，我也希望能夠通過這篇文章給到大家更多的啟發(fā)。內(nèi)容如果有不嚴謹、錯誤的地方還望大家給與指正。
作者：百度MEUX，百度移動生態(tài)用戶體驗設(shè)計中心，負責百度移動生態(tài)體系的用戶/商業(yè)產(chǎn)品的全鏈路體驗設(shè)計
本文由 @百度MEUX 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載
題圖來自Unsplash，基于CC0協(xié)議
*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
