node系列之數據接口注冊登陸接口的實現

1、使用express腳手架創建項目

2、了解項目的目錄結構

3、準備數據庫相關文件

4、編寫注冊接口

5、編寫登陸接口

6、驗證登陸實現

7、預告

1、使用express腳手架創建項目

// 安裝腳手架，只需安裝一次

npm i express-generator -g

// 創建express項目

express myapp --view=ejs

cd myapp

// 安裝依賴

npm i 

// 安裝需要使用的模塊

// 數據庫模塊 用戶唯一id模塊 密碼加密模塊 token模塊

npm i mongoose node-uuid bcryptjs jsonwebtoken -S



2、了解項目的目錄結構

bin

www ------- 服務器啟動

node_modules ------- 項目的依賴文件

public ------- 靜態資源文件夾

images ------- 靜態圖片

javascripts ------- 靜態的js文件

stylesheets ------- 靜態的樣式表文件

routes ------- 路由文件

index.js ------- 默認的路由

users.js ------- 用戶相關的路由

views ------- 路由對應的頁面

index.ejs ------- 默認的首頁

error.ejs ------- 錯誤頁面

app.js ------- 使用中間件，注冊路由

package.json ------- 描述文件

3、準備數據庫相關文件

大勛在node系列之數據庫mongoose的封裝中給大家介紹了如何封裝mongoose，可以先行查看如何封裝，封裝的文件夾為sql，如果不想看的，可以直接通過網盤下載該文件夾



將該sql文件放置項目的跟目錄下

• myapp
  
  - sql
  
  - collection
  
  users.js
  
  db.js
  
  index.js
  
  
  
  4、編寫注冊接口
  
  目標文件： myapp/routes/users.js
  
  
  
  實現思路：使用post提交數據的方式，先以手機號查詢有沒有該用戶，如果有該用戶，提示用戶該賬號已經注冊過了；如果沒有該用戶，則可以完成注冊，首先得將密碼加密，加密完成后插入數據庫
  
  
  
  代碼實現：
  
  
  
  // 找到用戶集合
  
  var User = require('./../sql/collection/users');
  
  // 找到數據庫封裝文件
  
  var sql = require('./../sql');
  
  // 狀態碼的封裝
  
  var utils = require('./../utils')
  
  // 用戶唯一標識的id
  
  var uuid = require('node-uuid');
  
  // 密碼加密模塊
  
  var bcrypt = require('bcryptjs');
  
  var salt = bcrypt.genSaltSync(10); // 加密級別
  
  
  
  // 實現注冊接口 -- post提交方式
  
  router.post('/register', (req, res, next) => {
  
    // 1、先獲取表單信息
  
    let { username, password, tel } = req.body;
  
    // 2、根據手機號查詢 用戶集合中是否有該用戶，如果有，返回有該賬戶，如果沒有注冊繼續
  
    sql.find(User, { tel }, { id: 0 }).then(data => {
  
      // 2.1 判斷有沒有該用戶
  
      if (data.length === 0) {
  
        // 2.2 沒有該用戶----繼續完成注冊操作
  
        // 2.2.1 生成用戶的id
  
        let userid = 'users' + uuid.v1();
  
        // 2.2.2 對密碼加密
  
        password = bcrypt.hashSync(password, salt)
  
        // 2.2.3 插入數據庫
  
        sql.insert(User, { userid, username, password, tel}).then(() => {
  
          res.send(utils.registersuccess)
  
        })
  
      } else {
  
        // 2.3 已有該用戶
  
        res.send(utils.registered)
  
      }
  
    })
  
  })
  
  
  
  附 狀態碼封裝模塊 myapp/utils/index.js
  
  module.exports = {
  
    registered: {
  
      code: '10000',
  
      message: '該用戶已注冊，請直接登錄' 
  
    },
  
    registersuccess: {
  
      code: '10101',
  
      message: '注冊成功' 
  
    }
  
  }
  
  
  
  5、編寫登陸接口
  
  目標文件 myapp/routes/users.js
  
  實現思路：根據手機號查詢有沒有該用戶，如果沒有，提示用戶未注冊，如果有該用戶，使用bcryptjs模塊驗證密碼的有效性，如果有效，生成token，返回給前端相應的token值。
  
  var jwt = require('jsonwebtoken');
  
  // 實現登陸功能
  
  router.post('/login', (req, res, next) => {
  
    // 1、獲取表單信息
  
    let { tel, password } = req.body;
  
    // 2、依據手機號查詢有沒有該用戶
  
    sql.find(User, { tel }, { _id: 0 }).then(data => {
  
      // 2.1 判斷有么有該用戶
  
      if (data.length === 0) {
  
        // 2.2 沒有該用戶
  
        res.send(utils.unregister)
  
      } else {
  
        // 2.3 有該用戶，驗證密碼
  
        // 2.3.1 獲取數據庫中的密碼
  
        let pwd = data[0].password;
  
        // 2.3.2 比較 輸入的 密碼和數據庫中的密碼
  
        var flag = bcrypt.compareSync(password, pwd) // 前為輸入，后為數據庫
  
        if (flag) {
  
          // 2.3.3 密碼正確,生成token
  
          let userid = data[0].userid
  
          let username = data[0].username
  
          let token = jwt.sign({ userid, username }, 'daxunxun', {
  
            expiresIn: 606024// 授權時效24小時
  
          })
  
          res.send({
  
            code: '10010',
  
            message: '登陸成功',
  
            token: token
  
          })
  
        } else {
  
          // 2.3.4 密碼錯誤
  
          res.send({
  
            code: '10100',
  
            message: '密碼錯誤'
  
          })
  
        }
  
      }
  
    })
  
  })
  
  
  
  6、驗證登陸實現
  
  目標文件： myapp/app.js
  
  實現思路：很多的數據請求都需要登陸之后才能獲取到，在此統一封裝驗證登陸
  
  // 引入token模塊
  
  var jwt = require('jsonwebtoken');
  
  // 全局的路由匹配
  
  app.use((req, res, next) => {
  
   // 排除登陸注冊頁面
  
    if (req.url !== '/users/login' && req.url !== '/users/register') {
  
    // 不同形式獲取token值
  
      let token = req.headers.token || req.query.token || req.body.token;
  
      // 如果存在token ---- 驗證
  
      if (token) {
  
        jwt.verify(token, 'daxunxun', function(err, decoded) {
  
          if (err) {
  
            res.send({ 
  
              code: '10119', 
  
              message: '沒有找到token.' 
  
            });
  
          } else {
  
            req.decoded = decoded;  
  
            console.log('驗證成功', decoded);
  
            next()
  
          }
  
        }) 
  
      } else { // 不存在 - 告訴用戶---意味著未登錄
  
        res.send({ 
  
          code: '10119', 
  
          message: '沒有找到token.' 
  
        });
  
      }
  
    } else {
  
      next()
  
    }
  
  })
  
  
  
  
  

在網頁和移動端界面中，內容和信息是否能夠經過系統性、有效的整理和組織，對于內容的可用性和實用性，都是意義巨大的。而在呈現信息的時候，視覺間隔是組織信息的關鍵因素。它說起來并不難理解，但是在實際的運用當中，卻是千變萬化，今天我們來梳理一下流行的視覺間隔的方法。

什么是視覺間隔

視覺間隔是一種布局元素，它有助于將內容分隔成為清晰的分組、選項和部分。它可以讓設計師更好地組織內容的視覺體驗，處理信息的層級，也有助于用戶理解內容，明白內容之間的關系。

