如果說 npm 的大新聞，莫過于之前的 left-pad 撤包事件，event-stream 投毒事件，Ant Design 彩蛋事件。使得很多前端開發者又開始重新思考 npm 生態時候真的存在問題？



今天我們文章的主角是 memwatch，一個用來幫助我們檢查 Node.js 是否存在內存泄漏的庫，和這個庫傳奇的一生。



2012 年 02 月 06 日，一位 Mozilla 的工程師 lloyd 創建了這個庫，并寫了一篇博文“Is My NodeJS Program Leaking?”（我的 Node.js 程序是否存在內存泄漏？）。這個包最初被命名為 gcstats，代碼上傳到了 github。



6 月 27 日，npm 包改名為 memwatch，發布 0.1.1 版。



7 月 4 日，lloyd 為這個庫添加了開源許可協議：WTFPL，發布 0.1.2 版。很多人對這個開源許可協議可能比較陌生，WTFPL 的全稱是 Do What The Fuck You Want To Public License，中文譯名：你他媽的想干嘛就干嘛公共許可證。也許就是這份協議開啟了 memwatch 庫不尋常的一生。



2013 年 3 月 14 日，作者 lloyd 提交了最后一次代碼，發布了 0.2.2 版本。支持的 Node.js 版本為 0.6.0。隨后這個庫再也沒有更新過。



從作者的博文和推文可以看到，作者在 2014 年離開了 Mozilla。而從作者的 github 動態更可以看出，作者應該是轉入了 golang 陣營。



2014 年 6 月 28 日，作者的一位前同事 deepak1556 fork 了這個庫，增加了對 Node.js 0.11 的支持，并發起了合并請求。但是作者并沒有回復，也沒有合并此次請求。此時距離原作者放棄這個庫也已經過去一年多了。



2015 年 2 月 7 日，marcominetti 又 fork 了 deepak1556 的庫，增加了對 Node.js 0.12 的支持，并向原庫發起了合并請求，同樣沒有得到作者的任何回復。于是 marcominetti 決定自立門戶，于是將 memwatch 改名為 memwatch-next 發布到了 npm。



2017 年 1 月 27 日，如同前兩位維護者一樣，marcominetti 也最終放棄了繼續更新這個庫。到此時，此庫支持的 Node.js 版本為 4、5、6。



2018 年 5 月 6 日，eduardbcom 又 fork 了 marcominetti 的庫，增加了 Node.js 9 的支持，并且放棄了對 Node.js 9 以下所有版本的支持。改名為 node-memwatch 并發布到了 npm。隨后再也沒有更新過代碼。



2018 年 7 月 17 日，一位開發者 dyatko 又 fork 了 eduardbcom 的庫，增加了對 Node.js 8 的支持，并向原庫發起了合并請求，同樣沒有得到作者的任何回復。



但在此次 pr 的評論中，另一位開發者說，airbnb 也 fork 了 marcominetti 的庫，并改名為 @airbnb/node-memwatch 發布到了 npm。



有了大廠接手，也算是這個庫最終的歸宿吧。







相關閱讀



開發者對 npm 公司不滿，unpublish 了自己的所有模塊



月下載量千萬的 npm 包被黑客篡改，Vue 開發者可能正在遭受攻擊



駁《我不是很懂 Node.js 社區的 DRY 文化》



機器人偽裝成人類在 GitHub 上為開源項目修復 bug

兩列布局的幾種方法

html結構

 <div class="content">

      <div class="content-left">

        左側固定200px

      </div>

      <div class="content-right">

        右側自適應

      </div>

 </div>



1.通過float和margin-left

 / 清除瀏覽器默認邊距 /

      {

        margin: 0;

        padding: 0;

      }



      .content{

        overflow: hidden;

      }

      / 脫離文檔流 /

      .content-left {

        float: left;

        width: 200px;

        height: 200px;

        background: red;

      }



      .content-right {

        / 通過margin-left將左邊位置空出 /

        margin-left: 200px;

        background: blue;

        height: 200px;

      }



2.通過 position: absolute;絕對定位

 / 清除瀏覽器默認邊距 /

      {

        margin: 0;

        padding: 0;

      }



      .content {

        overflow: hidden;

        position: relative;

      }

      / 脫離文檔流 /

      .content-left {

        position: absolute;

        top: 0;

        left: 0;

        width: 200px;

        height: 200px;

        background: red;

      }



      .content-right {

        / 通過margin-left將左邊位置空出 /

        margin-left: 200px;

        background: blue;

        height: 200px;

      }



3.通過flex彈性布局

/ 清除瀏覽器默認邊距 /

      {

        margin: 0;

        padding: 0;

      }



      .content {

        overflow: hidden;

        display: flex;

      }

      .content-left {

          / 除了width: 200px;還可以flex-basis: 200px; /

        width: 200px;

        height: 200px;

        background: red;

      }



      .content-right {

          / flex:1;將剩余空間分給它 /

        flex: 1;

        background: blue;

        height: 200px;

      }



4.通過 display: table;表格布局

 / 清除瀏覽器默認邊距 /

      {

        margin: 0;

        padding: 0;

      }



      .content {

        overflow: hidden;

        display: table;

        / 必須給父級定寬不然自適應盒子沒定寬只會由內容撐開 /

        width: 100%;

      }

      .content-left {

        display: table-cell;

        width: 200px;

        height: 200px;

        background: red;

      }



      .content-right {

        display: table-cell;

        background: blue;

        height: 200px;

      }



5.通過inline-block和calc（）函數

 / 清除瀏覽器默認邊距 /

      {

        margin: 0;

        padding: 0;

      }



      .content {

        / 必須加font-size=0;把inline-block默認間距去掉，

        不過設置后里面文字不顯示了可以給里面塊設置font-size:20px;

        或者把兩個塊之間的換行刪掉也能去掉間距/

        font-size: 0;

        overflow: hidden;

      }

      .content-left {

        font-size: 20px;

        display: inline-block;

        width: 200px;

        height: 200px;

        background: red;

      }



      .content-right {

        font-size: 20px;

        display: inline-block;

        background: blue;

        height: 200px;

        / 注意calc里的運算符兩邊要有空格 /

        width: calc(100% - 200px);

      }



6.通過float和calc()函數，左右兩塊都要浮動

 / 清除瀏覽器默認邊距 /

      {

        margin: 0;

        padding: 0;

      }



      .content {

        overflow: hidden;

      }

      .content-left {

        float: left;

        width: 200px;

        height: 200px;

        background: red;

      }

      .content-right {

        float: left;

        background: blue;

        height: 200px;

        / 注意calc里的運算符兩邊要有空格 /

        width: calc(100% - 200px);

      }



