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