node系列之?dāng)?shù)據(jù)接口注冊(cè)登陸接口的實(shí)現(xiàn)

1、使用express腳手架創(chuàng)建項(xiàng)目

2、了解項(xiàng)目的目錄結(jié)構(gòu)

3、準(zhǔn)備數(shù)據(jù)庫(kù)相關(guān)文件

4、編寫(xiě)注冊(cè)接口

5、編寫(xiě)登陸接口

6、驗(yàn)證登陸實(shí)現(xiàn)

7、預(yù)告

1、使用express腳手架創(chuàng)建項(xiàng)目

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

npm i express-generator -g

// 創(chuàng)建express項(xiàng)目

express myapp --view=ejs

cd myapp

// 安裝依賴(lài)

npm i 

// 安裝需要使用的模塊

// 數(shù)據(jù)庫(kù)模塊 用戶(hù)唯一id模塊 密碼加密模塊 token模塊

npm i mongoose node-uuid bcryptjs jsonwebtoken -S



2、了解項(xiàng)目的目錄結(jié)構(gòu)

bin

www ------- 服務(wù)器啟動(dòng)

node_modules ------- 項(xiàng)目的依賴(lài)文件

public ------- 靜態(tài)資源文件夾

images ------- 靜態(tài)圖片

javascripts ------- 靜態(tài)的js文件

stylesheets ------- 靜態(tài)的樣式表文件

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

index.js ------- 默認(rèn)的路由

users.js ------- 用戶(hù)相關(guān)的路由

views ------- 路由對(duì)應(yīng)的頁(yè)面

index.ejs ------- 默認(rèn)的首頁(yè)

error.ejs ------- 錯(cuò)誤頁(yè)面

app.js ------- 使用中間件，注冊(cè)路由

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

3、準(zhǔn)備數(shù)據(jù)庫(kù)相關(guān)文件

大勛在node系列之?dāng)?shù)據(jù)庫(kù)mongoose的封裝中給大家介紹了如何封裝mongoose，可以先行查看如何封裝，封裝的文件夾為sql，如果不想看的，可以直接通過(guò)網(wǎng)盤(pán)下載該文件夾



將該sql文件放置項(xiàng)目的跟目錄下

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

在網(wǎng)頁(yè)和移動(dòng)端界面中，內(nèi)容和信息是否能夠經(jīng)過(guò)系統(tǒng)性、有效的整理和組織，對(duì)于內(nèi)容的可用性和實(shí)用性，都是意義巨大的。而在呈現(xiàn)信息的時(shí)候，視覺(jué)間隔是組織信息的關(guān)鍵因素。它說(shuō)起來(lái)并不難理解，但是在實(shí)際的運(yùn)用當(dāng)中，卻是千變?nèi)f化，今天我們來(lái)梳理一下流行的視覺(jué)間隔的方法。

什么是視覺(jué)間隔

視覺(jué)間隔是一種布局元素，它有助于將內(nèi)容分隔成為清晰的分組、選項(xiàng)和部分。它可以讓設(shè)計(jì)師更好地組織內(nèi)容的視覺(jué)體驗(yàn)，處理信息的層級(jí)，也有助于用戶(hù)理解內(nèi)容，明白內(nèi)容之間的關(guān)系。

視覺(jué)間隔和頁(yè)面上的其他內(nèi)容在一起，構(gòu)成視覺(jué)層級(jí)，這是它最重要的作用。在視覺(jué)間隔的幫助之下，用戶(hù)可以輕松地感知內(nèi)容之間的關(guān)系，明白各個(gè)信息片段之間的關(guān)系是相似，并列，承襲，從屬，還是其他。

視覺(jué)間隔的可用性也同樣重要：在很多時(shí)候，有的視覺(jué)間隔元素看起來(lái)是可點(diǎn)擊，可交互的，這在移動(dòng)端界面上，是非常重要的。

視覺(jué)間隔的種類(lèi)

談到視覺(jué)間隔，我們可以從兩方面來(lái)進(jìn)行拆解分析：視覺(jué)間隔的外觀和功能。按照視覺(jué)特征，視覺(jué)間隔有5種基本的類(lèi)型：

• 線條
• 色彩
• 負(fù)空間
• 陰影/體積
• 圖片

下面我們分別針對(duì)這5種類(lèi)型進(jìn)行說(shuō)明。

線條

很長(zhǎng)時(shí)間以來(lái)，在排版印刷領(lǐng)域，線條就一直是一種用來(lái)分隔內(nèi)容的方法。線條的分隔功能是認(rèn)可度最高的一種間隔方式，用戶(hù)幾乎不用思考，就能夠理解和感知它，并且發(fā)揮作用。

另一方面，這種間隔方式也很容易顯得過(guò)于簡(jiǎn)單，并且和應(yīng)有的形態(tài)相去甚遠(yuǎn)。這也是為什么設(shè)計(jì)師在想盡辦法去尋求別的視覺(jué)間隔形態(tài)。太多的線條間隔會(huì)讓屏幕上的視覺(jué)干擾太多，并且?guī)?lái)不必要的視覺(jué)噪音。

所以，能夠?qū)⒕€條間隔用得微妙、恰到好處、出神入化，是設(shè)計(jì)師功力的一個(gè)重要體現(xiàn)。

在這個(gè)網(wǎng)站產(chǎn)品頁(yè)面中，使用深色的線條間隔來(lái)分割產(chǎn)品信息，用來(lái)組織和間隔信息內(nèi)容。

在這個(gè)頁(yè)面當(dāng)中，線條分隔了不同的內(nèi)容區(qū)塊，讓頁(yè)面的結(jié)構(gòu)更易于被掃讀。

這個(gè)電商網(wǎng)站將不同級(jí)別的視覺(jué)內(nèi)容進(jìn)行了分離，借助簡(jiǎn)單的水平線將價(jià)格、CTA按鈕以及承載相關(guān)信息的表單分隔到不同的區(qū)域。

負(fù)空間

負(fù)空間，也就是留白，也是最為常見(jiàn)的一種視覺(jué)分隔元素。留白絕不是對(duì)空間的浪費(fèi)，和屏幕上其他的元素一樣，它同樣發(fā)揮著重要的作用，拱衛(wèi)支撐著整個(gè)用戶(hù)體驗(yàn)。負(fù)空間是最為流行的視覺(jué)分隔之一，尤其是在極簡(jiǎn)主義風(fēng)格為主導(dǎo)的設(shè)計(jì)當(dāng)中。負(fù)空間本身遵循著格式塔原理，尤其是其中「接近原理」和「相似原理」是負(fù)空間在設(shè)計(jì)中，發(fā)揮分隔作用的核心所在。合理地運(yùn)用負(fù)空間，還能強(qiáng)化頁(yè)面的呼吸感。

上面這款旅行規(guī)劃 APP當(dāng)中，使用留白將不同的條目分開(kāi)，沒(méi)有使用額外的具體視覺(jué)元素，僅僅只靠留白。

Health Blog 的列表的排版層次是基于負(fù)空間來(lái)實(shí)現(xiàn)的，看起來(lái)清晰又充滿呼吸感。

色彩對(duì)比

高對(duì)比度的色彩，同樣能夠帶來(lái)清晰的視覺(jué)間隔效果。在 UI 界面中高對(duì)比度的色彩有著極為明顯視覺(jué)表現(xiàn)潛質(zhì)，它們能夠增強(qiáng)網(wǎng)站的信息和內(nèi)容的表現(xiàn)力，分割區(qū)塊，營(yíng)造氛圍。對(duì)比度是影響頁(yè)面和屏幕可讀性的關(guān)鍵因素之一。在具體的應(yīng)用當(dāng)中，不同的色彩會(huì)有效地分離不同的選項(xiàng)、條目和區(qū)域，這意味著它作為視覺(jué)分隔的作用非常強(qiáng)。這也是近年來(lái)分屏式設(shè)計(jì)如此流行的原因所在。

這是一套移動(dòng)端菜單的概念設(shè)計(jì)，強(qiáng)烈的色彩對(duì)比讓信息清晰可見(jiàn)。

