基于 Vue 智能提示組件V-Tooltip

天給大家推薦一個超棒的Vue下拉式/移動式/tooltips提示組件VTooltip。

v-tooltip 基于 vue.js 構建的輕量級 工具提示條、彈出窗口、下拉式提示 組件。star高達1.6K。

安裝

$ npm i v-tooltip -S

# 瀏覽器/CDN
<script src="https://unpkg.com/v-tooltip"></script>

引入插件

import Vue from 'vue'
import VTooltip from 'v-tooltip'

Vue.use(VTooltip)

使用

<template>
  <div class="example">
    <!-- 通過指令 v-tooltip 使用 -->
    <button v-tooltip.top-center="msg">Hover me</button>
    
    <button v-tooltip="{
      content: msg,
      placement: 'bottom-center',
      classes: ['info'],
      targetClasses: ['it-has-a-tooltip'],
      offset: 100,
      delay: {
        show: 500,
        hide: 300,
      },
    }">Hover me</button>
    
    <!-- 通過組件v-popover使用 -->
	<v-popover offset="16" placement="bottom" autoHide="true">
      <button class="tooltip-target">Click me</button>
      
      <template slot="popover">
        <input class="tooltip-content" v-model="msg" placeholder="Tooltip content" />
		<p>{{ msg }}</p>
        <ExampleComponent />
        
        <a v-close-popover>Close</a>
        <a v-close-popover.all>Close All</a>
      </template>
    </v-popover>
  </div>
</template>
<script>
export default {
  data() {
	return {
		msg: 'This is a button.'
	}
  }
}
</script>

# 示例地址
https://akryum.github.io/v-tooltip/

# 倉庫地址
https://github.com/Akryum/v-tooltip

okay，就分享到這里。喜歡的話多支持下，希望對大家有些許幫助哈~~

到現如今最流行的瀏覽器，那么一定是chrome，無論是它的速度，還是它的穩定性，還是它的簡潔，都讓人愛不釋手，此外，更多的人選擇它的理由是它有著豐富的擴展插件，這些擴展插件讓你的瀏覽器變得異常強大，讓你的瀏覽器不僅僅是瀏覽器。

chrome擴展結構

chrome的擴展是以.crx結尾的安裝包，如果你把它下載下來，并把它重命名為.rar壓縮包文件，然后你就可以使用壓縮軟件對它進行解壓，加壓之后，就會發現其實chrome的擴展包里面就是一些js，css，html文件，可以說你只要會寫前端，那么開發一個chrome擴展插件將會非常容易。

在這些文件中，有一個manifest.json文件，它是擴展的描述文件，定義了擴展的名稱和版本號等信息。

{
    "name": "BrowserActionExtension",
    "version": "0.0.1"
    "manifest_version": 2,
    "browser_action": {
        "default_title": "That's the tool tip",
        "default_popup": "popup.html"
    }
}

在這個配置文件中，你還可以添加其它屬性，只要你的擴展需要的屬性，你都可以在這里添加配置。

每一個擴展都有一個被瀏覽器運行的背景頁，此外還有事件頁面，背景頁面一直都是激活狀態，而事件頁面只是在觸發事件的時候才會激活，因此為了節省內存和提高瀏覽器的性能，盡可能選擇事件頁面。兩者通過persistent屬性進行區分。

"background": {
    "scripts": ["background.js"],
    "persistent": false/true
}

當我們的擴展想要訪問瀏覽器當前頁面的dom樹的時候，我們需要使用內容腳本，這些腳本會在頁面刷新的時候執行。

"content_scripts": [
    {
        "matches": ["https://*/*", "https://*/*"],
        "js": ["content.js"]
    }
]

對于擴展的UI界面，我們可以通過browser_action屬性進行配置，通過此屬性，我們可以設置擴展的圖標，設置點擊彈出的頁面。

"browser_action": {
    "default_icon": {
        "19": "icons/19x19.png",
        "38": "icons/38x38.png"
    },
    "default_title": "That's the tool tip",
    "default_popup": "popup.html"
}

除了browser_action可以配置擴展圖標之外，page_action可以配置圖標，兩者的區別是，browser_action總是顯示在擴展欄，而page_action則是滿足一定條件才會顯示，比如頁面有vue腳本時候才會顯示vue調試圖標。

"page_action": {
    "default_icon": {
        "19": "images/icon19.png",
        "38": "images/icon38.png"
    },
    "default_title": "Google Mail",
    "default_popup": "popup.html"
}

chrome被開發人員所喜愛的另一個原因是它提供了非常強大的調試工具欄，而我們的擴展也是可以加入到調試工具欄的。

通過使用devtools_page屬性，我們就可以將我們的擴展加入到調試工具欄的一個tab中。

"devtools_page": "devtools.html"

我們在devtools.html中只需要添加一個js引入語句就可以。

<script src="devtools.js"></script>

在devtools.js文件里，我可以可以放入我們實際的擴展內容。

chrome.devtools.panels.create(
    "MyExtension", 
    "img/icon16.png", 
    "index.html",
    function() {

    }
);

擴展能夠做什么

擴展能夠做什么主要取決于瀏覽器為我們提供了哪些API，慶幸的是，chrome為我們提供了足夠多好用的API。

我們可以操作用戶的書簽和瀏覽記錄
我們可以控制下載，管理下載內容
我們可以監聽網絡請求，監聽事件響應
我們可以修改界面樣式，可以添加自定義css
我們可以在頁面添加想要的元素

總之，chrome幾乎為我們提供了完整控制瀏覽器的擴展api，正是有了這些api，才誕生了幾十萬的擴展插件。

擴展的調試

在我們本地開發好擴展之后，我們可以通過本地瀏覽器進行調試。

首先，我們需要先進入擴展程序頁面，打開開發者模式

然后，我們可以通過選擇加載已解壓的擴展程序加載我們的擴展。

最后，我們通過在控制臺輸出調試信息來調試我們的擴展。

完整的示例

manifest.json