視覺間隔和頁面上的其他內容在一起，構成視覺層級，這是它最重要的作用。在視覺間隔的幫助之下，用戶可以輕松地感知內容之間的關系，明白各個信息片段之間的關系是相似，并列，承襲，從屬，還是其他。

視覺間隔的可用性也同樣重要：在很多時候，有的視覺間隔元素看起來是可點擊，可交互的，這在移動端界面上，是非常重要的。

視覺間隔的種類

談到視覺間隔，我們可以從兩方面來進行拆解分析：視覺間隔的外觀和功能。按照視覺特征，視覺間隔有5種基本的類型：

• 線條
• 色彩
• 負空間
• 陰影/體積
• 圖片

下面我們分別針對這5種類型進行說明。

線條

很長時間以來，在排版印刷領域，線條就一直是一種用來分隔內容的方法。線條的分隔功能是認可度最高的一種間隔方式，用戶幾乎不用思考，就能夠理解和感知它，并且發揮作用。

另一方面，這種間隔方式也很容易顯得過于簡單，并且和應有的形態相去甚遠。這也是為什么設計師在想盡辦法去尋求別的視覺間隔形態。太多的線條間隔會讓屏幕上的視覺干擾太多，并且帶來不必要的視覺噪音。

所以，能夠將線條間隔用得微妙、恰到好處、出神入化，是設計師功力的一個重要體現。

在這個網站產品頁面中，使用深色的線條間隔來分割產品信息，用來組織和間隔信息內容。

在這個頁面當中，線條分隔了不同的內容區塊，讓頁面的結構更易于被掃讀。

這個電商網站將不同級別的視覺內容進行了分離，借助簡單的水平線將價格、CTA按鈕以及承載相關信息的表單分隔到不同的區域。

負空間

負空間，也就是留白，也是最為常見的一種視覺分隔元素。留白絕不是對空間的浪費，和屏幕上其他的元素一樣，它同樣發揮著重要的作用，拱衛支撐著整個用戶體驗。負空間是最為流行的視覺分隔之一，尤其是在極簡主義風格為主導的設計當中。負空間本身遵循著格式塔原理，尤其是其中「接近原理」和「相似原理」是負空間在設計中，發揮分隔作用的核心所在。合理地運用負空間，還能強化頁面的呼吸感。

上面這款旅行規劃 APP當中，使用留白將不同的條目分開，沒有使用額外的具體視覺元素，僅僅只靠留白。

Health Blog 的列表的排版層次是基于負空間來實現的，看起來清晰又充滿呼吸感。

色彩對比

高對比度的色彩，同樣能夠帶來清晰的視覺間隔效果。在 UI 界面中高對比度的色彩有著極為明顯視覺表現潛質，它們能夠增強網站的信息和內容的表現力，分割區塊，營造氛圍。對比度是影響頁面和屏幕可讀性的關鍵因素之一。在具體的應用當中，不同的色彩會有效地分離不同的選項、條目和區域，這意味著它作為視覺分隔的作用非常強。這也是近年來分屏式設計如此流行的原因所在。

這是一套移動端菜單的概念設計，強烈的色彩對比讓信息清晰可見。

即使是在這樣的柔和的設計當中，色彩的對比度也發揮了相當的作用：一方面，強烈的色彩對比讓CTA按鈕和輸入框之間有了明顯的區分，另一方面，右側的主視覺元素的背景也同樣借由不同色彩的對比，做到了突出的效果。

在 GNO Blankets 這個網站當中，強烈的明暗對比將網站元素分隔成為精美而清晰的區塊。

陰影和體積

陰影和體積也是一種非常常見的視覺間隔方式，通過營造在「高度」或者說高程上的視覺差異，從而達到分層的效果，而這種設計也是符合人類一直以來的認知習慣。這種方法有利于保持整個設計的平衡和易讀性，另一方面，它又能保持足夠的微妙和自然，不會那么引人矚目從而讓人覺得出戲或者受到干擾。

這個APP的目錄頁面所有元素都采用了白色的背景，而陰影讓布局呈現出了縱深層次，讓內容足以展現又不顯突兀。

這款提供定制化花束服務的APP也采用了類似的陰影元素，讓整體看起來清晰又通透。

圖片

圖片在 UI 界面當中，同樣也是一種非常有效的視覺間隔，尤其是在包含大量文本內容的界面中。無論是博客、在線媒體網站還是其他類型的網站當中，圖片的間隔作用都非常明顯。無論是照片、插畫、3D圖形，它們作為圖片都可以很好的平衡文本內容，提高內容的識別度和可讀性，有效地劃分層級，并且提高情感吸引力。

這個比特幣網站的著陸頁就使用了帶有3D效果「了解更多」動態圖片，圖片和文本在內容和功能上都清晰地分隔開來。

在這個餐廳 APP 當中，圖片作為劃分內容的關鍵元素而存在。

按照功能劃分

如果從功能的角度上來劃分視覺間隔，可以根據它所處的層次來進行劃分。

全出血間隔

使用線條作為全出血間隔是最為常見的，它會很跨整個屏幕布局來作為信息層級的劃分。

這個畫廊圖庫 APP 的藝術家目錄當中，使用線條作為全出血間隔，來區分藝術家。

這個名為完美食譜的APP也使用了全出血間隔線來區分內容。

在這個財務APP當中，也使用了全出血間隔線來區分條目。

在這個電影APP的結帳頁面當中，也使用了線條來作為全出血間隔。

嵌入式間隔

嵌入式間隔的功能是將相關性較高的內容分割開，并且它通常會和標題或者其他的特定元素保持對齊或者對應，它們通常是進行某個大區塊內不同組件的分隔，或者將多個同類的元素分隔開。

這個網站當中，使用橫向的短分隔線來區分表單中的參數條目。

中間分隔

這種分割線通常會置于布局的中間某處，同樣是分隔相關的內容，但是通常它們在屬性上不一定是一致的，但是層級近似。

在這個出售草藥的電商網站的右側，使用中間分隔線將文本和可交互的區域清晰地分隔開。

值得思考的問題

上面對于不同類型的視覺分隔方式都有描述，在此之外，還有兩個問題需要注意：

• 保持微妙：視覺分隔不應該醒目、太過引人矚目，它們不應該分散用戶的注意力，它們應該支撐布局的同時，微妙而不那么抓人眼球。

• 中等頻率：這和上一點是相輔相承的，過多的分隔線會變成視覺噪音，讓用戶瀏覽的時候感到疲倦。因此，應該仔細考慮使用頻率，盡可能使用負空間，而不是線條。不要過度使用太多色彩，應該盡量保持整體的協調一致。

文章來源：站酷

我們通過門鈴聲兒得知門外有人來訪，也能通過電話鈴聲得知正被人呼叫。短信通知也有著類似的作用，包括各類產品的消息推送。

但不同的是，消息推送的重要性隨著「通知」被濫用而變得不那么重要了。它們變得不像門鈴或電話鈴聲起到的作用性那么大，包括短信現在也大多是垃圾信息。

而且，通知越來越多地通過各種方式去觸達用戶。比如消息未讀的紅點提示，或者顯示消息的數字統計，以及手機使用過程中的頂部提示與聲音或震動的提醒，等等。

但我們還是無法抑制點擊圖標的沖動，這僅僅是因為它具有未讀的計數或紅點提示，即使我們已經知道當中的內容并不重要。