即使是在這樣的柔和的設(shè)計(jì)當(dāng)中，色彩的對(duì)比度也發(fā)揮了相當(dāng)?shù)淖饔茫阂环矫妫瑥?qiáng)烈的色彩對(duì)比讓CTA按鈕和輸入框之間有了明顯的區(qū)分，另一方面，右側(cè)的主視覺(jué)元素的背景也同樣借由不同色彩的對(duì)比，做到了突出的效果。

在 GNO Blankets 這個(gè)網(wǎng)站當(dāng)中，強(qiáng)烈的明暗對(duì)比將網(wǎng)站元素分隔成為精美而清晰的區(qū)塊。

陰影和體積

陰影和體積也是一種非常常見(jiàn)的視覺(jué)間隔方式，通過(guò)營(yíng)造在「高度」或者說(shuō)高程上的視覺(jué)差異，從而達(dá)到分層的效果，而這種設(shè)計(jì)也是符合人類(lèi)一直以來(lái)的認(rèn)知習(xí)慣。這種方法有利于保持整個(gè)設(shè)計(jì)的平衡和易讀性，另一方面，它又能保持足夠的微妙和自然，不會(huì)那么引人矚目從而讓人覺(jué)得出戲或者受到干擾。

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

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

圖片

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

這個(gè)比特幣網(wǎng)站的著陸頁(yè)就使用了帶有3D效果「了解更多」動(dòng)態(tài)圖片，圖片和文本在內(nèi)容和功能上都清晰地分隔開(kāi)來(lái)。

在這個(gè)餐廳 APP 當(dāng)中，圖片作為劃分內(nèi)容的關(guān)鍵元素而存在。

按照功能劃分

如果從功能的角度上來(lái)劃分視覺(jué)間隔，可以根據(jù)它所處的層次來(lái)進(jìn)行劃分。

全出血間隔

使用線條作為全出血間隔是最為常見(jiàn)的，它會(huì)很跨整個(gè)屏幕布局來(lái)作為信息層級(jí)的劃分。

這個(gè)畫(huà)廊圖庫(kù) APP 的藝術(shù)家目錄當(dāng)中，使用線條作為全出血間隔，來(lái)區(qū)分藝術(shù)家。

這個(gè)名為完美食譜的APP也使用了全出血間隔線來(lái)區(qū)分內(nèi)容。

在這個(gè)財(cái)務(wù)APP當(dāng)中，也使用了全出血間隔線來(lái)區(qū)分條目。

在這個(gè)電影APP的結(jié)帳頁(yè)面當(dāng)中，也使用了線條來(lái)作為全出血間隔。

嵌入式間隔

嵌入式間隔的功能是將相關(guān)性較高的內(nèi)容分割開(kāi)，并且它通常會(huì)和標(biāo)題或者其他的特定元素保持對(duì)齊或者對(duì)應(yīng)，它們通常是進(jìn)行某個(gè)大區(qū)塊內(nèi)不同組件的分隔，或者將多個(gè)同類(lèi)的元素分隔開(kāi)。

這個(gè)網(wǎng)站當(dāng)中，使用橫向的短分隔線來(lái)區(qū)分表單中的參數(shù)條目。

中間分隔

這種分割線通常會(huì)置于布局的中間某處，同樣是分隔相關(guān)的內(nèi)容，但是通常它們?cè)趯傩陨喜灰欢ㄊ且恢碌?，但是層?jí)近似。

在這個(gè)出售草藥的電商網(wǎng)站的右側(cè)，使用中間分隔線將文本和可交互的區(qū)域清晰地分隔開(kāi)。

值得思考的問(wèn)題

上面對(duì)于不同類(lèi)型的視覺(jué)分隔方式都有描述，在此之外，還有兩個(gè)問(wèn)題需要注意：

• 保持微妙：視覺(jué)分隔不應(yīng)該醒目、太過(guò)引人矚目，它們不應(yīng)該分散用戶(hù)的注意力，它們應(yīng)該支撐布局的同時(shí)，微妙而不那么抓人眼球。

• 中等頻率：這和上一點(diǎn)是相輔相承的，過(guò)多的分隔線會(huì)變成視覺(jué)噪音，讓用戶(hù)瀏覽的時(shí)候感到疲倦。因此，應(yīng)該仔細(xì)考慮使用頻率，盡可能使用負(fù)空間，而不是線條。不要過(guò)度使用太多色彩，應(yīng)該盡量保持整體的協(xié)調(diào)一致。

文章來(lái)源：站酷

我們通過(guò)門(mén)鈴聲兒得知門(mén)外有人來(lái)訪，也能通過(guò)電話鈴聲得知正被人呼叫。短信通知也有著類(lèi)似的作用，包括各類(lèi)產(chǎn)品的消息推送。

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

而且，通知越來(lái)越多地通過(guò)各種方式去觸達(dá)用戶(hù)。比如消息未讀的紅點(diǎn)提示，或者顯示消息的數(shù)字統(tǒng)計(jì)，以及手機(jī)使用過(guò)程中的頂部提示與聲音或震動(dòng)的提醒，等等。

但我們還是無(wú)法抑制點(diǎn)擊圖標(biāo)的沖動(dòng)，這僅僅是因?yàn)樗哂形醋x的計(jì)數(shù)或紅點(diǎn)提示，即使我們已經(jīng)知道當(dāng)中的內(nèi)容并不重要。

而我要說(shuō)的是，當(dāng)通知內(nèi)容變得次要且被濫用之后，它仿佛成了一種違背設(shè)計(jì)原則的功能 —— 中斷用戶(hù)當(dāng)前行為。因?yàn)樗蚱屏擞脩?hù)與產(chǎn)品之間的層級(jí)關(guān)系，破局至產(chǎn)品之外來(lái)吸引用戶(hù)的注意力，這是一個(gè)非常打擾的行為。如果我在看書(shū)，突然收到一條并不重要的消息，那我一定會(huì)非常反感。

所以，為了不被「紅點(diǎn)」支配，以及不讓通知所打擾，我會(huì)把手機(jī)里所有產(chǎn)品的消息推送都給關(guān)了。

但是，以上內(nèi)容并不能說(shuō)明通知的無(wú)用論。同樣有許多用戶(hù)還是沉迷于通知的使用上，它所控制的是用戶(hù)對(duì)于某個(gè)產(chǎn)品的控制欲，擔(dān)心錯(cuò)過(guò)某條消息，就好像我在豆瓣寫(xiě)了篇隨筆，就想看別人給我點(diǎn)贊評(píng)論的消息，但我又不可能一直盯著，所以通知這時(shí)候就起到了一個(gè)很好的作用。

以至于對(duì)于優(yōu)秀的產(chǎn)品人或設(shè)計(jì)師，包括運(yùn)營(yíng)來(lái)說(shuō)，利用好通知，就能掌握用戶(hù)心理，巧妙的將用戶(hù)留在產(chǎn)品中。它們甚至有助于與打算放棄產(chǎn)品的用戶(hù)建立聯(lián)系并促進(jìn)互動(dòng)。

那么，我們應(yīng)該如何更合理的設(shè)計(jì)通知呢？下面我們通過(guò)「通知的組成部分」以及「通知的使用類(lèi)型與規(guī)則」來(lái)詳細(xì)做一次拆解。

通知的組成部分

關(guān)于通知的簡(jiǎn)單定義：它是一種吸引用戶(hù)注意的功能模式，讓用戶(hù)獲悉新事件的信息動(dòng)態(tài)。產(chǎn)品將其發(fā)送給用戶(hù)并與用戶(hù)產(chǎn)生交流。

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

被動(dòng)只讀型，是指該信息可讀，但不可進(jìn)行操作；操作反饋型，是指用戶(hù)可對(duì)該通知進(jìn)行操作，如某寶訂單支付成功后的地址信息確認(rèn)通知。

所以在梳理組件的時(shí)候也要注意掉這個(gè)差異。

1. 消息中心

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

所以它是一個(gè)匯總表。但也有可能它就是信息來(lái)源點(diǎn)，比如一些系統(tǒng)通知，告知要升級(jí)，因?yàn)樗鼪](méi)有其他功能可承載，所以只會(huì)在消息中心里出現(xiàn)。