7.使用grid布局

 / 清除瀏覽器默認邊距 /

      {

        margin: 0;

        padding: 0;

      }



      .content {

        overflow: hidden;

        display: grid;

        grid-template-columns: 200px 1fr;

        / grid布局也有列等高的默認效果。需要設置: align-items: start;。 /

        align-items: start;

      }

      .content-left {

        height: 200px;

        background: red;

        / grid布局還有一個值得注意的小地方和flex不同:在使用margin-left的時候，

        grid布局默認是box-sizing設置的盒寬度之間的位置。

        而flex則是使用兩個div的border或者padding外側之間的距離。 */

        box-sizing: border-box;

        grid-column: 1;

      }

      .content-right {

        background: blue;

        height: 200px;

        box-sizing: border-box;

        grid-column: 2;

      }

業內有很多人覺得手勢交互沒必要拿出來深究，覺得用戶使用產品的過程中，自然而然就會去使用拇指，進行手勢操作。但這種說法，就跟「用戶心理模型」類似。當然，對于用戶來說沒必要深究手勢交互，但作為設計師，如果不了解其背后的邏輯，那么就無法解決產品設計背后的一些問題。

所以我們今天，好好聊一聊手勢交互這件事。你會發現，原來你以往觀察或以為的設計問題，都是手勢交互在作祟。

手勢的意義

我們以前經常聽到「以用戶為中心做產品設計」這句話，意思是產品需依附于目標用戶的真實場景來設計。與此同時，其實還有一句話在提醒著交互設計師如何做產品設計，就是「以觸摸屏為中心做產品設計」。

為什么呢？因為用戶從始至終都是在跟觸摸屏做接觸，不管換了什么設備，他們都是要通過屏幕與產品進行交互的。

我們可以在這里思考一下手勢的意義。

手勢的出現改變了什么？可以回想一下 iPhone 4 發布的時候，當看到這樣一臺屏幕上沒有任何按鍵的設備，是不是會覺得不可思議？鍵盤，電話接聽按鍵等都消失不見了。

人們在使用 iPhone 這樣的產品時，不再需要去強行記憶任何固體按鍵。觸摸屏與手勢的結合，幫助我們隱藏不必要的元素，幫助用戶聚焦于內容，在有限的物理空間獲得更多的信息。

所以用戶通過觸摸屏與產品進行交互，跟通過鍵盤按鍵與屏幕進行交互是完全不同的。手勢交互更自然且更。

手勢操作對我們來說如此自然和直觀的主要原因是因為它們類似于與真實對象進行直接交互。譬如你用遙控器控制電視上的按鍵，需要通過上下左右這樣的操作來定位指示器，而觸摸屏直接就可以通過手指點擊內容進行操作。這是完全不同的概念。

綜上所述，我們能知道，手勢的三個要素：簡潔、易用、直觀。

所以我們通過一些常見的手勢行為，就可以在產品界面上很輕松的完成任務。

常見的手勢行為：

• 點擊：單指短暫觸摸表面；
• 雙擊：單指快速兩次觸摸表面（通常是縮放）；
• 拖動：沿表面移動而不會破壞接觸；
• 捏/展開：用兩根手指觸摸表面以移入（捏合）或移出（展開）；
• 按下：單指觸摸表面并按??；
• 滑動：快速手勢，不需要觸摸目標。

當然，我們經常也會遇到一些背離手勢交互的產品設計，雖然也是點擊、拖動等等，但操作起來總是不那么順心。這里面有一個關鍵點就是，手勢直觀性。

有數據表明，蘋果的 3D Touch 使用率非常低，就是因為直觀性太差，用戶不知道通過這個操作能帶來什么結果，且使用它需要長按，經常會同時呼出「卸載」，那么效率也就會降低。久而久之，用戶就不去使用了。

正面例子如下圖，滑動與文案結合。

這樣一看，用戶馬上就能知道這個操作行為如何觸發，緊接著就產生行動，然后會反饋結果。

這也是手勢交互的核心：觸發，行動，反饋。

對比 3D Touch，觸發沒有提示，行動后時常有兩種反饋結果，相比起來就不那么友好了。

除了上面聊的這些，手勢交互還能從另一方面來提升效率，就是拇指操作區域。

拇指驅動設計

我們都知道，現在手機屏幕越來越大，甚至比最早屏幕大了一倍以上。但是很多設計師并沒有轉換思維，跟進這個趨勢的變化。

這里給大家普及一個知識：大部分人誤以為，手指在屏幕上的熱區是永恒不變的，但其實手指熱區會根據設備的變大而縮小。因為手掌支撐設備的重心靠后走了，所以拇指操控屏幕的范圍也就變小了。如下圖。

結果是，手機屏幕變大，雙手持機的用戶變多，但依然還有 75％ 的用戶是使用拇指來觸摸屏幕的。因此，術語「拇指驅動設計」應運而生。

我們上面說到，在使用一些產品的時候，經常會遇到使用起來不順心的情況，然后說了「手勢直觀性」的概念。但這里，還有個更重要的原因，就是「拇指操作區域」。

拇指操作區域被分為三塊內容，分別是：易于觸達，難以觸達，以及介于兩者之間的區域。

看下圖。

所以在設計界面時，要注意界面的主要操作元素是否處于用戶易于觸達的范圍之內。

如果你仔細觀察并思考過，也會發現，iOS 的產品界面中，「返回」按鈕就位于「難以觸達」的區域。原因是產品人員本身也不想用戶返回或退出，而是讓用戶聚焦于當前頁面，想要返回，那就需要付出一點成本，什么成本？操作成本。

有人會說，由于 iOS 可以從手機的左邊緣向右側輕掃以獲得返回效果，因此在大多數 iOS 產品中，返回都不需要太大的操作成本。但是，并不是所有 iPhone 用戶都知道這一點，也不是所有產品都支持這一特性的。而且手勢交互的進化本來也就是為了提升用戶操作的效率，所以本質上他們并不矛盾，只是相比以前，我們現在的操作更快了。并且「右滑」返回，本身在手勢操作中相比「點擊」也是更具操作成本的。

當了解了手勢的一些意義，以及拇指操作區域對于產品設計的重要性之后，我們就可以通過一些案例來做一個全局分析了。

1. 內容在上，操作在下

許多人設計 App，但是沒人研究過 App 為什么要這么設計。

比如，為什么起初要把標簽欄放底下呢？關于這個問題，當初我也是問了許多人，而基本都只是說這是官方設計規范。這相當于是一句廢話。