而我要說的是，當通知內容變得次要且被濫用之后，它仿佛成了一種違背設計原則的功能 —— 中斷用戶當前行為。因為它打破了用戶與產品之間的層級關系，破局至產品之外來吸引用戶的注意力，這是一個非常打擾的行為。如果我在看書，突然收到一條并不重要的消息，那我一定會非常反感。

所以，為了不被「紅點」支配，以及不讓通知所打擾，我會把手機里所有產品的消息推送都給關了。

但是，以上內容并不能說明通知的無用論。同樣有許多用戶還是沉迷于通知的使用上，它所控制的是用戶對于某個產品的控制欲，擔心錯過某條消息，就好像我在豆瓣寫了篇隨筆，就想看別人給我點贊評論的消息，但我又不可能一直盯著，所以通知這時候就起到了一個很好的作用。

以至于對于優秀的產品人或設計師，包括運營來說，利用好通知，就能掌握用戶心理，巧妙的將用戶留在產品中。它們甚至有助于與打算放棄產品的用戶建立聯系并促進互動。

那么，我們應該如何更合理的設計通知呢？下面我們通過「通知的組成部分」以及「通知的使用類型與規則」來詳細做一次拆解。

通知的組成部分

關于通知的簡單定義：它是一種吸引用戶注意的功能模式，讓用戶獲悉新事件的信息動態。產品將其發送給用戶并與用戶產生交流。

因此從這個定義中我們可以知道，通知有兩種形式，分別是被動只讀型和操作反饋型。

被動只讀型，是指該信息可讀，但不可進行操作；操作反饋型，是指用戶可對該通知進行操作，如某寶訂單支付成功后的地址信息確認通知。

所以在梳理組件的時候也要注意掉這個差異。

1. 消息中心

這里的消息中心，是一個信息匯總中心，但并不一定是信息來源。意思是，信息來源可能是有很多用戶在你的文章下面點贊了，而這個點贊行為被匯總到了消息中心，再用消息中心指引作者去到文章頁面查看具體詳情。

所以它是一個匯總表。但也有可能它就是信息來源點，比如一些系統通知，告知要升級，因為它沒有其他功能可承載，所以只會在消息中心里出現。

或者類比 iOS 系統的通知中心，如果通知是 App 推送的，那么它會指引用戶進入某個 App；如果通知是系統行為，如勿擾模式，「6:00 前來電和通知將會靜音」這個通知，是只可在通知中心進行操作的。想要更改，就需要手動打開設置。

2. 通知指示符

它可以是點，也可以是計數器，只要表明目前消息中心有新的信息就可以。我個人一直覺得這就是讓我們多數人養成強迫癥的罪魁禍首。

3. 信息標題

它主要是指該信息來自于誰或屬于什么子類型，比如用戶互動點贊消息，評論消息，系統消息等等。用戶可以通過標題來獲悉該信息類型，再通過內容摘要來判斷內容是否重要。

當然，這里的摘要如果過長，就需要省略處理，引導用戶進入消息源或消息中心。

4. 推送時間

推送時間是一個看起來簡單，實際上也好像不是很復雜的邏輯。只要說明該通知的發送時間即可，但是需要注意的是時間段問題。比如幾分鐘前，幾小時前，幾天前，這里的邏輯是按照時間推進規則持續增加來告知用戶該消息的推送時間節點的。也就是過得越久，時間概念就越大。

5. 通知圖標

上面講到消息類型，我們也經常會在各類產品中發現不同通知的類型會匯總在各自的類型下。包括用戶所接收到的信息，通常也會告知用戶該信息屬于什么類型。有時候，標題可能會更細，但是用戶通過圖標可以判斷該信息屬于什么類型，甚至都不需要仔細查看標題與內容。

但是，并不是所有產品的信息都可以通過圖標來判斷，有時候圖標只是一個大方向，如果手機鎖屏，相對于用戶來說，這條通知只是告訴用戶該信息是由什么產品推送，而并不能指向至該產品的什么類型的信息。所以在使用的過程中，同樣需要根據業務的場景，謹慎地選擇圖標。

6. 閱讀指示器

它就像是上面提到的紅點，這里指的是進入 App 的消息中心之后，所顯示的內容。

7. 操作行為

這里的操作行為分兩種，分別是 App 外與 App 內，它們之間的操作邏輯是不同的。iOS 系統通知的清除操作，只是在系統的通知中心將該信息清除，進入具體 App 后，這條消息還是會存在。而在 App 內刪除該條信息，則該信息才會真正消失。

所以從上面可以看到，通知推送，是有兩大類別的，分別是 App 外與 App 內，它們之間的邏輯關系與展示形式會有所差異，需要根據具體情況進行設計分析。

8. 小結

對上面的內容進行總結，可以得到這樣一幅畫像：

大部分系統或產品的通知組成，都可以通過此圖概括，唯一不同的是，它們會隨著不同的業務而發生變化。

比如豆瓣的推送消息告知用戶近期有新的電影上映，那么通知來源要么是電影模塊的功能詳情頁，要么是通知中心的系統消息；而通知類型就是內容更新；詳情則根據具體內容來組合排列；最后送達至用戶。

而其中的差別就是，如果是通知中心推送的，用戶點擊之后則是進入通知中心列表。如果是具體功能推送的，那么用戶點擊進入的就是具體功能頁面。如下圖所示：

從這里可以看出，通知是有具體模式的。

一旦確定了通知的主要目標，以及想要解決的問題，包括它們如何對業務產生作用以及對用戶形成吸引力，就可以確定通知的具體樣式了。

在這一節里只要知道通知的組成部分與通知模式如何指引用戶進入 App 即可。后面我來帶大家理一遍邏輯，以及在設計通知時要注意哪些問題。

通知的使用方法

聊完上面的內容之后，我相信大家對通知的組成與使用模式已經有了全新的認識，但也僅此而已，我們還是不知道一個優秀的通知功能應該從哪些方面去提升用戶體驗。這里面所包含的不止是表象，還有內在的規則邏輯。所以從這一節開始，我們仔細來梳理一遍。

從我們平時使用到的，以及上文提到的，可以大概先梳理出幾類常見的通知類型。

1. 用戶信息類通知

這種類型的通知有很多，比如微信消息發送，知乎私信，手機短信等等，它們主要由用戶主動生成發送至其他用戶被動接收，作用就是促進用戶與用戶之間的互動關系，以提升用戶使用產品的頻率與時長。

這種通知，可給予用戶操作也可不給予操作，不操作就是讀取，并回復；操作就是可對該用戶的信息進行屏蔽、已讀、刪除等設置。

這是最常見的通知類型，在多數社交產品與有社交特性的產品里都能看到。

說明

之所以給予用戶信息的操作行為，是因為用戶信息可分為感興趣的與不感興趣的，它主要取決于人。不感興趣的人，頻繁的發送信息，會影響用戶對產品的好感度，畢竟有很多用戶消息并不是用戶想要接收的，所以在社交產品里，用戶可刪除好友，或拉黑好友；在有社交屬性的產品里，用戶可拉黑賬戶，以達到不被騷擾的訴求。

如果沒有到達刪除好友的程度，也可對該好友的信息進行屏蔽，甚至對該好友信息做已讀而實際上未讀的處理；或者對重要信息做未讀而實際上已讀的處理。

當然，用戶還能對群消息做更復雜的設置。這就是產品對這類通知的一種優化方式。

2. 系統推送類通知

我們經常會在手機上收到一種系統類通知，或者在 App 中也會收到類似的系統通知。大多是關于系統升級，密碼更新等。

