有理有據(jù)，有面有料，是一個(gè)設(shè)計(jì)作品的專業(yè)體現(xiàn)。之前花了四篇小文（鏈接在文末），講述如何提升設(shè)計(jì)師設(shè)計(jì)作品的內(nèi)在含金量和外在形式感，今天，我們將用最后的篇幅，聊聊如何給設(shè)計(jì)作品創(chuàng)造一個(gè)盡可能完美的終局——交互文檔的細(xì)節(jié)。
千里之堤毀于蟻穴，再專業(yè)的交互設(shè)計(jì)，如果在后期交付時(shí)頻繁出現(xiàn)細(xì)節(jié)的缺失和補(bǔ)充，其實(shí)還是很容易遭受研發(fā)和測(cè)試同學(xué)diss的。甚至有可能因?yàn)橐粋€(gè)細(xì)節(jié)的疏忽，導(dǎo)致整體交互方案的崩盤，不得不從頭再來。
如果研發(fā)過程中發(fā)生這樣的設(shè)計(jì)事故，其實(shí)是非常影響團(tuán)隊(duì)士氣和個(gè)人專業(yè)影響力的。
設(shè)計(jì)細(xì)節(jié)篇，分兩個(gè)維度來闡述，一個(gè)是文檔外,一個(gè)是文檔內(nèi)。
文檔外，其實(shí)是要回歸設(shè)計(jì)的初衷，很多設(shè)計(jì)師包括我自己，設(shè)計(jì)久了，總愿意把自己當(dāng)作是用戶的代言人，盡可能的為用戶體驗(yàn)著想，絞盡腦汁的尋求最佳體驗(yàn)的設(shè)計(jì)，并以此為傲。
這如果是在產(chǎn)品發(fā)展的成熟期，功能相對(duì)穩(wěn)定，體驗(yàn)同質(zhì)化嚴(yán)重，這個(gè)時(shí)候追求的體驗(yàn)，尋求體驗(yàn)的突破是非常有意義的，可以讓產(chǎn)品獲得更多的口碑，從而帶來更多的用戶和收益。
但是如果是在探索期和成長(zhǎng)期，過度的追求單一維度的體驗(yàn)，可能反而會(huì)成為一種產(chǎn)品發(fā)展的桎梏，阻礙產(chǎn)品的成長(zhǎng)，而在衰退期追求的體驗(yàn)，則完全背離了公司作為商業(yè)組織的利益點(diǎn)，會(huì)顯得和整個(gè)項(xiàng)目組格格不入。
產(chǎn)品生命周期與用戶體驗(yàn)要求
所以對(duì)于探索期和衰退期的產(chǎn)品來說，設(shè)計(jì)師要盡可能考慮商業(yè)性和技術(shù)可行性。用最小的設(shè)計(jì)代價(jià)，快速的迭代，完成產(chǎn)品的目標(biāo)（驗(yàn)證價(jià)值或解決問題）。
如果設(shè)計(jì)師在這兩個(gè)階段太揪細(xì)節(jié)，可能會(huì)因?yàn)榈貌坏巾?xiàng)目的支持而心灰意冷。
技術(shù)可行性和商業(yè)收益，不是我們所擅長(zhǎng)的領(lǐng)域，通過前面的設(shè)計(jì)法則和用戶埋點(diǎn)也不能準(zhǔn)確推算，所以還需及時(shí)向技術(shù)及商務(wù)同學(xué)確認(rèn)，別人家能做的產(chǎn)品形態(tài)，咱們家技術(shù)框架不一定支持。別人家能做的精簡(jiǎn)，可能會(huì)損害咱們家的主營(yíng)業(yè)務(wù)。
涉及到這兩點(diǎn)，除非有自上而下的旨意，否則單憑設(shè)計(jì)之力無異于蚍蜉撼樹，很容易讓自己費(fèi)力不討好。
文檔內(nèi)的交互細(xì)節(jié)，主要在于文檔的完整性和閱讀體驗(yàn)，既要面面俱到，又要清晰簡(jiǎn)潔。
面面俱到是指要盡量包含所有流程、頁面及狀態(tài)，避免遺漏。它體現(xiàn)了一個(gè)交互設(shè)計(jì)師設(shè)計(jì)思維的嚴(yán)謹(jǐn)性和設(shè)計(jì)態(tài)度。
網(wǎng)上有很多關(guān)于交互走查表的模板，非常的全面，但就是因?yàn)樘^全面，反而讓很多新人設(shè)計(jì)師望而生畏，避而遠(yuǎn)之，這就失去了交互走查表本身的意義。
我認(rèn)為，交互走查表其實(shí)就是提供給設(shè)計(jì)師的一份幫助文檔，大家都知道在設(shè)計(jì)的時(shí)候，提示要盡可能的簡(jiǎn)短，要適時(shí)出現(xiàn)，要清晰簡(jiǎn)潔，遺憾的是我看到的交互走查表往往都不滿足這一條。
冗長(zhǎng)的交互走查表，就像是冗長(zhǎng)的幫助文檔一樣，把責(zé)任都推給了設(shè)計(jì)師，仿佛在說：誰讓你不按照我逐條檢查呢？
如果出現(xiàn)細(xì)節(jié)的遺漏，就變成了設(shè)計(jì)師自己的錯(cuò)。
誰都不想遺漏，但是后期設(shè)計(jì)時(shí)間往往真的就很緊迫，設(shè)計(jì)師除了細(xì)節(jié)的補(bǔ)充，可能還有其他很多任務(wù)需要做，大家只是想確認(rèn)一下而已，哪有時(shí)間和精力去看那么冗長(zhǎng)的“幫助文檔”。
所以發(fā)揮一下設(shè)計(jì)師的同理心，根據(jù)二八原則，80%設(shè)計(jì)師可能遺漏的問題都只是認(rèn)知走查表里20%的內(nèi)容，這20%的內(nèi)容也真正意義上影響我們80%的用戶和體驗(yàn)，是設(shè)計(jì)者最為關(guān)心的。
那么，我們是不是先把這20%的設(shè)計(jì)解決好呢？這才是真正急設(shè)計(jì)師之所急，站在設(shè)計(jì)師的角度考慮問題。
所以本文精心篩選出最容易被大家所忽略，且大多數(shù)設(shè)計(jì)又必須要考慮的異常分支，為大家整理了一份《設(shè)計(jì)細(xì)節(jié)check表》，以確保主體流程的主要設(shè)計(jì)“面面俱到”。（流程設(shè)計(jì)、布局設(shè)計(jì)，以及互動(dòng)設(shè)計(jì)，如果大家在前期有遵守對(duì)應(yīng)的設(shè)計(jì)原則，再加上數(shù)據(jù)的支持，應(yīng)該大方向都是正確的。我也希望大家盡量通過前期的理論和數(shù)據(jù)，去保證流程和整體設(shè)計(jì)的正確性，而不是要等到最后細(xì)節(jié)確認(rèn)的時(shí)候，才來審視檢驗(yàn)整體，讓細(xì)節(jié)篇，真的是在完善細(xì)節(jié)。）
設(shè)計(jì)細(xì)節(jié)Check表
我把這份《設(shè)計(jì)細(xì)節(jié)check表》按照從整體到局部進(jìn)行了歸類：
最大的單元是指每個(gè)任務(wù)流程的檢查，然后是頁面單元，因?yàn)轫撁嫔婕暗郊虞d的異常分支比較多，所以單獨(dú)拆出來和頁面狀態(tài)并列分別闡述。最后是組塊單元，主要包括輸入類和非輸入類的組件操作及反饋。
下面我們逐一來看：
流程檢查主要包括三點(diǎn)：
秉承一致性原則，同一個(gè)產(chǎn)品，能保持一致的地方，要盡可能保持一致。
在實(shí)際項(xiàng)目中，同一個(gè)產(chǎn)品，往往有多個(gè)設(shè)計(jì)師，每個(gè)設(shè)計(jì)師都負(fù)責(zé)相對(duì)獨(dú)立的一大模塊，偶爾就會(huì)涉及到相似功能的設(shè)計(jì)，因?yàn)槭遣煌嗽谶M(jìn)行，所以設(shè)計(jì)出來的形態(tài)就可能不一致；
但對(duì)于用戶來說，使用相似功能的人，往往可能是同一撥人，設(shè)計(jì)的不一致，體驗(yàn)就會(huì)有差異，不僅對(duì)于用戶來說學(xué)習(xí)成本高，而且對(duì)于項(xiàng)目組來說同時(shí)維系兩套不同的設(shè)計(jì)，成本也比較高。
如果一個(gè)流程的正向流程和逆向流程是完全一致的，一般無需特別說明，但是如果返回時(shí)需要跳過某些頁面或者狀態(tài)快速返回，則需要進(jìn)行特殊標(biāo)注，否則可能會(huì)被研發(fā)同學(xué)遺漏。
當(dāng)遇到特殊情況，程序崩潰，后臺(tái)殺死，斷電等，進(jìn)度是否能夠能自動(dòng)保存并恢復(fù)，如果需要，就需要考慮恢復(fù)的時(shí)機(jī)和形式。
說完流程，再來說單獨(dú)的頁面。談到頁面時(shí)，首先要談的是加載狀態(tài)，畢竟頁面不是憑空就有的。
加載狀態(tài)主要要考慮以下幾點(diǎn)：
預(yù)加載的時(shí)機(jī)是什么時(shí)候，預(yù)加載的內(nèi)容有多少？（對(duì)于用戶會(huì)長(zhǎng)時(shí)瀏覽的內(nèi)容，一般建議預(yù)加載，預(yù)加載的內(nèi)容一般會(huì)結(jié)合內(nèi)容大小、瀏覽時(shí)長(zhǎng)、甚至網(wǎng)絡(luò)狀態(tài)綜合決定）
在信息未加載出來前，界面是顯示空白引導(dǎo)，還是默認(rèn)占位符，還是顯示上一次的緩存內(nèi)容？（一般有緩存優(yōu)先顯示緩存，無緩存先顯示默認(rèn)占位符，等內(nèi)容加載完成后再進(jìn)行替換）
是否顯示加載圖標(biāo)，進(jìn)度條，是否可以取消加載？（一般情況下等待超過0.1s，就能夠被用戶感知到，就建議顯示加載圖標(biāo)，以便用戶知道程序已經(jīng)接收到并在響應(yīng)用戶的操作指令。如果等待超過1秒，就建議顯示進(jìn)度條，并提供取消操作，便于用戶自主控制）
是全部加載，還是分布加載顯示？（一般情況下，在2~3屏內(nèi)的有限內(nèi)容，或者完全非同類的內(nèi)容，是可以一次性全部加載的，因?yàn)橛脩艨赡芫褪菦_著某一類內(nèi)容進(jìn)來的，很可能會(huì)快速滑動(dòng)到目標(biāo)內(nèi)容。
而對(duì)于同類型的圖文信息，而且是內(nèi)容比較多時(shí)，一般都會(huì)采取分布加載的形式，避免浪費(fèi)多數(shù)用戶的流量。
視頻播放機(jī)制、廣告圖片加載等，一般還要考慮網(wǎng)絡(luò)情況，一般WIFI情況下，因?yàn)閷?duì)流量及網(wǎng)速的要求低，所以采用自動(dòng)播放視頻，自動(dòng)顯示圖片、播放廣告等，更容易被用戶所接收）
是否自動(dòng)重試加載，何時(shí)進(jìn)行超時(shí)提示等。（很多產(chǎn)品在設(shè)計(jì)時(shí)，如果不是完全無網(wǎng)絡(luò)，僅僅是網(wǎng)絡(luò)信息不穩(wěn)定，會(huì)嘗試自動(dòng)加載，以避免用戶手動(dòng)操作。如果自動(dòng)加載超過上限，才會(huì)提示讓用戶稍后再試）
頁面加載出來后，就要要考頁面本身的狀態(tài)了。
需要考慮的異常頁面狀態(tài)主要有以下幾種：
考慮完整體頁面后，最后再來考慮一下頁面內(nèi)的組件狀態(tài)。先來看一下輸入類。
輸入框/文本框要考慮的主要有三點(diǎn)：
最后看一下非輸入類的操作組件。
“文本/圖標(biāo)按鈕、鏈接、可操作的卡片/列表”要考慮一下幾點(diǎn)：
如果設(shè)計(jì)完成后，初步檢查以上五項(xiàng)內(nèi)容，基本上可以確定主題流程的主要設(shè)計(jì)內(nèi)容已經(jīng)面面俱到了。
文章來源：人人都是產(chǎn)品經(jīng)理
HMI是什么？這又和我有什么關(guān)系，如果你想置身于智能時(shí)代，HMI的認(rèn)知是一個(gè)不可錯(cuò)過，而海哥把這一生的精力投身于該領(lǐng)域，下面我們開始開啟這條認(rèn)知之路。我將分三個(gè)部分闡述HMI，分別是：HMI是什么？HMI有什么用？誰在做HMI？
HMI，是英文Human Machine Interface的首字母縮寫，中文意思為“人機(jī)界面”，或“人機(jī)接口”，在國(guó)內(nèi)用“人機(jī)界面”多，HMI是“人與機(jī)器之間傳遞和交換信息的媒介和對(duì)話接口”，可以簡(jiǎn)單理解為是一臺(tái)微型的電腦，外形像平板電腦，比如蘋果的iPad，但是她有很多插口，像傳統(tǒng)辦公桌上的臺(tái)式電腦（后面稱PC電腦），有usb接口、網(wǎng)線接口、串行接口。通常HMI像個(gè)積木一樣，嵌入到機(jī)器上的，一般是自動(dòng)化大機(jī)器，通過HMI來控制和監(jiān)視機(jī)器的運(yùn)作，你可以理解為HMI是一臺(tái)電腦，她控制打印機(jī)打印東西這樣的關(guān)系。海哥帶你看看HMI廬山真貌：
看起來是不是一個(gè)平板電腦嗎？對(duì)的，外形看起來像平板，但是它比較厚，而且很多電腦用的接口，而大家在生活中接觸最多的兩種HMI有兩種，一種是取款機(jī)，另外一種就是汽車中控。
下面，海哥帶你了解HMI組成，它是由兩大部分組成的，就是硬件和軟件。
HMI硬件方面，像PC電腦一樣，有五大模塊：處理器（如CPU）、顯示單元（如顯示器）、輸入單元（如鼠標(biāo)、鍵盤）、通訊接口（如網(wǎng)卡）、數(shù)據(jù)存儲(chǔ)單元（如硬盤），那一個(gè)優(yōu)質(zhì)的HMI硬件主要看哪方面呢？就是處理器，處理器有8位、16位、32位，數(shù)字越高，處理能力越強(qiáng)。接下來看看硬件周邊的接口，HMI可以連接很多種設(shè)備，比如可編程控制器（簡(jiǎn)稱PLC）、變頻器、直流調(diào)速器、儀表和工業(yè)設(shè)備等，它們連接到HMI的串口接口，串口的類型有RS232、RS485等。
好了，上面大概對(duì)HMI的硬件有初步了解，下面海哥帶你看看軟件部分，軟件部分包括兩部分，就是系統(tǒng)和畫面組態(tài)軟件。系統(tǒng)就像PC電腦的windows系統(tǒng)一樣，有自身硬件運(yùn)作正常的系統(tǒng)，比如我們?nèi)A為的鴻蒙OS系統(tǒng)。接著就是畫面組態(tài)軟件，其實(shí)就是像windows里面的Word軟件，叫法上不一樣而已，常規(guī)情況下畫面組態(tài)軟件只有一個(gè)，不能像windows那樣裝很多種類型軟件，而HMI固定是裝一種，我們常規(guī)叫他為“工程”，當(dāng)然汽車上的HMI，就像平板電腦上，功能和軟件都很豐富，因?yàn)樗菨M足消費(fèi)者人群的，而只運(yùn)行一個(gè)軟件的，多用在工業(yè)機(jī)器上，可以減少HMI資源消耗，還能保證整個(gè)HMI的穩(wěn)定性。
海哥剛開始對(duì)組態(tài)軟件不太懂，組態(tài)到底是什么？“組態(tài)”（Configure）是“配置”、“設(shè)定”等意思，它讓用戶像搭積木一樣，把所需要的軟件功能搭建起來，不需要編寫計(jì)算機(jī)程序。目前常用的組態(tài)軟件有：iFix、Vijeo Designer、WinCC、組態(tài)王、MCGS，不同廠家的HMI硬件使用不同的組態(tài)軟件，所以他們連接要有不同的驅(qū)動(dòng)程序，這對(duì)技術(shù)人員來說，學(xué)習(xí)成本還是比較高，因?yàn)槟壳斑€沒有一個(gè)巨頭來定義這個(gè)通用標(biāo)準(zhǔn)，而最近華為的鴻蒙OS系統(tǒng)，開始定義行業(yè)的平臺(tái)標(biāo)準(zhǔn)，海哥個(gè)人覺得這是一件了不起的事情。下面看看常用的組態(tài)軟件長(zhǎng)什么樣子，我們用WinCC作為例子。
接下來，海哥告訴你HMI的分類，大概可以分三種：
（1、薄膜鍵輸入的HMI，顯示尺寸小于5.7ˊ，畫面組態(tài)軟件免費(fèi)，屬初級(jí)產(chǎn)品。
（2、觸摸屏輸入的HMI，顯示屏尺寸為5.7ˊ～12.1ˊ，畫面組態(tài)軟件免費(fèi)，屬中級(jí)產(chǎn)品。
（3、基于平板PC計(jì)算機(jī)的、多種通訊口的、高性能HMI，顯示尺寸大于10.4ˊ，畫面組態(tài)軟件收費(fèi)，屬高端產(chǎn)品。
對(duì)于高端HMI產(chǎn)品，面對(duì)5G的個(gè)性化定制的市場(chǎng)特征，HMI的“配方功能”會(huì)很重要，所謂配方功能，就是一臺(tái)設(shè)備完成不同種類工件的加工，這需要人機(jī)界面上具備配方功能，在加工A產(chǎn)品時(shí)，執(zhí)行A配方，加工B產(chǎn)品時(shí)，執(zhí)行B配方，比如西門子公司的MP系列，而如果要實(shí)現(xiàn)千人千面的生產(chǎn)需求，也許配方更是一個(gè)海量級(jí)的，這也是自動(dòng)化所面臨的機(jī)遇與挑戰(zhàn)。
下面說說工作流程，一個(gè)HMI制作應(yīng)用的制作過程大概是這樣的流程：
海哥簡(jiǎn)短解釋一下這些流程，在日后海哥會(huì)在每個(gè)模塊都會(huì)有細(xì)節(jié)教程。
市場(chǎng)調(diào)研：了解到市面上的數(shù)據(jù)量，比如手機(jī)用戶數(shù)量，大部分用戶使用時(shí)長(zhǎng)，競(jìng)爭(zhēng)對(duì)手處于什么樣的狀態(tài)等；
用戶畫像：了解用戶的年齡、地區(qū)、行為習(xí)慣、心理習(xí)慣等，并賦予到一個(gè)場(chǎng)景中，了解用戶在場(chǎng)景中的整個(gè)活動(dòng)和心理的過程；
需求定位：了解到目標(biāo)用戶的特征后，定制產(chǎn)品或的重點(diǎn)價(jià)值，用戶為什么需要你，你有什么不一樣；
頭腦風(fēng)暴：由不同崗位人員，一起想點(diǎn)子，先暢所欲言，再根據(jù)調(diào)研和需求來判斷合適的點(diǎn)子；
原型設(shè)計(jì)：原型簡(jiǎn)單理解為手工紙質(zhì)品，或模型，可以用塑料泡沫或電腦的Axure等軟件，做出實(shí)體或虛擬的產(chǎn)品，這需要快速簡(jiǎn)單進(jìn)行；
可用性測(cè)試：測(cè)試原型是否可行，讓一些陌生人用用，看他們能理解這是什么，會(huì)不會(huì)用等；
高保真設(shè)計(jì)：就是把“毛坯房”變成精裝修，開始做最終的視覺效果；
開發(fā)制造：開發(fā)與機(jī)器制造，實(shí)現(xiàn)功能；
測(cè)試修復(fù)：用一種極端條件來檢查產(chǎn)品有沒有問題，比如24小時(shí)運(yùn)作會(huì)不會(huì)有問題，突然斷電有沒有問題；
版本迭代：第一代產(chǎn)品做出來不等于成功了，因?yàn)槭袌?chǎng)在變，用戶也在變，需要保持變化，優(yōu)化產(chǎn)品。
下面是一些問題，可以幫助大家更好了解HMI：
問：HMI看起來不就是一個(gè)很厚的觸摸屏嗎？
答：HMI是由兩部分組成，分別是硬件和軟件，而像手機(jī)或平板的那種觸摸屏，只是一個(gè)觸摸的硬件，這種只是讓你能觸摸的部件而已，可以理解為臺(tái)式電腦上的顯示器，只是這個(gè)顯示器可以觸摸。
問：PC電腦能當(dāng)HMI設(shè)備用嗎？
答：當(dāng)然可以，只是PC電腦不在會(huì)嵌入到機(jī)器上，而是通過很長(zhǎng)的線或者無線網(wǎng)絡(luò)連接到機(jī)器，而PC電腦需要通過HMI的軟件，來操控機(jī)器。
問：SCADA與HMI的區(qū)別？
答：SCADA是監(jiān)控和數(shù)據(jù)采集系統(tǒng)，英文是Supervisory Control And Data Acquisition，它包含HMI，SCADA是整局的工業(yè)控制系統(tǒng)，范圍更大。
HMI有什么用？海哥認(rèn)為，有機(jī)器的地方就有HMI存在的可能性，特別是5G物聯(lián)網(wǎng)的“萬物互聯(lián)”的到來，數(shù)據(jù)不只是在電腦上流動(dòng)，還會(huì)在機(jī)器、衣服、鞋子、碗、車等場(chǎng)景中串聯(lián)，而把目光放在當(dāng)下，HMI應(yīng)用領(lǐng)域已經(jīng)在機(jī)器、工廠、建筑物、汽車、高度監(jiān)管的制藥和食品行業(yè)、石油/天然氣、采礦等領(lǐng)域已經(jīng)有運(yùn)作，從這些行業(yè)屬性來說，你有沒發(fā)現(xiàn)從事HMI的行業(yè)的人，它的市場(chǎng)體量有足夠大的想象空間？哈哈，別拉后腿了，與海哥一起跟上。
目前的HMI可以做些什么呢？
（1、實(shí)時(shí)的信息狀態(tài)與趨勢(shì)顯示；
（2、圖形化、流程化控制生產(chǎn)線監(jiān)控和控制；
（3、警報(bào)的產(chǎn)生和記錄；
（4、歷史信息的自動(dòng)記錄、報(bào)表自動(dòng)生成；
HMI的意義有哪些呢？
（1、發(fā)揮機(jī)器應(yīng)有的功能，因?yàn)槟憧梢酝ㄟ^數(shù)據(jù)顯示上了解到；
（2、人工合理調(diào)節(jié)機(jī)器參數(shù)，讓機(jī)器間的協(xié)作、使用效率提高；
（3、HMI預(yù)警能確保安全與經(jīng)濟(jì)提升；
（4、讓使用者操作機(jī)器和系統(tǒng)更友善，符合他們的生理、心理的需求，提高使用者的滿意度；
想在這個(gè)行業(yè)有所作為，我們?cè)趺茨懿恢佬袠I(yè)的頂尖高手在哪呢？有了標(biāo)桿，起碼可以衡量我們自身的水準(zhǔn)，還有我們?nèi)笔裁?，從另外一個(gè)角度來說，你如何作戰(zhàn)略選擇，讓自己也能從差異化中，變成另外一個(gè)頂尖高手，下面我們看看專注于HMI的企業(yè)，海哥找來自動(dòng)化制造類的和汽車類的，行業(yè)很深很大，日后海哥繼續(xù)挖掘新的。
下面是自動(dòng)化領(lǐng)域HMI企業(yè)。
三菱
網(wǎng)址：www.mitsubishielectric.com
三菱奉行的企業(yè)經(jīng)營(yíng)理念“Changes for the Better”，“One三菱電機(jī)”為中國(guó)“更好的未來”和實(shí)現(xiàn)“更好的社會(huì)”做貢獻(xiàn)為經(jīng)營(yíng)理念。e-F@ctory靈活運(yùn)用IT技術(shù)，將生產(chǎn)現(xiàn)場(chǎng)與上層信息系統(tǒng)直接相連。即可實(shí)現(xiàn)工廠的“可視化”，同時(shí)又能促進(jìn)生產(chǎn)設(shè)備的高性能化和最優(yōu)化，縮短開發(fā)及調(diào)試周期，降低運(yùn)用及維護(hù)成本，從而削減生產(chǎn)工序的整體成本，實(shí)現(xiàn)“工廠全面最優(yōu)化”
西門子
網(wǎng)址：www.industry.siemens.com.cn
面對(duì)日益復(fù)雜的機(jī)器和系統(tǒng)過程，作為一站式供應(yīng)商，西門子專門設(shè)計(jì)開發(fā)出了 SIMATIC HMI 人機(jī)界面技術(shù)。SIMATIC HMI 采用開放式、標(biāo)準(zhǔn)化硬件和軟件接口，可快速集成到用戶的自動(dòng)化系統(tǒng)中，從而滿足用戶的特定人機(jī)界面需求。
施耐德
網(wǎng)址：www.schneider-electric.cn
施耐德電氣是家居、樓宇、數(shù)據(jù)中心、基礎(chǔ)設(shè)施和工業(yè)領(lǐng)域能源管理與自動(dòng)化技術(shù)數(shù)字化轉(zhuǎn)型的領(lǐng)先企業(yè)?！拔覀兊目萍?，無處不在”，施耐德電氣確保每一個(gè)人，在任何時(shí)間，在任何地方都能盡享能效之利。
歐姆龍
網(wǎng)址：www.omron.com.cn
創(chuàng)立于1933年的歐姆龍集團(tuán)是全球知名的自動(dòng)化控制及電子設(shè)備制造廠商，掌握著世界領(lǐng)先的傳感與控制核心技術(shù)。通過不斷創(chuàng)造新的社會(huì)需求，歐姆龍集團(tuán)已在全球擁有超過35,000名員工，營(yíng)業(yè)額達(dá)8,595億日元。產(chǎn)品涉及工業(yè)自動(dòng)化控制系統(tǒng)、電子元器件、汽車電子、社會(huì)系統(tǒng)、健康醫(yī)療設(shè)備等廣泛領(lǐng)域，品種多達(dá)數(shù)十萬種。
BEIJER 北爾
網(wǎng)址：www.beijerelectronics.cn
北爾電子成立于1981年，總部在瑞典南部的Malm?。北爾電子是上市公司北爾集團(tuán)三大事業(yè)部之一。北爾集團(tuán)的客戶包括 阿法拉法(Alfa Laval)、龐巴迪(Bombardier)、阿爾斯通(Alstom)和艾默生(Emerson)等要求苛刻的大型跨國(guó)企業(yè)。2018年北爾電子集團(tuán)銷售額達(dá)到14億瑞典克朗。
臺(tái)達(dá)
網(wǎng)址：www.deltaww.com
臺(tái)達(dá)成立于1971年，總部在臺(tái)灣，為全球提供電源管理及散熱解決方案，秉承“Smarter. Greener. Together.”的品牌理念，自動(dòng)化模塊中，專注于交流馬達(dá)驅(qū)動(dòng)器、電源治理、感測(cè)、控制與運(yùn)動(dòng)等產(chǎn)品領(lǐng)域的創(chuàng)新研發(fā)，同時(shí)整合工業(yè)自動(dòng)化產(chǎn)品，繼而開發(fā)工業(yè)控制網(wǎng)絡(luò)，為全球客戶提供全方位的解決方案服務(wù)。
汽車中控領(lǐng)域HMI服務(wù)企業(yè)中，海哥找了三家，他們分別是：HARMAN、INTELLIAS、ELEKTROBIT。
HARMAN
網(wǎng)址：www.harman.com
1980年成立，總部在美國(guó)，它是三星的子公司，公司員工規(guī)模過萬，開發(fā)聯(lián)網(wǎng)汽車系統(tǒng)，音頻和視頻產(chǎn)品，企業(yè)自動(dòng)化和互聯(lián)服務(wù)。北美，歐洲和亞洲汽車制造商是哈曼的客戶。該公司還是HMI軟件開發(fā)服務(wù)的先驅(qū)提供商。
INTELLIAS
網(wǎng)址：www.intellias.com
Intellias是一家定制軟件工程公司，專注于汽車、基于位置的服務(wù)和金融技術(shù)行業(yè)。公司員工規(guī)模上千人。Intellias被Inc. 5000公認(rèn)為歐洲最有前途，發(fā)展最快的私營(yíng)公司之一。該軟件開發(fā)公司也被列入全球外包100。
ELEKTROBIT
網(wǎng)址：www.elektrobit.com
作為汽車軟件行業(yè)的領(lǐng)導(dǎo)者，憑借 30 多年為本行業(yè)服務(wù)的經(jīng)驗(yàn)，EB 的軟件為 1 億多輛汽車中的逾 10 億臺(tái)設(shè)備提供支持，并提供針對(duì)互聯(lián)汽車基礎(chǔ)設(shè)施、人機(jī)界面 (HMI) 技術(shù)、導(dǎo)航、輔助駕駛、電子控制單元 (ECU) 和軟件工程服務(wù)的靈活、創(chuàng)新的解決方案。
總結(jié)一下，今天的《海哥HMI人機(jī)交互》，海哥帶你了解了HMI是什么，可以簡(jiǎn)單理解HMI就是一個(gè)平板PC，既包含了硬件，又包括了軟件系統(tǒng)，硬件方面核心是看處理器，而軟件方面需要用組態(tài)軟件來開發(fā)，針對(duì)項(xiàng)目來做定制開發(fā)，開發(fā)出來的工程文件，通過串口下載到HMI的處理器上，這樣HMI就可以管控自動(dòng)化生產(chǎn)的設(shè)備，HMI是SCADA總要組成部分。
文章來源：站酷
Struts2中轉(zhuǎn)發(fā)和重定向的區(qū)別以及實(shí)現(xiàn)方法
最近遇到一個(gè)問題，就是在設(shè)置struts2的攔截器以后，想要訪問必須登錄，想要的效果是轉(zhuǎn)到登錄頁面，也就是轉(zhuǎn)到xxx.jsp，但是發(fā)現(xiàn)沒有轉(zhuǎn)到，而是action結(jié)尾的，后來發(fā)現(xiàn)是因?yàn)樵趕truts.xml里面配置的時(shí)候，沒有在result中配置type屬性，struts默認(rèn)的是重定向，就是網(wǎng)址不變，解決辦法就是在result中加type=”redirect”,就可以了
轉(zhuǎn)發(fā)和重定向的區(qū)別：
重定向是不共享request的東西，重定向后的頁面中無法接收request里的東西，另外dispatcher結(jié)果類型的default屬性為TRUE，故<result- type/>缺省為dispatcher 所以如果沒有設(shè)置type屬性的話，那么默認(rèn)的是請(qǐng)求轉(zhuǎn)發(fā)，就是說你要是什么都不寫的話，默認(rèn)就是這樣的
1
<result name="list" type="dispatcher">/admin/jsp/userAction/list.jsp</result>
1
重定向的兩個(gè)屬性：
redirect是在處理完當(dāng)前Action之后，重定向到另外一個(gè)實(shí)際的物理資源，以.jsp結(jié)尾這樣的
redirectAction也是重定向，但它重定向到的是另外一個(gè)Action，就是以action結(jié)尾這樣的
只要是重定向，那么之前凡是保存在request里面的東西就全都消失了
因?yàn)橹囟ㄏ驅(qū)嶋H是發(fā)送第二個(gè)請(qǐng)求，故請(qǐng)求中的東西也就不會(huì)出現(xiàn)在第二個(gè)請(qǐng)求里面了
也就是說重定向是不共享request的東西，重定向后的頁面中無法接收request里的東西，
藍(lán)藍(lán)設(shè)計(jì)( m.yvirxh.cn )是一家專注而深入的界面設(shè)計(jì)公司，為期望卓越的國(guó)內(nèi)外企業(yè)提供卓越的UI界面設(shè)計(jì)、BS界面設(shè)計(jì) 、 cs界面設(shè)計(jì) 、 ipad界面設(shè)計(jì) 、 包裝設(shè)計(jì) 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計(jì)、 網(wǎng)站建設(shè) 、平面設(shè)計(jì)服務(wù)。
Sketch 58 Beta 版本已于近期推出（其實(shí)最近一段時(shí)間已更新了好幾個(gè)測(cè)試版），官方終于推出 Smart Layout 智能布局，讓 Symbol 組件獲得響應(yīng)功能，變得更加靈活和強(qiáng)大。
之前我們只能使用第三方插件來制作響應(yīng)式組件，比如之前介紹的 Kitchen 和 Anima。不過畢竟不是官方親生的，難免會(huì)包含一些 bug 和不足。
比如 Kitchen 插件在制作 Symbol 組件的時(shí)候，其自動(dòng)排版功能會(huì)出錯(cuò)。Anima 插件對(duì)上傳到藍(lán)湖的標(biāo)注會(huì)有顯示問題。關(guān)鍵是在團(tuán)隊(duì)協(xié)作的時(shí)候，其他使用源文件的同學(xué)也必須安裝對(duì)應(yīng)的插件，否則沒有效果。
那么這次 Sketch 58 Beta 版本新推出的 Smart Layout 智能布局功能，能否解決長(zhǎng)期困擾設(shè)計(jì)師的響應(yīng)布局問題呢？一起來看下。
如果想體驗(yàn) Sketch Beta 版本，請(qǐng)進(jìn)入 Sketch 測(cè)試版主頁下載→https://www.sketch.com/beta/。但是要記住，一定不要用在自己的正式文件中，防止修改后，低版本打不開。
Sketch 58 要求 Mac 系統(tǒng)版本是 macOS High Sierra 10.13.4 及以上，下面是 Sketch 各大版本對(duì)應(yīng)的 Mac 系統(tǒng)版本，如果遇到新版的 Sketch 打不開就需要檢查下自己的系統(tǒng)版本。
本次 Sketch 58 Beta 最大的更新就是 Smart Layout。
在新建 Symbol 組件時(shí)，彈窗新增 Layout 選項(xiàng)，總共有 7 個(gè)屬性，分別對(duì)應(yīng)不同的圖標(biāo)，下面是每個(gè)屬性的簡(jiǎn)單介紹。
1. No Layout
正常布局，也就是和原先一樣，沒有特殊效果。
2. Left to Right Layout
賦予 Symbol 組件智能布局效果，組件尺寸會(huì)根據(jù)內(nèi)容變化，方向是水平從左往右布局。
3. Horizontally Center Layout
同上，方向是中間往左右兩端布局。
4. Right to Left Layout
同上，方向是從右往左布局。
5. Top to Bottom Layout
賦予 Symbol 組件智能布局效果，組件尺寸會(huì)根據(jù)內(nèi)容變化，方向是垂直從上往下布局。
6. Vertically Center Layout
同上，方向是中間往上下兩端布局。
7. Bottom to Top Layout
同上，方向是從下往上布局。
另外在選擇好 Layout 屬性后，Symbol 頁面的畫板組件圖標(biāo)會(huì)發(fā)生變化，除了 No Layout 布局還是之前的畫板圖標(biāo)之外，其余 6 個(gè)都有對(duì)應(yīng)的新圖標(biāo)，看下圖。
此外，選擇畫板后，右側(cè)的屬性面板中會(huì)新增布局選擇功能，包含上面講的7種屬性，可隨時(shí)對(duì) Layout 布局進(jìn)行更改。
看上面的描述還是比較迷惑，實(shí)際上智能布局簡(jiǎn)單來說，就是賦予 Symbol 組件內(nèi)容邊距的功能，尺寸隨內(nèi)容變化而變化，有點(diǎn)類似于前端 CSS 中的 padding 屬性。下面用實(shí)際例子展示。
以前我們使用過 Kitchen 和 Anima 制作過彈性按鈕。需求是，文字兩端的邊距（即CSS中的padding）保持固定，文字?jǐn)?shù)量不固定，按鈕寬度隨文字內(nèi)容走。
那么在 Sketch 58 中，我們先制作一個(gè)按鈕，文字兩端的邊距是 20。
轉(zhuǎn)化為 Symbol，出現(xiàn)彈窗，在新增的 Layout 下拉中，選擇 Left to Right Layout，這樣文字變化時(shí)，左邊是固定不動(dòng)的，內(nèi)容往右邊延展。
這樣一個(gè)彈性按鈕就做好了，不管文字有多少，兩端邊距永遠(yuǎn)保持固定 20。和前端 CSS 中的 padding-left 和 padding-right 功能一樣。
如果這個(gè)時(shí)候我們?cè)倮?Symbol，右側(cè) Overrides 會(huì)出現(xiàn)一個(gè)新的圖標(biāo)：縮小實(shí)例以適配內(nèi)容。點(diǎn)擊后，被拉伸的組件會(huì)還原為文字內(nèi)容長(zhǎng)度。
注意，這個(gè)和原先的重設(shè)覆蓋層圖標(biāo)不同，不會(huì)清除覆蓋的文本內(nèi)容，只會(huì)還原為適合內(nèi)容大小。
以上是從左往右的布局，水平兩端和從右往左也是一樣的道理，只是方向不一樣，下圖是從右往左的布局。
這就是智能布局的主要功能，賦予 Symbol 組件 CSS 代碼 padding 屬性，具備響應(yīng)特征。還需要注意的是，智能布局目前只針對(duì) Symbol 組件，Kitchen 插件是可以作用于普通組的。
上面是單個(gè)組件的智能布局，如果是嵌套組件呢？也是可以的，一起試下。
我們把剛才做的按鈕橫向分布三個(gè)，再一起做成新的按鈕組 Symbol 組件，結(jié)構(gòu)看下圖。
新的按鈕組內(nèi)，每個(gè)按鈕已經(jīng)是響應(yīng)式的，那么做成組后就會(huì)保持組內(nèi)元素的間距固定，更改下文字內(nèi)容看下圖。
非常棒，已經(jīng)滿足了我們剛開始的需求。但是不建議嵌套過多，要保持組件化設(shè)計(jì)思維。當(dāng)然了，間距問題，Sketch 57 已經(jīng)提供了多元素間距調(diào)整功能，只多了一步，但是不用把整體再次轉(zhuǎn)化 Symbol，大家可以根據(jù)自己的需要靈活選擇。
以上講的是水平方向布局，同理垂直方向布局道理也一樣，我們以最常見的信息卡片為例子。一般情況下卡片圖片不變，標(biāo)題和內(nèi)容文字的不固定會(huì)導(dǎo)致卡片整體高度也會(huì)發(fā)生變化。利用智能布局我們可以讓卡片變成響應(yīng)式擴(kuò)展。
確定好上下左右的間距，例子中用的 16，然后建立組件，Layout 選擇從上往下布局，這樣標(biāo)題和內(nèi)容文字增多，上下的間距是保持不變的，內(nèi)容高度自動(dòng)增加。
以上就是 Sketch 58 Beta 版本新增的 Smart Layout 智能布局介紹。關(guān)于這個(gè)新功能，我們還可以做很多響應(yīng)式的組件，提升設(shè)計(jì)效率。Sketch 的更新速度也在加快，很多之前第三方插件才可以實(shí)現(xiàn)的效果也被官方一一收入囊中。希望 Sketch 的發(fā)展越來越好，成為設(shè)計(jì)師真正的設(shè)計(jì)利器。
58 版本的歡迎界面也做了大更新，至于好不好看就因人而異了。最后來一睹芳容。
文章來源：優(yōu)設(shè)
vue 1.0.3 中 $set 函數(shù)是動(dòng)態(tài)改變或添加一個(gè) data 中的屬性值時(shí) 屬性 key 不可以使用純數(shù)字。
例如：
var app = new Vue({
el:"#app",
data:{
test:{
k1:'v1',
k2:'v2'
}
},
methods:{
changeTestValue:function{
// 動(dòng)態(tài)改變 test 中某一屬性的值
var key = 'test.k1'; // 改變 test 屬性中的 k1 的值
this.$set(key,'changev1'); // 此處執(zhí)行沒有問題
// 改變 整個(gè) test 的值可以使用
this.$set('test',{k1:'change-demo-v1',k2:'change-demo-v2'}); // 此處執(zhí)行沒有問題
// 動(dòng)態(tài)給 test 增加一個(gè)屬性 k3
this.$set('test.k3','test-add-value3'); // 此處執(zhí)行沒有問題
// 此處有坑 當(dāng)你的 屬性為全數(shù)字的時(shí)候，則 函數(shù)無效，不報(bào)錯(cuò)，但是也添加不上值。
// 例如
this.$set('test.123','test-add-123'); // 此處執(zhí)行不報(bào)錯(cuò)，但是也沒有效果。
// 所以在使用老版本vue的時(shí)候盡量避免 屬性 key 未純數(shù)字，或其他特殊字符。
}
}
});
除了這個(gè)坑以外還有另外一個(gè)坑，不過沒有具體試驗(yàn)，
watch 監(jiān)聽某一值得變化，好像有點(diǎn)問題， 實(shí)際結(jié)果是只要 data 中的任意一個(gè)值發(fā)生變化都會(huì)被捕捉到。
最后還是使用 vue 2.x 以上版本吧，bug 少很多。
另外 $set 函數(shù)在2.x 中使用方式有所變化。
this.$set(target,key,obj);
target 對(duì)象類型，是需要賦值或修改的對(duì)象，
key 是字符串類型， 是 target 對(duì)象的屬性
obj 可以是字符串，可以是對(duì)象類型，是 你要修改的或增加的值
藍(lán)藍(lán)設(shè)計(jì)( m.yvirxh.cn )是一家專注而深入的界面設(shè)計(jì)公司，為期望卓越的國(guó)內(nèi)外企業(yè)提供卓越的UI界面設(shè)計(jì)、BS界面設(shè)計(jì) 、 cs界面設(shè)計(jì) 、 ipad界面設(shè)計(jì) 、 包裝設(shè)計(jì) 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計(jì)、 網(wǎng)站建設(shè) 、平面設(shè)計(jì)服務(wù)。
這幾天，各個(gè)產(chǎn)品群設(shè)計(jì)群又被「綠洲」的話題刷屏了，自從8月29日新浪悄悄上架了這款產(chǎn)品后，一時(shí)間中國(guó)版ins、意圖稱霸圖片社交、趁小紅書下架搶占用戶等等說服層出不窮。今天我們就從一個(gè)設(shè)計(jì)師的角度，看看綠洲這款產(chǎn)品有什么不同。
綠洲是一款社交產(chǎn)品，從已經(jīng)看到的產(chǎn)品功能和內(nèi)容上，類似ins，也就是說他是一款圖片社交產(chǎn)品，由新浪推出，目前處于內(nèi)測(cè)階段，除官方邀請(qǐng)的kol外只能通過邀請(qǐng)碼注冊(cè)使用。
社交產(chǎn)品在國(guó)內(nèi)難做大家都知道，原因也不必再說，但社交產(chǎn)品一旦做成產(chǎn)生的巨大利益和助推力又讓國(guó)內(nèi)大大小小的公司都在向這個(gè)寶藏發(fā)起沖擊。那么為什么新浪選擇的是圖片社交產(chǎn)品呢？
首先是基于國(guó)內(nèi)市場(chǎng)，還沒有出現(xiàn)一家獨(dú)大的圖片社交產(chǎn)品，不像國(guó)外已經(jīng)有了ins，國(guó)內(nèi)的圖片社交領(lǐng)域勉強(qiáng)還能算作是「藍(lán)?！梗由献罱〖t書下架導(dǎo)致市場(chǎng)有短暫的空白，大批kol和內(nèi)容生產(chǎn)者出走。也正是推出這款產(chǎn)品的良好時(shí)機(jī)。
當(dāng)然也有一種說法是：國(guó)內(nèi)的社交產(chǎn)品形態(tài)存在「跳代」的現(xiàn)象，從文字社交直接跳到了視頻社交，并已經(jīng)有了很成熟、用戶規(guī)模極大的產(chǎn)品抖音，所以從產(chǎn)品發(fā)展形態(tài)來看，圖片社交產(chǎn)品在國(guó)內(nèi)并沒有什么生存土壤。這里我直接說出自己的觀點(diǎn)：我認(rèn)為圖片社交在國(guó)內(nèi)還是有機(jī)會(huì)的，而且機(jī)會(huì)不小。對(duì)此我有以下幾個(gè)維度的思考：
1. 信息含量和傳達(dá)效率
首先不可否認(rèn)的是圖片的信息含量是遠(yuǎn)遠(yuǎn)大于文字的，使用圖片能夠更的傳達(dá)信息和更豐富的情感，想一想過去很多偉大的文學(xué)作品往往需要用一本書來體現(xiàn)某些情感和精神。但是在科技社會(huì)里，往往是一張攝影作品更能震撼人心，圖片中包含的信息更加直觀，人物、場(chǎng)景、顏色、故事都可以直接呈現(xiàn)在用戶面前，而不需要通過文字進(jìn)行描寫，也不需要運(yùn)用很多寫作技巧進(jìn)行鋪墊。這并不是說圖片比文字更優(yōu)秀，而是說圖片的形態(tài)在互聯(lián)網(wǎng)產(chǎn)品中可以更的傳達(dá)信息和情感。
說到這可能有朋友會(huì)說：圖片的信息和情感的傳達(dá)更，那視頻也同樣比圖片的信息含量更多，更，為什么圖片社交還有機(jī)會(huì)呢？這就要說到下一個(gè)維度—內(nèi)容生產(chǎn)門檻。
2. 內(nèi)容生產(chǎn)門檻
無論是圖片社交還是視頻社交，內(nèi)容都是產(chǎn)品中極重要的一部分，例如現(xiàn)在大家在看抖音時(shí)，大部分高質(zhì)量?jī)?nèi)容都是由專業(yè)的內(nèi)容生產(chǎn)者制作的，其中涉及到選題、劇本、拍攝、剪輯、后期、壓縮等等流程，即使不是專業(yè)的團(tuán)隊(duì)生產(chǎn)也是身兼數(shù)職的多面手生產(chǎn)者。流程一長(zhǎng)，工作量也就大大增加了。工作量一增加，門檻就會(huì)變高。如果不是為了靠抖音賺錢、如果不是為了增粉變現(xiàn)，又有多少人能投入這么多精力和時(shí)間去生產(chǎn)內(nèi)容？?jī)?nèi)容不多、質(zhì)量不高又怎么吸引更多用戶來使用-參與-生產(chǎn)最后形成閉環(huán)？
綠洲則不是這樣，雖然用戶可以上傳視頻，但主要的內(nèi)容還是圖片，拍一張圖片的各種成本要比拍一段視頻小太多啦，結(jié)果就是有更多的內(nèi)容生產(chǎn)者可以參與進(jìn)來，而不是被高門檻攔在產(chǎn)品之外，當(dāng)你生產(chǎn)了一段內(nèi)容，至少要發(fā)給幾個(gè)親朋好友來看看吧？即使只在產(chǎn)品內(nèi)部發(fā)個(gè)動(dòng)態(tài)，如果有人為你點(diǎn)贊、評(píng)論、又關(guān)注了你，至少再拍一點(diǎn)的動(dòng)力會(huì)大一些吧？這樣循環(huán)下去，內(nèi)容、用戶就全部都有了。舉個(gè)極端一點(diǎn)的例子，如果微信只能發(fā)圖片，那么還會(huì)有這么多人使用嗎？原因也是圖片的生產(chǎn)成本要大于文字（非文學(xué)作品的文字）。所以我認(rèn)為，內(nèi)容生產(chǎn)門檻也是綠洲的優(yōu)勢(shì)之一。
3. 信息接收程度
最后一點(diǎn)則是大眾用戶的信息接受程度。我們可能從新聞報(bào)道上經(jīng)常能看到體育記錄的突破，例如幾十年前科學(xué)家預(yù)言了人類短跑極限早就被突破幾十次了?；蛘呤强吹饺祟惼骄鶋勖谶^去幾百年的時(shí)間里提高了幾十歲。這里我想說的是：當(dāng)互聯(lián)網(wǎng)尤其是移動(dòng)互聯(lián)網(wǎng)普及之后，人類對(duì)于信息可接收量增加了多少？過去看紙質(zhì)書和現(xiàn)在拿著手機(jī)，每天閱讀文字圖片視頻等等能達(dá)到過去的多少倍？這里我沒有找到專業(yè)機(jī)構(gòu)的研究報(bào)告。但是這個(gè)增長(zhǎng)程度我想大家的意見應(yīng)該會(huì)十分一致。
信息接收能力的提高會(huì)倒逼著改變產(chǎn)品形態(tài)、過去我們每天只能接收2000個(gè)文字和50張圖片，所以我們習(xí)慣看報(bào)紙?，F(xiàn)在我們每天能接受10000個(gè)文字和300張圖片，所以我們?cè)谟妙^條用微信用微信用抖音。當(dāng)用戶有了適應(yīng)一項(xiàng)改變的基礎(chǔ)，那么必然會(huì)出現(xiàn)滿足用戶這種進(jìn)化的產(chǎn)品。抖音是，綠洲可能也是。
4. 磨刀霍霍的kol和網(wǎng)紅
前幾年無論公眾號(hào)、頭條號(hào)、直播很是催生了一批實(shí)現(xiàn)財(cái)務(wù)自由的幸運(yùn)者們，但更多的確實(shí)沒有抓住平臺(tái)早期紅利的玩家，在眾多自媒體和直播平臺(tái)都成熟之后，想要從中獲利是越來越難了。這時(shí)候出現(xiàn)了一個(gè)新興的、并且很有潛力的新平臺(tái)。那這些錯(cuò)過了上一波機(jī)會(huì)的預(yù)備役kol和網(wǎng)紅們會(huì)不會(huì)蜂擁而至呢？而更多的現(xiàn)有kol和網(wǎng)紅為了鞏固自己的地位、擴(kuò)大影響力和粉絲規(guī)模也同樣會(huì)去參與一番。去了之后為了自己的利益更是會(huì)給更多人安利這個(gè)產(chǎn)品。
說他有潛力是因?yàn)樗紦?jù)的天時(shí)、地利與人和。天時(shí)已經(jīng)說過，市場(chǎng)潛力巨大又縫小紅書下架，地利則是國(guó)內(nèi)暫無一家獨(dú)大的圖片社交產(chǎn)品，人和則是擁有幾億活躍用戶的微博作為后盾。如此的產(chǎn)品，再加上利益驅(qū)動(dòng)。想必內(nèi)容方面已經(jīng)問題不大了。
5. 內(nèi)測(cè)+邀請(qǐng)的機(jī)制
這幾天下載了綠洲的朋友們應(yīng)該都知道，如果你沒有邀請(qǐng)碼的話即使下載了也是不能注冊(cè)的，整個(gè)產(chǎn)品還處于「內(nèi)測(cè)階段」 。只有前期官方邀請(qǐng)的部分kol和少量?jī)?nèi)測(cè)用戶才能使用，每個(gè)內(nèi)測(cè)用戶又只能邀請(qǐng)一定數(shù)量的更多用戶。并且整體內(nèi)測(cè)數(shù)量也有限制。截止9月4日下午內(nèi)測(cè)人數(shù)已經(jīng)滿了，之后即使有邀請(qǐng)碼也不能注冊(cè)使用。那么這個(gè)內(nèi)測(cè)+邀請(qǐng)機(jī)制有什么好處呢？
有種說法是饑餓營(yíng)銷，利用用戶越得不到越想要的心理來獲取更多用戶。但這種說法有點(diǎn)說不通，因?yàn)閮?nèi)測(cè)總?cè)藬?shù)是有限制的。并且現(xiàn)在不是幾年前了，可能今天你內(nèi)測(cè)限制注冊(cè)人數(shù)那明天用戶就把你忘了，畢竟現(xiàn)在產(chǎn)品這么多，娛樂活動(dòng)數(shù)不勝數(shù)，已經(jīng)不是十年前那個(gè)產(chǎn)品稀缺的時(shí)代了。我大概有兩點(diǎn)猜想，一是產(chǎn)品方希望通過內(nèi)容試水，看看產(chǎn)品在市場(chǎng)上的反饋，進(jìn)而做出符合國(guó)內(nèi)用戶習(xí)慣的修改再大規(guī)模推廣（嗯，之所以要做符合國(guó)內(nèi)用戶習(xí)慣的修改是因?yàn)樗駃ns了~），二是產(chǎn)品方希望變「爆火三天死」為「細(xì)水長(zhǎng)流」，之前的馬桶MT、聊天寶、包括子彈短信等等產(chǎn)品在剛剛發(fā)布的時(shí)候都是非?；鸨⒂脩粼诙潭處滋熘畠?nèi)就過了百萬大關(guān)，但是現(xiàn)在呢？還有多少人在繼續(xù)用？增長(zhǎng)曲線還敢貼出來嗎？而使用了內(nèi)測(cè)+邀請(qǐng)機(jī)制則不同，一方面可以保持用戶維持一定數(shù)量的增長(zhǎng)，一方面又不會(huì)因?yàn)橛脩舻娜昼姛岫榷焖倮鋮s，對(duì)于社交產(chǎn)品而言，如果你身邊有朋友在用，那你繼續(xù)用的概率就會(huì)大很多。如果你發(fā)現(xiàn)你身邊的朋友在用，那即使你已經(jīng)卸載了也有一定可能重新下載回來再用一用，也就是用細(xì)水長(zhǎng)流的方式不斷召回之前的用戶，用留存做增長(zhǎng)。
上面說了一些我為什么認(rèn)為綠洲（或其他圖片社交產(chǎn)品）有一定生存空間的原因。下面我們來看看綠洲中一些很不錯(cuò)的設(shè)計(jì)細(xì)節(jié)。
1. 條目巨大，更重視內(nèi)容質(zhì)量
用戶的一條動(dòng)態(tài)（在產(chǎn)品設(shè)計(jì)中我們一般習(xí)慣稱之為條目，下面以條目稱呼它）往往占據(jù)了一整屏的空間，作者使用的還是長(zhǎng)度較長(zhǎng)的全面屏手機(jī)依然如此。這種設(shè)計(jì)可以在一定程度上說明產(chǎn)品方比較重視內(nèi)容。做產(chǎn)品設(shè)計(jì)的朋友應(yīng)該都知道：條目占據(jù)的空間越大一般包含的信息量就越多，也更容易形成轉(zhuǎn)化，對(duì)應(yīng)到綠洲中這個(gè)轉(zhuǎn)化就是點(diǎn)贊、評(píng)論、關(guān)注等等用戶的操作。一旦用戶做出這些操作，就會(huì)對(duì)產(chǎn)品形成更深度的使用習(xí)慣，也就有更多可能性變成活躍用戶。當(dāng)然條目占據(jù)空間過大同樣有風(fēng)險(xiǎn)，也就是如果這一條內(nèi)容的質(zhì)量不夠高的話用戶可能會(huì)產(chǎn)生流失，因?yàn)橛脩艨赡懿⒉粫?huì)繼續(xù)向下滑動(dòng)去看下一條內(nèi)容了。所以一般內(nèi)容質(zhì)量較高的產(chǎn)品條目占據(jù)的空間較大，質(zhì)量較低的產(chǎn)品條目占據(jù)空間較小，希望一屏之中能夠容納更多數(shù)量的條目，用戶數(shù)量換質(zhì)量希望其中能有一條對(duì)用戶形成轉(zhuǎn)化。所以綠洲的這個(gè)設(shè)計(jì)細(xì)節(jié)作者猜測(cè)是產(chǎn)品方重視內(nèi)容的體現(xiàn)。
2. 上傳圖片，實(shí)時(shí)看到效果
如下圖：
當(dāng)我們?cè)谏蟼鲌D片時(shí)，頁面上部為圖片的放大展示圖，頁面下部分為縮略圖，用戶可以在選擇圖片時(shí)實(shí)時(shí)看到自己選擇的圖片的細(xì)節(jié)，舉個(gè)例子，如果某漂亮妹子想發(fā)張自拍，但是相機(jī)里保存的是幾十張連拍照片，此時(shí)她就可以在選擇圖片時(shí)直接看到自己當(dāng)前選擇的圖片是否是自己最滿意的一張。而不需要上傳后才能看到，或是切換到系統(tǒng)相冊(cè)中去查看，再記住那張自己最滿意的照片的位置再回來重新上傳。
我們常見的產(chǎn)品中上傳照片時(shí)一般都是直接顯示縮略圖，好處是頁面效率高一屏可以展示更多圖片，壞處是不能直接看到照片的細(xì)節(jié)。這種設(shè)計(jì)比較好的平衡了這個(gè)問題。關(guān)于上傳圖片的優(yōu)秀設(shè)計(jì)我們前幾天還分享了ZAO里面的一個(gè)設(shè)計(jì)案例，下圖是ZAO核心流程中的兩個(gè)頁面，是選擇「影視劇片段」和「上傳替換素材」的頁面:
在此頁面選擇要替換的人物，點(diǎn)擊后進(jìn)入下圖上傳素材，選擇從相冊(cè)選擇。
我們可以看到，當(dāng)我們選擇從相冊(cè)上傳素材進(jìn)行替換時(shí)，系統(tǒng)已經(jīng)自動(dòng)對(duì)相冊(cè)內(nèi)的圖片進(jìn)行了判斷，在用戶上傳照片之前就對(duì)照片清晰度是否合適進(jìn)行了提示，而不是上傳后再給一個(gè)彈框。
作者對(duì)這個(gè)設(shè)計(jì)細(xì)節(jié)大致想法如下：
與上面案例相關(guān)的東西作者還想起了閑魚：
一是閑魚中，當(dāng)用戶上傳的商品圖片比較模糊時(shí)系統(tǒng)會(huì)提示用戶重新上傳，以提高二手物品的賣出速度。這里的設(shè)計(jì)是在用戶上傳圖片進(jìn)行提示，作者覺得就沒有ZAO中這個(gè)設(shè)計(jì)體驗(yàn)更好。
3. 更強(qiáng)、更方便的互動(dòng)方式
社交產(chǎn)品中，用戶之間的互動(dòng)率是一個(gè)十分重要的指標(biāo)，對(duì)內(nèi)容的點(diǎn)贊評(píng)論可以很大程度上加強(qiáng)用戶粘性，使用戶與用戶之間產(chǎn)生關(guān)系鏈，這樣用戶流失的概率就會(huì)小很多。一般的產(chǎn)品中常見的功能像點(diǎn)贊評(píng)論在綠洲里也有了不一樣的變化，并且體驗(yàn)還真的不錯(cuò)，如下：
當(dāng)用戶對(duì)某一條消息產(chǎn)生了互動(dòng)的傾向時(shí)，可以直接使用三個(gè)表情表示不同的情緒，分別是愛心、鼓掌和笑哭，如果想要評(píng)論的話只需要點(diǎn)擊WOW按鈕系統(tǒng)就可以自動(dòng)生成一句評(píng)論，不需要用戶自己思考寫什么內(nèi)容，這樣用戶進(jìn)行評(píng)論操作的成本就大大的降低了。如果對(duì)生成的評(píng)論不滿意的話還可以再次點(diǎn)擊生成不同的評(píng)論。
4. 不足的用戶認(rèn)知負(fù)荷
當(dāng)然作者同事也看到了體驗(yàn)不是很好的設(shè)計(jì)細(xì)節(jié)，如下圖產(chǎn)品中使用了太多無文字按鈕，導(dǎo)致根本不知道這些都是什么功能，綠洲對(duì)自己的介紹是更清爽的朋友圈，如果說是為了讓界面更干凈簡(jiǎn)約才使用了這樣設(shè)計(jì)的話我覺得有些本末倒置了，國(guó)內(nèi)用過ins的用戶畢竟還是少數(shù)，對(duì)于大部分用火狐來說綠洲還是一款陌生的產(chǎn)品，在陌生的產(chǎn)品中使用這種不能明確表達(dá)功能含義的無文字按鈕則讓用戶十分迷茫，大大增加了認(rèn)知負(fù)荷。
昨天晚上作者在家附近的面館吃飯，正在等著自己的油潑面、羊肉串、拍黃瓜、小酥肉、酸梅湯的時(shí)候看到了一件事：某50歲左右的大叔點(diǎn)菜說想要一份涼皮。
服務(wù)員問：您是要麻醬涼皮的還是秘制涼皮？
大叔猶豫一下，問：秘制涼皮是什么的？
服務(wù)員答：就是有涼皮和面筋摻一塊，放上醋、鹽、香油、辣子，酸甜口的可辣可不辣。
大叔繼續(xù)猶豫了一下說：那給我來個(gè)麻醬涼皮吧。
故事到這開始有點(diǎn)意思了，這個(gè)用戶(大叔)對(duì)秘制涼皮是沒有概念的，雖然經(jīng)過服務(wù)員解釋之后明白了是什么，也知道了口味，但是對(duì)于「秘制涼皮」這個(gè)概念的熟悉程度還是比較低，所以最終沒有選擇它。這和我們?cè)谶M(jìn)行產(chǎn)品設(shè)計(jì)時(shí)對(duì)一些文案的設(shè)計(jì)很像。大家第一眼看過之后能明白是什么意思嗎？反正我是沒有明白。不明白就會(huì)產(chǎn)生認(rèn)知負(fù)荷。也就會(huì)影響向下的轉(zhuǎn)化率。當(dāng)用戶點(diǎn)擊幾次沒有找到自己想要的東西之后，他也就走了，去哪了呢？可能是「商城」「歷史文章」「限時(shí)促銷」這些他明白是什么意思的地方。
你只是綠洲，你還不是微信，這樣的設(shè)計(jì)有些為時(shí)過早了。
昨天我故意吃的比較慢，觀察了一下麻醬涼皮和秘制涼皮的購(gòu)買人數(shù)，在大約40分鐘的時(shí)間里，大約有7人選擇了麻醬涼皮，2人選擇了秘制涼皮。服務(wù)員大約解釋了4次什么是秘制涼皮，每次大約需要20秒，加上顧客猶豫的時(shí)間，這40分鐘里服務(wù)員大約多花了3分鐘時(shí)間解釋、等待用戶做選擇。
如果把這種場(chǎng)景放到我們的產(chǎn)品設(shè)計(jì)中則意味著更低的效率、更少的使用時(shí)間、更低的轉(zhuǎn)化率。以及推出新功能之后更少的使用率。現(xiàn)在很多產(chǎn)品中對(duì)功能的命名都基本一致、一些常規(guī)圖標(biāo)的樣式也都基本一樣。目的也就是為了減輕用戶的認(rèn)知負(fù)荷。
簡(jiǎn)單介紹
多個(gè)頁面和 servlet 組成了一個(gè)基于 Java 的 web 應(yīng)用程序。JSP 使用轉(zhuǎn)發(fā)和重定向兩種方式將控制權(quán)從一個(gè) servlet 傳遞到另一個(gè) servlet 或者 JSP。
轉(zhuǎn)發(fā)（Forward）方法： 將請(qǐng)求從一個(gè) servlet 轉(zhuǎn)發(fā)到 web 應(yīng)用程序中的另一個(gè)資源，這個(gè)資源可以是一個(gè) servlet、JSP 頁面、或者 HTML 文件。
重定向（Redirect）方法： 方法將請(qǐng)求重定向到另一個(gè) web 應(yīng)用程序。使用轉(zhuǎn)發(fā)（ Forward ）方法無法完成此操作。如果一個(gè)重定向命中了同一個(gè) web 應(yīng)用程序的不同資源，那么它使用的 URL 將與原始請(qǐng)求的 URL 不同。如果你不想響應(yīng)一個(gè)請(qǐng)求，你可以將請(qǐng)求重定向到一個(gè)不同的 URL，然后瀏覽器將會(huì)將你的新請(qǐng)求重定向到你提供的新的 URL。這篇文章詳細(xì)解釋了兩種方式的不同之處。
什么是轉(zhuǎn)發(fā)（Forward）
在基于 web 的系統(tǒng)或者應(yīng)用程序中，通常需要在不同的資源或 JSP 之間轉(zhuǎn)移控制權(quán)。例如：你如希望從電子商務(wù)網(wǎng)站下單，則需要先進(jìn)行注冊(cè)，然后才可以繼續(xù)。如果你還未在他們的系統(tǒng)中注冊(cè)，那么購(gòu)物車界面可能會(huì)將控制權(quán)轉(zhuǎn)移到負(fù)責(zé)注冊(cè)過程的 JSP 表單。轉(zhuǎn)發(fā)（ Forward ）方法即是用于此目的。它用于將請(qǐng)求從一個(gè) JSP 轉(zhuǎn)發(fā)到統(tǒng)一上下文中的另一個(gè)資源。
什么是重定向（Redirect）
此方法也用于轉(zhuǎn)發(fā) HTTP 請(qǐng)求，但與轉(zhuǎn)發(fā)（ Forward ）不同的是：它是一個(gè)兩步過程，其中重定向發(fā)生在客戶端到不同的應(yīng)用程序。Redirect 方法將用戶重定向到新的 URL。客戶端的瀏覽器會(huì)自動(dòng)對(duì)來自服務(wù)器中的重定向表頭中指定的 URL 發(fā)出新的請(qǐng)求。它需要與客戶機(jī)進(jìn)行往返通訊，因此相對(duì)來說會(huì)比轉(zhuǎn)發(fā)（ Forward ）方法慢些。
轉(zhuǎn)發(fā)（Forward）與重定向（Redirect）區(qū)別
轉(zhuǎn)發(fā)（Forward）與重定向（Redirect）的描述
Forward() 方法用于將請(qǐng)求從一個(gè) JSP 轉(zhuǎn)發(fā)到另一個(gè) JSP，或從一個(gè) JSP 轉(zhuǎn)發(fā)到另一個(gè) servlet，或從一個(gè) JSP 轉(zhuǎn)發(fā)到 web 應(yīng)用程序的另一個(gè)資源?？刂剖窃谌萜鞯膬?nèi)部傳遞的，瀏覽器/客戶機(jī)不參與此過程。Forward( )方法在 RequestDispatcher 中聲明。
Sendredirect () 方法在 HttPServletResponse 中聲明，用于將客戶端請(qǐng)求重定向到不同服務(wù)器或上下文中可用的不同 URL。 通過重定向，您可以將瀏覽器重定向到完全不同的應(yīng)用程序。
客戶端是否參與轉(zhuǎn)發(fā)（Forward）和重定向（Redirect）
這兩種方法之間的一個(gè)關(guān)鍵區(qū)別是 web 容器在 Forward() 情況中處理了所有的內(nèi)部進(jìn)程，而且 URL 在客戶端的瀏覽器中不會(huì)改變，因此客戶端/瀏覽器不會(huì)參與其中，從而使它們完全不知道動(dòng)作已經(jīng)發(fā)生。
而在 Sendredirect () 的情況中，該方法設(shè)置適合的頭部信息和正文內(nèi)容以將請(qǐng)求重定向到不同的 URL 中，瀏覽器付負(fù)責(zé)將新的請(qǐng)求發(fā)送到客戶端可見的 URL。
執(zhí)行控制
當(dāng)在請(qǐng)求時(shí)執(zhí)行 Forward() 方法，當(dāng)前的請(qǐng)求會(huì)被轉(zhuǎn)發(fā)到另一個(gè) JSP 頁面，對(duì)當(dāng)前 JSP 的處理也會(huì)被終止。請(qǐng)求可能會(huì)被轉(zhuǎn)發(fā)到另一個(gè)用 Java 編程語言編寫的 servlet，或者一個(gè)靜態(tài)的 HTML 頁面。
一個(gè) SendRedirect() 請(qǐng)求只是簡(jiǎn)單告知瀏覽器轉(zhuǎn)到另一個(gè) URL，將執(zhí)行控制發(fā)送到 web 應(yīng)用程序之外。它使用一個(gè)兩步的過程來指示瀏覽器的 URL 發(fā)出另一個(gè)將控制轉(zhuǎn)發(fā)到另一個(gè)客戶端的請(qǐng)求。
速度
Forward () 在服務(wù)器內(nèi)運(yùn)行，執(zhí)行速度比 SendRedirect () 快。
重定向必須通過瀏覽器，然后等待瀏覽器發(fā)出新的 HTTP 請(qǐng)求。 一個(gè)重定向使得服務(wù)器發(fā)送 HTTP 響應(yīng)狀態(tài)代碼 302 和一個(gè)包含新的 URL 的位置頭到瀏覽器，并且在瀏覽器收到狀態(tài)代碼 302 之后，它對(duì)位置頭中的 URL 發(fā)出一個(gè)新的請(qǐng)求。 這需要與客戶機(jī)進(jìn)行往返通信，這使得它比 Forward () 相對(duì)慢一些。
轉(zhuǎn)發(fā)（Forward）和重定向（Redirect）比較圖表
轉(zhuǎn)發(fā)（Forward） 重定向（Redirect）
用于將請(qǐng)求從一個(gè) JSP 轉(zhuǎn)發(fā)到另一個(gè) JSP，或從一個(gè) JSP 轉(zhuǎn)發(fā)到另一個(gè) servlet，或從一個(gè) JSP 轉(zhuǎn)發(fā)到 web 應(yīng)用程序的另一個(gè)資源。 用于將客戶端請(qǐng)求重定向到不同服務(wù)器或上下文中可用的不同 URL。
Forward( )方法在 RequestDispatcher 中聲明。 Sendredirect () 方法在 HttPServletResponse 中聲明
不涉及客戶端/瀏覽器，web 容器在內(nèi)部處理該過程。 當(dāng)客戶端將 URL 作為一個(gè)新的請(qǐng)求后，控制權(quán)將會(huì)轉(zhuǎn)移至客戶端或?yàn)g覽器。
當(dāng)一個(gè)組件執(zhí)行業(yè)務(wù)邏輯并與另一個(gè)組件共享結(jié)果時(shí)，它最有效。 當(dāng)客戶端應(yīng)從一個(gè)頁面重定向到另一頁面時(shí)，此方法效果最佳。
它在服務(wù)器內(nèi)運(yùn)行，并且比重定向執(zhí)行得更快。 它比轉(zhuǎn)發(fā)慢，因?yàn)樗枰c客戶端進(jìn)行往返通信。
使用時(shí)，原來的 URL 請(qǐng)求不變。 原始的 URL 請(qǐng)求會(huì)改變。
兩種資源都必須屬于同一上下文。 將請(qǐng)求重定向到不屬于當(dāng)前上下文的其它 URL。
轉(zhuǎn)發(fā)（Forward）和重定向（Redirect）總結(jié)
學(xué)習(xí)轉(zhuǎn)發(fā)方法和重定向方法之間的區(qū)別是 Java 開發(fā)人員最重要的部分之一。 雖然控制器可以在處理請(qǐng)求結(jié)束時(shí)執(zhí)行轉(zhuǎn)發(fā)（Forward）或重定向（Redirect）方法，但它們有自己的一組用途。
大多數(shù)情況下，您會(huì)使用 Forward () 方法，因?yàn)樗?SendRedirect () 稍微快一點(diǎn)，而后者實(shí)際上需要與客戶機(jī)進(jìn)行往返通信，使其比 Forward() 更慢。 通過重定向，你可以將瀏覽器導(dǎo)向到另一個(gè)應(yīng)用程序。 這是轉(zhuǎn)發(fā)無法做到的。
簡(jiǎn)而言之，當(dāng)一個(gè)組件必須執(zhí)行業(yè)務(wù)邏輯并與另一個(gè)組件共享結(jié)果時(shí)，轉(zhuǎn)發(fā)（Forward）工作效果最好，而當(dāng)客戶端應(yīng)該從一個(gè)頁面重定向到另一個(gè)頁面時(shí)，重定向（Redirect）工作效果最好。
以上內(nèi)容翻譯自：
Difference Between Forward and Redirect。
能力有限，還望斧正。
藍(lán)藍(lán)設(shè)計(jì)( m.yvirxh.cn )是一家專注而深入的界面設(shè)計(jì)公司，為期望卓越的國(guó)內(nèi)外企業(yè)提供卓越的UI界面設(shè)計(jì)、BS界面設(shè)計(jì) 、 cs界面設(shè)計(jì) 、 ipad界面設(shè)計(jì) 、 包裝設(shè)計(jì) 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計(jì)、 網(wǎng)站建設(shè) 、平面設(shè)計(jì)服務(wù)。
2019年7月20日，UXRen北京舉辦了《如何通過體驗(yàn)設(shè)計(jì)賦能產(chǎn)品增長(zhǎng)》的沙龍分享，本文基于嘉賓 何曉頔（搜狗高級(jí)用戶研究工程師）的現(xiàn)場(chǎng)分享總結(jié)而成。
何曉頔2015年開始從事用研工作，2018年加入搜狗，目前在搜狗搜索擔(dān)任用戶研究工程師；期間支持搜狗搜索相關(guān)產(chǎn)品的用戶研究工作，完成搜狗閱讀app、搜狗搜索app、搜狗圖片搜索改版研究，搜狗醫(yī)療搜索系列研究，搜狗翻譯app調(diào)研等項(xiàng)目；擅長(zhǎng)全局思考問題，綜合考慮各方訴求，通過研究方法的熟練運(yùn)用，需求的深度解讀，結(jié)果的產(chǎn)出，不斷提升用研的影響力及價(jià)值。
由于用研資源的緊張，傳統(tǒng)研究模式周期長(zhǎng)，使得用研游離在項(xiàng)目邊緣，融入難，導(dǎo)致時(shí)效性跟不上整個(gè)項(xiàng)目的推進(jìn)，出現(xiàn)信息不對(duì)等的情況，從而造成研究方向的偏差，而且研究結(jié)果也會(huì)和設(shè)計(jì)、產(chǎn)品的需求脫節(jié)，造成落地難的問題。
敏捷用研可以很好的解決這個(gè)問題，它可以很好地融入在項(xiàng)目的各個(gè)階段中，能夠在3-5天內(nèi)地完成調(diào)研需求，真正融入到整個(gè)項(xiàng)目的流程中，在每個(gè)階段都以結(jié)果導(dǎo)向的解決問題，形成每個(gè)階段的連接器。所以說他以用戶思維為核心，通過用研的驅(qū)動(dòng)性，增加用戶在整個(gè)項(xiàng)目中的參與度和體驗(yàn)感，不僅能夠?qū)崿F(xiàn)成本的減少，還能提高響應(yīng)的效率，實(shí)現(xiàn)信息層面的對(duì)等，還原用戶的真情實(shí)感，性價(jià)比高的同時(shí)還提升了用研的價(jià)值。
敏捷用研可以在敏捷項(xiàng)目的各環(huán)節(jié)中發(fā)揮作用，而且在不同階段可以有針對(duì)性的解決問題。
2.1 改版前
需求分析
用戶點(diǎn)擊行為研究
書城結(jié)構(gòu)布局研究
2.2 改版中
用戶需求挖掘
搜索行為探索
2.3 改版后：改版效果評(píng)估
2.4 項(xiàng)目合作模式
3.1 招募策略——健全流程
招募問卷設(shè)計(jì)
招募渠道
招募用戶特征及數(shù)量
獎(jiǎng)勵(lì)機(jī)制
3.2 研究策略——模板化、透明化
模板化：搭建問題包，分門別類、系統(tǒng)整理，隨時(shí)調(diào)用、整合
過程透明：邊訪談邊總結(jié)，根據(jù)需求，隨時(shí)調(diào)整、直到數(shù)據(jù)樣本趨于穩(wěn)定
3.3 溝通策略——循序漸進(jìn)
結(jié)合迭代研究模式，從小范圍調(diào)研起步，與客戶及時(shí)共享研究進(jìn)度和成果，循序漸進(jìn)：
3.4 參與策略
3.5 小結(jié)
敏捷調(diào)研不是為了快而快，而是快速解決產(chǎn)品需求和設(shè)計(jì)問題打造好的體驗(yàn)！
問題1：內(nèi)部用戶招募。國(guó)企，公司logo優(yōu)化調(diào)研， 因?yàn)闀r(shí)間和成本的關(guān)系，邀約的是公司的內(nèi)部員工（年齡集中在40-50歲區(qū)間段），調(diào)研的結(jié)果內(nèi)部員工更偏好原logo的微小變化的版本，與設(shè)計(jì)方期望差別非常大，想知道是否是不應(yīng)該找內(nèi)部員工測(cè)試。
回答：就上述問題，不建議找內(nèi)部員工測(cè)試。
內(nèi)部招募是一種短平快的用戶招聘渠道，但是，
問題2：概念測(cè)試。概念型產(chǎn)品可以用電話訪談的形式進(jìn)行測(cè)試么
回答：概念型產(chǎn)品，由于屬于市場(chǎng)上未出現(xiàn)產(chǎn)品，很難在電話中通過語言描述的方式讓用戶理解和想象出來，因此，概念類測(cè)試不建議用問卷和電話訪談的方式，建議通過面對(duì)面訪談+高保真原型展示的方式進(jìn)行測(cè)試，如果實(shí)在滿足不了高保真，哪怕線框的示意圖都比單薄的語言描述更強(qiáng)。
問題3：用研考核機(jī)制。用研的輸出建議，有些被采納，有些不被采納，采納的建議到產(chǎn)品成型很多已不是建議的“原型”了，如何衡量用研結(jié)果的直接作用。
回答：
每一次學(xué)習(xí)改版案例，不僅僅只是去看在視覺層面的變化，更多的應(yīng)該是要學(xué)習(xí)到作者改版背后的思考。為什么要這么改，原因是什么，目的又是什么，怎么做，有哪些限制等等，有很多東西要去思考。所以，帶著問題并結(jié)合自己實(shí)際中所做的項(xiàng)目來看案例，應(yīng)該會(huì)是一個(gè)很有收獲的過程。
Booking.com繽客 是一家荷蘭初創(chuàng)公司，并已經(jīng)發(fā)展成為全球最大的旅游電子商務(wù)公司之一。
在Booking上，旅客可以選擇世界上任何一處的住宿地點(diǎn)，包括公寓，度假酒店，民宿，五星級(jí)豪華度假村，樹屋甚至冰屋等等。每天，通過平臺(tái)預(yù)訂的房間數(shù)超過155萬。無論是商務(wù)旅行還是休閑旅行，人們都可以快速輕松地預(yù)訂到理想的住處。
自從Booking發(fā)布以來，許多競(jìng)爭(zhēng)對(duì)手都采用類似的商業(yè)模式瘋狂跟進(jìn)，搶占市場(chǎng)，并且在某些方面比Booking本身做的還好。
在調(diào)研的前期階段，我去搜集了一些競(jìng)爭(zhēng)對(duì)手和類似的平臺(tái)，分析UI，用戶體驗(yàn)，用戶地圖，信息架構(gòu)和關(guān)鍵功能。但是我并不會(huì)花太多時(shí)間過于深入的去分析這些產(chǎn)品，因?yàn)槲蚁Ｍ麑⒅攸c(diǎn)放在Booking這個(gè)產(chǎn)品本身的訴求上。
在之前的調(diào)研過程中，我發(fā)現(xiàn)了許多不同的使用場(chǎng)景，經(jīng)過匯總歸集，我集中關(guān)注以下3個(gè)場(chǎng)景：
在進(jìn)一步的研究中，我明確了4位具有不同需求和不同目標(biāo)的典型用戶，這些數(shù)據(jù)對(duì)于改善不同用戶的體驗(yàn)非常有用。
這個(gè)分析的目的是通過梳理最佳的用戶流程并提升產(chǎn)品體驗(yàn)，來為不同需求的用戶提供最好的用戶體驗(yàn)。
△ 數(shù)據(jù)來源：在線研究和用戶訪談（30個(gè)用戶樣本）
收集用戶評(píng)論，從中我收到了很多有價(jià)值的反饋，這些評(píng)論中沒有特別明確指出是可用性或功能性的問題。我將這些反饋分為4類（譯者注：對(duì)反饋的問題進(jìn)行提煉整理）：
毫無疑問，最相關(guān)的是預(yù)訂被取消的問題。太多用戶會(huì)注意到不合理的費(fèi)用或與房間的主人取得聯(lián)系時(shí)遇到困難。
基于30個(gè)用戶樣本，我試圖獲得進(jìn)一步的用戶反饋，從中注意到以下的幾點(diǎn)事實(shí)：
我想引用一段話，來總結(jié)這里面遇到的問題，這段話也蠻有意思的，它說的是：
「與其他應(yīng)用比較來看，套路顯得有點(diǎn)多，會(huì)讓你覺得一切看起來都蠻劃算，總是想多賣一些東西給你?！?
總結(jié)之前的分析，我提出了以下幾點(diǎn)觀點(diǎn)：
從用戶痛點(diǎn)出發(fā)，嘗試找到合適的解決方案，來提升產(chǎn)品體驗(yàn)。
1. 主頁
總的來說，我對(duì)首頁進(jìn)行了大手術(shù)。主頁的搜索功能已經(jīng)完全重新設(shè)計(jì)，減少過多的干擾信息。
導(dǎo)航：我設(shè)計(jì)了一個(gè)新的導(dǎo)航欄，剝離出「已保存」功能，這樣用戶就可以快速找到自己所收藏的商品。此外，我也優(yōu)化了「交易」的模塊，后面我會(huì)詳細(xì)的說說這塊的改動(dòng)思路。
其它功能 :至于之前的版本，我保留了搜索和相關(guān)推薦的功能，重新設(shè)計(jì)界面以改善UI的可用性。
2. 社交功能
如今，社交網(wǎng)絡(luò)在用戶的生活中扮演重要的角色，那沒理由在booking中做的這么差。我搞了一個(gè)新功能，允許用戶關(guān)聯(lián)自己的好友并查看他們的選擇，包括他們的評(píng)價(jià)（喜歡/不喜歡）。我已將此功能放置到主頁的下方，因?yàn)槲蚁Ｍ趯⑵渫茝V到其他模塊之前收集更多有關(guān)它的數(shù)據(jù)。
3. 搜索功能
把這個(gè)功能分解為多個(gè)步驟。在輸入第一個(gè)詞后，即使沒有指定日期或其他信息，也能顯示相匹配的酒店。此外，我也加入了語音搜索，使搜索更容易。基于之前我對(duì)不同用戶角色的定義，搜索的結(jié)果將根據(jù)最后的信息進(jìn)行推薦：
4. 列表頁面
列表頁針對(duì)易用性方面做了整體的優(yōu)化：
5. 詳情頁
我列出許多可以在詳情頁面中加入的修改。將總價(jià)格突出顯示，以免有些隱形消費(fèi)用戶可能會(huì)被忽略。
增強(qiáng)了一個(gè)與評(píng)論相關(guān)的次要功能，允許用戶通過不同標(biāo)簽篩選它們。
6. 交易功能
在優(yōu)化開始時(shí)，我確定了操作場(chǎng)景2—— 「用戶還不知道自己的目的地」作為優(yōu)化方向。為了提供更好的用戶體驗(yàn)，我增加了一個(gè)新的功能，用戶可以在其中找到不同目的地的區(qū)間。利用篩選功能，用戶可以選擇最適合其需求的區(qū)間（區(qū)間 – 大陸 – 國(guó)家等…）
最后，我還設(shè)計(jì)了一個(gè)整個(gè)項(xiàng)目的動(dòng)效原型，把之前所有重設(shè)計(jì)的頁面串聯(lián)起來。
由于時(shí)間限制，分析和結(jié)果是基于我的個(gè)人經(jīng)驗(yàn)和少量數(shù)據(jù)，需要進(jìn)行深入分析和其他測(cè)試，以便完善和驗(yàn)證解決方案。
文章來源：優(yōu)設(shè)網(wǎng)
vue-cli3發(fā)布自2018年8月，距離現(xiàn)在還不是特別久，最好搭建項(xiàng)目剛好用到，所以寫下這篇文章，記錄一下踩坑經(jīng)歷。
vue的作者說過，vue-cli的本質(zhì)是模
版的拉取，太多的配置導(dǎo)致了模版的難以維護(hù)，所以重構(gòu)后的版本提供了插件的功能，一個(gè)插件對(duì)應(yīng)一個(gè)功能，這樣避免了多個(gè)模版，也使得cli維護(hù)性得到提高，這也是本篇文章的核心介紹內(nèi)容。
我對(duì)cli3的理解是，一方面擴(kuò)展了cli2的核心能力 ，一方面封裝了webpack邏輯和配置。在過去要去做一個(gè)cli，通常需要閱讀cli2的代碼，cli2的核心模塊分別是 generator,prompts,template，git-repo,并用同樣的方法去做一個(gè)cli，這樣其實(shí)成本不小，cli3的插件就是提供了這樣一種能力，你用他的規(guī)則，去做一個(gè)npm包，并發(fā)到倉(cāng)庫(kù)，就可以獲得這種能力。
首先，先介紹一下vue-cli3，他的發(fā)布帶了哪些新功能呢？我總結(jié)一下，大概有以下5點(diǎn)：
1.功能豐富。這點(diǎn)相信大家都很好理解，他實(shí)在太好用了，模版里包含了大多數(shù)業(yè)界比較新的功能，可以一鍵集成typescripts等類型定義工具, eslint/tslint等語法檢驗(yàn)工具，風(fēng)格規(guī)范，prettier，husky等格式化工具，還有postcss、pwa、vue-cli-server等等。
2.提高封裝性和擴(kuò)展性。這點(diǎn)指的是vue-cli-server，在過去webpack的邏輯和配置在項(xiàng)目里獨(dú)立維護(hù)，各個(gè)項(xiàng)目之間就像孤島，vue-cli-server就像一個(gè)紐帶，連接起了各個(gè)項(xiàng)目，為項(xiàng)目升級(jí)webpack提供便利性，并且通過一份配置，提供個(gè)性化配置。
這里順帶扯一下vue.config.js, 這個(gè)東西就是用來個(gè)性化配置webpack的，他提供了很多的配置項(xiàng)，具體可以看官方文檔：
https://cli.vuejs.org/zh/config/
我們挑幾個(gè)常用的來講：
configureWebpack，這個(gè)幾乎是用的比較多的，簡(jiǎn)單的方法，可以通過配置的方式配置，如下所示：
-
module.exports = {
-
configureWebpack: {
-
plugins: [
-
new MyAwesomeWebpackPlugin()
-
]
-
}
-
}復(fù)制代碼
這份配置，最終會(huì)被合并到原來的配置里，不會(huì)覆蓋。
復(fù)雜的方法，可以往這個(gè)字段傳一個(gè)函數(shù)，如下所示：
-
module.exports = {
-
configureWebpack: config => {
-
if (process.env.NODE_ENV === 'production') {
-
// 為生產(chǎn)環(huán)境修改配置...
-
} else {
-
// 為開發(fā)環(huán)境修改配置...
-
}
-
}
-
}復(fù)制代碼
這樣就可以在一個(gè)函數(shù)里做一些簡(jiǎn)單的邏輯，config是webpack config，你可以直接修改config對(duì)象，也可以返回一個(gè)對(duì)象，這個(gè)對(duì)象最終也會(huì)被合并會(huì)webpack對(duì)象。
第三種方式，是通過webpack-chain來鏈?zhǔn)秸{(diào)用，代碼如下所示：
-
module.exports = {
-
chainWebpack: config => {
-
config.module
-
.rule('vue')
-
.use('vue-loader')
-
.loader('vue-loader')
-
.tap(options => {
-
// 修改它的選項(xiàng)...
-
return options
-
})
-
}
-
}復(fù)制代碼
3.提供圖形化管理界面，最所周知，gui易懂，cli，vue在降低學(xué)習(xí)門檻這方面，已經(jīng)是非常好了。
通過vue ui指令，可以查看編譯各個(gè)模塊的情況，模塊依賴情況，插件的情況，非常便于管理。
4.便捷性。vue-cli-server不僅支持項(xiàng)目的編譯，也支持單文件的編譯，具體的方法可以看官網(wǎng)介紹。
5.提供了cli的核心能力，也就是問詢，模版渲染，文件生成這幾大核心功能。具體的示意圖可以看如下：
以上是cli2的核心模塊，需要引用hbs,inquirer.js,metalsmit等基本模塊，cli3的插件機(jī)制基本幫我們封裝好了，我們只需要根據(jù)插件的規(guī)范，就可以獲取這種能力。
由于有的讀者可能對(duì)cli2的流程比較陌生，所以我想簡(jiǎn)單描述一下cli2的工作流程，如下圖所示：
首先，cli2提供init指令，執(zhí)行這個(gè)指令，會(huì)去遠(yuǎn)程拿模版文件，并拉到本地用戶目錄的.vue-template的文件夾，然后通過meta里問題，去問你，然后生成最終模版到你執(zhí)行命令的目錄。
說完vue-cli2，我們來看看vue-cli3的插件是怎么樣的？
首先根據(jù)插件的位置，我們分成了cli插件，和service插件。cli的插件有完整的開發(fā)目錄，所能做的事情也比較多一點(diǎn)，service插件是一份js文件，導(dǎo)出一個(gè)函數(shù)。
cli插件的目錄如下所示：
具體的用發(fā)可以在官網(wǎng)了解到：
https://cli.vuejs.org/zh/dev-guide/plugin-dev.html#cli-%E6%8F%92%E4%BB%B6
那么他們是怎么工作的呢？
cli的代碼主要在@vue/cli 下面，他的大概的流程如下圖所示：
@vue/cli/bin/vue.js:
-
program
-
.command('add <plugin> [pluginOptions]')
-
.description('install a plugin and invoke its generator in an already created project')
-
.option('--registry <url>', 'Use specified npm registry when installing dependencies (only for npm)')
-
.allowUnknownOption()
-
.action((plugin) => {
-
require('../lib/add')(plugin, minimist(process.argv.slice(3)))
-
})
-
-
program
-
.command('invoke <plugin> [pluginOptions]')
-
.description('invoke the generator of a plugin in an already created project')
-
.option('--registry <url>', 'Use specified npm registry when installing dependencies (only for npm)')
-
.allowUnknownOption()
-
.action((plugin) => {
-
require('../lib/invoke')(plugin, minimist(process.argv.slice(3)))
-
})復(fù)制代碼
首先，執(zhí)行vue指令，會(huì)執(zhí)行@vue/cli/bin/vue.js，這里定義了vue add , vue invoke，vue build，vue serve，等指令，可以看出，add指令其實(shí)是包含invoke指令的，add指令主要是安裝一個(gè)包，并且觸發(fā)generator.js，invoke主要是觸發(fā)generator.js。
然后再來看@vue/cli/lib/add.js，
-
const packageManager = loadOptions().packageManager || (hasProjectYarn(context) ? 'yarn' : 'npm')
-
await installPackage(context, packageManager, options.registry, packageName)復(fù)制代碼
-
const generatorPath = resolveModule(`${packageName}/generator`, context)
-
if (generatorPath) {
-
invoke(pluginName, options, context)
-
} else {
-
log(`Plugin ${packageName} does not have a generator to invoke`)
-
}復(fù)制代碼
add.js主要安裝包，然后執(zhí)行invoke模塊，我們?cè)倏纯磇nvoke模塊做了什么。
@vue/cli/lib/invoke.js
-
const generator = new Generator(context, {
-
pkg,
-
plugins: [plugin],
-
files: await readFiles(context),
-
completeCbs: createCompleteCbs,
-
invoking: true
-
})復(fù)制代碼
invoke里主要實(shí)例化generator類，然后把你的插件當(dāng)成參數(shù)傳給類，generator類算是vue-cli的核心類了。
@vue/cli/lib/generator.js
-
plugins.forEach(({ id, apply, options }) => {
-
const api = new GeneratorAPI(id, this, options, rootOptions)
-
apply(api, options, rootOptions, invoking)
-
})復(fù)制代碼
這個(gè)類主要負(fù)責(zé)執(zhí)行你的插件，然后把generatorapi作為參數(shù)傳入插件的generator.js導(dǎo)出的函數(shù)。
具體的vue-cli插件的開發(fā)是怎么樣的呢，我寫了一個(gè)demo，用在模擬多項(xiàng)目的ci模版管理，通常每個(gè)項(xiàng)目都有一份.gitlab-ci.yml模版，所以我們一般可以抽出一個(gè)公共的ci模版來管理，這里我用cli插件來管理，真正的項(xiàng)目可能不具備可行性，這里我只是用來寫一個(gè)例子。
目錄結(jié)構(gòu)大概如上所示，執(zhí)行vue add foo后，就會(huì)出現(xiàn)propmts對(duì)話框，然后選擇答案后，就會(huì)根據(jù)配置生成模版到你的根目錄下。
_gitlab-ci.yml ,根據(jù)問題選擇是否用私有npm倉(cāng)庫(kù)：
-
script:
-
<%_ if (options.config === 'npm') { _%>
-
- nrm add companynpm http://xxx.y.cn:XXXXX/
-
- nrm use companynpm
-
<%_ } _%>復(fù)制代碼
prompts.js,主要一些問題的設(shè)計(jì)：
-
module.exports = [
-
{
-
name: 'config',
-
type: 'list',
-
message: `是否需要切換內(nèi)部源:`,
-
choices: [
-
{
-
name: '需要',
-
value: 'npm',
-
short: ''
-
},
-
{
-
name: '不需要',
-
value: 'npm',
-
short: ''
-
}
-
]
-
}
-
]復(fù)制代碼
generator.js 這個(gè)模塊很簡(jiǎn)單，直接渲染模版
-
module.exports = (api, options, rootOptions) => {
-
// 復(fù)制并用 ejs 渲染 `./template` 內(nèi)所有的文件
-
api.render('./template')
-
}復(fù)制代碼
service插件主要放在項(xiàng)目本地，是一份js代碼，然后導(dǎo)出一個(gè)函數(shù)，通過package.json配置指向這個(gè)js文件的路徑，
service主要依賴的代碼在@vue/cli-service里，首先先執(zhí)行@vue/cli-service/bin/vue-cli-service.js文件，
-
const Service = require('../lib/Service')
-
const service = new Service(process.env.VUE_CLI_CONTEXT || process.cwd())
-
-
.....
-
-
service.run(command, args, rawArgv).catch(err => {
-
error(err)
-
process.exit(1)
-
})復(fù)制代碼
該文件實(shí)例化Service類，這個(gè)類是service插件的核心類，然后再執(zhí)行run方法。
再來看看@vue/cli-service/lib/Service.js的代碼：
首先構(gòu)造函數(shù)執(zhí)行resolvePlugin，把官方提供的插件和項(xiàng)目里的插件都加載進(jìn)來，
-
constructor (context, { plugins, pkg, inlineOptions, useBuiltIn } = {}) {
-
this.plugins = this.resolvePlugins(plugins, useBuiltIn)
-
}復(fù)制代碼
resolvePlugin這個(gè)函數(shù)主要在這里引入本地的插件：
-
resolvePlugins (inlinePlugins, useBuiltIn) {
-
// Local plugins
-
if (this.pkg.vuePlugins && this.pkg.vuePlugins.service) {
-
const files = this.pkg.vuePlugins.service
-
if (!Array.isArray(files)) {
-
throw new Error(`Invalid type for option 'vuePlugins.service', expected 'array' but got ${typeof files}.`)
-
}
-
plugins = plugins.concat(files.map(file => ({
-
id: `local:${file}`,
-
apply: loadModule(file, this.pkgContext)
-
})))
-
}
-
-
return plugins
-
}復(fù)制代碼
run方法又會(huì)執(zhí)行init方法，在該方法內(nèi)部執(zhí)行插件：
-
init (mode = process.env.VUE_CLI_MODE) {
-
// apply plugins.
-
this.plugins.forEach(({ id, apply }) => {
-
apply(new PluginAPI(id, this), this.projectOptions)
-
}
-
}復(fù)制代碼
那么service插件要如何來實(shí)踐，我們來看如下的例子：
首先在package.json配置一下，指向本地的插件my-service.js
-
"vuePlugins": {
-
"service": [
-
"my-service.js"
-
]
-
}復(fù)制代碼
my-service.js的代碼如下所示：
-
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
-
const webpack = require('webpack');
-
-
module.exports = (api, projectOptions) => {
-
api.registerCommand(
-
'analyze',
-
{
-
description: 'start analyze server',
-
},
-
(args) => {
-
// 注冊(cè) `vue-cli-service analyze`
-
let options = projectOptions.pluginOptions.demoOptions
-
console.log(options);
-
// resolve webpack config
-
const webpackConfig = api.resolveWebpackConfig();
-
webpackConfig.plugins.push(new BundleAnalyzerPlugin());
-
-
-
webpack(webpackConfig,(err,stats)=>{
-
if(!err) console.log('打包成功')
-
})
-
},
-
);
-
};復(fù)制代碼
該插件主要擴(kuò)展vue-cli-service的指令，加了analyze指令，這個(gè)指令主要會(huì)向webpack的配置增加一個(gè)BundleAnalyzerPlugin的插件，用來分析包的大小，當(dāng)然，這里也是沒有太大的現(xiàn)實(shí)可行性的，vue-cli 提供了vue ui的Gui界面讓你看到打包后各個(gè)模塊的大小，或者cli的命令，vue-cli-service build --report，也能生一個(gè)報(bào)告，效果也是一樣。
至此，vue-cli和service插件的使用和實(shí)現(xiàn)都介紹完了，如果有哪里寫的不到位，希望各位大神能提出指正
藍(lán)藍(lán)設(shè)計(jì)的小編 http://m.yvirxh.cn
<nobr id="qyle9"></nobr>