{
    "name": "BrowserExtension",
    "version": "0.0.1",
    "manifest_version": 2,
    "description" : "Description ...",
    "icons": { "16": "icons/16x16.png", "48": "icons/48x48.png", "128": "icons/128x128.png" },
    "omnibox": { "keyword" : "yeah" },
    "browser_action": {
        "default_icon": { "19": "icons/19x19.png", "38": "icons/38x38.png" },
        "default_title": "That's the tool tip",
        "default_popup": "browseraction/popup.html"
    },
    "background": {
        "scripts": ["background.js"],
        "persistent": false
    },
    "chrome_url_overrides" : {
        "newtab": "newtab/newtab.html"
    },
    "content_scripts": [{
        "matches": ["http://*/*", "https://*/*"],
        "js": ["content.js"]
    }],
    "devtools_page": "devtools/devtools.html"
}

background.js

// omnibox
chrome.omnibox.onInputChanged.addListener(function(text, suggest) {
    suggest([
      {content: "color-divs", description: "Make everything red"}
    ]);
});
chrome.omnibox.onInputEntered.addListener(function(text) {
    if(text=="color-divs") colorDivs();
});

chrome.extension.onMessage.addListener(function(request, sender, sendResponse) {
    switch(request.type) {
        case "color-divs":
            colorDivs();
        break;
    }
    return true;
});

chrome.extension.onConnect.addListener(function (port) {
    port.onMessage.addListener(function (message) {
        switch(port.name) {
            case "color-divs-port":
                colorDivs();
            break;
        }
    });
});

// send a message to the content script
var colorDivs=function() {
    chrome.tabs.getSelected(null, function(tab){
        chrome.tabs.sendMessage(tab.id, {type: "colors-div", color: "#F00"});
        // setting a badge
        chrome.browserAction.setBadgeText({text: "red!"});
    });
}

popup.html

<script type="text/javascript" src="popup.js"></script>
<div style="width:200px">
    <button id="button">Color all the divs</button>
</div>

popup.js

window.onload=function() {
    document.getElementById("button").onclick=function() {
        chrome.extension.sendMessage({
            type: "color-divs"
        });
    }
}

devtools.html

window.onload=function() {
    var port=chrome.extension.connect({ name: "color-divs-port" });
    document.getElementById("button").onclick=function() {
        port.postMessage({ type: "color-divs"});
    }
}

content.js

chrome.extension.onMessage.addListener(function(message, sender, sendResponse) {
    switch(message.type) {
        case "colors-div":
            var divs=document.querySelectorAll("div");
            if(divs.length===0) {
                alert("There are no any divs in the page.");
            } else {
                for(var i=0; i<divs.length; i++) {
                    divs[i].style.backgroundColor=message.color;
                }
            }
        break;
    }
});

總結

chrome瀏覽器的擴展開發其實并不難，用到的知識都是基礎的js，html，css，我們只需要知道一些和瀏覽器交互的屬性和操作的api，就可以開發出一個屬于自己的瀏覽器擴展。

輯導語：彈窗，不只是“彈出式廣告”，它是一把雙刃劍，用得好能使用戶更加聚焦，用得不好則可能使用戶不快甚至擊退潛在用戶。那么，彈窗要怎么設計呢？本文作者對彈窗進行了詳細的分析，一起來看一下吧。

說到彈窗，很多人對彈窗的印象還停留在“彈出式廣告”: 網站為了獲利，廣告商為了增加點擊率，那時候的廣告就像槍林彈雨，用戶無處可躲，進而惱羞成怒，甚至想要砸掉電腦。

廣告彈窗曾經在2010年被《時代》雜志評為最糟糕的發明之一。

我們如今再熟悉不過的淘寶曾經為在電商領域存活下來，也不得已使用大量的“流氓廣告”，雖然這的確使得用戶惱怒，但是不得不說，淘寶也因此刷臉頻繁而讓大家更熟悉它。

彈窗是一把雙刃劍，用的好確實使用戶更加聚焦，而如果使用的不恰當，可能會使用戶不快甚至擊退潛在用戶。在設計彈窗時，你有沒有遇到過下面的困惑？

該在什么時候選擇用彈窗，什么時候用頁面呢?
彈窗的標題怎么起?
彈窗疊彈窗最多可以疊幾個?

可以說，彈窗設計的好不好，可以極大的體現一個設計師的基本功扎不扎實，別看一個小小的彈窗設計起來似乎非常容易，但面對不同的用戶場景、業務背景，彈窗背后的思考從未停止，今天就讓我們全方位地了解彈窗。

01 彈窗的定義

在正式認識彈窗前，我們不妨設想以下的場景: 你正在家中做事情，但是這個時候電話鈴響了，你不得不放下手中的事情去接電話，但是假如在智能家居環境中，你可以通過人工智能自動接電話，同時你手中的事情仍然在繼續中。

如果說把前者比喻成跳轉的頁面，那么后者就是彈窗，它能夠在吸引你當下注意力的同時，不離開當前的場景。

目前設計界對于彈窗的定義多種多樣，從外觀布局上看，彈窗是頁面上層彈出的容器，容器中承載著文本、按鈕、選項、標簽或表單等組合內容；從設計目的上看，彈窗是用戶與產品間對話的一種方式，是對用戶注意力的一種引導形式，根據抓取用戶注意力的多少，可具體定義為Dialogue、Actionbar、Popover、Toast、Snackbar等等特定形式。

從廣義上講，彈窗其實并沒有如它的定義那樣框的那么死，有時候彈窗不一定有容器，比如追劇時常見的彈幕，也是一種新型彈窗；再比方說新手引導，也是一種彈窗。不過，咱們在這里談論的還是狹義上的大家在規范中所常見的彈窗，那些非典型的彈窗就不在今天討論的范圍之內。

02 彈窗的組成

彈窗的基本組成可以拆解為：

遮罩
彈窗主體(容器、標題、內容、動作按鈕)
關閉入口(不必要/模態彈窗沒有)

1. 遮罩