這類通知多數是用戶被動接收，且對于系統與用戶來說是較為重要的。當然也有不重要的，比如 App 更新說明的通知，告知用戶新功能有什么變化，或系統更新了什么等等。

對于這類通知，用戶大多無法進行設置，因為它們比較強制，沒有可以商量的余地，類似于告知用戶：我們有新的消息，比較重要，你來看看，即使你不打算更新或執行也來看下。

說明

系統類通知，通常來說較為被動，要么強制用戶執行操作，要么就是提醒用戶系統近期做了更新，或者是一些并不重要的信息提示，比如勿擾模式。

強制類系統通知不能頻繁，否則會給用戶造成控制欲反制的副作用。類似于本身用戶使用產品需要對產品享有控制權，現在反而被產品控制了。這是不行的。

3. 通用推送類通知

這類通知就是第一節中提到的那些，比如點贊/評論，內容更新等等，這類通知如果是忠實用戶，那么或許不會反感它的頻率，當然還是需要適當。但如果是普通用戶，那么造成的影響就是直接關閉該 App 的所有通知。

我們現在的很多人，之所以開始反感通知的主要原因，就是這類通知所造成的。內容不斷更新，隨著時間的推移，每天推送多條對于該用戶來說無用的通知。包括只適合一些符合條件的用戶參與的活動通知也推送給所有人，那么用戶就會逐漸對這類產品的通知失去興趣，造成無法彌補的損失。

即便像某團一樣，經常彈出開啟通知的彈框，也依然無法召喚回用戶。這就是很典型的下場。

說明

通用型通知，如果是業務很復雜的產品，就必須建立通知推送的功能模塊，給予用戶進行選擇接受哪類信息的權力。允許用戶進行相應的設置，如活動類推送可拒絕接收。

在很多產品中都已經置入這樣的推送模塊設置，如下圖。

這類內容就是針對于產品的具體業務進行細分。

比如興趣精選，私信消息等做好類別劃分。用戶可對自己感興趣的通知做選擇性的推送接收。

另外就是，在相同賬戶的不同設備之間，推送應該同步推送與被處理。不能這邊推送了，那邊沒推送，或者這邊處理了，那邊沒被處理。

4. 智能推送類通知

不知道大家是否有印象，在使用如大眾點評等產品時，只要你切換了城市，產品就會推送通知告知用戶該城市有哪些值得游玩的景點與品嘗的美食。

雖然這類通知還算不上多少智能，但至少在用戶群體中是存在這類訴求的。而這類訴求有時候并不能主動感知，因為用戶可能會想不起來通過哪類產品來查找附近美食。當這么一條通知出現的時候，正好解決了用戶的問題，反而提升了用戶對于產品的好感度。

現在很多產品的通知都逐漸智能化，不會像以前那樣，三更半夜發來一條無關緊要的通知。而出現這類問題的主要原因還是在于產品、設計、運營，在這方面沒有下過功夫，只將通知作為一種普通的工具來使用。導致用戶開始排斥通知，將其強制關閉。之后，就很難再讓用戶開啟了。同理心效應，當做這類功能的時候，可以回想一下自己是如何被其他產品打擾的。

隨著大數據的發展，我相信未來的通知系統會更加全面，且能做到千人千面的模式，不過在此之前，各位產品設計師，還需要對通知下一番功夫才是。

5. 小結

我們還可以繼續舉例說明，但是基本大同小異，所以到這里為止，我再對上面的內容做一次總結，梳理出一個好的通知應該是如何設計的。

干擾最小化：通知本身具有強制性和干擾性。它的目的是把用戶的注意力吸引到產品上來，所以要認真思考發送通知的內容、時間、頻率；不要提醒用戶當前屏幕上已經處于展示狀態的內容；也不要推送與用戶無關的系統信息。

跨設備：當用戶讀過了某條信息，這條信息應該不再做展示。同理，用戶也應該能夠在其它更適合接收消息的設備上找到已讀信息。用戶通知應該在所有設備上進行同步。

允許設置：允許用戶在「設置」中禁止或調整通知的形式。如案例一，通過選擇推送內容，來影響接收推送的頻率。案例二，可選消息提醒的形式是紅點+數字，或僅是紅點。

時效性：良好的通知應盡可能實時推送。而不是等這件事情都過去很久了，才推送給用戶知道。

支持匯總：把同類型的通知合并為一條，并顯示信息未讀數量。也可以考慮一鍵展開通知，顯示信息詳情。

可操作性：把通知和操作結合在一起，讓用戶不需要打開首頁就能對特定通知進行常規操作。操作應該清晰明了，且僅在未重復默認操作時提供。同時操作應該是有意義、實時、和內容對應的，并且能讓用戶完成某個任務。如案例一，可以在不打開郵件的情況下，直接對通知進行管理、查看和清除。案例二中的操作針對的是未讀郵件，可便捷地在通知板面進行回復、刪除、標為已讀或垃圾郵件。

總結

對本篇文章的拓展總結：

• 通知具有召喚屬性，但是頻率過多就會變成打擾，所以要注意通知的頻率與內容重要性；
• 設計師或產品經理應該將通知的內容分類梳理出來，以便維護或新增必要需求可能需要用到的推送信息。
• 通知一般為兩種類型，一類是推送只讀型，一類是操作反饋型；設計師需根據不同類型的通知做好對應的設計，針對具體問題具體分析；
• 想要利用好「通知」，也需要對業務有詳細的了解，再代入本文所列舉的注意點，就可以設計出一個體驗更佳的通知模式。
• 通知規則不會脫離本篇文章的范圍，所以只要詳細研讀，必會有所收獲。

文章來源：站酷

前言

為什么要重視布局

目前主流布局趨勢是怎樣的

-

偏移與疊加網格布局

-

上圖文字與圖片交疊錯落排版，圖片與圖片之間也是網格交錯

上面移動端設計，設計師通過留出左側空網格，整體內容往右側偏移，導航相對內容來說做了差異化設計，并未進行偏移設計（看我上圖紅框部分）  。這樣做的目的是因為，我們點擊漢堡菜單的時候，本來整體就要往右側移動，如果再繼續移動，那么內容會顯示不下，同時視覺效果并沒有很好

半偏移網格布局，界面中并非所有的內容都偏移底層網格，而是部分模塊這樣去做，原因是內容多的情況下。

分屏布局

分屏布局，顧名思義就是將屏幕進行幾種不同區域的劃分，然后內容分布排版在里面，分屏布局解決的主要問題將屏幕大的設備進行合理劃分空間設計，一般是在橫屏運用比較多，比如PAD，或者WEB或者車機中控屏，下面一起看下分屏布局在實際設計中的具體表現

上圖界面設計采用了1/2分屏布局，將圖片與內容文字進行區域劃分，下圖是將主文案擺放在分割區域中間（文字較少情況下可以這樣去做）增強形式感。當然分屏布局可以有多重形式，列如，2/3,1/3，3/4等等，可以根據內容進行選擇合適分屏

Z軸視差布局

-

地址:https://www.stereo.ca/project/clinique-dentaire-gagnon/

內容重疊布局

地址:https://www.stereo.ca/project/clinique-dentaire-gagnon/

卡片布局

卡片布局還有一個最大好處就是，他能夠封裝內容，使得畫面布局整潔，所有內容都往容器里面放，信息之間保持很好的區分

全封閉卡片布局，內容之間通過卡片封裝，中間無空隙

自由式網格布局

如何運用這些布局進行創新設計

-

上面利用樂高積木思維重新對布局進行拆解組合，當然一切的布局都是基于當前你的主旨，你的產品內容，找到合適布局，然后去研究他，并且拆解，然后重新搭建屬于自己產品一套布局規則