或者類(lèi)比 iOS 系統(tǒng)的通知中心，如果通知是 App 推送的，那么它會(huì)指引用戶(hù)進(jìn)入某個(gè) App；如果通知是系統(tǒng)行為，如勿擾模式，「6:00 前來(lái)電和通知將會(huì)靜音」這個(gè)通知，是只可在通知中心進(jìn)行操作的。想要更改，就需要手動(dòng)打開(kāi)設(shè)置。

2. 通知指示符

它可以是點(diǎn)，也可以是計(jì)數(shù)器，只要表明目前消息中心有新的信息就可以。我個(gè)人一直覺(jué)得這就是讓我們多數(shù)人養(yǎng)成強(qiáng)迫癥的罪魁禍?zhǔn)住?

3. 信息標(biāo)題

它主要是指該信息來(lái)自于誰(shuí)或?qū)儆谑裁醋宇?lèi)型，比如用戶(hù)互動(dòng)點(diǎn)贊消息，評(píng)論消息，系統(tǒng)消息等等。用戶(hù)可以通過(guò)標(biāo)題來(lái)獲悉該信息類(lèi)型，再通過(guò)內(nèi)容摘要來(lái)判斷內(nèi)容是否重要。

當(dāng)然，這里的摘要如果過(guò)長(zhǎng)，就需要省略處理，引導(dǎo)用戶(hù)進(jìn)入消息源或消息中心。

4. 推送時(shí)間

推送時(shí)間是一個(gè)看起來(lái)簡(jiǎn)單，實(shí)際上也好像不是很復(fù)雜的邏輯。只要說(shuō)明該通知的發(fā)送時(shí)間即可，但是需要注意的是時(shí)間段問(wèn)題。比如幾分鐘前，幾小時(shí)前，幾天前，這里的邏輯是按照時(shí)間推進(jìn)規(guī)則持續(xù)增加來(lái)告知用戶(hù)該消息的推送時(shí)間節(jié)點(diǎn)的。也就是過(guò)得越久，時(shí)間概念就越大。

5. 通知圖標(biāo)

上面講到消息類(lèi)型，我們也經(jīng)常會(huì)在各類(lèi)產(chǎn)品中發(fā)現(xiàn)不同通知的類(lèi)型會(huì)匯總在各自的類(lèi)型下。包括用戶(hù)所接收到的信息，通常也會(huì)告知用戶(hù)該信息屬于什么類(lèi)型。有時(shí)候，標(biāo)題可能會(huì)更細(xì)，但是用戶(hù)通過(guò)圖標(biāo)可以判斷該信息屬于什么類(lèi)型，甚至都不需要仔細(xì)查看標(biāo)題與內(nèi)容。

但是，并不是所有產(chǎn)品的信息都可以通過(guò)圖標(biāo)來(lái)判斷，有時(shí)候圖標(biāo)只是一個(gè)大方向，如果手機(jī)鎖屏，相對(duì)于用戶(hù)來(lái)說(shuō)，這條通知只是告訴用戶(hù)該信息是由什么產(chǎn)品推送，而并不能指向至該產(chǎn)品的什么類(lèi)型的信息。所以在使用的過(guò)程中，同樣需要根據(jù)業(yè)務(wù)的場(chǎng)景，謹(jǐn)慎地選擇圖標(biāo)。

6. 閱讀指示器

它就像是上面提到的紅點(diǎn)，這里指的是進(jìn)入 App 的消息中心之后，所顯示的內(nèi)容。

7. 操作行為

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

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

8. 小結(jié)

對(duì)上面的內(nèi)容進(jìn)行總結(jié)，可以得到這樣一幅畫(huà)像：

大部分系統(tǒng)或產(chǎn)品的通知組成，都可以通過(guò)此圖概括，唯一不同的是，它們會(huì)隨著不同的業(yè)務(wù)而發(fā)生變化。

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

而其中的差別就是，如果是通知中心推送的，用戶(hù)點(diǎn)擊之后則是進(jìn)入通知中心列表。如果是具體功能推送的，那么用戶(hù)點(diǎn)擊進(jìn)入的就是具體功能頁(yè)面。如下圖所示：

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

一旦確定了通知的主要目標(biāo)，以及想要解決的問(wèn)題，包括它們?nèi)绾螌?duì)業(yè)務(wù)產(chǎn)生作用以及對(duì)用戶(hù)形成吸引力，就可以確定通知的具體樣式了。

在這一節(jié)里只要知道通知的組成部分與通知模式如何指引用戶(hù)進(jìn)入 App 即可。后面我來(lái)帶大家理一遍邏輯，以及在設(shè)計(jì)通知時(shí)要注意哪些問(wèn)題。

通知的使用方法

聊完上面的內(nèi)容之后，我相信大家對(duì)通知的組成與使用模式已經(jīng)有了全新的認(rèn)識(shí)，但也僅此而已，我們還是不知道一個(gè)優(yōu)秀的通知功能應(yīng)該從哪些方面去提升用戶(hù)體驗(yàn)。這里面所包含的不止是表象，還有內(nèi)在的規(guī)則邏輯。所以從這一節(jié)開(kāi)始，我們仔細(xì)來(lái)梳理一遍。

從我們平時(shí)使用到的，以及上文提到的，可以大概先梳理出幾類(lèi)常見(jiàn)的通知類(lèi)型。

1. 用戶(hù)信息類(lèi)通知

這種類(lèi)型的通知有很多，比如微信消息發(fā)送，知乎私信，手機(jī)短信等等，它們主要由用戶(hù)主動(dòng)生成發(fā)送至其他用戶(hù)被動(dòng)接收，作用就是促進(jìn)用戶(hù)與用戶(hù)之間的互動(dòng)關(guān)系，以提升用戶(hù)使用產(chǎn)品的頻率與時(shí)長(zhǎng)。

這種通知，可給予用戶(hù)操作也可不給予操作，不操作就是讀取，并回復(fù)；操作就是可對(duì)該用戶(hù)的信息進(jìn)行屏蔽、已讀、刪除等設(shè)置。

這是最常見(jiàn)的通知類(lèi)型，在多數(shù)社交產(chǎn)品與有社交特性的產(chǎn)品里都能看到。

說(shuō)明

之所以給予用戶(hù)信息的操作行為，是因?yàn)橛脩?hù)信息可分為感興趣的與不感興趣的，它主要取決于人。不感興趣的人，頻繁的發(fā)送信息，會(huì)影響用戶(hù)對(duì)產(chǎn)品的好感度，畢竟有很多用戶(hù)消息并不是用戶(hù)想要接收的，所以在社交產(chǎn)品里，用戶(hù)可刪除好友，或拉黑好友；在有社交屬性的產(chǎn)品里，用戶(hù)可拉黑賬戶(hù)，以達(dá)到不被騷擾的訴求。

如果沒(méi)有到達(dá)刪除好友的程度，也可對(duì)該好友的信息進(jìn)行屏蔽，甚至對(duì)該好友信息做已讀而實(shí)際上未讀的處理；或者對(duì)重要信息做未讀而實(shí)際上已讀的處理。

當(dāng)然，用戶(hù)還能對(duì)群消息做更復(fù)雜的設(shè)置。這就是產(chǎn)品對(duì)這類(lèi)通知的一種優(yōu)化方式。

2. 系統(tǒng)推送類(lèi)通知

我們經(jīng)常會(huì)在手機(jī)上收到一種系統(tǒng)類(lèi)通知，或者在 App 中也會(huì)收到類(lèi)似的系統(tǒng)通知。大多是關(guān)于系統(tǒng)升級(jí)，密碼更新等。

這類(lèi)通知多數(shù)是用戶(hù)被動(dòng)接收，且對(duì)于系統(tǒng)與用戶(hù)來(lái)說(shuō)是較為重要的。當(dāng)然也有不重要的，比如 App 更新說(shuō)明的通知，告知用戶(hù)新功能有什么變化，或系統(tǒng)更新了什么等等。