為了使用戶更聚焦于彈窗，我們會在彈窗容器下方頁面上方加一層遮罩，通常這種遮罩是半透明黑色，如果遮罩顏色越深，用戶越能夠專注于當前頁面；遮罩顏色越淺，用戶的跳出感越小，產品也更親民。

當頁面中出現多個彈窗時，也就意味著多個遮罩層，這個時候遮罩層的顏色該怎么確定呢?

根據各大規范，彈窗疊彈窗不建議超過三個，當彈窗大于等于3個時，遮罩的顏色就不再改變。這里再補充一點，當彈窗數量過多，一個疊一個，用戶容易迷失放向，這時候可以采用位置錯層的方法。

2. 彈窗主體

彈窗主體可以拆解為標題、內容、動作按鈕。

彈窗的標題和內容的書寫規則，在后文中有詳細描述，這里不再贅述。

彈窗的動作按鈕一般不超過3個:

1個按鈕: 那一定是可以關閉彈窗的操作，比如信息公告類的彈窗的“我知道了”。

2個按鈕:這是最常見的情況。一個是推進任務進程的動作，一個是取消。

3個按鈕:這種情況比較少見，比如“了解更多”，但這會讓用戶離開彈窗，導致彈窗任務未完成，所以不推薦使用。如果有更多內容需要向用戶展示，可以內嵌一個信息擴展，點擊圖標在彈窗下方展示更多信息，這樣了解更多信息的同時，也不用離開彈窗。

至于彈窗按鈕的位置擺放，有兩種常見的擺放規則:等分居中擺放和某一側擺放(右側居多)，不同平臺有不同的擺法，接下來舉例說明:

1）Material design中右對齊

2）IOS中等分居中擺放

3）在Fiori規范中，手機端的按鈕是等分居中擺放，但是在電腦端采用右對齊

3. 彈窗的關閉入口

對于模態和非模態的關閉方式，從根本上說是很不同的。

對于模態彈窗，它的關閉方式只有做出選項選擇后彈窗才會消失，包括“取消”選項。而非模態彈窗的關閉方式就很多了，總結下來有四種方式:

1)關閉按鈕(叉叉)

通常是位于右上角，少數規范把關閉按鈕放在左上角，只要保持一致即可。

2)取消按鈕

通常和“確認”或者其他推進任務完成的動作按鈕放在一起，成對出現。

3)ESC鍵

敲擊ESC鍵，也可以退出非模態彈窗。 Esc鍵是英文單詞escape的縮寫，在1960年由IBM的一位程序員創建，它的功能是“撤銷”、“退出”。

盡管如今使用鼠標進行交互的人占絕大多數，但是出于無障礙設計(包容性設計)的需要，通過鍵盤完成交互是必不可少的，所以ESC按鈕也是必需的。

而且這類快捷鍵上的優化能夠大大提升用戶使用效率，減輕用戶的操作成本。

尤其在B端產品中，調用鍵盤進行操作優化，是一個不可忽視的用戶爽點。

4)點擊遮罩區域

遮罩區域就是彈窗背后的內容區，通常為了使用戶更聚焦會加上一層暗色遮罩，當用戶點擊遮罩區域后，非模態彈窗會自動消失，不過為了避免用戶誤觸，如果彈窗是表單等需要用戶輸入的內容時，這些內容要自動保存。

對于“取消”和“關閉”按鈕，這里想要再闡述更清楚一些:先舉個生活中常見的例子，假設你有一個愛問十萬個為什么的小孩，你正在津津有味地追劇，結果他跑過來問你問題，他還沒張口呢，你就捂住耳朵不聽不聽，這個呢就相當于彈窗右上角的關閉按鈕(叉叉)，不過關閉按鈕僅僅存在于非模態彈窗中，用戶可以不做任何選擇地關掉彈窗，而模態彈窗要求用戶必須做出某種選擇，不給用戶逃避的機會，所以模態彈窗是沒有關閉按鈕的。

然后小孩問你是雞生蛋還是蛋生雞，你聽了這個問題也不知道怎么解釋，只能和小孩說，這個問題我也不知道怎么回答，這個就相當于彈窗的“取消”按鈕。

雖然“取消”按鈕和關閉按鈕(叉叉)最終都會導致彈窗關閉，但是從邏輯上而言，是不同的。

03 彈窗的類型

1. 模態&amp；非模態

彈窗可以分為模態彈窗和非模態彈窗兩種類型，這兩個概念來源于開發人員的術語。

當打開一個模態彈窗后，它所屬頁面的進程被打斷了，必須等用戶處理完畢模態彈窗后，才能夠回到剛才正在進行的頁面。

舉個例子，你準備刪除一個重要的文件，系統彈出一個彈窗，問你確認要刪除嗎?這個你時候你必須下一個明確的指令，選擇刪除或者不刪除，然后你才可以離開當前界面，我們可以簡單的把模態彈窗理解為用戶不得不做的選擇。

再來看非模態彈窗，非模態彈窗允許用戶在不打斷當前頁面的同時，去處理其他任務，舉個例子，設計師們最熟悉不過的PS，你可以同時調用多個彈窗去更改畫面參數，因為藝術創作是一個多線過程，藝術家可以想到什么參數就改變什么參數。

模態和非模態只是一個比較概括性的概念，而且不同的規范里可能對相似的某一類彈窗的稱呼完全不同或者有輕微差異，接下來我分別根據 Microsoft-Fluent UI、Google- Material Design、IOS 規范中拿出一些比較有代表性的彈窗類型詳細講一講。

2. 典型彈窗

1）Actionsheet

類型:模態彈窗

參考規范:IOS Design

簡介:Action sheet一次展示和當前語境相關的兩個或者更多的動作，非必要不要展示太多的動作選項，以及避免在動作列表中使用滾動條。

關鍵點:

動作按鈕: 把危險性選擇 (如清空、刪除)放在最上面，把取消按鈕置于底部。
避免使用太多動作按鈕讓Action Sheet列表產生滾動條。
毀滅性操作需要在視覺上突出。

2）Modal

類型:模態彈窗