總結

-

全文向大家介紹5種布局思路，當然其實不止這5種，但是其他布局相對來說會運用少一些，這些布局我們可以加以學習利用，可以運用在任何設計中去，當然運用的時候，一定要清晰知道自己產品的主旨目標，用戶群體，合理運用布局，做出創新設計！

轉自：站酷-設計TNT 

Patch和Diff算法

網上看了好多的博客和源碼教程，感覺很多仔細的地方沒有說清，而且在一些復雜的部分加了好多的描述，所以就想自己也寫下心得, 方便自己, 方便他人，有興趣的同學可以關注我的github里面有我之前一些博文 github/193Eric



我們知道的，在數據更改后，會觸發getter，然后通過dep.notify()來通知watcher觸發update進而更新視圖，最終是通過Diff算法來對比新老Vnode的差異，并把差異更新到Dom視圖上



Diff

我們知道的，Virtual DOM是一顆樹，而diff算法主要把兩顆樹進行對比，找出之間的差異，來渲染頁面



diff 算法是通過同層的樹節點進行比較而非對樹進行逐層搜索遍歷的方式，所以時間復雜度只有 O(n)，是一種相當的算法



1.調用patch函數比較Vnode和OldVnode,如果不一樣直接return Vnode即將Vnode真實化后替換掉DOM中的節點



2.如果OldVnode和Vnode值得進一步比較則調用patchVnode方法進行進一步比較，分為以下幾種情況：



Vnode有子節點，但是OldVnode沒有，則將Vnode的子節點真實化后添加到真實DOM上



Vnode沒有子節點，但是OldVnode上有，則將真實DOM上相應位置的節點刪除掉



Vnode和OldVnode都有文本節點但是內容不一樣，則將真實DOM上的文本節點替換為Vnode上的文本節點



Vnode和OldVnode上都有子節點，需要調用updateChildren函數進一步比較



updateChildren比較規則



提取出Vnode和OldVnode中的子節點分別為vCh和OldCh，并且提出各自的起始和結尾變量標記為 oldS oldE newS newE



如果是oldS和newE匹配上了，那么真實dom中的第一個節點會移到最后



如果是oldE和newS匹配上了，那么真實dom中的最后一個節點會移到最前，匹配上的兩個指針向中間移動



如果都沒有，在沒有key的情況下直接在DOM的oldS位置的前面添加newS，同時newS+1。在有key的情況下會將newS和Oldch上的所有節點對比，如果有相同的則移動DOM并且將舊節點中這個位置置為null且newS+1。如果還沒有則直接在DOM的oldS位置的前面添加newS且newS+1

直到出現任意一方的start>end，則有一方遍歷結束，整個比較也結束



updateChildren例子：



假設:



真實dom為 A、B、C

oldDom為 A1、B1、C1

newDom為 A2、D2、C2、B2



先確定oldS = A1 ; oldE = C1; newS = A2; newE = B2



先對比oldS和newS,oldE和newE,發現oldS = newS 所以真實dom的A固定不動。排序為 A、B、C

然后oldS = B1 ; oldE = C1; newS = D2; newE = B2



對比發現 oldS = newE , 所以真實dom,B要插入到后面去



真實dom排序為：A、C、B



然后oldS = C1; oldE = C1; newS = D2; newE = B2



對比發現兩兩都不對等，所以走第三步。

假設有key存在，所以newS直接和oldDom里面的所有節點對比，發現沒有存在，然后插入到oldS前面，且newS+1

真實dom排序為：A、D、C、B

然后重新開始，oldS++ > oldE-- ,結束了。



這就是updateChildren，之后就是一直遍歷，運行updateChildren直到沒有

1, JavaScript的Ajax

Ajax的全稱是Asynchronous JavaScript and XML，意思就是用JavaScript執行異步網絡請求，而不需要重載（刷新）整個頁面。

Ajax使用XMLHttpRequest對象取得新數據，然后再通過 DOM 將新數據插入到頁面中。另外，雖然名字中包含 XML 的成分，但 Ajax 通信與數據格式無關; 這種技術就是無須刷新頁面即可從服務器取得數據，但不一定是 XML 數據。

對于IE7+和其他瀏覽器，可以直接使用XMLHttpRequest對象，對于IE6及以前的瀏覽器，使用ActiveXObject對象。



使用方法如下：



var xhr;

if (window.XMLHttpRequest) {

    xhr = new XMLHttpRequest();

} else {

    xhr = new ActiveXObject('Microsoft.XMLHTTP');

}

1

2

3

4

5

6

啟動請求：



xhr.open(method, url, boolean);     

xhr.send();

1

2

注：

1，xhr.open參數含義：

method：請求方式，post、get等

url: 請求鏈接，只能向同源的url發送請求

boolean：是否異步請求，true：異步， false: 同步，默認為true

2，調用 open()方法并不會真正發送請求， 而只是啟動一個請求以備發送。

3，send()方法接收一個參數，即要作為請求主體發送的數據(post方法會使用，get方法直接傳null)。如果不需要通過請求主體發送數據，則必須傳入 null，因為這個參數對有些瀏覽器來說是必需的。調用send()之后，請求就會被分派到服務器。



XMLHttpRequest對象的異步請求示例如下：



function success(text) {

    console.log(text);

}



function fail(code) {

   console.log(code);

}



var xhr = new XMLHttpRequest();     // 新建XMLHttpRequest對象

xhr.onreadystatechange = function () { 

    // 狀態發生變化時，函數被回調

    if (xhr.readyState === 4) { // 成功完成

        // 判斷響應結果:

        if (xhr.status === 200) {

            // 成功，通過responseText拿到響應的文本:

            return success(xhr.responseText);

        } else {

            // 失敗，根據響應碼判斷失敗原因:

            return fail(xhr.status);

        }

    } else {

        // HTTP請求還在繼續...

    }

}



// 發送請求:

xhr.open('get', '/api/categories');

xhr.send(null);

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

xhr的屬性含義如下：

responseText: 作為響應主體被返回的文本。

responseXML: 如果響應的內容類型是"text/xml"或"application/xml"，這個屬性中將保存響應數據的 XML DOM 文檔。

status: 響應的 HTTP 狀態。

statusText: HTTP 狀態的說明。

readyState ：表示請求/響應過程的當前活動階段?？扇≈等缦隆?br />
0: 未初始化。尚未調用 open()方法。

1: 啟動。已經調用 open()方法，但尚未調用 send()方法。

2: 發送。已經調用 send()方法，但尚未接收到響應。

3: 接收。已經接收到部分響應數據。

4: 完成。已經接收到全部響應數據，而且已經可以在客戶端使用了。

只要 readyState 屬性的值由一個值變成另一個值，都會觸發一次 readystatechange 事件?？梢岳眠@個事件來檢測每次狀態變化后readyState 的值。通常，我們只對 readyState 值為 4 的階段感興趣，因為這時所有數據都已經就緒。不過，必須在調用 open()之前指定 onreadystatechange事件處理程序才能確保跨瀏覽器兼容性。



另外，在接收到響應之前還可以調用 abort()方法來取消異步請求:



xhr.abort();

1

調用這個方法后，XHR 對象會停止觸發事件，而且也不再允許訪問任何與響應有關的對象屬性。在終止請求之后，還應該對 XHR 對象進行解引用操作。由于內存原因，不建議重用 XHR 對象。



2， jQuery的Ajax