對(duì)于這類(lèi)通知，用戶(hù)大多無(wú)法進(jìn)行設(shè)置，因?yàn)樗鼈儽容^強(qiáng)制，沒(méi)有可以商量的余地，類(lèi)似于告知用戶(hù)：我們有新的消息，比較重要，你來(lái)看看，即使你不打算更新或執(zhí)行也來(lái)看下。

說(shuō)明

系統(tǒng)類(lèi)通知，通常來(lái)說(shuō)較為被動(dòng)，要么強(qiáng)制用戶(hù)執(zhí)行操作，要么就是提醒用戶(hù)系統(tǒng)近期做了更新，或者是一些并不重要的信息提示，比如勿擾模式。

強(qiáng)制類(lèi)系統(tǒng)通知不能頻繁，否則會(huì)給用戶(hù)造成控制欲反制的副作用。類(lèi)似于本身用戶(hù)使用產(chǎn)品需要對(duì)產(chǎn)品享有控制權(quán)，現(xiàn)在反而被產(chǎn)品控制了。這是不行的。

3. 通用推送類(lèi)通知

這類(lèi)通知就是第一節(jié)中提到的那些，比如點(diǎn)贊/評(píng)論，內(nèi)容更新等等，這類(lèi)通知如果是忠實(shí)用戶(hù)，那么或許不會(huì)反感它的頻率，當(dāng)然還是需要適當(dāng)。但如果是普通用戶(hù)，那么造成的影響就是直接關(guān)閉該 App 的所有通知。

我們現(xiàn)在的很多人，之所以開(kāi)始反感通知的主要原因，就是這類(lèi)通知所造成的。內(nèi)容不斷更新，隨著時(shí)間的推移，每天推送多條對(duì)于該用戶(hù)來(lái)說(shuō)無(wú)用的通知。包括只適合一些符合條件的用戶(hù)參與的活動(dòng)通知也推送給所有人，那么用戶(hù)就會(huì)逐漸對(duì)這類(lèi)產(chǎn)品的通知失去興趣，造成無(wú)法彌補(bǔ)的損失。

即便像某團(tuán)一樣，經(jīng)常彈出開(kāi)啟通知的彈框，也依然無(wú)法召喚回用戶(hù)。這就是很典型的下場(chǎng)。

說(shuō)明

通用型通知，如果是業(yè)務(wù)很復(fù)雜的產(chǎn)品，就必須建立通知推送的功能模塊，給予用戶(hù)進(jìn)行選擇接受哪類(lèi)信息的權(quán)力。允許用戶(hù)進(jìn)行相應(yīng)的設(shè)置，如活動(dòng)類(lèi)推送可拒絕接收。

在很多產(chǎn)品中都已經(jīng)置入這樣的推送模塊設(shè)置，如下圖。

這類(lèi)內(nèi)容就是針對(duì)于產(chǎn)品的具體業(yè)務(wù)進(jìn)行細(xì)分。

比如興趣精選，私信消息等做好類(lèi)別劃分。用戶(hù)可對(duì)自己感興趣的通知做選擇性的推送接收。

另外就是，在相同賬戶(hù)的不同設(shè)備之間，推送應(yīng)該同步推送與被處理。不能這邊推送了，那邊沒(méi)推送，或者這邊處理了，那邊沒(méi)被處理。

4. 智能推送類(lèi)通知

不知道大家是否有印象，在使用如大眾點(diǎn)評(píng)等產(chǎn)品時(shí)，只要你切換了城市，產(chǎn)品就會(huì)推送通知告知用戶(hù)該城市有哪些值得游玩的景點(diǎn)與品嘗的美食。

雖然這類(lèi)通知還算不上多少智能，但至少在用戶(hù)群體中是存在這類(lèi)訴求的。而這類(lèi)訴求有時(shí)候并不能主動(dòng)感知，因?yàn)橛脩?hù)可能會(huì)想不起來(lái)通過(guò)哪類(lèi)產(chǎn)品來(lái)查找附近美食。當(dāng)這么一條通知出現(xiàn)的時(shí)候，正好解決了用戶(hù)的問(wèn)題，反而提升了用戶(hù)對(duì)于產(chǎn)品的好感度。

現(xiàn)在很多產(chǎn)品的通知都逐漸智能化，不會(huì)像以前那樣，三更半夜發(fā)來(lái)一條無(wú)關(guān)緊要的通知。而出現(xiàn)這類(lèi)問(wèn)題的主要原因還是在于產(chǎn)品、設(shè)計(jì)、運(yùn)營(yíng)，在這方面沒(méi)有下過(guò)功夫，只將通知作為一種普通的工具來(lái)使用。導(dǎo)致用戶(hù)開(kāi)始排斥通知，將其強(qiáng)制關(guān)閉。之后，就很難再讓用戶(hù)開(kāi)啟了。同理心效應(yīng)，當(dāng)做這類(lèi)功能的時(shí)候，可以回想一下自己是如何被其他產(chǎn)品打擾的。

隨著大數(shù)據(jù)的發(fā)展，我相信未來(lái)的通知系統(tǒng)會(huì)更加全面，且能做到千人千面的模式，不過(guò)在此之前，各位產(chǎn)品設(shè)計(jì)師，還需要對(duì)通知下一番功夫才是。

5. 小結(jié)

我們還可以繼續(xù)舉例說(shuō)明，但是基本大同小異，所以到這里為止，我再對(duì)上面的內(nèi)容做一次總結(jié)，梳理出一個(gè)好的通知應(yīng)該是如何設(shè)計(jì)的。

干擾最小化：通知本身具有強(qiáng)制性和干擾性。它的目的是把用戶(hù)的注意力吸引到產(chǎn)品上來(lái)，所以要認(rèn)真思考發(fā)送通知的內(nèi)容、時(shí)間、頻率；不要提醒用戶(hù)當(dāng)前屏幕上已經(jīng)處于展示狀態(tài)的內(nèi)容；也不要推送與用戶(hù)無(wú)關(guān)的系統(tǒng)信息。

跨設(shè)備：當(dāng)用戶(hù)讀過(guò)了某條信息，這條信息應(yīng)該不再做展示。同理，用戶(hù)也應(yīng)該能夠在其它更適合接收消息的設(shè)備上找到已讀信息。用戶(hù)通知應(yīng)該在所有設(shè)備上進(jìn)行同步。

允許設(shè)置：允許用戶(hù)在「設(shè)置」中禁止或調(diào)整通知的形式。如案例一，通過(guò)選擇推送內(nèi)容，來(lái)影響接收推送的頻率。案例二，可選消息提醒的形式是紅點(diǎn)+數(shù)字，或僅是紅點(diǎn)。

時(shí)效性：良好的通知應(yīng)盡可能實(shí)時(shí)推送。而不是等這件事情都過(guò)去很久了，才推送給用戶(hù)知道。

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

可操作性：把通知和操作結(jié)合在一起，讓用戶(hù)不需要打開(kāi)首頁(yè)就能對(duì)特定通知進(jìn)行常規(guī)操作。操作應(yīng)該清晰明了，且僅在未重復(fù)默認(rèn)操作時(shí)提供。同時(shí)操作應(yīng)該是有意義、實(shí)時(shí)、和內(nèi)容對(duì)應(yīng)的，并且能讓用戶(hù)完成某個(gè)任務(wù)。如案例一，可以在不打開(kāi)郵件的情況下，直接對(duì)通知進(jìn)行管理、查看和清除。案例二中的操作針對(duì)的是未讀郵件，可便捷地在通知板面進(jìn)行回復(fù)、刪除、標(biāo)為已讀或垃圾郵件。

總結(jié)

對(duì)本篇文章的拓展總結(jié)：

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

文章來(lái)源：站酷

前言

為什么要重視布局

目前主流布局趨勢(shì)是怎樣的

-

偏移與疊加網(wǎng)格布局

-

上圖文字與圖片交疊錯(cuò)落排版，圖片與圖片之間也是網(wǎng)格交錯(cuò)