參考規范:Microsoft-fluent UI

簡介:Modals也是一種模態彈窗，它需要人們把注意力從當前頁面短暫轉移到彈窗上，并且需要用戶的交互動作。和Dialog不同的是， Modal 更適合長文本內容，如隱私條款、知情同意書等等，抑或是要求用戶進行較為復雜的操作行為如更改頁面設置。

3）Dialog

類型:模態彈窗

參考規范:Microsoft-fluent UI

簡介:Dialog是一種模態彈窗，它需要人們把注意力從當前頁面短暫轉移到彈窗上，并且需要用戶的交互動作。它基本被用于較為簡單的場景下，如確認信息、刪除文檔、做出一個選擇。

分類:

Alert Dialogue: 因為緊急信息、詳情展示或者動作打斷用戶，用戶必須做出一個選擇才能關掉彈窗。
Simple Dialogue: 展示會立即生效的列表選項，它不需要動作按鈕。
Confirmation Dialogue: 需要用戶確認當前選擇，假如用戶反悔了，可以在這一步修改。
Full-screen Dialogue: 全屏彈窗會充滿整個屏幕，包含需要完成一系列任務的動作，只適用于手機端。

使用場景:

發生阻止程序運行的錯誤
需要向用戶展示完成某個特定任務的的關鍵信息，如決定、聲明
需要最高程度地抓取用戶注意力

關鍵點:

在當前強制要求輸入的區域完成前，保存按鈕處于置灰狀態。
在全屏彈窗上層允許出現一些簡單的彈窗。
標題保持簡潔，最多不超過兩行，假如長度不確定或者更長，把它們放在內容區而不是標題區。
盡量減少使用Dialogue，因為它們毫無征兆的出現，會打斷用戶的進程。
大多數彈窗內容應當盡量避免使用滾動條，如果非使用不可(如選擇時間日期)，保持標題和底部的動作按鈕區域固定，遮罩區域的背景也不動。

4）Drawer

類型:模態彈窗

參考規范:Material Design

簡介:Drawer是一種容器，它的性質和生活中的抽屜很像，通常用來放置和某個特定窗口相關的一些信息或者選項。默認情況下， Drawer是隱藏的，它通常是通過一個按鈕或者菜單觸發，從父級界面的一側滑出來，所以它不能夠脫離父級界面而單獨存在。

關鍵點:避免使用drawer，現在流行的軟件已經很少會使用drawer了，而且也不提倡使用。如果你想展示補充性的內容的話，不妨嘗試一下panel、popover、sidebars、split views。

5）Popover

類型:模態、非模態

參考規范:IOS Design

簡介:當你輕觸一個區域時，Popover會短暫的出現在其他內容的上層，通常來說，一個Popover包含一個箭頭，指向它彈出來的位置。當你點擊屏幕中的其他區域或者Popover上的按鈕時，一個非模態的popover會取消顯示。而模態的popover只能通過點擊它上面的cancel或者其他按鈕而取消顯示。

Popover更最適合大屏幕的設備，并且可以容納很多元素，包括導航欄、工具欄、tab欄、表格、圖片、地圖、傳統視圖等等。當Popover可見時，在它消失前，當前頁面的其他交互是不能進行的。

關鍵點:

避免在iPhone中使用Popover：一般來說，Popover 會在ipad中使用。在iphone中，通常會通過把信息展示在一個全屏的模態視圖中來優化屏幕空間，而不是使用Popover。
使用一個關閉按鈕來確認。一個關閉按鈕是值得加上去的，比如“取消”或者“完成”，當然如果空間不擁擠的情況下，還可以加上“保存然后退出”“不保存然后退出”這樣的選項。一般來說，當Popover沒必要再展示的情況下，它應當能夠自動退出。在大多數情況下，當用戶點擊了它區域之外的范圍或者是對Popover做出某種選擇后，它會關閉。如果需要在Popover上做出多個選擇時，Popover應當一直顯示直到用戶做出明確的關閉行為。
自動關閉非模態Popover時，總是自動保存。用戶容易誤碰到某個區域關掉非模態的Popover，除非是用戶點擊了明確的“取消”的按鈕，這種時候才不保存工作。
在屏幕上適當的放置Popover。一個Popover的箭頭應當直接指向觸發它的地方，因為Popover不能在屏幕上拖來拖去挪動位置，所以它不可以遮擋住屏幕上用戶重要的內容，當然它也不能擋住觸發它的元件。
一次只展示一個Popover。同時展示很多的popover，會增加畫面的噪聲，致使用戶疑惑。不要使用瀑布或者階梯式的Popover，就是那種一個接一個的彈出來的。如果你想展示一個新彈窗，那就把打開著的先關掉。
不要在Popover 的上層再展示其他彈窗，除了Alert。
如果可能的話，讓用戶點擊一下就能再打開一個新的Popover，避免多余的點擊步驟。
不要讓Popover展示的太大。一個Popover不應該占據整個屏幕，只讓它達到可以剛好可以容納其中的內容，并且指向彈出它的方向就可以了。
確保Popover看上去像Popover。盡管用戶可以個性化改變一個Popover的視覺外觀，但是還是要避免設計用戶識別不出的Popover。當Popover包含標準的控件和視圖時往往用戶體驗最佳。

6）Snackbar &amp； Toast

類型:非模態

參考規范:Material Design

簡介:此處將Snackbar和Toast放在一起講，因為這兩者十分相似但是又有所差異。

Toast屬于一種輕量級的反饋，它比Snack bar的提示程度輕，常常以小彈框的形式出現，一般出現1到2秒會自動消失，但為了保持一致性，同個產品盡量使用同一位置。和Snack bar有所區別的是，Toast常常被用作系統提示消息，不包含動作按鈕，可以出現在屏幕上中下任意位置，并且只有安卓中有Toast。

Snack bar被用來通知用戶該程序正在發生或者即將發生的進程，也就是說Snack bar的內容一定是和用戶當前操作相關的，而Toast彈出的內容和當前操作沒有任何關系，只是一個系統提示，比如說“你收到了一條消息”這種。