通過翻閱多方資料，我發現在工業設計領域有一條重要的基本設計原則：內容在上，操作在下。

比如在使用電腦的時候，操作在下意味著使用者在操作過程中，手指始終處于界面下方，而內容在上面，就不會出現手指遮擋內容的情況。

如下圖的鍵盤操作提示：

基于此，相信你也知道為什么標簽欄在下方了吧？

另外，為什么 iOS 設計規范建議將「編輯」按鈕放置在界面右/左上方的位置呢？

界面右/左上角的位置對拇指來說顯然是不友好的。然而，這樣做的原因也是顯而易見的：編輯功能會讓數據發生變化。將這類控件放在難以操作的位置上（與左上角的返回是一個道理），就是一種防御性的設計策略，可以在一定程度上避免因為太容易產生誤操作而導致的破壞性的結果。

通過這一小段之前聊過的內容，你們會發現，手勢與拇指操作其實在驅動著產品設計。下面我們來聊個大的案例。

漢堡包菜單的消失解析

漢堡包菜單，也就是側邊欄導航，Facebook 早期測試顯示側邊欄導航讓用戶使用率降低了一半。

我們一起來看看市面上給出的三類說法。

1. 可見性太低

默認狀態下，用戶是看不見側邊欄的，除非點擊了側邊欄的彈出按鈕。所以這種情況下，里面的功能都是用戶腦袋里已知的，但很可能都想不起來。比如，現在你回想一下知乎底部 5 個標簽分別是什么？或者微信右上角「+」里面有哪些功能？是不是要想一會兒，才能記起來？甚至還是想不起來。

之前我在文章里寫過，用戶對于功能的使用一定是「所見即所得」，而不是「心向往之」。用戶只會注意自己看到的信息，而不是憑借記憶或想象來使用產品。

底部標簽欄就很好的解決了漢堡包菜單的「可見性」問題。

2. 效率較低

效率較低主要在于操作頻率，大家看下面兩組圖的對比。

第一張圖，當用戶從首頁進入到個人信息頁面，只需要兩步；而第二張圖，則要三步。

這里多一步看起來似乎影響不大，但如果現在要從個人信息頁面到「標簽 3」的話，第一張圖也只需要兩步，第二張圖還是需要三步，當頻繁去使用這樣的產品后，用戶的整體效率就會下降，體驗也會隨之降低。

3. 與平臺模式沖突

大家應該知道，在 iOS 的操作頁面中，通過手勢可對 tab 進行左右切換，而側邊欄除了通過點擊菜單按鈕展開之外，也可以通過右滑彈出。這里面有什么沖突呢？看下圖。

當頁面聚焦在「標簽 2」時，右滑除了能回到「標簽 1」，同樣也很可能會切出側邊導航欄。

這樣的手勢沖突，導致頁面層級與功能導航的優先級混亂了。

無論是導航還是控件，當它們組成一個頁面后，它們的操作就會有優先級。比如下面這個例子。

如果你對標紅的分段控件比較熟悉，就知道，它是可通過屏幕滑動進行切換的。但是在「短信」里，它是不能通過滑動屏幕進行切換的，因為用戶可對單條信息進行左滑做刪除或其他操作。所以當頁面操作模式存在矛盾時，我們會將子層級操作優先于父層級操作。

譬如你進入朋友圈，是不能馬上回到首頁的，這時候頁面層級較深，產品人員要將用戶聚焦于頁面本身，如果直接能返回到首頁，頁面層級和產品架構就會混亂。

類似的例子還有很多，我這里就不繼續列舉了。

所以從「短信」的例子可以看出，當控件與控件之間的手勢發生沖突時，我們要考慮優先級，將內容優先于頁面來處理。那么回到上面的例子，分段控件與漢堡包菜單的手勢發生沖突時，很明顯我們要優先分段控件的操作，而禁止掉漢堡包菜單的右滑手勢。結果就是，效率又低了。

4. 小結

這三類，如果你認真思考里面的關系，其實就會發現，它們的共通點就是與拇指的聯系過于被動或直接被切斷了。

• 第一個「可見性太低」的例子，菜單被隱藏，拇指不能直接與菜單產生關系，并且距離過遠，拇指難以觸達。
• 第二個「效率太低」的例子，用戶需要通過拇指來回操作，導致效率降低，這就跟使用遙控器控制電視機一樣，用戶無法直接觸達內容。
• 第三個「手勢沖突」的例子，其實就很清晰了，就是說標簽欄的優先級可能會被頁面的其它控件所取代，那么拇指就無法直接對其產生作用，從而禁止當前頁面的手勢交互行為。

它們的核心點就是拇指與觸摸屏的關系。

如果你現在還不能深刻理解漢堡包菜單的劣勢，那就想一下去看一下現在的產品，其中「我的」、「個人中心」或「更多」其實都是變相的漢堡包菜單。

在「我」這個標簽頁里，這一系列功能列表，無非就是另一種模式的漢堡包菜單，只是這里呈現的都是不重要的功能，并不影響用戶使用這個產品。回想一下，你是不是很少，甚至從來沒用過這里的某幾個功能？再跟手勢結合，就會發現，「我」所處區域并不是容易點擊的區域，這就是它效率低下的原因了。現在能懂了么？

彈框的操作路徑

當傳統的確認彈窗逐漸被手勢操作取代，大家就應該察覺到：以往從電腦遷移到移動設備上的交互行為已逐漸被改善。

我曾經寫過一篇文章，叫「取消按鈕的設計邏輯」，講了「左取消，右行進」這個原理。意思就是當我們在設計彈框的時候，用戶已經習慣這樣的操作路徑，所以不要輕易更換位置以混淆用戶的認知。再從手勢的角度來說，就是右邊更容易點擊。

后來有同學說到，但是有些特殊場景，譬如刪除資料，而產品人員不希望用戶刪除，于是把刪除放在左邊，取消放在右邊。畢竟右邊更容易點擊，所以位置換了會比較合理。

這是錯的！

我們不能通過改變用戶使用產品的常識來將產品人員的想法置于用戶之上。當用戶已經形成「左取消，右行進」的認知之后，違反這樣的一致性，去換位置是很危險的。所以出現了 action sheet，來解決一些產品關于 alert 無法解決的問題。

如圖。

大家要記住的是，當頁面邏輯與手勢操作產生邏輯沖突時，我們不是去否定以前已經被驗證且正確的內容，而是通過創新，來解決這個沖突。這就是拇指驅動設計的一種方式。