$.ajax({

        url:"",

        type:"GET",

        contentType: '',

        async:true,

        data:{},

        dataType:"",

        success: function(){

        }

});

1

2

3

4

5

6

7

8

9

10

url 必填項，規定把請求發送到哪個 URL。

type 以什么樣的方式獲取數據，是get或post

contentType：發送POST請求的格式，默認值為’application/x-www-form-urlencoded;

charset=UTF-8’，也可以指定為text/plain、application/json

async 是否異步執行AJAX請求，默認為true，千萬不要指定為false

data 發送的數據，可以是字符串、數組或object。如果是GET請求，data將被轉換成query附加到URL上，如果是POST請求，根據contentType把data序列化成合適的格式；

dataType

接收的數據格式，可以指定為’html’、‘xml’、‘json’、'text’等，缺省情況下根據響應的Content-Type猜測。

success 可選。執行成功時返回的數據。

缺點：

是基于XHR原生開發的，目前已有的fetch可替代。本身是針對mvc的編程模式，不太適合目前mvvm的編程模式。jQuery本身比較大，如果單純的使用ajax可以自己封裝一個，不然會影響性能體驗。



3，Axios

Vue2.0之后，axios開始受到更多的歡迎。其實axios也是對原生XHR的一種封裝，不過是Promise實現版本。它是一個用于瀏覽器和 nodejs 的 HTTP 客戶端，符合的ES規范。



axios具有以下特征：



從瀏覽器中創建 XMLHttpRequest

支持 Promise API

客戶端支持防止CSRF

提供了一些并發請求的接口

從 node.js 創建 http 請求

攔截請求和響應

轉換請求和響應數據

取消請求

自動轉換JSON數據

PS:防止CSRF:就是讓你的每個請求都帶一個從cookie中拿到的key, 根據瀏覽器同源策略，假冒的網站是拿不到你cookie中得key的，這樣，后臺就可以輕松辨別出這個請求是否是用戶在假冒網站上的誤導輸入，從而采取正確的策略。



設置全局的 axios 默認值



axios.defaults.baseURL = '
axios.defaults.headers.common['Authorization'] = AUTH_TOKEN;

axios.defaults.headers.post['Content-Type'] = 'application/x-www-form-urlencoded'

1

2

3

注：axios 的 headers的 content-type 默認是 “application/json ”



默認情況下，axios將JavaScript對象序列化為JSON，如果是get請求，對請求參數不用做任何處理，但是如果是post請求，并且Content-Type 為application/x-www-form-urlencoded，需要使用URLSearchParams API格式化請求參數, 否則Content-Type依然是application/json



var params = new URLSearchParams();

params.append('param1', 'value1');

params.append('param2', 'value2');

1

2

3

get請求，以下3中寫法完全等價



axios.get('/user?id=12345&name=xiaoming')

.then(function (response) {

    console.log(response);

})

.catch(function (error) {

    console.log(error);

});

1

2

3

4

5

6

7

axios.get('/user', {

    params: {

      id: '12345'，

      name: 'xiaoming'

    }

})

.then(function (response) {

    console.log(response);

})

.catch(function (error) {

    console.log(error);

});

1

2

3

4

5

6

7

8

9

10

11

12

axios({

    url: '/user',

    method: 'get',

    params: {

      id: '12345'，

      name: 'xiaoming'

    }

})

.then(function (response) {

    console.log(response);

})

.catch(function (error) {

    console.log(error);

});

1

2

3

4

5

6

7

8

9

10

11

12

13

14

post請求，以下2種寫法完全等價



axios({

    url: '/user',

    method: 'post',

    headers: {

        'Content-Type': 'application/json'

    },

    data: {

      id: '12345'，

      name: 'xiaoming'

    }

})

.then(function (response) {

    console.log(response);

})

.catch(function (error) {

    console.log(error);

});

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

var url = '/user';

var data = {

      id: '12345'，

      name: 'xiaoming'

    };

axios.post(url, data, {

       headers: {

        'Content-Type': 'application/json'

    }

})

.then(function (response) {

    console.log(response);

})

.catch(function (error) {

    console.log(error);

});

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

執行多個并發請求



function getUserAccount() {

  return axios.get('/user/12345');

}

 

function getUserPermissions() {

  return axios.get('/user/12345/permissions');

}

 

axios.all([getUserAccount(), getUserPermissions()])

  .then(axios.spread(function (acct, perms) {

    // 兩個請求現在都執行完成

}));

1

2

3

4

5

6

7

8

9

10

11

12

創建實例



可以使用自定義配置新建一個 axios 實例



axios.create([config])

var instance = axios.create({

  baseURL: '
  timeout: 1000,

  headers: {'X-Custom-Header': 'foobar'}

});

1

2

3

4

5

6

配置會以一個優先順序進行合并，順序由低到高為

1，在 node_modules/axios/lib/defaults.js 找到的庫的默認值

2，實例的 defaults 屬性

3，請求的 config 參數



// 使用由庫提供的配置的默認值來創建實例

// 此時超時配置的默認值是 0

var instance = axios.create();

 

// 覆寫庫的超時默認值

// 現在，所有請求都會等待 2.5 秒

instance.defaults.timeout = 2500;

 

// 為已知需要花費很長時間的請求覆寫超時設置

instance.get('/longRequest', {

  timeout: 5000

});

1

2

3

4

5

6

7

8

9

10

11

12

攔截器



在請求發出之前或響應被 then 或 catch 處理前攔截它們做預處理。



// 添加請求攔截器

axios.interceptors.request.use(function (config) {

    // 在發送請求之前做些什么

  }, function (error) {

    // 對請求錯誤做些什么

  });

 

// 添加響應攔截器

axios.interceptors.response.use(function (response) {

    // 對響應數據做點什么

  }, function (error) {

    // 對響應錯誤做點什么

  });

1

2

3

4

5

6

7

8

9

10

11

12

13

可以在稍后移除攔截器：



var myInterceptor = axios.interceptors.request.use(function () {/.../});

axios.interceptors.request.eject(myInterceptor);

1

2

可以為自定義 axios 實例添加攔截器



var instance = axios.create();

instance.interceptors.request.use(function () {/.../});

1

2

4, fetch

window 自帶了 window.fetch 方法, 在版的 Firefox 和 Chrome 中已經提供支持，其他瀏覽器還有兼容性問題，要做兼容性處理。fetch 是一個 基于promise設計的low-level API，不是ajax的進一步封裝，而是原生js,它注定不會像你習慣的 $.ajax 或是 axios 等庫幫你封裝各種各樣的功能或實現.



interface GlobalFetch {

    fetch(input: RequestInfo, init?: RequestInit): Promise<Response>;

}

1

2

3

fetch()是一個全局的函數，返回一個promise對象。它有兩個參數,第一個參數是請求的地址，第二個參數是可選，RequestInit是個對象格式如下:



interface RequestInit {

    body?: any;

    cache?: RequestCache;

    credentials?: RequestCredentials;

    headers?: HeadersInit;

    integrity?: string;

    keepalive?: boolean;

    method?: string;

    mode?: RequestMode;

    redirect?: RequestRedirect;

    referrer?: string;

    referrerPolicy?: ReferrerPolicy;

    window?: any;

}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

優點：

符合關注分離，沒有將輸入、輸出和用事件來跟蹤的狀態混雜在一個對象里

更好更方便的寫法

更加底層，提供的API豐富

脫離了XHR，是ES規范里新的實現方式

fetch中可以設置mode為"no-cors"(不跨域)



缺點：