Snack bar同樣短暫的出現在屏幕的底部，不中斷用戶體驗，也不需要用戶任何操作，自己就會消失。它繼承了Toast的所有基礎屬性，但是不同的是:

它常常只出現在屏幕底部
可以出現0-1個動作按鈕(不包括“取消”按鈕)
點擊Snack bar之外的區域，它會消失

這里值得注意的一點，Material design中已經不再推薦使用Toast而是更推薦Snack bar了，但是目前Toast在安卓應用上仍然在被廣泛使用。

下面著重介紹一下Snack bar。

使用場景:既想要展示信息，又想最小程度地打斷用戶注意。

關鍵點:

文案內容和當前程序的進程直接相關。
Snackbar中不能包含圖標。
盡量使用不透明純色背景，也可以加一點點的透明度，只要文案清晰可見即可。
為了和文案區別，動作按鈕用不同的顏色強調。
使用優先級最低的按鈕樣式，通常是文字按鈕。
動作按鈕不是必須的，因為即使什么也不做，snack bar也會自行消失，最多加一個動作按鈕，通常是“取消”。
最快4秒鐘，最慢10秒鐘， Snack bar會自行消失。
當同時有多個snack bar需要出現時，它們是一個一個出現的，前一個snack bar消失后，下一個才會出現。
通常出現在界面的底部，并且要避免它遮住導航、頻繁使用的交互組件等等重要的UI元素。
只有當界面底部沒有常駐的導航元件如底部tab欄時， snack bar才可以和屏幕等寬顯示。
當界面中有懸浮動作按鈕(FAB)時，snack bar不可以和FAB重疊，而是位于FAB的上方，底部有常駐導航元件時同理。

7）Tooltip

類型:非模態

參考規范:Material Design

簡介:當Tooltip通過鼠標懸停、聚焦、或者觸摸后被激活，它會識別一個與之對應的元素然后在該元素附近顯示簡短、描述性的文案，通常是對該元素的功能解釋，在停留短暫的時長后，Tooltip會自行消失。

關鍵點:

通常為了避免歧義和補充說明，Tooltip用來解釋圖像、圖標、相似相關的元素，不會用來解釋本來意思就顯而易見的文字。
文案只用文字，不要添加任何富文本信息如圖標、圖像。
完整展示整個Tooltip的元件，避免因為靠近邊緣而被裁切。
只要用戶的鼠標還停留在目標元素內部，Tooltip就不會自己消失，當用戶離開目標元素后，Tooltip會停留1。5秒后消失。

8）Andriod Notification

類型:非模態

參考規范:Material Design

簡介:在軟件不被使用期間，Notifications提供關于軟件簡短、時不時的的相關資訊。這種資訊可以是來自其他用戶的交流信息或者提供任務提醒。

Notifications如何被用戶注意到:

顯示狀態欄圖標
在鎖屏界面被展示
發出聲音或者震動
在當前屏幕短暫的出現
設備的屏幕閃爍一下

9）Message bar

類型:非模態

參考規范:Microsoft Fluent UI react 8.65.1

簡介:顯示軟件或者文件的錯誤、警告、重要的信息。比如說，一個文檔上傳失敗，那么錯誤的messabe bar就會出現。

關鍵點:

通常一個Message bar會顯示在軟件頂部，主操作欄的下面。比如說office的Message bar就是在ribbon的下面，在文檔畫布的上面。
多條信息可以同時出現，但是一個場景或者相關一系列場景應當一個只展示一個Message bar。 Message bar很少是關于一個操作的直接反饋，而是展示一個用戶應當了解的關于軟件或者文檔的總體的信息。
使用圖標來暗示Message的類型: 比如說，信息圖表就代表咨詢類的message；盾牌的圖標就代表和安全相關的message；警告圖標代表非阻塞型錯誤警告；

10）Coachmark &amp； Teaching bubble

類型:非模態

參考規范:Microsoft Fluent UI react 8.65.1

簡介:Coachmark 是為了吸引用戶注意力并且增加用戶使用他們的機會，當鼠標懸停或者選擇Coachmark時，Teaching bubble就會顯示。

關鍵點:

一次一個Coachmark只可以和一個Teaching bubble組合。
Coachmark可以是單個的，也可以是連續的。應當減少使用連續的coachmark，它只在復雜多步驟的交互中會被使用，連續coachmark最好不超過3步。
Coachmark只被設計來放Teaching bubble。
不可以改變Coachmark的尺寸、顏色和動畫。打開彈出窗口時，這個操作會減少用戶。

04 彈窗的設計原則

1. 什么時候選用彈窗

彈窗作為一種容器，在選用時常常和抽屜、頁面一起比較，那么在給定一個內容時，我們該根據什么來選擇使用哪種類型的容器呢?

首先，我們先把這三個容器的定義搞清楚。

彈窗：在不離開當前頁面的情況下，完成對某個任務的聚焦。
抽屜：建立在父級頁面的基礎上的一個附加面板，在被需要時呼出。
頁面：處于最下層的容器，也是我們最常見的容器形式。

接著，在我們被給定一個需求時，要先分析這個需求，從一下幾個方面去判斷:

1）信息承載量

既然是容器，必然有容量這一說，在這里用信息承載量可能更合適，信息承載量包括圖片、視頻、文本、表格等等各種形式的信息量，當信息量非常大，密密麻麻十分惱人時，彈窗自然是不被推薦使用的了，通常來說信息承載量大小有這么一個規律: 頁面 &gt；抽屜 &gt；彈窗。

不過信息承載量只是考慮的第一步，是一個比較宏觀的方面，不是決定性因素。

2）頁面獨立性

獨立性可以理解為與前一個或者當前頁面的聯系是否緊密。頁面的獨立性最高，當你不斷打開一個又一個新的頁面，常常會記不得上一個頁面的內容，這就是因為這些頁面的內容相對獨立，關聯性不大。