上面移動(dòng)端設(shè)計(jì)，設(shè)計(jì)師通過(guò)留出左側(cè)空網(wǎng)格，整體內(nèi)容往右側(cè)偏移，導(dǎo)航相對(duì)內(nèi)容來(lái)說(shuō)做了差異化設(shè)計(jì)，并未進(jìn)行偏移設(shè)計(jì)（看我上圖紅框部分）  。這樣做的目的是因?yàn)?，我們點(diǎn)擊漢堡菜單的時(shí)候，本來(lái)整體就要往右側(cè)移動(dòng)，如果再繼續(xù)移動(dòng)，那么內(nèi)容會(huì)顯示不下，同時(shí)視覺(jué)效果并沒(méi)有很好

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

分屏布局

分屏布局，顧名思義就是將屏幕進(jìn)行幾種不同區(qū)域的劃分，然后內(nèi)容分布排版在里面，分屏布局解決的主要問(wèn)題將屏幕大的設(shè)備進(jìn)行合理劃分空間設(shè)計(jì)，一般是在橫屏運(yùn)用比較多，比如PAD，或者WEB或者車(chē)機(jī)中控屏，下面一起看下分屏布局在實(shí)際設(shè)計(jì)中的具體表現(xiàn)

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

Z軸視差布局

-

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

內(nèi)容重疊布局

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

卡片布局

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

全封閉卡片布局，內(nèi)容之間通過(guò)卡片封裝，中間無(wú)空隙

自由式網(wǎng)格布局

如何運(yùn)用這些布局進(jìn)行創(chuàng)新設(shè)計(jì)

-

上面利用樂(lè)高積木思維重新對(duì)布局進(jìn)行拆解組合，當(dāng)然一切的布局都是基于當(dāng)前你的主旨，你的產(chǎn)品內(nèi)容，找到合適布局，然后去研究他，并且拆解，然后重新搭建屬于自己產(chǎn)品一套布局規(guī)則

總結(jié)

-

全文向大家介紹5種布局思路，當(dāng)然其實(shí)不止這5種，但是其他布局相對(duì)來(lái)說(shuō)會(huì)運(yùn)用少一些，這些布局我們可以加以學(xué)習(xí)利用，可以運(yùn)用在任何設(shè)計(jì)中去，當(dāng)然運(yùn)用的時(shí)候，一定要清晰知道自己產(chǎn)品的主旨目標(biāo)，用戶(hù)群體，合理運(yùn)用布局，做出創(chuàng)新設(shè)計(jì)！

轉(zhuǎn)自：站酷-設(shè)計(jì)TNT 

Patch和Diff算法

網(wǎng)上看了好多的博客和源碼教程，感覺(jué)很多仔細(xì)的地方?jīng)]有說(shuō)清，而且在一些復(fù)雜的部分加了好多的描述，所以就想自己也寫(xiě)下心得, 方便自己, 方便他人，有興趣的同學(xué)可以關(guān)注我的github里面有我之前一些博文 github/193Eric



我們知道的，在數(shù)據(jù)更改后，會(huì)觸發(fā)getter，然后通過(guò)dep.notify()來(lái)通知watcher觸發(fā)update進(jìn)而更新視圖，最終是通過(guò)Diff算法來(lái)對(duì)比新老Vnode的差異，并把差異更新到Dom視圖上



Diff

我們知道的，Virtual DOM是一顆樹(shù)，而diff算法主要把兩顆樹(shù)進(jìn)行對(duì)比，找出之間的差異，來(lái)渲染頁(yè)面



diff 算法是通過(guò)同層的樹(shù)節(jié)點(diǎn)進(jìn)行比較而非對(duì)樹(shù)進(jìn)行逐層搜索遍歷的方式，所以時(shí)間復(fù)雜度只有 O(n)，是一種相當(dāng)?shù)乃惴?br />


1.調(diào)用patch函數(shù)比較Vnode和OldVnode,如果不一樣直接return Vnode即將Vnode真實(shí)化后替換掉DOM中的節(jié)點(diǎn)



2.如果OldVnode和Vnode值得進(jìn)一步比較則調(diào)用patchVnode方法進(jìn)行進(jìn)一步比較，分為以下幾種情況：



Vnode有子節(jié)點(diǎn)，但是OldVnode沒(méi)有，則將Vnode的子節(jié)點(diǎn)真實(shí)化后添加到真實(shí)DOM上



Vnode沒(méi)有子節(jié)點(diǎn)，但是OldVnode上有，則將真實(shí)DOM上相應(yīng)位置的節(jié)點(diǎn)刪除掉



Vnode和OldVnode都有文本節(jié)點(diǎn)但是內(nèi)容不一樣，則將真實(shí)DOM上的文本節(jié)點(diǎn)替換為Vnode上的文本節(jié)點(diǎn)



Vnode和OldVnode上都有子節(jié)點(diǎn)，需要調(diào)用updateChildren函數(shù)進(jìn)一步比較



updateChildren比較規(guī)則



提取出Vnode和OldVnode中的子節(jié)點(diǎn)分別為vCh和OldCh，并且提出各自的起始和結(jié)尾變量標(biāo)記為 oldS oldE newS newE



如果是oldS和newE匹配上了，那么真實(shí)dom中的第一個(gè)節(jié)點(diǎn)會(huì)移到最后



如果是oldE和newS匹配上了，那么真實(shí)dom中的最后一個(gè)節(jié)點(diǎn)會(huì)移到最前，匹配上的兩個(gè)指針向中間移動(dòng)



如果都沒(méi)有，在沒(méi)有key的情況下直接在DOM的oldS位置的前面添加newS，同時(shí)newS+1。在有key的情況下會(huì)將newS和Oldch上的所有節(jié)點(diǎn)對(duì)比，如果有相同的則移動(dòng)DOM并且將舊節(jié)點(diǎn)中這個(gè)位置置為null且newS+1。如果還沒(méi)有則直接在DOM的oldS位置的前面添加newS且newS+1

直到出現(xiàn)任意一方的start>end，則有一方遍歷結(jié)束，整個(gè)比較也結(jié)束



updateChildren例子：



假設(shè):



真實(shí)dom為 A、B、C

oldDom為 A1、B1、C1

newDom為 A2、D2、C2、B2



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



先對(duì)比oldS和newS,oldE和newE,發(fā)現(xiàn)oldS = newS 所以真實(shí)dom的A固定不動(dòng)。排序?yàn)?A、B、C

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



對(duì)比發(fā)現(xiàn) oldS = newE , 所以真實(shí)dom,B要插入到后面去



真實(shí)dom排序?yàn)椋篈、C、B



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



對(duì)比發(fā)現(xiàn)兩兩都不對(duì)等，所以走第三步。

假設(shè)有key存在，所以newS直接和oldDom里面的所有節(jié)點(diǎn)對(duì)比，發(fā)現(xiàn)沒(méi)有存在，然后插入到oldS前面，且newS+1

真實(shí)dom排序?yàn)椋篈、D、C、B

然后重新開(kāi)始，oldS++ > oldE-- ,結(jié)束了。



這就是updateChildren，之后就是一直遍歷，運(yùn)行updateChildren直到?jīng)]有

1, JavaScript的Ajax

Ajax的全稱(chēng)是Asynchronous JavaScript and XML，意思就是用JavaScript執(zhí)行異步網(wǎng)絡(luò)請(qǐng)求，而不需要重載（刷新）整個(gè)頁(yè)面。

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

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



使用方法如下：



var xhr;

if (window.XMLHttpRequest) {

    xhr = new XMLHttpRequest();

} else {

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

}

1

2

3

4

5

6

啟動(dòng)請(qǐng)求：



xhr.open(method, url, boolean);     

xhr.send();

1

2

注：

1，xhr.open參數(shù)含義：

method：請(qǐng)求方式，post、get等

url: 請(qǐng)求鏈接，只能向同源的url發(fā)送請(qǐng)求

boolean：是否異步請(qǐng)求，true：異步， false: 同步，默認(rèn)為true

2，調(diào)用 open()方法并不會(huì)真正發(fā)送請(qǐng)求， 而只是啟動(dòng)一個(gè)請(qǐng)求以備發(fā)送。