包括我們以前在移動設備上選擇刪除某項數據，都會彈出警告框，詢問我們是否確認刪除。這種方式會打斷我們的操作行為，久而久之，用戶已經對此交互方式習以為常，或者說免疫了，但這種彈框的方式始終被認為是不好的一種交互手段。所以側滑刪除，已經被更多產品功能用來取代沒必要彈框的操作。

也許很多人沒思考過底層原因，或者僅僅只是覺得其相比彈框顯得更友好。其實這個行為是基于手勢交互做了相應的優化，讓用戶操作起來更加方便。

Banner

到了這里，我再舉個所有人都熟悉的例子，就是輪播圖了。

輪播圖最早出現于網頁端，后來被大量商家模仿，以至于到移動端還備受各產品設計人員的歡迎。但其實很多人對輪播圖的使用方法都是錯誤的。

下面來看輪播圖與手勢的關系。

試想：你的輪播圖有 6 張 Banner，你要翻到第 4 張，無論是往前翻還是往后翻都要產生 3 次交互行為。而大部分產品的用戶在界面停留的時間不會這么久，更不會看完你 Banner 的內容。以至于有研究表明，大部分產品里，除了第一張 Banner 的點擊率能達到 83% 之外，其余的點擊率都非常低。

有人說可以點擊下面的原點指示器做跳轉，這么小的點，你覺得點擊它現實么？所以手勢交互與輪播圖是相互矛盾的一種設計方式。

所以當運營策劃了一個活動，而你就往頂部的輪播圖里塞，這個行為就已經注定這個活動的用戶參與度是很低的了。除了個別電商產品，他們以賣廣告位給商家作為盈利點，但即便如此，我相信這個廣告位除了第一張圖的點擊量稍高外，其他圖片的點擊量相對于產品本身的用戶體量比較而言還是很低的。這也是為什么部分產品把輪播圖規則改為用戶進入首頁隨機展示輪播圖頁面，而不是強制指定于顯示第一張的原因。

畢竟輪播圖在頂部，用戶需要通過拇指長時間的在「延伸區域」進行操作，那么使用率自然就降低了。

如果你的產品有很多活動是在同時期進行的，那么我給部分產品的建議是放一個活動主題入口，如下圖。（當然，這要視情況而定，并不是通用的。）

搜索框的變化

我們現在看到的搜索框基本都是放在屏幕頂部。

為什么呢？

市面上對這個問題的解釋是這樣的：用戶已經被現在的產品訓練得在界面的頂部必須看到一個搜索框，設計師打破這個常規就要承擔風險。

看完這篇文章，你就已經知道，對于用戶來說，由于屏幕頂部離拇指很遠，處于難以觸達的區域，在體驗上很不好。所以搜索框成了認知上應該在頂部，但操作體驗上又不應該在頂部的一個設計。

但是回想一下，會發現大多數 App 的主要內容都是位于易于觸達的區域。所以當看到高德地圖把搜索框移動到下面來之后，就能知道，拇指驅動設計的概念被越來越多的人認識到其重要性。

地圖類產品把搜索框移到下面來的首創應用不是高德，應該是 Lyft。

瞧，拇指驅動設計，多酷~

總結

《上癮》里有句話：當人們不由自由地做出下一個舉動時，新的習慣就會成為他們日常生活的一部分。

當手勢充分地發揮了作用，輔助用戶操作或實現功能，它就成了用戶不可分割的一部分。

今天通過對手勢意義的解讀，以及拇指驅動設計的解析，再加上這些案例的拆解，我相信你能更好地理解為什么手勢交互這么重要了。

交互設計師對于「觸摸屏」，必須有深刻的認識，才能理解設計背后的邏輯。

如果這篇文章對你有幫助，記得點個贊，后面我好持續輸出。

文章來源：優設

如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里

心理學在我們生活中涉及的面很廣，是每個行業都要了解的，對于設計師來說，更要了解用戶的心理，因為我們的設計是面向用戶的 

   我們經常需要引用（白嫖）一些網頁上的文字，但是豆丁網，百度文庫等等設置的有復制權限，我們無法直接復制，或者復制文字有上限，提示付費。

    這里介紹幾種，都是些花里胡哨的白嫖方案：

1.手機掃描：

    拿著手機，用手機QQ的文字掃描直接去識別問題，遇上好識別的文章短的直接就識別，但是這種方法遇到文章比較長的就十分麻煩?？梢葬槍δ切┻x中



2.魔鬼牽引：

    原來在計蒜客就這樣搞，選中網站上的文字，然后用鼠標一直拖到別的頁面，或者一個記事本什么的，屢試不爽。



3.側邊翻譯：

    側邊翻譯，火狐或者谷歌下載一些插件，比如說側邊翻譯，這個東西小巧玲瓏，選中文字側邊翻譯之后你就可以對文本進行復制了。



4.原始查看法：

    在瀏覽器中直接F12，打開瀏覽器查看，就下面這個東西，瀏覽器你要復制的文本就在這里面，里面封裝的html語言，你可以搜索你需要找的文字，然后可以直接復制，如果想要復制多一點你也可以直接把里面的html語言拿出來解析到自己的網頁里面，然后再進行復制。





5.氪金法：

    沒別的，充錢就完事了。



6.某巨巨提供：

    下載一個ocr工具，類似qq掃描的功能。

互聯網的底層邏輯就是以一種更的形式來滿足了我們的需要，讓我們的生活和生產更加的智能和。

底層邏輯是什么？如果給它一個釋義的話，那應該是：最初的意圖或做一件事情原始的出發點。

互聯網的底層邏輯

我們生活在一個網絡時代?？梢岳镁W絡，購物，打車，叫外賣，娛樂，辦證，學習等需要?？墒窃跊]有網絡的年代里，做任何事情都是需要跑腿和親力親為。

我們對比沒有網絡年代?；ヂ摼W給我們生活帶來了極高的便利和效率。

我認為互聯網的底層邏輯是：用一種更的形式來滿足我們生活生產而產生的需要。

我們拿買衣服，購買外套舉例。

• 進店購買：詢問導購–找到外套–挑選–決定買不買
• 網上購買：搜索外套–屏幕展示外套–挑選–決定買不買。

經過對比發現：

進店購買和網絡購買最初的意圖都是滿足穿衣服。兩種形式的心理活動邏輯一樣。都是店鋪找到外套，然后作出購買決定。只是兩種方法的獲取形式和途徑是不一樣的。

1. 實體店詢問導購，變成了我們線上自主搜索。
2. 口頭說出外套變成輸入關鍵詞“外套”。
3. 獲取到的結果由導購帶到引導變成外套信息數據展示

互聯網技術的讓購物，讓買衣服多了一種途徑，多了一種形式并且有別于我們傳統的購買方式。

