我們總在期待 Next Big Thing，企盼下一次數(shù)字革命。喊了這么多年的物聯(lián)網(wǎng)現(xiàn)在還沒有明顯起來的跡象，而 VR 也因為頭戴設(shè)備的大型化和沉浸式場景的泛用性較差的原因，反倒是 AR 和 MR 依托智能手機、浴霸式鏡頭組和 APP 有一定起色，但是也沒有到革命性改變的程度，只能算是一個小趨勢。當然，人工智能/深度學習所帶來的影響更加深遠，但是短時間以內(nèi)，它所帶來的變化趨近于隱形。
而最近2年，各種雙屏和柔性屏的發(fā)布，則可能是距離我們最近的硬件變革，可能和柔性屏/雙屏設(shè)備有關(guān)。
也許現(xiàn)在說硬件交互設(shè)計到了類似 2007 年 iPhone 發(fā)布一樣拐點有點夸張，但是對于現(xiàn)在幾乎純粹拼配置死水微瀾一樣的手機電腦市場而言，這種明顯區(qū)別于以往的硬件設(shè)計，將會直接帶來交互、設(shè)計和體驗上的改變。
2019年是否算得上是雙屏設(shè)備元年，現(xiàn)在下結(jié)論為時過早，但是去年三星 Galaxy Fold 和 Moto Razr 的發(fā)布，確實給廣大硬件廠商好好打了一個樣。
盡管Galaxy Fold 去年折戟沉沙了，但是高昂的沉沒成本和大勢所趨讓三星肯定不能就這么算了， 回爐再造一番之后今年又帶著船薪版本的 Galaxy Fold 2 殺將回來，順帶還兼顧女性市場整了一個對標 Moto Razr 的化妝盒手機 Galaxy Z flip。
圖片來自 TheVerge
當然，華為的 Mate Xs 也是相當優(yōu)秀的產(chǎn)品，這款明顯對標三星 Galaxy Fold 2 的產(chǎn)品，并沒有將柔性屏制作成為向內(nèi)折疊，而是完全翻過來，將它作為外屏來進行設(shè)計，反向折疊，展開的時候，屏幕自然延展。
圖片來自 TheVerge
不過思路最為清奇的并非是華為，而是 TCL。就在這幾天，TCL 帶來了兩款全新的原型機，一款手機帶有兩個折疊軸，相當于是將傳統(tǒng)手機屏幕延展到以往的3倍，徹底折疊開相當于是一個 10英寸的平板電腦（回過頭來想，就像是將一個平板電腦反向折疊到手機的大小，但是重量不變……）。
圖片來自 TheVerge
另外一款原型機則選擇了抽拉式的設(shè)計，機身可以如同抽屜一樣拉開，柔軟的屏幕會被拉出，延展開來差不多和 iPad Mini 一個大小了。
圖片來自 TheVerge
圖片來自Engadget
除了這幾款之外，在今年年初的 CES 消費電子展上，聯(lián)想、戴爾、華碩，這些目前世界上最大的消費電子制造商，紛紛帶來了各自的折疊屏和雙屏設(shè)備。
聯(lián)想帶來的 ThinkPad X1 Fold，是一個價格昂貴的柔性折疊屏平板電腦，它額外附帶了一個藍牙鍵盤。
圖片來自 TheVerge
考慮到聯(lián)想在此之前已經(jīng)發(fā)布過帶有LEC+墨水屏的雙屏設(shè)備 Yoga Book 2，可以說聯(lián)想是已經(jīng)具備了制造兩種不同類型屏幕設(shè)備的能力。
作為對手的戴爾，帶來了分別對標聯(lián)想這兩個系列的對應產(chǎn)品：Concept Ori 和 Concept Duet。
Concept Ori 采用的是兩塊傳統(tǒng)硬屏，你既可以讓一款屏幕作為屏幕，另一塊作為虛擬輸入鍵盤或者手繪板，也可以使用配備的藍牙鍵盤，吸附在底下的屏幕上來進行輸入，而且當鍵盤移動到靠近轉(zhuǎn)軸的地方，還能讓底下露出的半塊屏幕作為觸控板來使用：
圖片來自 TheVerge
Concept Duet 在概念上則和 聯(lián)想的 ThinkPad X1 Fold 類似，一塊柔性可折疊的屏幕，便于收納，一體連接。
圖片來自 TheVerge
看了這么多硬件，是不是覺得信息量有點大？不過簡單來說，所有的這些產(chǎn)品，都在說一件事情：屏幕要延展開，這是一個正在發(fā)生的趨勢。
同時，我們還注意到一個很明顯的特征，就是所有的這些柔性屏設(shè)備都非常的……騷，且貴。動輒兩三千美元的起步價，如果可靠堅挺也就算了，不僅轉(zhuǎn)軸易損，且屏幕也存在易損的問題。根據(jù) ifanr 的上手評測，即使是在優(yōu)化了轉(zhuǎn)軸和屏幕折疊角度之后，三星所發(fā)布的 Galaxy Z Flip 的屏幕中段依然有著不可忽視的折痕，這一問題可能會是絕大多數(shù)折疊柔性屏設(shè)備的通病。
圖片來自愛范兒
與之相反，采用硬質(zhì)雙屏設(shè)計的硬件設(shè)備，從生產(chǎn)成本、工藝成熟度、價格上，都更加有優(yōu)勢。
值得注意的是，柔性折疊屏和硬質(zhì)雙屏設(shè)備，在基本的使用體驗和邏輯上是一致的，除了極少數(shù)特殊的設(shè)備之外（比如 TCL的雙折疊式的概念機），多數(shù)情況下，兩者是差不多的。
只不過存在一個問題，雙屏設(shè)備的交互和體驗，需要有對應操作系統(tǒng)支持，因為從單屏到雙屏，其實交互邏輯已經(jīng)發(fā)生了巨大的改變。
一直在創(chuàng)新且「穩(wěn)健」地更新軟硬件的蘋果公司，應該不會在市場未曾成熟的情況下選擇發(fā)布硬件，這意味著你不會很快看到雙屏 iOS 硬件，而面向著大量 OEM 廠商的 Android 和 Windows 則截然不同。著兩年廠商已經(jīng)身體力行證明了一件事情：只要操作系統(tǒng)和設(shè)計跟上，硬件馬上量產(chǎn)不是問題。
最近泄漏的 Android 11 的新特性已經(jīng)出現(xiàn)了可折疊屏幕的影子，但是具體情況恐怕要到因為疫情跳票的 Google I/O 大會上會揭曉答案。但是另一邊，賊心不死的微軟，已經(jīng)開始布局面向可雙屏設(shè)備的新一代操作系統(tǒng) Windows 10X了。
圖片來自 TheVerge
去年微軟發(fā)布的兩款雙屏設(shè)備 Surface Duo 和 Surface Neo 并不都是采用尚未發(fā)布的 Windows 10X 操作系統(tǒng)，但是兩者都沿用了幾乎相同的交互邏輯，較小的 Neo 采用的是 Android 操作系統(tǒng)。這兩款硬件和系統(tǒng)交互設(shè)計，將會在未來一段時間以內(nèi)，成為雙屏硬件的軟件交互的重要參考和主要標桿，聯(lián)想和戴爾這波 OEM 廠商，無疑是參考著微軟的風向標來搞硬件產(chǎn)品的。
圖片來自 TheVerge
傳統(tǒng)而臃腫的「開始」菜單欄在 Windows 10X 當中，被精簡為我們更熟悉的模式，新的 Windows 10X 在原有的 Windows 10 的基礎(chǔ)上，應該有對移動端（比如 ARM 架構(gòu)的CPU）和小屏幕有更好的支持。
但是，更有價值的，是微軟為雙屏設(shè)備所制定的交互設(shè)計規(guī)范。
下面是基于微軟官方文檔，精簡編譯后的規(guī)范：
雙屏交互概述
雙屏設(shè)備可以基于不同的工業(yè)設(shè)計，有多種硬件樣式。微軟發(fā)布的 Surface Neo 和 Surface Duo 可以作為典型的雙屏設(shè)備作為參考。雙屏本身可以借由鉸鏈、轉(zhuǎn)軸來連接，也可以基于柔性屏來實現(xiàn)。
所有的雙屏設(shè)備都具備有折疊、旋轉(zhuǎn)、翻轉(zhuǎn)的功能，兩塊屏幕都可以用來作為顯示，也可以一個做屏幕一個承載虛擬鍵盤，當然也可以借由外設(shè)，構(gòu)建、組合成為新的模式。所以，為這樣的硬件設(shè)計的時候，需要考慮到各種不同的情況，并且適配硬件，幫助用戶實現(xiàn)更多的目標。
:no_upscale()/cdn.vox-cdn.com/uploads/chorus_asset/file/19247637/akrales_190930_3649_0139.jpg)
圖片來自 TheVerge
當用戶打開應用的時候，它的主要界面窗口應該最大化，占據(jù)一塊屏幕的全寬和全高。這樣用戶可以一次打開多個不同的應用，顯示在雙屏上。
圖片來自 TheVerge
當然，你的APP 也可以完整鋪滿兩個屏幕，這個界面布局被稱為「跨屏布局」。在默認情況下，它應該像在大屏幕上一樣，一個窗口跨屏幕顯示。但是你可以修改這種模式，讓它可以鋪滿兩個屏幕的同時，還可以兼顧到中間有轉(zhuǎn)軸和鉸鏈的硬件。對于這個問題，我們隨后有詳細的討論。
響應式布局
比起傳統(tǒng)的響應式布局，對于雙屏硬件，我們要討論的「響應」模式要復雜得多。就像下面這張圖中所說的，要為這樣多樣、復雜的情況進行設(shè)計：
我們默認用戶在多數(shù)時候，是處于雙屏展開的狀態(tài)，當用戶打開 APP 的時候，它的主要界面窗口，將會最大化占據(jù)一個屏幕，這個時候另一個屏幕處于空置狀態(tài)，用戶可以在這個屏幕上打開另外的應用，并且用戶可以通過托拽窗口的方式，來重新整理窗口和APP的排布模式。
同時，單個應用程序也應該可以進行跨屏布局，既可以讓單個應用分別在兩塊屏幕上各呈現(xiàn)一個窗口，也可以作為單個窗口完整鋪滿兩塊屏幕。不論是充分利用接縫的存在，還是說盡可能地利用全部屏幕區(qū)域來聚焦單個內(nèi)容，應用程序應該都可以做到。當然，這些情況我們隨后會單獨說到。
首先，作為一個已有的應用程序，在雙屏設(shè)備上應該能夠繼承原有的功能，并且盡可能地兼容雙屏的體驗。在開始討論如何為雙屏場景進行設(shè)計應用之前，我們先應該對雙屏交互進行介紹。
雙屏的響應式布局
首先，無論屏幕尺寸如何，方向如何，應用程序應該都可以保持良好的外觀，善用 UI 平臺的現(xiàn)有的布局技術(shù)，通過合理地縮放來自適應，填滿屏幕。如果你的屏幕元素依賴屏幕長寬比，那么應該善用平臺給的 API 來進行靈活的優(yōu)化。
考慮到你的應用將會在很多不同尺寸、不同長寬比、不同類型的設(shè)備上運行，所以你的應用程序應該足以應對各種不同的情況。請記住，你的設(shè)計將會遭遇和以往截然不同的屏幕尺寸和長寬比，比如縱向（全景視圖）、橫向（較寬的全景視圖）、縱向雙屏分別顯示等不同情況。
考慮所有的屏幕方向
用戶在很多平臺上有習慣的、常見的屏幕方向，比如在 Android 和 iOS 上，通常應用是豎屏顯示的，在 Windows 上，多數(shù)情況下是橫向全屏顯示的。而在雙屏設(shè)備上，這種情況會發(fā)生改變。
比如你的應用原本是為豎屏設(shè)計的，但是需要經(jīng)常輸入內(nèi)容，那么你要考慮到雙屏設(shè)備上，你的應用可能是會被橫屏顯示，用戶會像用筆記本電腦那樣來使用應用，也就是說兩塊屏幕都橫向顯示，靠下平攤在桌面的屏幕會顯示虛擬鍵盤或者手寫區(qū)域，作為輸入窗口，而顯示窗口也是橫向的。
雙屏為多任務(wù)提供更好的顯示環(huán)境，你不會知道用戶會在什么樣的場合，以什么樣的姿勢來握持設(shè)備，但是考慮潛在的使用姿態(tài)，可以讓你更好得對應用進行設(shè)計和優(yōu)化。
根據(jù)我們的研究，如果你的應用是注重輸入的應用，那么用戶在平面上打字和輸入將會是最舒服也最常見的姿勢。那么在這種情況下，你應該針對橫屏顯示進行針對性的優(yōu)化。
支持多種輸入模式
對于新的雙屏設(shè)備，通常都支持多種輸入模式，包括打字輸入，屏幕觸摸和手寫筆這樣的截至。這意味著用戶可以靈活地根據(jù)需求，選擇不同的姿勢和輸入模式，并且快速切換，以適應不同的需求。
換句話來說，就是你在設(shè)計的時候，需要支持所有的輸入方式，以便用戶可以自由選擇交互模式。
托拽交互
你的應用應該支持屏幕托拽，這不僅是為了兼容雙屏設(shè)備，而是對于絕大多數(shù)的設(shè)備的使用情況而進行兼容，確保用戶體驗的一致和靈活。只不過相比于在屏幕單屏上進行托拽移動，在雙屏上托拽移動，將會帶來更多的可能性，并且這樣也將會在雙屏使用場景之下，最為重要的交互模式之一。
為了確保托拽操作的自然，你需要確保諸如文本、圖像、視頻等常見的交互對象和元素，可以在任何地方進行剪切、復制、粘貼，并且對于共享和放松之類的操作也啟用托拽操作，這將最大化地利用雙屏的優(yōu)勢。
應用的多屏呈現(xiàn)
用戶會希望在兩塊屏幕上并排顯示同一應用中的不同內(nèi)容，因此你的你用應該支持多實例呈現(xiàn)和運行。
多媒體內(nèi)容畫中畫體驗
如果你的應用是一個多媒體應用，那么應該支持畫中畫模式，用戶可以邊看視頻邊執(zhí)行別的操作。
上面提及的很多功能屬于基礎(chǔ)應用要求，并不是專門針對雙屏設(shè)備而做，但是如果你的應用支持上面的功能，那么在雙屏上將會明顯擁有更好的用戶體驗。接下來，我們著重聊一下在雙屏設(shè)備上進行設(shè)計的問題。
在雙屏設(shè)備上，你的應用應當支持在單個屏幕上運行，也可以在雙屏上運行，當一個應用在兩個屏幕上顯示的時候，我們稱之為「跨屏」，而跨屏顯示這個問題對于雙屏設(shè)備而言，是至關(guān)重要的，如何顯示將會帶來巨大的影響。這種獨特交互模式可能會解鎖前所未有的使用方法。比如，有轉(zhuǎn)軸和接縫的雙屏設(shè)備，因為屏幕的特征而非常適合分隔并行式的生產(chǎn)力解決方案。
跨屏是用戶的選擇
用戶有選擇如何使用應用的方式的權(quán)力，包括何時跨屏顯示。某些應用可能在單屏或者跨屏顯示的時候，看起來不夠好看，但是如何使用的權(quán)力，應該交給用戶去選擇。
盡管本文會針對如何處理多屏布局提供幾種不同的方案和想法，但是請選擇適合你的用戶和應用的呈現(xiàn)方式。
考慮用戶意圖和設(shè)備方向
當你的兩個屏幕都被利用起來的時候（橫向雙屏，縱向雙屏），了解用戶的意圖至關(guān)重要。盡管還有更多的調(diào)研需要做，但是結(jié)合我們目前已有的觀察，可以得出如下的趨勢：
在為雙屏設(shè)備設(shè)計應用的時候，有四種常見的布局方案是你需要考慮的。通常這取決于應用是單屏還是跨屏，是默認視圖還是全屏視圖：
1、單屏默認模式
2、跨屏默認模式
3、單屏全屏模式
4、跨屏全屏模式
當單個應用以單個窗口運行，并且跨越兩個屏幕的時候，跨屏布局就出現(xiàn)了。如果你原有的應用從未針對雙屏設(shè)備進行優(yōu)化的話，那么系統(tǒng)會提示你「應用將會擴展并占據(jù)所有屏幕」，并且這個時候，應用界面會自行調(diào)整大小，適應新的尺寸。
這種情況下，界面中間的接縫會顯得非常明顯。這是雙屏設(shè)備先天的副產(chǎn)物。要如何優(yōu)雅地處理接縫？這就是下面這節(jié)內(nèi)容將會探討的問題，我們將會提供一些常見的處理方案yi。
是否總是要適應接縫？
如果你的應用不作任何優(yōu)化就直接在雙屏設(shè)備上投放使用，接縫并不總會給用戶體驗帶來影響。比如地圖類應用，用戶可以隨意移動地圖內(nèi)容，接縫帶來的割裂并不會對使用體驗造成實質(zhì)性的影響。在后面「擴展畫布」這一節(jié)，將會對這個問題進行深入討論。
但是對于另外一部分應用，接縫帶來的問題就非常嚴重了。比如在一個表格類應用當中，如果不作修改和調(diào)整，有的內(nèi)容會直接被接縫給割裂開，你必須進行滾動才能正常查看。而對于某些相對更加固定無法移動的元素而言，接縫帶來的體驗是破壞性的。而這個時候，我們需要使用一些技術(shù)方案來處理這個問題。
規(guī)避接縫
將元素移到一邊
由于兩塊屏幕之間有明顯的接縫，因此當用戶在使用應用的時候，某些 UI 元素可能會正好被穿過接縫，邏輯上這不會影響功能，但是如果將這些 UI 元素移動到屏幕的一邊來顯示，會提供更好的體驗。最好避免在接縫處顯示文本內(nèi)容，這會影響可讀性。
應用程序?qū)υ捒驊撘频狡聊坏囊贿?，尤其是需要點擊按鈕操作的時候。
底部菜單應該移動到屏幕一側(cè)，而不是延伸到兩個屏幕上。
用戶調(diào)用上下文菜單的時候，應該將接縫視作為屏幕邊界處理，尤其是在靠近屏幕邊緣的地方觸發(fā)菜單的時候。
應用內(nèi)的下拉菜單或者可擴展容器如果可能會跨越接縫的話，應該改變擴展方向。
當整個應用界面擴展開來的時候，應該整個移動到屏幕的上側(cè)，而不是在靠近中心的位置橫跨接縫。
貼合接縫
使用偶數(shù)列并和接縫對齊
當界面中使用網(wǎng)格布局的時候，垂直或者水平方向盡量使用偶數(shù)行或者偶數(shù)列，這樣可以讓接縫和界面間隙正好重合，用戶可以更加舒適地查看信息。
在網(wǎng)格中使用偶數(shù)列，尤其是對于容器、表單，并且考慮到接縫來控制間距。
除此之外，還有許多應用會考慮充分利用另外一個屏幕來顯示彈出菜單或者下級頁面的內(nèi)容。這種使用邏輯確實會讓應用更加易用，并且在視覺上會更加干凈清爽。但是請記住，如果彈出的界面并不是全屏的，可能會暗示它是可折疊和可關(guān)閉的，因此，你需要根據(jù)實際的設(shè)計需求，來靈活的處理呈現(xiàn)樣式。全覆蓋另外一屏的彈出界面，更加適合小尺寸屏幕。
重新排列 UI 元素
移動到接縫的任一側(cè)
還有一種用來優(yōu)化響應式布局的方法是，當屏幕方向或者大小發(fā)生變化的時候，重新排列你的內(nèi)容。這種方式讓你可以在兩個屏幕上隨意擴展你的內(nèi)容，你可以通過分組來重新排列，以更有目的的方式來適配屏幕和內(nèi)容。
遮罩和分割
對于一些無法重新排列的元素，比如全屏圖片和視頻，這個時候只能使用遮罩和分割的方式來處理。
遮罩的思路是，將接縫視作為一個遮罩元素，而圖片被它給遮擋了一部分，根據(jù)格式塔原理，我們的大腦會自動補足缺少的部分，遮罩遮罩處理方式適合處理多媒體（視頻，圖片等）這樣的畫布類型的場景，在這些場景下，保持圖像的連續(xù)性比顯示內(nèi)容的完整性更加重要。
分割的思路是將內(nèi)容均勻切割為兩個部分，完整呈現(xiàn)，這對于包含有多個控件和元素的普通界面而言，是更加合理的處理方式，包括可能會出現(xiàn)在屏幕中間的按鈕。
根據(jù)類型的不同，這兩種處理方式各有優(yōu)勢，我們將繼續(xù)跟進不同的用戶行為特征，來尋求更優(yōu)的解決方案。
文章來源：優(yōu)設(shè)
旅程映射創(chuàng)建了一個完整的體驗視圖，正是這一過程將不同的數(shù)據(jù)點聚集在一起并進行可視化處理，以了解產(chǎn)品需求，從而可以吸引各個群體中不感興趣的利益相關(guān)者，并促進協(xié)作性對話和變革。可通過揭示一系列交互過程中沮喪和愉悅的時刻來幫助了解客戶體驗，揭示了滿足客戶痛點，減輕分散性的機會，并最終通過暴露新機會提供附加價值而最終使產(chǎn)品脫穎而出。
如何使用旅程映射來了解與公司互動過程中的客戶行為，思維方式和情感動機。旅程映射在理解和優(yōu)化客戶體驗方面的實際應用，以及收集研究和從該研究中得出真實敘述的方法。
了解旅程圖何時是有用的設(shè)計工具，以及如何向擁有預算批準的客戶或團隊成員闡明該工具的優(yōu)點。如何使用成品傳達見解，與跨部門團隊成員互動以及如何通過發(fā)現(xiàn)激發(fā)變化。
旅程映射分為4條泳道：階段，動作，思想，心態(tài)/情緒。省略大多數(shù)流程細節(jié)，反映了用戶的思想，思考和情感。
旅程映射的價值：
客戶旅程圖的目標
將服務(wù)藍圖視為客戶旅程圖的第二部分。它們是旅程地圖的擴展，但它們不是專注于用戶（并從用戶的角度出發(fā)），而是專注于業(yè)務(wù)（并以其視角）。他們可以在特定客戶旅程中的各個接觸點上可視化不同服務(wù)組件（例如人員或流程）之間的關(guān)系?？蛻袈贸虉D之后，在進行組織或流程更改之前，內(nèi)部查明漏斗或斷點時使用服務(wù)藍圖。
客戶旅程地圖的目的是更好地了解最終用戶的旅程。這段旅程包括他們的思想和情感。相反，服務(wù)藍圖反映了組織的觀點，因此包括前期行動，后臺行動和支持流程。客戶旅程地圖的主要重點是了解有關(guān)最終用戶的更多信息，而服務(wù)藍圖的重點是記錄組織如何創(chuàng)建這種體驗。
制定有效旅程圖的五個步驟
界限
對于要創(chuàng)建多少個旅程圖沒有嚴格的規(guī)定。旅程映射作為一個過程是有益的，因為它在團隊成員之間建立了共同的愿景。通常，客戶旅程圖越集中，越好。在一種情況下，專注于一個角色的旅程圖講述了一個清晰的故事。
寬度與深度
確定旅程映射的范圍廣度，過程和范圍的不一致和含糊不清會導致失敗。
要素的平衡和重點
要素：角色，情境，動作，心態(tài)，情緒，接觸點，渠道，發(fā)現(xiàn)。滲透各個要素及以接觸點為重點從而發(fā)現(xiàn)機會點。
使用環(huán)境
明確使用環(huán)境，在如何的環(huán)境下使用，物理環(huán)境以及數(shù)字環(huán)境等。
接觸點和渠道
接觸點代表客戶與組織之間的特定交互。包括正在使用的設(shè)備，用于交互的通道及已完成的特定任務(wù)?？蛻袈贸逃梢幌盗薪佑|點組成，每個接觸點定義了特定交互的細節(jié)。地圖應使接觸點（地圖中的參與者實際與公司互動的時間）和渠道（通信或服務(wù)提供方法，例如網(wǎng)站或?qū)嶓w商店）與用戶目標和行動對齊。這些元素值得特別強調(diào)，因為它們經(jīng)常是發(fā)現(xiàn)品牌不一致和脫節(jié)的體驗的地方。
語境查詢
觀察用戶執(zhí)行任務(wù)時，您可以提出問題，從而可以澄清您的觀察并引發(fā)開放式對話。
任務(wù)分析
任務(wù)分析最常見的產(chǎn)出物就是那些對用戶為達成目標所采取步驟/行為的描繪。當我們把所有這些步驟都解析清楚了，就很容易發(fā)現(xiàn)用戶在哪些步驟中付出了額外的努力，哪些步驟是能夠直接去除以縮短操作流程的。
日記研究
由于客戶旅程會隨著時間的流逝并通過許多不同的渠道發(fā)生，因此日記研究是了解用戶隨時間推移的想法，感覺和動作的一種特別有用的方法。日記研究是一項長期研究：要求用戶記錄與特定目標相關(guān)的每項操作，以及他們在互動過程中的感受很多天，幾周或幾個月。由于參與者的行為，感受和想法盡可能接近實時地捕獲，因此消除了訪談所依賴的（容易出錯的）記憶。還在旅程的所有階段（而不是一個階段）從參與者那里獲取數(shù)據(jù)。日記研究的建立成本低廉，可以在進行其他類型的研究時在后臺運行。
定量支持
旅程地圖應該產(chǎn)生真實的敘述，而不是童話故事。從收集任何現(xiàn)有研究開始，需要其他基于旅程的研究來填補現(xiàn)有研究無法涵蓋的空白。這是一個定性研究過程。雖然定量數(shù)據(jù)可以幫助支持或驗證（或幫助說服可能將定性數(shù)據(jù)視為「模糊」的利益相關(guān)者），但僅憑定量數(shù)據(jù)無法建立故事。
旅程映射過程的整個重點是發(fā)現(xiàn)用戶體驗中的差距（這在全渠道旅程中尤為常見），然后采取行動來優(yōu)化體驗。洞察力和所有權(quán)是經(jīng)常被忽略的關(guān)鍵要素。從旅程映射中得出的任何見解都應明確列出?？梢詾槁贸痰貓D的不同部分分配所有權(quán)，以便清楚地知道誰負責客戶旅程的哪個方面。沒有所有權(quán)，沒有人有責任或權(quán)力去改變?nèi)魏螙|西。
文章來源：優(yōu)設(shè) 作者：Design Thinker
在這之前我得先提及一本書──《簡約至上：交互式設(shè)計四策略》。這本書基本算得上是交互設(shè)計的入門必讀書籍了，非常適合身處項目環(huán)節(jié)中上游的人員閱讀與學習。
作者 Giles Colborne 在書中提出了四個令交互設(shè)計成果最大化的簡易策略：合理刪除、分層組織、適時隱藏和巧妙轉(zhuǎn)移。這四個策略幾乎成為我設(shè)計與優(yōu)化每一個頁面時的自我指導方針。
我參閱了大量的應用，想總結(jié)出它們是如何運用導航欄來給產(chǎn)品賦能的。竟然很巧地發(fā)現(xiàn)，再花式的導航欄設(shè)計也難逃「四策略」手法。
首先，導航欄作為一個獨立控件，它本身就已經(jīng)是「分層組織」策略的一種表現(xiàn)形式。接下來我們來看看，優(yōu)秀的產(chǎn)品設(shè)計是如何運用另外三種策略來設(shè)計好導航欄的。
導航欄不能輕易刪除，但凡事沒有絕對。什么時候我們可以合理地刪除導航欄呢？
Nike Run Club（下文簡稱NRC）是耐克官方出品的一款跑步記錄 APP。既然做產(chǎn)品要站在用戶角度出發(fā)，那我們就來復原一下主要功能的用戶使用場景。
當你的老板要求你一天出 150 個界面設(shè)計的時候，你怕了，準備跑路，同時又不想浪費一天中任何一次記錄運動的機會。于是你打開 NRC，你的目的很明確：認真地跑路，并記錄運動。
點擊「開始」按鈕，當你一旦開始跑步，手機基本就不再使用了，直到跑步結(jié)束。
△ NRC在運動狀態(tài)下的界面刪除了導航欄
在用戶記錄跑步這樣一個單一事件中，NRC 知道你會專注運動，很少存在關(guān)注其他功能、瀏覽其他頁面的可能性。于是 NRC 可以很干脆地刪掉導航欄，而返回按鈕用了界面中的「結(jié)束」按鈕代替。
滴滴出行在呼叫快車時也做了刪除導航欄的處理。用戶一旦發(fā)單，開始呼叫司機時，呼叫頁面內(nèi)的所有操作都只聚集在界面下方的一個視覺區(qū)域內(nèi)。
△ 滴滴出行在呼叫過程中刪除了導航欄
上面兩個刪除導航欄的示例有什么共通點呢？
第一，用戶在當前頁面的事件狀態(tài)明確，不需要導航標題提醒用戶當前在什么位置，用戶也極少可能在當前頁面發(fā)生其他事件操作，于是完全可以去除導航標題與內(nèi)容控件。
第二，雖然刪除了返回按鈕，但都采用了很典型的「費茨定律」，就算用戶誤操作，也能便捷地撤銷正在發(fā)生的事件。反而這比循規(guī)蹈矩地運用導航欄來承載返回按鈕合理了許多。
△ 費茨定律簡易圖解
既然導航欄內(nèi)所有的規(guī)范元素都有可取代方案，為什么不刪除它呢？正如 Giles Colborne 在書中告訴我們的：大膽地刪除，但也不要極端到盲目刪除。
隱藏和刪除看起來十分相似，但其實不然。我們?nèi)绾螀^(qū)分這兩個技巧呢？
隱藏最常見的情況是，當導航欄的出現(xiàn)會成為打擾用戶沉浸體驗的障礙時，我們會選擇隱藏，例如看視頻、瀏覽圖片等顯示全屏媒體的場景，有導航欄反而會分散用戶的注意力。
△ 顯示全屏媒體時需要隱藏導航欄
不知道你有沒有發(fā)現(xiàn)到一個細節(jié)，在大多數(shù)情況下，需要沉浸體驗的頁面不但會隱藏導航欄，同時也會隱藏狀態(tài)欄，導航欄中載有當前頁面的標題、導航按鈕和內(nèi)容控件；狀態(tài)欄中會載有時間、Wi-Fi 等系統(tǒng)設(shè)備信息。
iOS 在人機交互指南中提醒我們，顯示全屏媒體時，請考慮暫時隱藏狀態(tài)欄，但請避免永久隱藏。如果沒有狀態(tài)欄，當用戶需要查看時間或其他設(shè)備信息時必須離開應用。設(shè)計師應該讓用戶可以使用簡單的手勢重新顯示隱藏的狀態(tài)欄。
△ 用戶可以方便地查看時間或其他設(shè)備信息
另一種情況是當前頁面非常注重一屏內(nèi)容展現(xiàn)時，我們會隱藏導航欄。
京東在用戶搜索了商品之后，頭部有三個信息欄，非常冗長。分別是：
△ 京東搜索商品后屏幕頭部的信息欄
用戶在搜索了商品之后，向上滑動頁面，京東會隱藏導航欄和全局篩選欄。
一是因為用戶搜索關(guān)鍵詞后，滑動頁面大概率表示已經(jīng)開始在挑選商品，這時候可以大膽地猜測用戶行為，認為搜索與排序的重要級下降了，搜索結(jié)果垂直內(nèi)容篩選的重要級上升了，便可以只保留下重要的操作。
二是可以讓內(nèi)容區(qū)域高度增加，隱藏頂部兩個欄目區(qū)域可以大致增加一個商品位的提前露出，增大了商品觸達用戶的可能性。這不就是 UI 設(shè)計為商業(yè)目標賦能的一個案例嗎？
△ 隱藏導航欄，增加了屏幕利用率
基于導航欄層級始終高于頁面內(nèi)容的特性，隨著用戶劃出第一屏，許多 APP 做了重要內(nèi)容或重要控件轉(zhuǎn)移到導航欄的設(shè)計。
豆瓣在影評討論區(qū)，用戶上滑頁面時，會將當前影片的信息轉(zhuǎn)移到導航欄。其實這種轉(zhuǎn)移很常見，許多內(nèi)容社區(qū) APP 都有這樣的交互設(shè)計，比如瀏覽的公眾號文章，再回到頂部試試。方便用戶時刻知道自己當前所瀏覽的內(nèi)容是關(guān)于哪一個主題的。這一類轉(zhuǎn)移是單純站在用戶體驗角度的考量。
△ 豆瓣在屏幕滾動后轉(zhuǎn)移影片信息到導航欄
但如果你仔細觀察，有一類轉(zhuǎn)移卻是綜合了用戶體驗與產(chǎn)品目標的共同抉擇。如果你再稍微了解一點該產(chǎn)品背后的故事，甚至可以讓你洞悉到，為了鞏固產(chǎn)品的調(diào)性和目標，PM 和 UI 們在頁面設(shè)計時做了多少細枝末節(jié)的引導。
知乎在用戶瀏覽當前問題時向上滑動頁面，也會像豆瓣一樣，將當前問題標題轉(zhuǎn)移到導航欄上，但與此同時會將「寫回答」的操作也轉(zhuǎn)移到導航欄。標題轉(zhuǎn)移是出于用戶體驗，和大多數(shù)內(nèi)容社區(qū)的做法大同小異；而「寫回答」的按鈕轉(zhuǎn)移，正符合知乎想要打造一個內(nèi)容交流社區(qū)的產(chǎn)品調(diào)性，他們希望刺激用戶進行問答互動，多輸出 UGC 內(nèi)容，希望用「寫回答」的按鈕轉(zhuǎn)移進一步激發(fā)用戶創(chuàng)作內(nèi)容的可能性。
△ 知乎轉(zhuǎn)移「寫回答」讓用戶更方便地進行問答互動
京東在店鋪首頁上滑頁面時，會將「關(guān)注」按鈕轉(zhuǎn)移到導航欄，方便用戶在瀏覽的過程中可以隨時收藏店鋪，增加了用戶對品牌店鋪的關(guān)注度和復購的可能性。京東靠自營模式發(fā)家，近幾年來開始慢慢重視 B2C 市場，在這個小小的關(guān)注按鈕上，是不是可以算略顯端倪呢？雖然我不能非?？隙?，可能提高用戶收藏操作只是為了輔助京東更好地進行營銷權(quán)重劃分，不過「關(guān)注」按鈕的轉(zhuǎn)移，確實能為 B2C 業(yè)務(wù)的滲透提供一份助力。
△ 京東轉(zhuǎn)移「關(guān)注」讓用戶更方便地收藏店鋪
所以我這里說到的「轉(zhuǎn)移」的目的，其實和 Giles Colborne 在書中講到的并不十分一致，Giles Colborne 是希望設(shè)計師將當前頁面低頻、冗雜的操作轉(zhuǎn)移到另一個頁面中去，而我提到的「轉(zhuǎn)移」反而是產(chǎn)品越注重什么功能，越可以利用導航欄層級的先天優(yōu)勢來實現(xiàn)轉(zhuǎn)移。
合理刪除、分層組織、適時隱藏和巧妙轉(zhuǎn)移已經(jīng)是我做設(shè)計和分析界面常用的一個手法，它并不一定是萬能的，但是它多多少少可以輔助我們做出更合理的設(shè)計。
這篇文章想要告訴大家的是，在平臺規(guī)范里的導航欄是死板又相對靜態(tài)的，但在四個策略的輔助下，結(jié)合用戶的操作手勢，也可以將它變得十分靈活，幫助頁面實現(xiàn)更好的用戶體驗。不要被規(guī)范限制的太死，轉(zhuǎn)換設(shè)計師的角色變成用戶，你可以研究出更多好玩的操作。隨便打開一個應用，去研究研究，你可能會樂在其中的。
文章來源：優(yōu)設(shè) 作者：UCD耍家
知名的免費圖標網(wǎng)站 Iconfinder 要和大家一起對抗新冠病毒，和圖標設(shè)計師聯(lián)手推出一系列「防疫免費圖標集」（Coronavirus awareness icons），超過 200 個與公共衛(wèi)生、病毒傳播相關(guān)圖標，這些圖案包括常見的 PNG 和 SVG 格式，可以將它們加入標志、海報、傳單或類似的內(nèi)容使用。
如果你想要制作廣告牌，提醒在這個區(qū)域要洗手或戴口罩，這里有免費圖標可讓信息更容易被閱讀。
依照 Iconfinder 網(wǎng)站說明，這些圖標可用于洗手說明、衛(wèi)生建議或是其他預防病毒傳染散播的提醒信息，所有圖標采用 Creative Commons BY-SA 3.0 授權(quán)釋出，使用時需要標示出處，并以相同方式分享。
網(wǎng)站鏈接：https://www.iconfinder.com/p/coronavirus-awareness-icons
值得一試的三個理由：
前往 Iconfider 的「Coronavirus awareness icons」網(wǎng)站，就能看到這套專為對抗新冠病毒提供的免費圖標集，點選 Download all icons 下載打包好的完整圖標。
在網(wǎng)站中展示一些收錄在這套圖標集的防疫相關(guān)圖案，每套圖案都有不同風格，例如以單純線條為主的設(shè)計，或是采用平面化設(shè)計的彩色圖標，可以依照自己的需求選擇。當然你也可以按下右上角的按鈕前往 Iconfinder 找到這套圖標的完整版本。
下載后就能取得完整的圖標集，依照不同名稱分類，有些是 SVG 格式，有些則包括 SVG 和不同大小的 PNG 文件，其中有個 iconfider_freebies.zip 在解壓縮后還能取得一些和防疫相關(guān)的圖標。
值得一試的三個理由：
文章來源：優(yōu)設(shè) 作者：Pseric
Persona，在國內(nèi)通常被稱為「用戶畫像」，其概念最初由 Alan Cooper 在 1999 年提出。由于用戶畫像具備幫助人們在設(shè)計過程中聚焦于目標用戶的需求，促進團隊中不同利益相關(guān)者的溝通等作用，而逐漸成為被廣泛使用的經(jīng)典設(shè)計工具。也正是由于其經(jīng)典地位，我們往往對用戶畫像在各類設(shè)計場景中的出現(xiàn)習以為常，卻很少去對這一工具進行反思。本文將基于用戶畫像的研究現(xiàn)狀，對其存在的問題與局限進行綜述和歸納。
Matthews 等學者為了探究設(shè)計師以及經(jīng)驗豐富的用戶體驗專家對用戶畫像的實際看法，從北美一家科技公司招募了 14 名設(shè)計師作為參與者。值得一提的是，這家公司擁有龐大且富有影響力的設(shè)計團隊，另外這 14 名參與者中，在設(shè)計領(lǐng)域有 10 年以上工作經(jīng)驗的人數(shù)過半。通過訪談的方式，Matthews 發(fā)現(xiàn)，大多數(shù)參與者在實際工作中都不會使用到用戶畫像，并分析了為何不用的 4 類原因。我將 Matthews 等原文中的 4 類原因歸納為以下 3 條。（下文中出現(xiàn)的 D1、M3、B1 等序號是參與者的編號）
1. 太過抽象
D1：如果你只向他們（指開發(fā)團隊）展示用戶畫像，他們是不會相信的。只有當他們看到用戶畫像背后有足夠的數(shù)據(jù)支撐，他們才可能相信。
其實，不止是設(shè)計師有這樣的看法，Basecamp（原37signals）的創(chuàng)始人 Jason Fried 在他的一篇博文里曾這樣說：它們（指用戶畫像）是模擬的、抽象的、虛構(gòu)的，我不認為你能為一個壓根不存在的人創(chuàng)造出優(yōu)秀的產(chǎn)品。
2. 缺少人情味
M3：我認為，有很多細節(jié)和微妙之處是無法通過對用戶畫像的描述而傳達的，我也不認為有人能像用戶畫像那樣思考或行事。坦白地說，我一直對用戶畫像以及它的用途充滿懷疑，我覺得它更像一個溝通工具。
缺少人情味的另一點在于：用戶畫像太過理想化。
B1：他們（指用戶畫像）描述了最為完美的用戶（對所設(shè)計的系統(tǒng)有著超乎尋常的熱情），以及最為匹配的情節(jié)。而真實的用戶并不像這樣，因此，用戶畫像并沒有很多作用。
3. 屬性無用，甚至有誤導作用
我們知道，一個用戶畫像在被創(chuàng)建的過程中，往往會被賦予若干個屬性，常見的基本屬性包括：年齡、職業(yè)、居住地等等。在訪談中，有些參與者表示，那些被賦予在用戶畫像身上的屬性沒什么用處。
A1：用戶畫像的數(shù)據(jù)完全沒有用。如果它是一個真實的人，我可能還會關(guān)注，但它本身不是一個真實的人，是那些添加在它身上的裝飾讓其看起來像真實的人，我覺得這是無用的。
還有一些參與者認為，用戶畫像身上的屬性和細節(jié)太過分散，導致偏離了本應關(guān)注的重點。
L1：在創(chuàng)建用戶畫像的過程中，我常常發(fā)現(xiàn)，那些原本次要的方面反而變得更加突出了。你會發(fā)現(xiàn)，那些與關(guān)鍵維度并非真正相關(guān)的細節(jié)，像技能、工作職責、對軟件和工具的熟悉程度，這些細節(jié)很容易提出，因為它們也同樣容易去溝通和理解。然而，隨之而來的代價是，把更為重要的細節(jié)給丟掉了。
1. 代表多少
Chapman 等學者指出，任何一個用戶畫像都僅僅只能代表潛在用戶群體中的某一小部分。那創(chuàng)建多個用戶畫像是否可行呢？可行是可行，但這又引出了一個新的問題：當用戶畫像的數(shù)量增多時，它的可記憶性是降低的，相應也降低了它在設(shè)計中起到的作用。多個用戶畫像往往存在著信息冗余的問題，過多的用戶畫像還會大大增加設(shè)計決策的成本。對于通過大數(shù)據(jù)自動生成的用戶畫像，數(shù)量過多這一問題尤為明顯：有時會產(chǎn)出成千上百個用戶畫像。
2. 屬性越多，涵蓋面越窄
既然用戶畫像所代表的是真實用戶，那么，它涵蓋的真實用戶數(shù)量能否通過某種方法預估出來呢？上文中我們提到的屬性（如年齡、職業(yè)、居住地等），為用戶數(shù)量的預估提供了可能?；谝陨蠁栴}，Chapman 等展開了定量分析的研究。他們一共選取了 8 個數(shù)據(jù)庫，其中 6 個是通過市場調(diào)研得出的真實用戶細分與特征數(shù)據(jù)庫，另外 2 個則通過多元數(shù)據(jù)模擬出來。然后，逐一地去增加用戶畫像的屬性數(shù)量，并依次與數(shù)據(jù)庫進行匹配。實驗的結(jié)果如下圖所示。不難發(fā)現(xiàn)：當用戶畫像被賦予的屬性增加時，它涵蓋的真實用戶比例是降低的；而屬性數(shù)量增加至 9 個以上后，各個數(shù)據(jù)庫的匹配率都很低。對此，Chapman 等的建議是在創(chuàng)建用戶畫像時，最好能對其涵蓋的用戶數(shù)量進行大致的評估，而不是簡單的假設(shè)。
△ 屬性越多，涵蓋面越窄
1. 偏低的投入產(chǎn)出比
前文中有提到，Matthews 等通過訪談去了解設(shè)計師對用戶畫像的看法，但這項研究還不足以觀察到設(shè)計師是如何將用戶畫像運用到實際工作中的?；谶@塊研究的缺失，學者 Friess 另辟蹊徑，從民族學的角度出發(fā)進行了探索。她采用的方法是：選取了一家位于美國的設(shè)計公司，對它其中一個團隊的設(shè)計決策過程進行全程地觀察與錄音。該設(shè)計團隊由 4 名核心成員組成，在設(shè)計決策開始前，其中 2 名團隊成員已經(jīng)花費了數(shù)周時間，通過調(diào)研創(chuàng)建了 8 個用戶畫像，并輸出了長達 20 頁的用戶畫像文檔，供團隊其他成員閱讀。Friess 對收集到的錄音片段進行話語分析后發(fā)現(xiàn)：在整個設(shè)計決策過程的話輪中，用戶畫像被提及的比例僅為 3% 左右。而且，在這為數(shù)不多的 3% 中，85.3% 的比例又是由那 2 名創(chuàng)建用戶畫像的成員提出。長達數(shù)周時間所創(chuàng)建的用戶畫像，換來設(shè)計決策過程中約為 3% 的提及率，這個投入產(chǎn)出比或許值得我們對用戶畫像的運用重新進行思考。
2. 過于主觀的代入
有這樣一種用戶畫像，它完全源于設(shè)計師對問題的主觀看法與偏見。更為通俗地講，是設(shè)計師先主觀地提出了設(shè)計概念，然后創(chuàng)建用戶畫像去支撐其概念，美其名曰「以用戶為中心」的設(shè)計。這種類型的用戶畫像由 Jones 等學者提出，他們稱其為「promotional personas」。Jones 等在伊利諾伊大學香檳分校教授設(shè)計類的課程，在長達 5 年的時間里，通過對學生們在課程所創(chuàng)建的用戶畫像進行觀察，他們對用戶畫像的幾種模式進行了歸類，而「promotional personas」就被歸在了「bad personas」這一類別中。Jones 等還舉出了一個他們在課程中觀察到的例子：有學生設(shè)計了一款鬧鐘，這款鬧鐘可以讓用戶以天為單位自定義規(guī)劃一整個月的鬧鈴時間。然后她做了一些調(diào)研，調(diào)研后發(fā)現(xiàn)身邊朋友們的作息都很規(guī)律，在時間管理工具上的使用頻次也較低，因此不太可能去用她所設(shè)計的那款鬧鐘。然而，她之后卻提出了一個與調(diào)研結(jié)果完全相反的用戶畫像，該用戶畫像每天醒來的時間都很不同，而且經(jīng)常由于睡過頭而錯過重要的事情。
設(shè)計師憑借自己的直覺與經(jīng)驗去創(chuàng)建用戶畫像這種方式，盡管也能在設(shè)計中起到一定作用，但如果將用戶畫像完全當做支撐主觀設(shè)計概念的工具，甚至不惜背離調(diào)研結(jié)果，用戶畫像就徹底地淪為一種形式了。這樣的用戶畫像，對整個設(shè)計過程都是有害無益的。
3. 無法取代真實用戶的參與
既然用戶畫像能作為真實用戶的代表，那么，對于參與式設(shè)計（participatory design）這種需要真實用戶直接參與的方式，用戶畫像是否能替代真實用戶呢？Bodker 等學者基于電子政務(wù)的項目，探究了用戶畫像對參與式設(shè)計是否有支撐作用。通過 4 個案例進行觀察，Bodker 等發(fā)現(xiàn)：盡管用戶畫像能促進設(shè)計師在實際的參與式設(shè)計開始之前去更多地聚焦于用戶，但在參與式設(shè)計的過程中，并不能讓設(shè)計師更貼近真實用戶的處境，反而可能分散設(shè)計師的注意力，讓其偏離對真實用戶參與情況的關(guān)注。這樣一來，也無法說明用戶畫像本身對參與式設(shè)計具有支撐作用。因此，如果要采用參與式設(shè)計，在條件允許的情況下，建議還是讓真實用戶參與其中，用戶畫像可能并不能取代真實用戶。
盡管上文總結(jié)和歸納了用戶畫像的種種問題與局限，但這些并不能否認用戶畫像作為一種工具，對設(shè)計過程所起到的幫助。問題和局限的提出，旨在幫助我們更多地去理解這一工具，細分它適合的設(shè)計場景，探索能否結(jié)合其他工具以彌補它的短板和不足，從而達到更好的使用效果。
文章來源：優(yōu)設(shè) 作者：陳夢蝶 驢媽媽UED
CSS 函數(shù)大家多多少少都使用過，比如 rgb() , rgba() , linear-gradient(), radial-gradient() , 等。
今天小編給大家介紹幾個特殊的 css 函數(shù)。
attr() 這是一個很強的函數(shù)，他可以讓數(shù)據(jù)傳輸?shù)侥愕?css 中，不需要借助其他東西。
用法：
<style>
div::before {
content : attr(data-abc);
}
</style>
<div data-abc='我是attr'></div>
calc() 用與動態(tài)計算長度值
給大家展示快速讓子盒子在父盒子中居中的另一種方法：
<style>
.father {
position: relative;
width: 300px;
height: 300px;
background-color: pink;
}
.child {
position: absolute;
/ 這里的 50px 為子盒子寬（高）的一半 /
top: calc(50% - 50px);
left: calc(50% - 50px);
width: 100px;
height: 100px;
background-color: blue;
}
</style>
<div class="father">
<div class="child"></div>
</div>
cubic-bezier() 定義了一個貝塞爾曲線(Cubic Bezier)。在這我就不多描述了，關(guān)于貝塞爾曲線，感興趣的同學可以自行去了解。
var() 用于插入自定義的 css 屬性值。
用法：和 sass，less 中定義變量的語法相似
<style>
:root {
--abc-- : red;
}
div {
width: 100px;
height: 100px;
background-color: var(--abc--);
}
</style>
<div></div>
counters() 這是一個古老但實用的屬性，用與 css 中計數(shù)
用法：
counter-reset : item 1；
給定計數(shù)器 item 的初始值1，也可用與復位。參數(shù) ‘item’ 為計數(shù)器的名稱，后面的 ‘1’ 參數(shù)如果不寫，默認是 0。
counter-increment: item 2;
設(shè)定當一個 item 計算器發(fā)生時計數(shù)器增加的值。參數(shù) ‘2’為每次計數(shù)增長 2。
counters(item,’-’);
寫在content中，顯示計數(shù)器的值，‘-’ 設(shè)定倆計算器拼接時中間的符號為’-‘。它還有第三個參數(shù)，是list-style-type , 與 css 屬性 list-style-type 是一模一樣的。用與設(shè)定計數(shù)器以什么形式顯示（阿拉伯數(shù)字，英文大小寫，等）
<style>
ul {
counter-reset: item 1;
}
li:before {
counter-increment: item 2;
content: counters(item, "-");
}
</style>
<ul class="test">
<li> html
<ul>
<li> css</li>
<li> js</li>
</ul>
</li>
<li> Node</li>
<li> ts</li>
</ul>
bootstrap-multiselect動態(tài)加載數(shù)據(jù)，首先要引用bootstrap-multiselect.css和bootstrap-multiselect.js
<select id="demo" name="demo" multiple></select>
JS代碼
$("#demo").multiselect({
// 自定義參數(shù)，按自己需求定義
nonSelectedText : '--請選擇--',
inheritClass : true,
maxHeight : 350,
includeSelectAllOption : true,
numberDisplayed : 5,
//下拉回調(diào)函數(shù)
onDropdownShow : function(event) {
$.ajax({
url : "${ctx}/xx/xx",
async : false,
type : "get",
dataType : "json",
success : function(data) {
var mark = new Array();
for (var i = 0; i < data.length; i++) {
mark.push({
value : data[i].markId,
label : data[i].markName
});
}
$("#demo").multiselect('dataprovider', mark);
}
})
},
});
獲取選中的值的集合
var selectList = $('#demo option:selected');
1
遍歷集合得到選中的value和label
for (var i = 0; i < selectList.length; i++) {
value = siteList[i].value;
label = siteList[i].label;
}
希望這篇文章可以幫助到你
一、首先找到第一次發(fā)起網(wǎng)絡(luò)請求的地址，將服務(wù)器返回set-cookie當全局變量存儲起來
wx.request({
......
success: function(res) {
console.log(res.header);
//set-cookie:PHPSESSID=ic4vj84aaavqgb800k82etisu0; path=/; domain=.fengkui.net
// 登錄成功，獲取第一次的sessionid,存儲起來
// 注意：Set-Cookie（開發(fā)者工具中調(diào)試全部小寫）（遠程調(diào)試和線上首字母大寫）
wx.setStorageSync("sessionid", res.header["Set-Cookie"]);
}
})
三、后臺獲取cookie中的PHPSESSID，將PHPSESSID當作session_id使用
<?php
// 判斷$_COOKIE['PHPSESSID']是否存在，存在則作session_id使用
if ($_COOKIE['PHPSESSID']) {
session_id($_COOKIE['PHPSESSID']);
}
session_start();
echo session_id();html5的新特點
1.語法更簡單
a) 頭部聲明
<!doctype html>
b) 簡化了字符集聲明
<meta charset="utf-8">
2.語法更寬松
a) 可以省略結(jié)束符的標簽
li、dt、dd、p、optgroup、option、tr、td、th
b) 可以完全省略的標簽
html、head、body
3.標簽語義化
增加了很多標簽，在作頁面的時候更加具有語義（定義了一些原本沒有語義的div模塊為有鮮明結(jié)構(gòu)的語義模塊）
a) <header>標記定義一個頁面或一個區(qū)域的頭部
b) <nav>標記定義導航鏈接
c) <article>標記定義一篇文章內(nèi)容
d) <section>標記定義網(wǎng)頁中一塊區(qū)域
e) <aside>標記定義頁面內(nèi)容部分的側(cè)邊欄
f) <footer>標記定義一個頁面或一個區(qū)域的底部
語義化標簽圖示
4.表單新增常用屬性------要求掌握
required：必填
placeholder：輸入內(nèi)容提示
autofocus：自動獲取焦點-----自動幫我們將光標點進去
<form method="post" action="http://www.baidu.com">
<!-- required 必填，必須的 -->
<!-- 自動獲取焦點----自動將光標定位到表單中 -->
<input type="text" placeholder="請輸入用戶名" autofocus="autofocus" required="required" />
<input type="submit" />
</form>
5.input新增type屬性值
a) type=“email”，文本框中只能輸入email地址
b) type=“date”，日期控件
c) type=“time”
d) type=“month”
e) type=“week”
f) type=“number”，喚醒數(shù)字鍵盤
g) type=“range”，滑塊
h) type=“color”
最近在做一個手機站，要求點擊分享可以直接打開微信分享出去。而不是jiathis，share分享這種的點擊出來二維碼。在網(wǎng)上看了很多，都說APP能喚起微信，手機網(wǎng)頁實現(xiàn)不了。也找了很多都不能直接喚起微信。
總結(jié)出來一個可以直接喚起微信的。適應手機qq瀏覽器和uc瀏覽器。
下面上代碼，把這些直接放到要轉(zhuǎn)發(fā)的頁面里就可以了：
html部分：
-
<script src="mshare.js"></script>//引進mshare.js
-
<button data-mshare="0">點擊彈出原生分享面板</button>
-
<button data-mshare="1">點擊觸發(fā)朋友圈分享</button>
-
<button data-mshare="2">點擊觸發(fā)發(fā)送給微信朋友</button>
js部分：
-
<script>
-
var mshare = new mShare({
-
title: 'Lorem ipsum dolor sit.',
-
url: 'http://m.ly.com',
-
desc: 'Lorem ipsum dolor sit amet, consectetur adipisicing elit. Quaerat inventore minima voluptates.',
-
img: 'http://placehold.it/150x150'
-
});
-
$('button').click(function () {
-
// 1 ==> 朋友圈 2 ==> 朋友 0 ==> 直接彈出原生
-
mshare.init(+$(this).data('mshare'));
-
});
-
</script>
下面是mshare.js的代碼分享，把這些代碼新建一個js文件放進去，然后在頁面中引進就ok了。
-
/**
-
* 此插件主要作用是在UC和QQ兩個主流瀏覽器
-
* 上面觸發(fā)微信分享到朋友圈或發(fā)送給朋友的功能
-
*/
-
'use strict';
-
var UA = navigator.appVersion;
-
-
/**
-
* 是否是 UC 瀏覽器
-
*/
-
var uc = UA.split('UCBrowser/').length > 1 ? 1 : 0;
-
-
/**
-
* 判斷 qq 瀏覽器
-
* 然而qq瀏覽器分高低版本
-
* 2 代表高版本
-
* 1 代表低版本
-
*/
-
var qq = UA.split('MQQBrowser/').length > 1 ? 2 : 0;
-
-
/**
-
* 是否是微信
-
*/
-
var wx = /micromessenger/i.test(UA);
-
-
/**
-
* 瀏覽器版本
-
*/
-
var qqVs = qq ? parseFloat(UA.split('MQQBrowser/')[1]) : 0;
-
var ucVs = uc ? parseFloat(UA.split('UCBrowser/')[1]) : 0;
-
-
/**
-
* 獲取操作系統(tǒng)信息 iPhone(1) Android(2)
-
*/
-
var os = (function () {
-
var ua = navigator.userAgent;
-
-
if (/iphone|ipod/i.test(ua)) {
-
return 1;
-
} else if (/android/i.test(ua)) {
-
return 2;
-
} else {
-
return 0;
-
}
-
}());
-
-
/**
-
* qq瀏覽器下面 是否加載好了相應的api文件
-
*/
-
var qqBridgeLoaded = false;
-
-
// 進一步細化版本和平臺判斷
-
if ((qq && qqVs < 5.4 && os == 1) || (qq && qqVs < 5.3 && os == 1)) {
-
qq = 0;
-
} else {
-
if (qq && qqVs < 5.4 && os == 2) {
-
qq = 1;
-
} else {
-
if (uc && ((ucVs < 10.2 && os == 1) || (ucVs < 9.7 && os == 2))) {
-
uc = 0;
-
}
-
}
-
}
-
/**
-
* qq瀏覽器下面 根據(jù)不同版本 加載對應的bridge
-
* @method loadqqApi
-
* @param {Function} cb 回調(diào)函數(shù)
-
*/
-
function loadqqApi(cb) {
-
// qq == 0
-
if (!qq) {
-
return cb && cb();
-
}
-
var script = document.createElement('script');
-
script.src = (+qq === 1) ? '//3gimg.qq.com/html5/js/qb.js' : '//jsapi.qq.com/get?api=app.share';
-
/**
-
* 需要等加載過 qq 的 bridge 腳本之后
-
* 再去初始化分享組件
-
*/
-
script.onload = function () {
-
cb && cb();
-
};
-
document.body.appendChild(script);
-
}
-
/**
-
* UC瀏覽器分享
-
* @method ucShare
-
*/
-
function ucShare(config) {
-
// ['title', 'content', 'url', 'platform', 'disablePlatform', 'source', 'htmlID']
-
// 關(guān)于platform
-
// ios: kWeixin || kWeixinFriend;
-
// android: WechatFriends || WechatTimeline
-
// uc 分享會直接使用截圖
-
var platform = '';
-
var shareInfo = null;
-
// 指定了分享類型
-
if (config.type) {
-
if (os == 2) {
-
platform = config.type == 1 ? 'WechatTimeline' : 'WechatFriends';
-
} else if (os == 1) {
-
platform = config.type == 1 ? 'kWeixinFriend' : 'kWeixin';
-
}
-
}
-
shareInfo = [config.title, config.desc, config.url, platform, '', '', ''];
-
// android
-
if (window.ucweb) {
-
ucweb.startRequest && ucweb.startRequest('shell.page_share', shareInfo);
-
return;
-
}
-
if (window.ucbrowser) {
-
ucbrowser.web_share && ucbrowser.web_share.apply(null, shareInfo);
-
return;
-
}
-
}
-
/**
-
* qq 瀏覽器分享函數(shù)
-
* @method qqShare
-
*/
-
function qqShare(config) {
-
var type = config.type;
-
//微信好友 1, 微信朋友圈 8
-
type = type ? ((type == 1) ? 8 : 1) : '';
-
var share = function () {
-
var shareInfo = {
-
'url': config.url,
-
'title': config.title,
-
'description': config.desc,
-
'img_url': config.img,
-
'img_title': config.title,
-
'to_app': type,
-
'cus_txt': ''
-
};
-
if (window.browser) {
-
browser.app && browser.app.share(shareInfo);
-
} else if (window.qb) {
-
qb.share && qb.share(shareInfo);
-
}
-
};
-
if (qqBridgeLoaded) {
-
share();
-
} else {
-
loadqqApi(share);
-
}
-
}
-
/**
-
* 對外暴露的接口函數(shù)
-
* @method mShare
-
* @param {Object} config 配置對象
-
*/
-
function mShare(config) {
-
this.config = config;
-
this.init = function (type) {
-
if (typeof type != 'undefined') this.config.type = type;
-
try {
-
if (uc) {
-
ucShare(this.config);
-
} else if (qq && !wx) {
-
qqShare(this.config);
-
}
-
} catch (e) {}
-
}
-
}
-
// 預加載 qq bridge
-
loadqqApi(function () {
-
qqBridgeLoaded = true;
-
});
-
if (typeof module === 'object' && module.exports) {
-
module.exports = mShare;
-
} else {
-
window.mShare = mShare;
-
}
好了，這樣就可以直接喚起微信進行分享啦
藍藍設(shè)計的小編 http://www.yvirxh.cn