3，send()方法接收一個(gè)參數(shù)，即要作為請(qǐng)求主體發(fā)送的數(shù)據(jù)(post方法會(huì)使用，get方法直接傳null)。如果不需要通過(guò)請(qǐng)求主體發(fā)送數(shù)據(jù)，則必須傳入 null，因?yàn)檫@個(gè)參數(shù)對(duì)有些瀏覽器來(lái)說(shuō)是必需的。調(diào)用send()之后，請(qǐng)求就會(huì)被分派到服務(wù)器。



XMLHttpRequest對(duì)象的異步請(qǐng)求示例如下：



function success(text) {

    console.log(text);

}



function fail(code) {

   console.log(code);

}



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

xhr.onreadystatechange = function () { 

    // 狀態(tài)發(fā)生變化時(shí)，函數(shù)被回調(diào)

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

        // 判斷響應(yīng)結(jié)果:

        if (xhr.status === 200) {

            // 成功，通過(guò)responseText拿到響應(yīng)的文本:

            return success(xhr.responseText);

        } else {

            // 失敗，根據(jù)響應(yīng)碼判斷失敗原因:

            return fail(xhr.status);

        }

    } else {

        // HTTP請(qǐng)求還在繼續(xù)...

    }

}



// 發(fā)送請(qǐng)求:

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: 作為響應(yīng)主體被返回的文本。

responseXML: 如果響應(yīng)的內(nèi)容類(lèi)型是"text/xml"或"application/xml"，這個(gè)屬性中將保存響應(yīng)數(shù)據(jù)的 XML DOM 文檔。

status: 響應(yīng)的 HTTP 狀態(tài)。

statusText: HTTP 狀態(tài)的說(shuō)明。

readyState ：表示請(qǐng)求/響應(yīng)過(guò)程的當(dāng)前活動(dòng)階段。可取值如下。

0: 未初始化。尚未調(diào)用 open()方法。

1: 啟動(dòng)。已經(jīng)調(diào)用 open()方法，但尚未調(diào)用 send()方法。

2: 發(fā)送。已經(jīng)調(diào)用 send()方法，但尚未接收到響應(yīng)。

3: 接收。已經(jīng)接收到部分響應(yīng)數(shù)據(jù)。

4: 完成。已經(jīng)接收到全部響應(yīng)數(shù)據(jù)，而且已經(jīng)可以在客戶(hù)端使用了。

只要 readyState 屬性的值由一個(gè)值變成另一個(gè)值，都會(huì)觸發(fā)一次 readystatechange 事件?？梢岳眠@個(gè)事件來(lái)檢測(cè)每次狀態(tài)變化后readyState 的值。通常，我們只對(duì) readyState 值為 4 的階段感興趣，因?yàn)檫@時(shí)所有數(shù)據(jù)都已經(jīng)就緒。不過(guò)，必須在調(diào)用 open()之前指定 onreadystatechange事件處理程序才能確?？鐬g覽器兼容性。



另外，在接收到響應(yīng)之前還可以調(diào)用 abort()方法來(lái)取消異步請(qǐng)求:



xhr.abort();

1

調(diào)用這個(gè)方法后，XHR 對(duì)象會(huì)停止觸發(fā)事件，而且也不再允許訪問(wèn)任何與響應(yīng)有關(guān)的對(duì)象屬性。在終止請(qǐng)求之后，還應(yīng)該對(duì) XHR 對(duì)象進(jìn)行解引用操作。由于內(nèi)存原因，不建議重用 XHR 對(duì)象。



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 必填項(xiàng)，規(guī)定把請(qǐng)求發(fā)送到哪個(gè) URL。

type 以什么樣的方式獲取數(shù)據(jù)，是get或post

contentType：發(fā)送POST請(qǐng)求的格式，默認(rèn)值為’application/x-www-form-urlencoded;

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

async 是否異步執(zhí)行AJAX請(qǐng)求，默認(rèn)為true，千萬(wàn)不要指定為false

data 發(fā)送的數(shù)據(jù)，可以是字符串、數(shù)組或object。如果是GET請(qǐng)求，data將被轉(zhuǎn)換成query附加到URL上，如果是POST請(qǐng)求，根據(jù)contentType把data序列化成合適的格式；

dataType

接收的數(shù)據(jù)格式，可以指定為’html’、‘xml’、‘json’、'text’等，缺省情況下根據(jù)響應(yīng)的Content-Type猜測(cè)。

success 可選。執(zhí)行成功時(shí)返回的數(shù)據(jù)。

缺點(diǎn)：

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



3，Axios

Vue2.0之后，axios開(kāi)始受到更多的歡迎。其實(shí)axios也是對(duì)原生XHR的一種封裝，不過(guò)是Promise實(shí)現(xiàn)版本。它是一個(gè)用于瀏覽器和 nodejs 的 HTTP 客戶(hù)端，符合的ES規(guī)范。



axios具有以下特征：



從瀏覽器中創(chuàng)建 XMLHttpRequest

支持 Promise API

客戶(hù)端支持防止CSRF

提供了一些并發(fā)請(qǐng)求的接口

從 node.js 創(chuàng)建 http 請(qǐng)求

攔截請(qǐng)求和響應(yīng)

轉(zhuǎn)換請(qǐng)求和響應(yīng)數(shù)據(jù)

取消請(qǐng)求

自動(dòng)轉(zhuǎn)換JSON數(shù)據(jù)

PS:防止CSRF:就是讓你的每個(gè)請(qǐng)求都帶一個(gè)從cookie中拿到的key, 根據(jù)瀏覽器同源策略，假冒的網(wǎng)站是拿不到你cookie中得key的，這樣，后臺(tái)就可以輕松辨別出這個(gè)請(qǐng)求是否是用戶(hù)在假冒網(wǎng)站上的誤導(dǎo)輸入，從而采取正確的策略。



設(shè)置全局的 axios 默認(rèn)值



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 默認(rèn)是 “application/json ”



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



var params = new URLSearchParams();

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

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

1

2

3

get請(qǐng)求，以下3中寫(xiě)法完全等價(jià)



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請(qǐng)求，以下2種寫(xiě)法完全等價(jià)



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

執(zhí)行多個(gè)并發(fā)請(qǐng)求



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) {

    // 兩個(gè)請(qǐng)求現(xiàn)在都執(zhí)行完成

}));

1

2

3

4

5

6

7

8

9

10

11

12

創(chuàng)建實(shí)例



可以使用自定義配置新建一個(gè) axios 實(shí)例



axios.create([config])

var instance = axios.create({

  baseURL: '
  timeout: 1000,

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

});

1

2

3

4

5

6

配置會(huì)以一個(gè)優(yōu)先順序進(jìn)行合并，順序由低到高為

1，在 node_modules/axios/lib/defaults.js 找到的庫(kù)的默認(rèn)值

2，實(shí)例的 defaults 屬性

3，請(qǐng)求的 config 參數(shù)



// 使用由庫(kù)提供的配置的默認(rèn)值來(lái)創(chuàng)建實(shí)例

// 此時(shí)超時(shí)配置的默認(rèn)值是 0

var instance = axios.create();

 

// 覆寫(xiě)庫(kù)的超時(shí)默認(rèn)值

// 現(xiàn)在，所有請(qǐng)求都會(huì)等待 2.5 秒

instance.defaults.timeout = 2500;

 

// 為已知需要花費(fèi)很長(zhǎng)時(shí)間的請(qǐng)求覆寫(xiě)超時(shí)設(shè)置

instance.get('/longRequest', {

  timeout: 5000

});

1

2

3

4

5

6

7

8

9

10

11

12

攔截器



在請(qǐng)求發(fā)出之前或響應(yīng)被 then 或 catch 處理前攔截它們做預(yù)處理。



// 添加請(qǐng)求攔截器

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

    // 在發(fā)送請(qǐng)求之前做些什么

  }, function (error) {

    // 對(duì)請(qǐng)求錯(cuò)誤做些什么

  });

 

// 添加響應(yīng)攔截器

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

    // 對(duì)響應(yīng)數(shù)據(jù)做點(diǎn)什么

  }, function (error) {

    // 對(duì)響應(yīng)錯(cuò)誤做點(diǎn)什么

  });

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 實(shí)例添加攔截器