再如直播賣貨，直播賣貨在網絡上火了一把?？诩t一哥李佳琦直播賣貨，1分鐘售罄14000支唇膏、打破“30秒涂口紅”吉尼斯記錄、5個半小時帶貨353萬……最高時段3000萬人在線圍觀。

現在我們要聊的并不是網絡紅人的偉大數據。而是網絡直播這個事。想一下，網絡直播是否在真實生活情景有原型。

看到上面的情景，是不是覺得熟悉了。

• “瞧一瞧，看一看”
• “廠家做活動，回饋消費者，不要1999，不要1599，只要999”
• “走過路過不要錯過”
• …..

我們暫時稱這些情景為現場直播，現場叫賣。由于互聯網技術的成熟，直播平臺的成熟。將現場直播搬到了網絡直播。網絡直播底層邏輯就是現場叫賣的另一種形式。

我們可以發現，互聯網很多項目其實都是可以從現實生活中找到原型：

• 購物–電商
• 線下地推–網絡直播
• 電話叫餐–外賣
• 培訓–網課
• 閱覽館–電子書
• 辦證跑腿提交紙質資料–網上提交電子檔資料
• ……

互聯網如何讓生活生產變得更為？

1. 連接，跨空間，跨地域連接人

假如沒有網絡，我們人與人之間的生產活動大多只存在于本地圈子。例如：

• 在當地文化圈學習，與當地同齡人成為同學。
• 信息和話題交流閉塞，對外界信息獲取滯后。
• 和當地人做生意，把貨品賣給當地的消費者。

有了網絡：

• 在抖音快手，我們可以看到其他城市的面貌，了解更多的人文民俗。
• 在網絡課程上學習平時接觸不到的知識。比如：理財，攝影，寫程序，做會計。
• 還可以通過電商將生意做到全國各地。

網絡連接能突破界限，跨地域、跨空間，將不同省份，不同城市的人，通過互聯網聯系起來。然后將我們的信息，個人技能，社會信息放大到更多地方。

2. 賦能，釋放能量，價值最大化

以前有種現象。那就是信息不平衡，需求與被滿足不平衡。

比如：A想采購一批水果加工儀器，但當地農業為主，別說售賣水果加工儀器，即便是詢問他人也鮮有人知道。

但在網絡時代，我們只要百度或者阿里巴巴搜索?？倳玫轿覀兿胍木€索或者結果，總能找到加工儀器供應商的信息。

再如：十八線縣城要學習IT編程語言，一般來說要去大城市培訓機構學習。有了網絡，直接在一些課程平臺上購買課程就可以了。

上面的例子想說明的就是互聯網可以放大社會資源的利用率，將價值更大化，讓更多人參與參與到社會資源的共享當中。消除局限和阻隔，將知識課程提供千千萬萬的人可以學習使用。

滴滴平臺一方面解決了人們打車難的問題，另一方面也將閑賦私家車全部利用起來，給打車這和私家車車主同時滿足需求和創造價值。

幾年前我們看著小卡片的菜單和電話叫外賣，現在我店家再也不用通過發傳單來招攬生意了，只要用戶有需要打開app就可以實現足不出戶享受用餐。

互聯網將社會資源效率更大化。無論是外賣平臺，學習平臺，電商平臺都是將原來局限在小范圍的服務放大到全國各地的人群使用。這些都是互聯網技術賦予的能量。

3. 破界，突破界限，讓不可能成為可能

在那個守著電視機，聽廣播看報紙，用著紙幣的年代。怎么也不會想到今天我們可以拿著手機看新聞，追劇，刷抖音；用手機乘公交，乘地鐵；手機當錢包，網紗購物，線下消費。所以很多老人好像有點不能理解年輕人的生活方式。

所以技術可以讓滿足我們需求的方式發生改變，甚至是顛覆的。

從前我們看的也并不是電視本身，而是看聲情并茂的畫面；報紙也不是報紙而是信息；使用紙幣是為了完成交易。電視，報紙，紙幣這是一個時代的載體。

互聯網技術的發展讓這些載體發生了變化，打破了刻板印象。讓我們知道了很多東西其實只是個物體，這些物體幫助實現我們內心產生的需要。

今天只是這些物體被新的物體替代了，就好比手機替代了一部分看電視的需求。在十幾年前我們怎么也不會想到今天那么多東西都被改變和替代。也許我們現在不切實際的想法，在將來的某一天也終將會被替代和成為現實。

互聯網把我們每一個人連接在一起。放大了市場，提升了效率，突破了界限。用一種新的形式滿足人們日新月異的需求升級。

互聯網繼續，5G來襲，展望未來。

互聯網已經滲透到了各行各業。大到與我們生活息息相關，也可以小到陌生領域。人們都說互聯網的發展已經到了瓶頸，我更愿意相信是互聯網是暫時進入到了它的發展周期。

技術只會不斷的向前，不斷的用新的更好的方式來突破替代的舊的形式。隨著5G網絡的到來，肯定會有新一輪的技術革命到來。

第5代移動通信網絡比4G網絡的傳輸速度要快10倍以上，一部1G的電影可在8秒之內下載完成，我相信這絕對又是一個新的起點，很期待5G時代給我們帶來的驚喜。

4G時代連接人與人，是服務業的升級

不難發現，4G網絡應用大多數屬于服務范疇。像電商，外賣，打車，餐飲其實都是服務員行業。4G時代提高了服務效率，實現了跨距離，跨空間服務。

視頻聊天可以穿越見面時空對話；電商可以讓你在一個地方買遍全國甚至全球；新零售可以實現不出門買菜做飯。4G網絡連接人與人，大大提高了人與人之間服務的效率和數量。

5G時代連接人與物，交互體驗升級

隨著5G網絡的到來及速度效率的提升，我們可以實現更加多元化的連接。

5G可以做到4G想做但有無法實現的事情，例如擴展到人與物之間的連接；也可以在4G基礎上實現更加精準的計算，又如精密的醫療，更加精準和快速的大數據。

5G網絡將繼續升級改變我們生活，它將繼續改變娛樂，交通，醫療，智能家居等等領域。我們可以試著猜想：

• VR技術，讓看電影能夠有更佳的3D體驗。
• 網上購物不在需要看圖片。而是有更好的體驗，身臨其境在虛擬的店鋪中?？梢詫ι唐酚杏|摸和移動等虛擬的互動體驗。
• 無人駕駛技術
• 智能家居。不在家或者在外地對家居進行操作，比如：關窗，開空調，掃地等。
• 智能醫療。如；遠程手術。由于5G網絡有著更加精準的效率。支持醫生運用機器跨醫院操作手術等。