fetch不支持同步請求

fetch只對網絡請求報錯，對400,500都當做成功的請求，需要封裝去處理

fetch默認不會帶cookie,需要添加配置項

fetch不支持abort,不支持超時控制，使用setTimeout及Promise.reject的實現的超時控制并不能阻止請求過程繼續在后臺運行，造成了流量的浪費

fetch沒有辦法原生監測請求的進度，而XHR可以



fetch的使用示例：



window.fetch(url)

    .then(response => {

        if (response.ok) {

            //通過 response 原型上的 json 方法將 response.body 轉換為 JS 對象，再返回出去

            return response.json();

        }

    }

).then(result => {

    console.log(result);

}).catch(error => {

    console.log(error);

})

1

2

3

4

5

6

7

8

9

10

11

12

需要注意以下幾點：

1，用 response.ok判斷fetch請求是否成功

2，服務端只返回了response對象，而真正的請求結果，即 response.body，則是一個 ReadableStream。fetch 將 response.body 設計成 ReadableStream 在請求大體積文件時變得非常有用。然而，在我們的日常使用中，還是短小的 JSON 片段更加常見。而為了兼容不常見的設計，我們不得不多一次 response.json() 的調用。不僅是調用變得麻煩，如果你的服務端采用了嚴格的 REST 風格，對于某些特殊情況并沒有返回 JSON 字符串，而是用了 HTTP 狀態碼（如：204 No Content），那么在調用 response.json() 時則會拋出異常。

3，Response 限制了響應內容的重復讀取和轉換，response .json / response.text 方法只能使用一個并且只能使用一次，同時使用兩個，或使用兩次都會報如下錯誤：



Uncaught (in promise) TypeError: Failed to execute 'json' on 'Response': body stream is locked

1

為什么不能使用兩次？

因為數據流只能讀取一次，一旦讀取，數據流變空，再次讀取會報錯。

————————————————

版權聲明：本文為CSDN博主「Sherry慈」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。

原文鏈接：https://blog.csdn.net/weixin_41480546/article/details/102805864

一年一度，天貓雙十一全球狂歡節，如約而至！

從2015年開始，我們每年都會在雙十一期間，將雙十一品牌設計的完整思路分享給大家，這已經成為雙十一設計團隊的傳統。不為別的，各位同仁辛苦一年，想跟大家就著新鮮出爐的設計嘮嘮嗑。

每逢雙十一logo出街，都會有熱心的朋友幫我們解讀，也有人問我們為啥不搞個官方發布？各位朋友，您現在看到的就是官方發布的內容，它不只有logo，而是從頭到尾一個完整的故事。

△ 2019天貓雙十一主logo

△ 2019天貓雙十一主logo多語言版本

今年是雙十一的第十一年，當我們接到這個任務的時候，就有機靈的同學提議：「我們用6個1吧，111111，61兒童節！」、「讓我們回歸購物的純真快樂！」。

「哈哈哈哈哈哈…」魔性的笑聲在整個會議室回蕩，看來往年撓破頭也解不開的難題，就這么解開了？故事當然不會這么簡單，我們還沒有往這個方向嘗試就被否了。

• 其一，雙十一是一個深入人心的認知，這四個一已經成為了超級符號，是我們寶貴的品牌資產，而六個一不但不能幫我們強化認知價值，反而會增加認知成本。
• 其二，六個一是一個純視覺的創意，他很難支撐起我們要傳達的消費者價值，也很難建立起情感連接。

我們應該從哪兒入手？

回歸到設計的本質來思考，我們認為，設計的本質是將一個想法或者觀點巧妙的表達給目標對象，表達的過程中，形式只是手段，重點在于我們要表達什么。

我們集合了阿里各事業部的設計師代表，讓大家回歸到一個普通消費者的狀態，一起聊一聊各自的雙十一故事，把這些故事提煉出來，就是消費者對于雙十一普遍真實的認知。在全年最便宜的一天，無論湊熱鬧也好，跟風也好，貪便宜也好，好像不買點什么總感覺錯過了什么。在這一天，「購物」毫無疑問成為頭等重要的事情。

△ 阿里巴巴經濟體設計師共創

那么我們要對消費者表達「購物」嗎，講我們多么便宜，貨品多么豐富，多么物美價廉？這些是消費者早就形成的認知，是我們不用表達大家都知道的事，它看起來并不是一個想法和觀點。

還是購物，但肯定不是教大家怎么購物，作為消費者，購物能給我們帶來什么？

有人說，購物能讓我們吃飽穿暖，讓我們出行方便，讓我們安居無憂。

如果這些你都有，你為什么還要購物？

因為每個人都向往更好的生活！

為了更好的生活，我們需要通過物品的改善帶來心理的滿足感。當然也有人會會說，滿足感也可以通過其他的方式獲取，比如關愛他人、親近自然、學習、修行、冥想等等，我們非常認同，更好的生活當然不僅僅只有購物。但我們當下探討的范疇僅僅只是「購物」以及「購物」能帶來的滿足感，對這種滿足感的期待，是每一個消費行為的動因。比如你想要買一件新衣服的時候，其實你已經在期待穿上這件新衣服的樣子，你在挑選一件禮物的時候，已經在期待他人收到這件禮物時的反應……

雙十一，全年最便宜的一天，無疑讓你的期待，變得「更值得」期待，所以「更值得」讓大家買得更多。

但，這些洞察還只是幫我們理清了消費行為背后的共性規律，實際上，細分到每個消費者，因為身份角色生活方式的不同，動因各自不同，還不能簡單的用向往更好的生活來概括，因為它太抽象，聽上去對，但每個消費者更關心的是我的需求是不是被滿足，而對于雙十一來講，我們就是要打造屬于每一人的雙十一，而不僅僅只是購物，這樣它才具有節日的文化屬性。

所以，我們開始探尋真實的消費者故事，尋找那些通過物品讓生活變得更好的故事，這些真實的故事，給了我們很大的感觸。我們發現，購物行為下，其實還隱藏了每一個消費者內心更深層的需求，它是一個個藏在心底的愿望，正是這些不同人的愿望，成就了每一個平凡人鮮活的人生。我們想要幫助他們實現自己的愿望。在雙十一當天，幫助每個消費者「愿望11實現」！這才是雙十一更應該滿足的消費者需求，它不僅僅是購物，而是通過物品價值上升到情感價值，這樣的品牌，才真正能夠讓人感受到溫度。

在傾聽這些故事的時候，我們的阿里女神被感動了，她主動要求幫我們寫一首歌，她想把她的感動通過音樂的方式記錄下來，配合我們精選出來的11個故事，講給大家聽。

△ 雙十一品牌設計概念篇mv

「logo出來了？」低沉而沙啞的聲音，把我們從自我陶醉中喚醒，我們找到了想要表達什么，但和怎么表達之間還隔著上百個logo方案。

于是，我們開始了一輪又一輪的打磨，打磨的的重點放在了如何表達「愿望11實現」這一主題，這個過程中，有兩個大方向上的分歧：

一個大方向是表現「愿望」，因為它比較有畫面感，也比較容易表達。

另一個大方向是表現「實現」，因為它是對結果的描述，更符合消費者對結果的預期。

在糾結掙扎過后，我們選擇了把兩個方向融合，劇情貌似又回到了熟悉的設計故事，「把這兩個方案融合一下！」我相信做設計的朋友，一定反復聽過這句話，沒聽過的朋友，那說明你做設計還不久，我保證在你今后的職業生涯里，這句話一定會反復出現。（一個會心的微笑）