var instance = axios.create();

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

1

2

4, fetch

window 自帶了 window.fetch 方法, 在版的 Firefox 和 Chrome 中已經(jīng)提供支持，其他瀏覽器還有兼容性問(wèn)題，要做兼容性處理。fetch 是一個(gè) 基于promise設(shè)計(jì)的low-level API，不是ajax的進(jìn)一步封裝，而是原生js,它注定不會(huì)像你習(xí)慣的 $.ajax 或是 axios 等庫(kù)幫你封裝各種各樣的功能或?qū)崿F(xiàn).



interface GlobalFetch {

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

}

1

2

3

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



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

優(yōu)點(diǎn)：

符合關(guān)注分離，沒(méi)有將輸入、輸出和用事件來(lái)跟蹤的狀態(tài)混雜在一個(gè)對(duì)象里

更好更方便的寫(xiě)法

更加底層，提供的API豐富

脫離了XHR，是ES規(guī)范里新的實(shí)現(xiàn)方式

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



缺點(diǎn)：

fetch不支持同步請(qǐng)求

fetch只對(duì)網(wǎng)絡(luò)請(qǐng)求報(bào)錯(cuò)，對(duì)400,500都當(dāng)做成功的請(qǐng)求，需要封裝去處理

fetch默認(rèn)不會(huì)帶cookie,需要添加配置項(xiàng)

fetch不支持abort,不支持超時(shí)控制，使用setTimeout及Promise.reject的實(shí)現(xiàn)的超時(shí)控制并不能阻止請(qǐng)求過(guò)程繼續(xù)在后臺(tái)運(yùn)行，造成了流量的浪費(fèi)

fetch沒(méi)有辦法原生監(jiān)測(cè)請(qǐng)求的進(jìn)度，而XHR可以



fetch的使用示例：



window.fetch(url)

    .then(response => {

        if (response.ok) {

            //通過(guò) response 原型上的 json 方法將 response.body 轉(zhuǎn)換為 JS 對(duì)象，再返回出去

            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

需要注意以下幾點(diǎn)：

1，用 response.ok判斷fetch請(qǐng)求是否成功

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

3，Response 限制了響應(yīng)內(nèi)容的重復(fù)讀取和轉(zhuǎn)換，response .json / response.text 方法只能使用一個(gè)并且只能使用一次，同時(shí)使用兩個(gè)，或使用兩次都會(huì)報(bào)如下錯(cuò)誤：



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

1

為什么不能使用兩次？

因?yàn)閿?shù)據(jù)流只能讀取一次，一旦讀取，數(shù)據(jù)流變空，再次讀取會(huì)報(bào)錯(cuò)。

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

版權(quán)聲明：本文為CSDN博主「Sherry慈」的原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。

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

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

從2015年開(kāi)始，我們每年都會(huì)在雙十一期間，將雙十一品牌設(shè)計(jì)的完整思路分享給大家，這已經(jīng)成為雙十一設(shè)計(jì)團(tuán)隊(duì)的傳統(tǒng)。不為別的，各位同仁辛苦一年，想跟大家就著新鮮出爐的設(shè)計(jì)嘮嘮嗑。

每逢雙十一logo出街，都會(huì)有熱心的朋友幫我們解讀，也有人問(wèn)我們?yōu)樯恫桓銈€(gè)官方發(fā)布？各位朋友，您現(xiàn)在看到的就是官方發(fā)布的內(nèi)容，它不只有l(wèi)ogo，而是從頭到尾一個(gè)完整的故事。

△ 2019天貓雙十一主logo

△ 2019天貓雙十一主logo多語(yǔ)言版本

今年是雙十一的第十一年，當(dāng)我們接到這個(gè)任務(wù)的時(shí)候，就有機(jī)靈的同學(xué)提議：「我們用6個(gè)1吧，111111，61兒童節(jié)！」、「讓我們回歸購(gòu)物的純真快樂(lè)！」。

「哈哈哈哈哈哈…」魔性的笑聲在整個(gè)會(huì)議室回蕩，看來(lái)往年撓破頭也解不開(kāi)的難題，就這么解開(kāi)了？故事當(dāng)然不會(huì)這么簡(jiǎn)單，我們還沒(méi)有往這個(gè)方向嘗試就被否了。

• 其一，雙十一是一個(gè)深入人心的認(rèn)知，這四個(gè)一已經(jīng)成為了超級(jí)符號(hào)，是我們寶貴的品牌資產(chǎn)，而六個(gè)一不但不能幫我們強(qiáng)化認(rèn)知價(jià)值，反而會(huì)增加認(rèn)知成本。
• 其二，六個(gè)一是一個(gè)純視覺(jué)的創(chuàng)意，他很難支撐起我們要傳達(dá)的消費(fèi)者價(jià)值，也很難建立起情感連接。

我們應(yīng)該從哪兒入手？

回歸到設(shè)計(jì)的本質(zhì)來(lái)思考，我們認(rèn)為，設(shè)計(jì)的本質(zhì)是將一個(gè)想法或者觀點(diǎn)巧妙的表達(dá)給目標(biāo)對(duì)象，表達(dá)的過(guò)程中，形式只是手段，重點(diǎn)在于我們要表達(dá)什么。

我們集合了阿里各事業(yè)部的設(shè)計(jì)師代表，讓大家回歸到一個(gè)普通消費(fèi)者的狀態(tài)，一起聊一聊各自的雙十一故事，把這些故事提煉出來(lái)，就是消費(fèi)者對(duì)于雙十一普遍真實(shí)的認(rèn)知。在全年最便宜的一天，無(wú)論湊熱鬧也好，跟風(fēng)也好，貪便宜也好，好像不買(mǎi)點(diǎn)什么總感覺(jué)錯(cuò)過(guò)了什么。在這一天，「購(gòu)物」毫無(wú)疑問(wèn)成為頭等重要的事情。

△ 阿里巴巴經(jīng)濟(jì)體設(shè)計(jì)師共創(chuàng)

那么我們要對(duì)消費(fèi)者表達(dá)「購(gòu)物」嗎，講我們多么便宜，貨品多么豐富，多么物美價(jià)廉？這些是消費(fèi)者早就形成的認(rèn)知，是我們不用表達(dá)大家都知道的事，它看起來(lái)并不是一個(gè)想法和觀點(diǎn)。

還是購(gòu)物，但肯定不是教大家怎么購(gòu)物，作為消費(fèi)者，購(gòu)物能給我們帶來(lái)什么？

有人說(shuō)，購(gòu)物能讓我們吃飽穿暖，讓我們出行方便，讓我們安居無(wú)憂。

如果這些你都有，你為什么還要購(gòu)物？

因?yàn)槊總€(gè)人都向往更好的生活！

為了更好的生活，我們需要通過(guò)物品的改善帶來(lái)心理的滿足感。當(dāng)然也有人會(huì)會(huì)說(shuō)，滿足感也可以通過(guò)其他的方式獲取，比如關(guān)愛(ài)他人、親近自然、學(xué)習(xí)、修行、冥想等等，我們非常認(rèn)同，更好的生活當(dāng)然不僅僅只有購(gòu)物。但我們當(dāng)下探討的范疇僅僅只是「購(gòu)物」以及「購(gòu)物」能帶來(lái)的滿足感，對(duì)這種滿足感的期待，是每一個(gè)消費(fèi)行為的動(dòng)因。比如你想要買(mǎi)一件新衣服的時(shí)候，其實(shí)你已經(jīng)在期待穿上這件新衣服的樣子，你在挑選一件禮物的時(shí)候，已經(jīng)在期待他人收到這件禮物時(shí)的反應(yīng)……

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

但，這些洞察還只是幫我們理清了消費(fèi)行為背后的共性規(guī)律，實(shí)際上，細(xì)分到每個(gè)消費(fèi)者，因?yàn)樯矸萁巧罘绞降牟煌瑒?dòng)因各自不同，還不能簡(jiǎn)單的用向往更好的生活來(lái)概括，因?yàn)樗橄?，?tīng)上去對(duì)，但每個(gè)消費(fèi)者更關(guān)心的是我的需求是不是被滿足，而對(duì)于雙十一來(lái)講，我們就是要打造屬于每一人的雙十一，而不僅僅只是購(gòu)物，這樣它才具有節(jié)日的文化屬性。

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