技術的進步會給我們的生活帶來改變，我們期待新的形式來滿足我們的需求，期待我們的生活和生產更加的智能和。

 文章來源：人人都是產品經理

需求整理的現狀

寫這篇文章的初衷，是在實際工作中遇到 PRD & DRD 文檔，對于一些交互設計圖，會產生不理解，或者說在實際落地畫圖的時候會發現一些前后不一致的問題，解釋過于冗余，不清晰。在接觸新的業務時，很難把新理解的內容從上至下的消化完整。所以希望通過這篇文章幫助剛接觸交互的同學更好地開展交互設計工作。

在傳統瀑布式需求分析流程中，我們設計師往往拿到的是已成型的信息架構圖&產品結構圖&關鍵業務流程圖，只是了解一下大概是什么類型的產品，很難發現企業產品中真正關鍵的流程價值點在哪里，或者說也不清楚后續發展的走向，只能卯足了勁去做圖做說明，整理完整。時間緊迫壓力大，又要照顧整個項目。往往決定產品成功與否的，是產品 20% 的主要功能（二八原則）。所以在面臨初期產品設計中，應該將主要精力放在重要功能流程中。

目前，在互聯網產品中，敏捷開發是所有產品設計者最推崇的。原因在于，能夠對業務、設計、開發更有前瞻性&敏捷性。

理解業務需求，是做好交互的首要條件

產品交互的成功一定是建立在業務需求提煉清晰的基礎上。業務需求的價值提煉，也是設計師需要參與完成的。業務需求是一個比較大的任務，來源可能是老板的要求，可能是產品提出的，也可能是用戶的反饋。通過業務需求，我們要分析出相關的業務目標。有個偶然的機會，了解到彩色 UML 的設計方法，在具體實踐中，感覺這個方法能夠快速適應任何業務流程，簡單方便，易懂，并能快速發現業務流程中的問題，加以修正完善。

彩色UML建模

有幸認識王海鵬老師，他推薦了早年他翻譯的彩色 UML 建模一書，作者 Peter Coad，是將彩色和企業組件集成到建模技術之中的第一本書的主要作者，是世界上經驗豐富的建模人員之一，他所創建的模型幾乎涉及到所有行業。

此書是第一本介紹用彩色來表達軟件設計的著作。作者用 4 種顏色來代表 4 種架構型，給定一種顏色，你就知道這個類可能具有哪些屬性、鏈接、方法和交互。得到的彩色構建塊能創建更好的模型，并獲得應有的認可。彩色和架構型僅僅是開始。作者更進一步將這些架構型發展為 12 個類的領域無關組件。作者在過去 10 年中創建的每個模型，都遵循這個組件所表達的基本形狀和職責。

筆者利用彩色 UML 建模的設計方法，用于業務梳理工作，達到了意想不到的效果。以下為彩色 UML 建模基本概念（截取彩色 UML 建模書中的介紹）。

△ 《彩色UML建模書》第9頁

△ 《彩色UML建模書》第10頁

△ 事例會員注冊

交互設計中常用圖

1. 實體關系圖（又稱ER圖）

定義：ER 圖是用來描述現實世界中的實體關系模型，所謂實體是指客觀上或者邏輯上存在并且可以區分的人事物。

作用：促使你以最適合技術理解實現的方法，來規范的描述功能模塊的核心要素，其實就是數據庫的物理結構。而這種描述是無二義的，最清晰傳達 PM 的設計思想。

2. 功能結構圖

功能結構圖就是按照功能的從屬關系畫成的圖表，在該圖表中的每一個框都稱為一個功能模塊。功能模塊可以根據具體情況分得大一點或小一點，分解得最小功能模塊可以是一個程序中的每個處理過程，而較大的功能模塊則可能是完成某一個任務的一組程序。用通俗的話來說，功能結構圖就是以功能模塊為類別，介紹模塊下各功能組成的圖表。

作用

• 梳理需求，以鳥瞰的方式對整個產品頁面中的功能結構形成一個直觀的認識。
• 思考并明確產品的功能模塊及其功能組成。

3. 信息結構圖

信息架構屬于用戶體驗的結構層，是產品的骨架。一般是由產品經理或者更高層的管理人員給出大框架。除非是大的產品迭代，否則不會大改。

作用

• 幫助 PM 梳理復雜內容的信息組成，避免信息內容在展示過程中出現遺漏、混亂、重復；
• 作為開發工程師建立數據庫的參考依據。

信息結構圖構成要素

• 導航：網頁訪問者的訪問途徑。
• 頻道：某一個同性質的功能或內容的共同載體，也可稱為功能或內容的類別。
• 子頻道：某頻道下細分的另一類別。
• 頁面：單個或附屬某個頻道或分類下的界面。
• 模塊：頁面中多個元素組成的一個區域內容，可以有一個或多個，也可以循環出現，如：文章列表。
• 模塊元素：模塊中的元素內容，以文章列表舉例，文章標題、文章摘要、文章發布時間，這些都是元素，都是組成模塊的內容，同時他們也是可以循環出現的。元素的類型可以是：文字、圖片、鏈接等等。

4. 產品結構圖

定義：產品結構圖是綜合展示產品信息和功能邏輯的圖表，簡單說產品結構圖就是產品原型的簡化表達。

作用：它能夠在前期的需求評審中或其他類似場景中作為產品原型的替代，因為產品結構圖相較于產品原型，其實現成本低，能夠快速對產品功能結構進行增、刪、改操作，減少 PM 在這個過程中的實現成本。

5. 業務流程圖（泳道圖）

業務流程圖，不是操作流程圖也不是頁面流程圖。它是產品的整體業務流程，直接和業務掛鉤，可以說是產品的核心流程。

作用

通過業務流程圖，鉆研關鍵事件的流程，分析為什么要這么做，探索出更深層次的問題，從而對現有不合理的業務流程進行重組優化，進而制定優化方案，改進現有流程；闡述在項目中各個角色是如何產生相關聯系的。

繪制規范/建議

• 讓涉眾參與，不要閉門造車：與業務流程圖包含的各個參與角色代表適時確認事情的原本流程。
• 恰當的層次分解，不要將所有的環節都鋪到一張圖上。
• 逐漸深入，先抓枝干：切忌一開始就陷入細節。
• 流程一定有開始和結束：切忌交出來的流程圖，讓讀者問：流程的開始點是什么？用清晰的代表開始和結束的符號來完成第一步和最后一 步。
• 流程圖符號繪制排列順序：由上至下，由左至右。
• 同一流程圖符號大小宜相對一致。
• 編號：這是讓溝通效率更高的優化措施。當你有了編號系統，相當于對你的流程圖都賦予了唯一識別身份證號。負責流程規則審核和優化的部門能夠清楚在郵件里傳達 H5.1 流程優化，大家就更明確指的是什么。
• 路徑符號應避免互相交叉。