融合說起來容易，這么抽象的文字怎么轉換成圖形表達，同時還要和貓頭+11.11融合，為什么要和貓頭+11.11融合呢，因為這是我們重要的品牌形象資產，從2015年開始，貓頭+11.11的組合就固定下來了，這意味著logo的80%的主體已經固定，我們的難點就在于在這20%的區域里，如何既要表達主題，還能做出和往年不一樣的感覺。我敢向你保證，雙十一的logo是所有logo里最難的，沒有之一，至少是我十幾年職業生涯里最硬的茬。

「愿望、實現、貓頭、11.11」這幾個詞反復在腦海里縈繞，經驗告訴我們，當面對如此復雜的局面，我們應該從里面跳出來，換個視角看問題，換什么視角？當然還是再次回到消費者視角，消費者愿望實現時是一種什么樣的狀態？是愿望實現時的滿足？好像還差點意思，愿望平時也能實現，和在雙十一實現愿望有什么不同？

我們認為，它應該是超越你期待的表達，從愿望實現時的滿足，升級到愿望實現時的驚喜！這才是狂歡節該有的味道。當然，驚喜也有很多種它還不夠有體感，如何找準驚喜體感？

答案是感同身受。于是我們開始了場景模擬，模擬消費者逛雙十一的場景。

當我們來到雙十一的時候：「咦！今年好像真的不一樣！」

繼續探索的時候：「呀！找了好久的idou同款原來在這里！」

準備下單的時候：「喔！真的很便宜！」

收到快遞的時候：「哇?。。?！」

聽上去有點夸張，但這確實是我們想要營造給消費者的驚喜，當人感到超越期待的驚喜時，會不自覺的放大瞳孔、張開嘴巴脫口而出。這是人類共通的體感，是不用解釋就有的共鳴。這讓我們瞬間被點亮了，「驚喜到脫口而出！」我們一下子找到了核心創意。

通過反復嘗試，我們發現氣泡形的表達，不僅能成為承載所有消費者愿望的想法框，同時也能成為表達愿望實現時驚喜到脫口而出的對話框，把這個氣泡形和貓頭+11.11結合，這就是我們今年雙十一主logo的原由，這個logo和以往雙十一的logo最大的不同在于，它更像是一個容器，容納不同人不同的個性化表達。它一改之前一直端著的狀態，以一種更加親民，更加個人化的方式呈現給大家。

△ 2019天貓雙十一品牌logo演繹視頻

當然，作為容器，我們還要把核心創意延展到線上線下各個場景。

△ 雙十一定制禮盒

△ 走向全球的雙十一

過去幾年，我們向大家介紹過天貓雙11的主風格的來龍去脈，一定會在創新的基礎上，保持一貫的傳承。所以今年波普藝術的主基調還是會延續下去，問題又回到了我們如何在波普藝術這個大的基調下面，通過老元素的新組合，創造出全新的視覺感受。相比符號，視覺風格更容易表現「驚喜到脫口而出！」這個idea，它可以通過形色質構全方位的表達。

當一個人「驚喜到脫口而出！」的時候，快樂的氣場圍繞在他周圍，這些無形的從中心向四周放散的表現，看上去很像是圓形聲波，同時它還能根據不同人的狀態做動態變化，這就形成了一種設計語言，一種能用固定的形式做出千變萬化的效果的語言。

當我們把它和波普藝術的主基調結合的時候，就形成了今年雙十一獨特的視覺語言，再通過形色質構的拆解，應用到各個場景。

△ 裝置應用

△ 天貓雙十一發布會現場應用

△ 天貓雙十一開幕盛典現場應用

文章來源：優設

這里我截取的是一個圖片，實際上是會動的。廢話不多說，上代碼。

HTML：



<canvas id="canvas"></canvas>

1

CSS：



/css reset /

body,p,div,ol,ul,li,dl,dt,dd,h1,h2,h3,h4,h5,h6,form,input,iframe,nav {

    margin: 0;

    padding: 0;

}

html,body {

    width: 100%;

    height: 100%;

}

body {

    font: 14px Microsoft YaHei;

    -webkit-text-size-adjust:100%;

    -moz-user-select: none;

    -webkit-user-select: none;

    user-select: none;

    position: relative;

    background: #000;

}

canvas {

    width: 100%;

    height: 100%;

    display: block;

    opacity: .8;

}





// 音量大小,0.01-1





//宇宙

var canvas = document.getElementById('canvas'),

ctx = canvas.getContext('2d'),

w = canvas.width = window.innerWidth,

h = canvas.height = window.innerHeight,



hue = 217,

stars = [],

count = 0,

maxStars = 1100;                //星星數量,默認1300

var canvas2 = document.createElement('canvas'),

ctx2 = canvas2.getContext('2d');

canvas2.width = 100;

canvas2.height = 100;

var half = canvas2.width / 2,

gradient2 = ctx2.createRadialGradient(half, half, 0, half, half, half);

gradient2.addColorStop(0.025, '#CCC');

gradient2.addColorStop(0.1, 'hsl(' + hue + ', 61%, 33%)');

gradient2.addColorStop(0.25, 'hsl(' + hue + ', 64%, 6%)');

gradient2.addColorStop(1, 'transparent');



ctx2.fillStyle = gradient2;

ctx2.beginPath();

ctx2.arc(half, half, half, 0, Math.PI 2);

ctx2.fill();



// End cache

function random(min, max) {

    if (arguments.length < 2) {

        max = min;

        min = 0;

    }



    if (min > max) {

        var hold = max;

        max = min;

        min = hold;

    }



    return Math.floor(Math.random() (max - min + 1)) + min;

}



function maxOrbit(x, y) {

    var max = Math.max(x, y),

    diameter = Math.round(Math.sqrt(max max + max max));

    return diameter / 2;

    //星星移動范圍，值越大范圍越小，

}



var Star = function() {



    this.orbitRadius = random(maxOrbit(w, h));

    this.radius = random(60, this.orbitRadius) / 10;       //星星大小,值越大星星越小,默認8

    

    this.orbitX = w / 2;

    this.orbitY = h / 2;

    this.timePassed = random(0, maxStars);

    this.speed = random(this.orbitRadius) / 80000;        //星星移動速度,值越大越慢,默認5W

    

    this.alpha = random(2, 10) / 10;



    count++;

    stars[count] = this;

}



Star.prototype.draw = function() {

    var x = Math.sin(this.timePassed) this.orbitRadius + this.orbitX,

    y = Math.cos(this.timePassed) this.orbitRadius + this.orbitY,

    twinkle = random(10);



    if (twinkle === 1 && this.alpha > 0) {

        this.alpha -= 0.05;

    } else if (twinkle === 2 && this.alpha < 1) {

        this.alpha += 0.05;

    }



    ctx.globalAlpha = this.alpha;

    ctx.drawImage(canvas2, x - this.radius / 2, y - this.radius / 2, this.radius, this.radius);

    this.timePassed += this.speed;

}



for (var i = 0; i < maxStars; i++) {

    new Star();

}



function animation() {

    ctx.globalCompositeOperation = 'source-over';

    ctx.globalAlpha = 0.5;                                 //尾巴

    ctx.fillStyle = 'hsla(' + hue + ', 64%, 6%, 2)';

    ctx.fillRect(0, 0, w, h)



    ctx.globalCompositeOperation = 'lighter';

    for (var i = 1,

    l = stars.length; i < l; i++) {

        stars[i].draw();

    };



    window.requestAnimationFrame(animation);

}



animation();

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