而我們僅僅是從定義上不難看出，彈窗和抽屜的獨立性較低，彈窗的前提是不離開當前頁面內容，甚至彈窗的主體不能夠遮住當前頁面的重要內容；抽屜是建立在父級頁面基礎上的，它是對父級頁面內容的補充。

大多數彈窗是與當前用戶正在執行的操作內容相關的，比如在表單錄入的場景下，選擇時間會彈出時間彈窗，選擇地址時會彈出地址簿彈窗。

抽屜比較適合內容度較深、邏輯緊密、概括性簡短的內容但不是時時必須展示的內容，如購物網站的目錄導航、safari收藏夾等等。

而頁面和頁面之間的邏輯性不強甚至可以毫無邏輯，比如跳轉到一個莫名其妙的廣告頁面。

3）頁面切換成本

當用戶因為某個業務需求需要頻繁在A和B頁面間切換時，這個時候我們就要考慮切換成本。

抽屜有一個固定位置的觸發按鈕，所以當需要頻繁操作時，用戶能夠快速找到并彈出抽屜，減少學習成本。

彈窗回到頁面的速度也很快，如果是非模態彈窗，它可能會自行消失、點擊遮罩區域消失或者點擊關閉按鈕消失，對于模態彈窗來說，只要用戶做出了明確的操作后，彈窗就會消失，自然的回到當前頁面。

頁面是切換成本最高的，一般需要點擊返回按鈕，返回上一級頁面，這個時候頁面加載需要一定的時間，用戶需要快速認知一個全新的頁面需要一定的適應時間，所以頁面的切換成本最高。

2. 彈窗文案怎么寫

1）UX Writing規則

說人話：彈窗應與現實世界相關連彈窗應該使用用戶的語言（用戶熟悉的文字，短語和概念），而不是一些系統特有的專有名詞。
表述清晰無歧義：在彈窗中使用語意清晰的問題和選項，而不是讓用戶產生疑惑，令用戶猶豫不決。
簡潔：在表述清晰的前提下，盡量減少字數，一方面是因為彈窗的尺寸大小有限，無法承載太多的字數；另一方面，任何人都不喜歡長篇大論，彈窗做的就是幫助用戶高效率理解問題、解決問題。
一致性：同樣的意思、同樣的操作所使用的詞語句子保持相同，比如說“編輯”和“修改”是差不多的意思，那么在這個系統中只能出現其中一個詞語。

2）標題

標題是用戶第一眼注意到的內容，用戶掃一眼標題來快速了解這個彈窗是做什么的，所以標題的重要性不言而喻。

如果彈窗是用戶主動觸發，彈窗標題應當包含觸發該彈窗的動作按鈕的文案，通常采用“動詞+名詞”的格式，這樣用戶才能通過標題確認自己進入了正確的模塊。
彈窗標題和內容是總-分關系。標題一般是陳述問題、詢問行為或者做出行為建議，通常比較簡短概括；內容是一個較為詳細的說明解釋以及操作的后果等等。
標題中不要使用諸如“錯誤!”“警告!”這種帶有強烈情緒的詞語，而是使用帶有信息的中性的句子，比如“某某任務終止”。

3）內容

用戶不喜歡被責怪。避免使用針對性措辭，比如:你出錯了!
生僻專業詞匯附加解釋，尤其像金融類產品，里面涉及了大量專業詞匯，非專業人士小白可能會一頭霧水，這時候可以采用Tooltip形式，當用戶懸停在該詞匯上，顯示對該詞匯的解釋。
內容不必再重復標題中的文案。
使用具體的可以付諸行動的語言，把重要的信息寫在開頭。
可以在內容中添加一些可供用戶參考的有用信息。

4）如何優化按鈕文案

操作清晰可預測。減少使用中性詞，從而避免用戶停頓思考，讓用戶看到文本的瞬間就明白按鈕時會發生什么。

優先考慮“動詞+名詞”的形式，如果不能夠這樣表達，再去考慮“確認”“取消”“關閉”這些中性詞。

5）反饋

操作后的反饋對于用戶體驗也很重要，正如你打游戲通關時，系統會發出喝彩的聲音，比如你提交了一個表單彈窗，當你提交后，應當顯示提交成功的反饋。

成功: 告知用戶結果或者當前進程
失敗: 告知用戶失敗的結果、失敗的原因、如何解決問題

3. 滾動條

首先要明確的一點，在各大規范中都不推薦使用滾動條，因為首先彈窗的內容承載量就不大，如果是業務場景復雜的彈窗，我們可以采用Tab或者分步彈窗，盡量去避免在彈窗中使用滾動條。

那么，如果不得不使用滾動條的情況下，有幾點要注意:

內嵌表格彈窗:當表格數據很少時，表格中不含滾動條；當表格數據列較多，出現水平滾動條；當表格數據行過多時，設定固定高度的表格，出現垂直滾動條。
一般彈窗:禁止使用水平滾動條，垂直滾動條出現時，要保證遮罩內容區的滾動條保持靜止，否則局面會變得混亂不堪。當關閉彈窗后，內容區的滾動條恢復運動。

4. 彈窗尺寸

1) Web端

調查市面上的電腦分辨率，從數據圖中可見，分辨率900 * 1080是主流，最小的分辨率是1024 * 768。

俗話說“一個水桶，盛水量得看最短的那塊木板”，所以理論上來說，只要彈窗能滿足1024*768的分辨率，就可以適配市面上所有的電腦。

寬度: 最大寬度一般在1000px左右。最小寬度由各個平臺制定
高度: 最大高度是600px左右。具體計算: 768px-瀏覽欄頂部高度(60~100px)-系統底部工具欄高度(40px)=628~668px，再加上彈窗不能像個充氣的氣球一樣擠滿整個屏幕，肯定還要留一些安全邊距(每個平臺的安全邊距不一樣)，我們再取個整——600px左右是最大高度。

各個平臺根據自身業務量和需求的差異性，可以根據內容量再給彈窗的尺寸分類，常見的可以分為: 超級大、大、中、小尺寸，比如螞蟻中臺的Alert的幾種尺寸:

2) 手機端

手機端的彈窗一般都是全屏顯示，除了一些特殊的彈窗類型如Alert， Error， Notification會有固定的尺寸規范。

5. 彈窗的兩種生效模式

彈窗中有兩種生效模式: 即時提交模式(immediate commit model)和延遲提交模式(delayed commit model)

舉個例子，如mac的偏好設置中的桌面屏保，當你選中后立即生效，這里沒有提交也沒有確認按鈕，這種就是即時提交模式；而延遲提交模式更為常見，比如注冊網站會員時，你需要填好所有的信息，然后確認一遍，最后提交。

即時提交模式更適合本身操作量不大，但是切換頻繁的操作，尤其對于視覺聽覺上的效果改變，即時提交是非常高效的，常見的比如更換手機鈴聲、選擇照片濾鏡、更換電腦壁紙等等。

延遲提交模式在B端中非常普遍，它需要用戶仔細斟酌輸入的內容，用戶修改編輯滿意后再確認提交，比起效率，它更重視質量、減少出錯率。

6. 彈窗的交互

1) 彈窗內的導航:

當彈窗內有次級彈窗(同一個容器，不同的內容)時，在次級彈窗標題部分，有一個返回按鈕，可以返回主彈窗。

2) 用戶改變彈窗的顯示大小

比如一些長列表，里面的條目很多，有一些字段因為比較長，被隱藏住了一部分，用戶需要滾動滑動條，來查看更多的條目，而當彈窗的大小可以被改變時，用戶就可以增大彈窗，從而每滾動一次，就能查看更多的條目，減少滾動條的操作次數，更大的視野也讓用戶的體驗感更好。

這里有兩個小細節值得注意:

要設定一個最大/最小寬度，保證彈窗始終可以被看見，不影響彈窗最基本功能的實現。
給一個暗示的符號，比如小三角符號，告知用戶這個頁面是可以被拉伸的。

3) 拖拽移動彈窗

有時候一個彈窗彈出來正好遮擋住了底部頁面的重要內容，所以彈窗需要有被移動和拖拽的功能:

4) 彈窗的防錯功能

在填寫表單場景下，比方說用戶已經花費了二十分鐘填寫表單，但是他不小心碰到了鍵盤上的Esc鍵，彈窗自動退出，那么他的內容就消失了，這對用戶來說是十分糟糕的，有如五雷轟頂!

所以對于一些彈窗而言，添加防錯功能是很有必要的，在不小心誤觸后，彈窗不會立刻關閉，而是彈出一個確認彈窗“你確定要離開嗎?你的內容將會丟失”，這個確認彈窗可以大大的降低誤觸帶來糟糕后果，畢竟很少人會連續誤觸兩次嘛。

確認彈窗確實是防錯的一個思路，還有一個思路是為彈窗添加自動保存功能，當彈窗不小心關閉后再打開時，剛才的內容還在，不過新用戶的心情會經歷一個跌宕起伏: “糟糕了!我的心血沒了!(哭泣)”–奧!!它們竟然還在，太驚喜了!”

7. 多個彈窗

需要明確的一點，在各大規范中，都不推薦彈窗疊彈窗，即使必要情況下，也會限制彈窗的數量，至于為什么這樣限制，打個比方你就懂了:大家小時候玩過俄羅斯套娃吧，每打開一個娃娃會發現里面還藏著一個娃娃，試想把娃娃換成彈窗，彈窗中還有彈窗。

這樣會讓用戶迷失在當前彈窗中，彈窗越多，用戶需要更多的時間和操作回到主彈窗(最外面的娃娃)。
最里面的彈窗因為隱藏的過深，不容易找到；三，過多的彈窗加大視覺工作量，增加視覺噪音，導致糟糕的用戶體驗，所以彈窗不推薦多層級堆疊。

但是在復雜的大型企業軟件中，不可避免的會出現多個彈窗的情況，我們又該怎么解決呢?

根據用戶的目標和任務的對應關系，彈窗和彈窗之間的關系可以分為線性和非線性關系。

1）非線形關系

比如Photoshop，里面的大量窗口都是非線形關系，我可以調一下這個參數，再跳到另一個窗口改變另一個參數，這些參數本身并不存在什么邏輯關系，所以Photoshop的工作臺可以將窗口隨意的打開、隱藏、關閉，可以根據設計師的使用頻率自定義工作臺的內容窗口，而面對復雜大量的功能，PS給了諸如搜索的工具，讓用戶自主的快速找到自己需要的功能。

對于多個非線形彈窗，與其耗費心機的建立一個復雜的結構導航，不如給他們工具，讓用戶找到他們自己想要的東西。

2）線形關系

當彈窗和彈窗之間存在緊密的邏輯關系時，常見的有三種形態:

A容器中彈出B容器
同一容器不同內容
關閉A容器后，彈出B容器

舉個例子，叮叮的“新建項目”:

假設用戶的目標是想要從已有項目中復制一個模版: 點擊全部模版后，跳到模版界面，這一步就是“A容器中彈出B容器”。

進入模版彈窗后，點擊新建模版，選擇“從已有項目中新建”，可以看出這一步的彈窗的容器沒有變化，只是將彈窗的內容區域進行改變，這就是“同一容器不同內容”。

而“關閉A容器后，彈出B容器”，這個就不太常見，比如通常我們卸載一些流氓軟件時，會確認卸載之后，再確認一次，使得用戶十分惱怒，這些流氓軟件為了留下來真的費盡心機；還有就是在填寫非常重要的信息時，系統為了提醒用戶“你一定要填寫正確，因為這是不可更改的哦”所以會確認兩次。

這個場景不常見，所以絕大多數彈窗只要一個確認彈窗就可以了。

05 彈窗的使用場景

我們從對話框傳遞的信息的性質和來源，可以將對話框分為系統彈窗、信息展示彈窗、操作彈窗。《About Face 4》一書中將彈窗更細致地分為屬性、功能、通知、公告、進度彈窗，其實理解起來是一樣的: 進度和公告是系統彈窗，通知屬于信息展示彈窗，功能彈窗就是操作彈窗。