在傾聽(tīng)這些故事的時(shí)候，我們的阿里女神被感動(dòng)了，她主動(dòng)要求幫我們寫(xiě)一首歌，她想把她的感動(dòng)通過(guò)音樂(lè)的方式記錄下來(lái)，配合我們精選出來(lái)的11個(gè)故事，講給大家聽(tīng)。

△ 雙十一品牌設(shè)計(jì)概念篇mv

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

于是，我們開(kāi)始了一輪又一輪的打磨，打磨的的重點(diǎn)放在了如何表達(dá)「愿望11實(shí)現(xiàn)」這一主題，這個(gè)過(guò)程中，有兩個(gè)大方向上的分歧：

一個(gè)大方向是表現(xiàn)「愿望」，因?yàn)樗容^有畫(huà)面感，也比較容易表達(dá)。

另一個(gè)大方向是表現(xiàn)「實(shí)現(xiàn)」，因?yàn)樗菍?duì)結(jié)果的描述，更符合消費(fèi)者對(duì)結(jié)果的預(yù)期。

在糾結(jié)掙扎過(guò)后，我們選擇了把兩個(gè)方向融合，劇情貌似又回到了熟悉的設(shè)計(jì)故事，「把這兩個(gè)方案融合一下！」我相信做設(shè)計(jì)的朋友，一定反復(fù)聽(tīng)過(guò)這句話，沒(méi)聽(tīng)過(guò)的朋友，那說(shuō)明你做設(shè)計(jì)還不久，我保證在你今后的職業(yè)生涯里，這句話一定會(huì)反復(fù)出現(xiàn)。（一個(gè)會(huì)心的微笑）

融合說(shuō)起來(lái)容易，這么抽象的文字怎么轉(zhuǎn)換成圖形表達(dá)，同時(shí)還要和貓頭+11.11融合，為什么要和貓頭+11.11融合呢，因?yàn)檫@是我們重要的品牌形象資產(chǎn)，從2015年開(kāi)始，貓頭+11.11的組合就固定下來(lái)了，這意味著logo的80%的主體已經(jīng)固定，我們的難點(diǎn)就在于在這20%的區(qū)域里，如何既要表達(dá)主題，還能做出和往年不一樣的感覺(jué)。我敢向你保證，雙十一的logo是所有l(wèi)ogo里最難的，沒(méi)有之一，至少是我十幾年職業(yè)生涯里最硬的茬。

「愿望、實(shí)現(xiàn)、貓頭、11.11」這幾個(gè)詞反復(fù)在腦海里縈繞，經(jīng)驗(yàn)告訴我們，當(dāng)面對(duì)如此復(fù)雜的局面，我們應(yīng)該從里面跳出來(lái)，換個(gè)視角看問(wèn)題，換什么視角？當(dāng)然還是再次回到消費(fèi)者視角，消費(fèi)者愿望實(shí)現(xiàn)時(shí)是一種什么樣的狀態(tài)？是愿望實(shí)現(xiàn)時(shí)的滿足？好像還差點(diǎn)意思，愿望平時(shí)也能實(shí)現(xiàn)，和在雙十一實(shí)現(xiàn)愿望有什么不同？

我們認(rèn)為，它應(yīng)該是超越你期待的表達(dá)，從愿望實(shí)現(xiàn)時(shí)的滿足，升級(jí)到愿望實(shí)現(xiàn)時(shí)的驚喜！這才是狂歡節(jié)該有的味道。當(dāng)然，驚喜也有很多種它還不夠有體感，如何找準(zhǔn)驚喜體感？

答案是感同身受。于是我們開(kāi)始了場(chǎng)景模擬，模擬消費(fèi)者逛雙十一的場(chǎng)景。

當(dāng)我們來(lái)到雙十一的時(shí)候：「咦！今年好像真的不一樣！」

繼續(xù)探索的時(shí)候：「呀！找了好久的idou同款原來(lái)在這里！」

準(zhǔn)備下單的時(shí)候：「喔！真的很便宜！」

收到快遞的時(shí)候：「哇?。。。　?

聽(tīng)上去有點(diǎn)夸張，但這確實(shí)是我們想要營(yíng)造給消費(fèi)者的驚喜，當(dāng)人感到超越期待的驚喜時(shí)，會(huì)不自覺(jué)的放大瞳孔、張開(kāi)嘴巴脫口而出。這是人類(lèi)共通的體感，是不用解釋就有的共鳴。這讓我們瞬間被點(diǎn)亮了，「驚喜到脫口而出！」我們一下子找到了核心創(chuàng)意。

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

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

當(dāng)然，作為容器，我們還要把核心創(chuàng)意延展到線上線下各個(gè)場(chǎng)景。

△ 雙十一定制禮盒

△ 走向全球的雙十一

過(guò)去幾年，我們向大家介紹過(guò)天貓雙11的主風(fēng)格的來(lái)龍去脈，一定會(huì)在創(chuàng)新的基礎(chǔ)上，保持一貫的傳承。所以今年波普藝術(shù)的主基調(diào)還是會(huì)延續(xù)下去，問(wèn)題又回到了我們?nèi)绾卧诓ㄆ账囆g(shù)這個(gè)大的基調(diào)下面，通過(guò)老元素的新組合，創(chuàng)造出全新的視覺(jué)感受。相比符號(hào)，視覺(jué)風(fēng)格更容易表現(xiàn)「驚喜到脫口而出！」這個(gè)idea，它可以通過(guò)形色質(zhì)構(gòu)全方位的表達(dá)。

當(dāng)一個(gè)人「驚喜到脫口而出！」的時(shí)候，快樂(lè)的氣場(chǎng)圍繞在他周?chē)@些無(wú)形的從中心向四周放散的表現(xiàn)，看上去很像是圓形聲波，同時(shí)它還能根據(jù)不同人的狀態(tài)做動(dòng)態(tài)變化，這就形成了一種設(shè)計(jì)語(yǔ)言，一種能用固定的形式做出千變?nèi)f化的效果的語(yǔ)言。

當(dāng)我們把它和波普藝術(shù)的主基調(diào)結(jié)合的時(shí)候，就形成了今年雙十一獨(dú)特的視覺(jué)語(yǔ)言，再通過(guò)形色質(zhì)構(gòu)的拆解，應(yīng)用到各個(gè)場(chǎng)景。

△ 裝置應(yīng)用

△ 天貓雙十一發(fā)布會(huì)現(xiàn)場(chǎng)應(yīng)用

△ 天貓雙十一開(kāi)幕盛典現(xiàn)場(chǎng)應(yīng)用

文章來(lái)源：優(yōu)設(shè)

這里我截取的是一個(gè)圖片，實(shí)際上是會(huì)動(dòng)的。廢話不多說(shuō)，上代碼。

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;                //星星數(shù)量,默認(rèn)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;

    //星星移動(dòng)范圍，值越大范圍越小，

}



var Star = function() {



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

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

    

    this.orbitX = w / 2;

    this.orbitY = h / 2;

    this.timePassed = random(0, maxStars);

    this.speed = random(this.orbitRadius) / 80000;        //星星移動(dòng)速度,值越大越慢,默認(rèn)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();

藍(lán)藍(lán)設(shè)計(jì)( www.yvirxh.cn )是一家專(zhuān)注而深入的界面設(shè)計(jì)公司，為期望卓越的國(guó)內(nèi)外企業(yè)提供卓越的UI界面設(shè)計(jì)、BS界面設(shè)計(jì) 、 cs界面設(shè)計(jì) 、 ipad界面設(shè)計(jì) 、 包裝設(shè)計(jì) 、 圖標(biāo)定制 、 用戶(hù)體驗(yàn) 、交互設(shè)計(jì)、 網(wǎng)站建設(shè) 、平面設(shè)計(jì)服務(wù)。