6. 任務流程圖

任務流程圖就是通過圖形化的表達形式，闡述產品在功能層面的邏輯和信息。它能夠更清晰、直觀地展示用戶在使用某個功能時，會產生的一系列操作和反饋的圖標。

作用：基于業務流程，進行任務流程梳理，闡述角色和程序發生交互的流程，你如何進行操作，系統如何進行反饋。

任務流程與需求文檔中的業務流程并不一樣。雖然它們都是流程圖，但業務流程更偏向于業務限制、后臺邏輯等，并不過分注重用戶的操作邏輯。而任務流程則需要關注用戶如何操作、界面如何反饋等，從而引導用戶完成用戶目標。

7. 頁面流程圖

定義：指電子產品具體所呈現的頁面跳轉流程圖。其承載了業務流程圖所包含的業務流轉信息。

作用：

• 交互設計/原型設計的底子，基本依據。
• 站在用戶視角，代表用戶所有可能的操作過程，頁面流程能快速發現體驗問題。
• 突出頁面元素與邏輯關系，提升原型設計的效率。

8. 線框圖/原型圖

定義：頁面的模塊、元素、人機交互的形式，利用線框描述的方法，將產品脫離皮膚狀態下更加具體跟生動的進行表達。

作用：用例闡釋者，用來了解用例的用戶界面；系統分析員，用來了解用戶界面如何影響系統分析；設計員，用來了解用戶界面如何施加影響及它對系統「內部」的要求；類測試人員，用來制定測試計劃活動。

構成要素

• 頁面標題：即每一個頁面的對應標題，一般就是導航欄標題。
• 頁面內容：以黑白為主，保證信息規整易讀。
• 交互說明：用標簽將其對應起來，包括交互邏輯、操作流程及反饋、元素狀態、字符限制、異常/特殊狀態、相關規則等等。
• 主流程線：只需要畫出主流程線即可，千萬不可太多太雜，時刻考慮讀者的感受。

9. 線框圖/原型圖交互說明的幾種類型

限制

包含范圍值、極限值等。

范圍值主要指數據的取值范圍。比如，當你的界面上出現了下拉菜單、篩選按鈕、滑塊等控件時，你必須標注清楚它們的選擇范圍，否則開發人員就不清楚該如何設定，如圖所示。

極限值主要指數據的顯示限制。比如，最多應該顯示多少字數，過時如何顯示，是否折行等，如圖所示。

狀態

包含默認狀態、常見狀態、特殊狀態等。

「默認狀態」主要指默認顯示的文字、數據、選項等。這些內容需要注明，否則開發人員可能難以意識到這是用戶填完的效果，還是默認就有的。

「常見狀態」主要指針對某一個模塊，經常遇到的一些狀態。這些狀態都需要在原型上表述出來。比如一個普通的積分模塊，一般會出現 3 種狀態：未登錄狀態、登錄后未簽到狀態、登錄后已簽到狀態，如圖所示。

「特殊狀態」一般指非正常情況下的樣式、文案、說明等，如圖所示：

操作

包含常見操作、特殊操作、誤操作、手勢操作等。

「常見操作」主要指正常操作時得到的反饋狀態。比如一個普通的翻頁控件，在經過不同操作后會立即出現如下的狀態。

「特殊操作」主要指一些極端情況下的操作。一般，用戶不會這么操作，但是一旦遇到極端情況，還是要想好應對措施，因為對于開發人員來說，不管是正常的還是極端的操作情況，他們都要去編寫對應的代碼。如下圖，是填寫用戶信息的例子，當不寫交互說明時，開放往往會遇到很多問題：如果已經勾選了 2 個人，再勾選第 3 個人，怎么辦？如果勾選了「張XX」，下面區塊中會相應地出現張XX的信息，那么這時候允許修改張XX的身份證信息嗎？假如允許的話，修改后「張XX」還保持勾選狀態嗎？表單提交后要新增一個被保險人信息嗎？若修改的是除身份證號碼以外的信息，「張XX」 還保持勾選狀態嗎？提交表單時是覆蓋原存儲信息嗎？若修改后出生日期、性別與身份證號碼不吻合怎么辦？等等。

面對各種復雜的情況，一方面要和開發人員積極探討，看看有沒有其他的解決方法可以簡化各種邏輯判斷；另一方面，在得出結論后，要把交互說明寫清楚，避免出現讓開發人員感到棘手的情況。

「誤操作」主要指當用戶操作錯誤時的情況。不過我們在設計時要盡量避免有用戶犯錯的機會。如圖所示，提示中已告訴用戶「庫存5件」，如果這個時候用戶在「數量」一欄中輸入「6」會怎么樣呢？系統會自動幫用戶將其改為「5」省去用戶手動修正的操作。

「手勢操作」主要指用戶使用移動產品時的操作方式。常見的有點擊雙擊、長按、捏、伸、滑動等等。

反饋

用戶操作后得到的反饋動作，包含提示、跳轉、動畫等。

「提示」主要指操作后，系統反饋給用戶的文字說明等，如圖所示。

「跳轉」主要指點擊某個鏈接后，頁面跳轉到哪里。設計師需要在原型上注明跳轉時是「原頁面刷新」還是「新頁面打開」。如果是做手機應用的話，需要注明跳轉時的轉場方式，如圖所示。

「動畫」主要指用戶操作后，系統通過動畫的方式反饋給用戶。動畫給人的感覺比較友好、趣味性較強，是非常常見的一種反饋形式。比如刪除某條信息，該信息以漸變消失的形式告訴用戶：這條信息已經被刪除了。在移動應用中，動畫反饋的形式更為常見。因此設計師一定要在原型上表述清楚動畫的形式，必要時可以制作 domo 動畫演示效果給開發人員。

文章來源：站酷

作為UI設計師，我相信大家都是專注于界面設計的好不好看，至于界面與界面之間如何交互，點擊之后如何反饋，是一個比較容易被忽略的重要環節。

那么我們怎么處理好界面交互中的加載設計，減少用戶因等待產生的焦慮情緒，保證整個體驗無縫銜接，今天這篇文章就來總結下APP中數據加載模式設計。

一、為什么要加載？