系統彈窗:這是由應用程序直接啟動，而不是用戶請求發出的，比如“版本升級到2.0”“頁面崩潰了”。

信息展示彈窗:顧名思義，就是展示信息的彈窗，這個信息可以是來自其他用戶的消息、也可以是查看詳情等等。

操作彈窗:用戶需要對彈窗執行具體的動作，比如常見的表單錄入、確認刪除、上傳信息等等。

一般的簡單場景下，不需要再搭建額外的層級關系，用常見的簡單的方式就可以完成需求，但是在復雜的業務場景下，我們可能會遇到各種各樣棘手的問題，如信息太多、信息太復雜.

于是我們將一些頁面中會用到的層級框架運用到彈窗中，但是切記彈窗的承載量是很小的，不要濫用這些手段(比如說彈窗中又有Tabbar，又有側邊欄，這樣是很忌諱的)，這里提供幾種解決思路:

1. Tab導航彈窗

Tab是一種導航控件，當頁面的內容眼花繚亂時，我們可以將內容分類然后放入不同的Tab頁面中，如Mac中的系統偏好設置的顯示器設置。

Tab選項卡的形式是多樣化的，包括僅文字、僅圖標、圖標+文字、帶有次級選項的Tab選項、帶數字/角標等等，設計師根據業務場景選擇最合適的。

當Tab和底部操作區同時存在時，操作區的層級永遠是最高的，所以說當點擊操作區按鈕時，其生效的范圍是所有Tab，而不是當前Tab。

如果用戶想在當前tab頁面完成操作的話，這個時候可以刪掉底部的操作區，推薦使用選擇控件如單選框/復選框，當勾選選項的瞬間，這個行為生效。

在使用Tabbar時有幾個小細節要注意:

使用盡量少的tab，并且保證每一個Tab始終可見。
當在某些情況下，某個Tab下的內容是空的或者不可見的，也要顯示這個tab，原因是保持系統的穩定性和可預測性，你可以在空白的頁面中解釋為什么當前頁面是空白的，避免讓用戶一頭霧水。

2. 側邊欄導航彈窗

由于彈窗的寬度限制， Tabbar可承受的數量有限，當Tab數量太多時，不妨考慮用Sidebar，以騰訊會議的設置彈窗舉例。 Sidebar和Tabbar類似，都是導航控件，所以同樣地，如果用戶想在當前sidebar選項頁面完成操作的話，推薦使用選擇控件如單選框/復選框，它也是立刻生效。

3. 分組彈窗

在表單錄入場景中，當信息又多又亂的時候，往往會降低用戶的閱讀效率，增加用戶的認知成本，分組就是一個很好的解決辦法。將同類的信息歸納成一組，可以給每個組加上一個標題，也可以只是在組和組之間加上分割線，界面更加清晰，操作流程更加高效。

4. 分步彈窗

分步彈窗適用于有一定的先后邏輯的操作步驟，必須完成第一步才能進行第二步，不可以像Tabbar或者Sidebar一樣隨心所欲地去任意位置，最常見的就是網站注冊。

這樣做有幾個好處:

用戶一次只要專注于一個步驟，降低用戶認知，提高操作效率。
由于必須先完成第一步才可以進行下一個步驟，上一步正確了才能進行下一步，大大降低了整體的出錯率。
步驟條也是一種進度條，能為用戶提供正向反饋，用戶有一種“一切盡在掌握之中”的感覺，帶給用戶的體驗感很好。
試想如果一上來用戶就被告知要寫一大堆的東西(用戶是非常討厭做輸入內容的工作的)，很可能面對大量內容時被勸退，但是分解到多個步驟中后，看上去就沒有那么多了，減少用戶的壓力。

5. 側邊欄作為參考

彈窗使我們不得不聚焦于當前任務中，但是在一些信息錄入場景中，我們錄入的信息并不像我們的身份信息一樣信手拈來，比如商品信息的錄入，這個時候可以采用側邊欄的形式將參考信息放在旁邊。

以叮叮的“新建工作待辦”——添加執行人舉例子: 為了減輕用戶的記憶壓力，叮叮在右側提供一個常駐的側邊欄，用戶可以通過“最近聊天”“我的好友”“我的群組”等方式查詢到自己好友的姓名，這個側邊欄于左邊的頁面是相對獨立的。

06 結語

彈窗規范雖然目前來說已經比較完善了，但是隨著業務場景的復雜化和多元化，我相信還會有更多新的規則產生，這就要求設計師不僅僅要了解并合理運用規范，更要勇于質疑和思考，去不斷地完善規范。

以上是我對彈窗的一些思考和總結，如果你有不同的想法，歡迎與我交流! 期待聽到你的聲音!

本文由郝小七指導http：//www.woshipm.com/u/917803

作者：自來卷夏憶

本文由 @自來卷夏憶原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

在線咨詢

上一篇：超酷實用的10款HTML5 CSS3菜單集合！
下一篇：使用 uncss 刪除頁面未使用的樣式！

您的項目需求

*請認真填寫需求信息，我們會在24小時內與您取得聯系。

整合營銷服務商

基于 Vue 智能提示組件V-Tooltip

chrome擴展結構

擴展能夠做什么

擴展的調試

完整的示例

總結

01 彈窗的定義

02 彈窗的組成

1. 遮罩

2. 彈窗主體

3. 彈窗的關閉入口

03 彈窗的類型

1. 模態&amp；非模態

2. 典型彈窗

04 彈窗的設計原則

1. 什么時候選用彈窗

2. 彈窗文案怎么寫

3. 滾動條

4. 彈窗尺寸

5. 彈窗的兩種生效模式

6. 彈窗的交互

7. 多個彈窗

05 彈窗的使用場景

1. Tab導航彈窗

2. 側邊欄導航彈窗

3. 分組彈窗

4. 分步彈窗

5. 側邊欄作為參考

06 結語

您的項目需求