1、用戶在進行某些操作時，都要從后臺請求數據，這個過程都需要時間，系統應該始終在合理的時間內做出適當的反饋，讓用戶了解正在發生的事情，讓用戶知道此時的操作是有反應，減緩用戶因等待而產生的焦慮感。同時加載方式也可以做的有趣，吸引用戶注意力，增加沉浸式體驗，讓用戶輕松自在的享受等待；

2、體驗無縫銜接，減少用戶跳失，正常的等待加載時間是0.3秒以內，同時不同場景對應有不同的加載方式。

二、常見的加載場景及方式

a.加載場景：

不同場景有不同的加載方式，常見的加載場景一般有以下幾種：下拉刷新、上拉加載、切換新頁面的數據加載、頁面局部模塊的加載、啟動頁加載、操作按鈕加載。實際工作中，要根據不同的場景搭配不同的加載樣式，才能更好的做到緩解用戶等待焦慮，降低用戶的跳失率。

b.加載方式：

1、全屏加載

主要出現在手機H5頁面，例如微信的文章詳情頁。一般會有進度條或有趣的動畫設計，減輕用戶等待時的焦慮感。加載失敗后，頁面通常為空白頁，且有重新刷新操作按鈕。

優點：將整個頁面的內容都加載出來才展現給用戶，能保證內容的整體性，全部加載完才能夠系統化的閱讀。

缺點：一般等待的時間較長，容易產生焦躁情緒，尤其是遇到網絡不好的情況

2、下拉刷新加載

主要出現在頁面內容為推薦類、或者信息更新頻次高的產品，通過刷新加載新數據，加載的loading樣式可以結合產品logo或IP形象進行設計，增加趣味性，吸引用戶注意力。

3.占位圖加載

如果頁面布局樣式比較固定，可以采用占位圖加載機制，先加載頁面布局和占位圖，先給用戶展示頁面框架，后加載頁面圖片細節部分，這種加載方式相對于直接展示白屏來說，呈現給用戶無縫銜接的感覺，體驗更加流暢。

4.分布加載

當頁面中有文字和圖片時，優先加載占網絡資源較小的元素，如先加載文字，后加載圖片，圖片加載完成前使用占位符顯示，保證用戶可以順暢閱讀，縮短用戶的等待時間，提高產品體驗。

優點：可以幫助用戶快速閱讀內容，了解信息。

這種加載形式更加適用于內容閱讀型的APP或圖片、視頻類資源比較多的頁面。

5.自動加載（懶加載）

當瀏覽信息時，不停的向上滑動，新的內容會不停的從底部出現，這種方式稱為自動加載。對于自動加載，要注意每次加載多少條內容，或者多少屏的內容。一般會在距下面內容一定距離時開始加載，當網速非?？斓臅r候，用戶并不能感知懶加載的動作，這樣可以營造一種無極限瀏覽的錯覺，很容易的把用戶吸引住。

優點：無需用戶操作，自動加載后續內容，營造沉浸式體驗。

應用：適合feed流、瀑布流、算法推薦類的內容。

6.預加載

提前加載好頁面信息內容，這樣當網絡不好的時候，可直接從本地緩存中渲染，就不用再加載了。

比如用戶在看A頁面的時候，App在后臺加載完B頁，等用戶打開B頁的時候就不需要等待加載了，因為App已經幫用戶提前加載好了，給用戶提供無縫鏈接的感覺，弊端就是服務器壓力很大，就是要預測用戶行為，加載其他數據，這樣會消耗不少流量，所以建議在WiFi網絡環境下采取這種預加載機制，而在蜂窩網絡狀態下則不采用預加載機制。

7.漸進式加載

一般出現在圖片類產品，比如pinterest、unsplash等，當瀏覽圖片的時候，經常是先看到一張模糊圖或與圖片較為相似的色彩值圖片，然后再漸漸的變得清晰，這種效果就叫做漸進式加載。漸進式加載能夠大大的提升體驗感。

8.后臺加載(異步處理)

用戶在前端執行操作后，客戶端立即給予操作成功反饋提示，然后把請求放到后臺與服務器交互，這一過程用戶是看不到的，也不需要等待，體驗是非常棒的。

例如在用微信發朋友圈時，會覺得特別流暢，即使在網絡不好的情況下，會看到你的動態立即展示在朋友圈列表，并不會提示你網絡不好，操作失敗，全部以操作成功來顯示，其實它只是將你發布的操作記錄了下來，等網絡一好就將動態上傳到服務器，從而完成發布行為，微信的點贊也是同樣的操作，你給好友點了贊，并不會提示你網絡不好，操作失敗，而是提示你點贊成功了，其實它只是將你點贊的操作記錄了下來，等網絡一好就將點贊的行為上傳到服務器，從而完成點贊行為會，給用戶帶來體驗流暢的感覺。

所以這種加載方式是需要根據具體使用場景來權衡使用的，對于一些重要的操作，建議還是使用模態的方式加載，對于一些小操作，如點贊、訂閱、關注，可采用后臺加載的方式。

9.模態加載

以上幾種方式都是采用非模態加載，不會對用戶造成干擾，用戶可以做別的事情，不需要等待加載完成，大大降低了等待的焦躁感。

模態加載對用戶干擾比較大，需要中斷用戶的其他操作，用戶只能等待加載結束，因為如果用戶執行了其他操作就會打斷正在進行的加載過程，實現不了用戶的目標。

應用：用戶執行的操作本身不能和其他操作同時進行，例如登錄，退出，應用啟動，手機支付等場景。

三、具體實施方法小結

1、能用非模態加載的盡量不要去用模態加載，如果非得用模態加載，也盡量給一個能取消的按鈕，方便用戶在不愿意等待的情況下取消操作。

2、如果加載的時間比較長，最好能告知用戶加載進度，讓用戶心理有個預期，這樣用戶更愿意等待，不會因為等待產生焦慮感，分分鐘卸載你的產品?？茖W的實驗證實，先慢后快的進度條是讓用戶心理感受上最快的設計，這是因為用戶最容易記住最后一瞬間的感覺，如果最后一瞬間，感知到了快，就覺得很順暢了。

3、數據加載本身就是很考驗用戶心態感受，所以盡量通過一些有趣的動畫來轉移用戶的注意力，營造沉浸式體驗，同時增加了趣味性，給予了產品人性化的設計。

總結

作為產品設計人員，盡量給用戶好的體驗，我們應該讓產品自己去解決問題，而不是把問題拋給用戶。在考慮人與客戶端交互的同時也要把客戶端和服務端之間的數據傳輸考慮進來，站在用戶、客戶端和服務器閉環的角度去思考產品，才能設計出體驗更好的數據加載方案。

轉自-站酷

藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務。