htmlxScheduler是一個類似于Google日歷的JavaScript日程安排控件，日歷事件通過Ajax動態加載，支持通過拖放功能調整事件日期和時間，事件可以按天，周，月三個種視圖顯示。

DHTMLX Scheduler官方最新版免費下載試用，歷史版本下載，在線文檔和幫助文件下載-慧都網

在本教程中，我們將使用兩個強大的工具：DHTMLX Scheduler庫和Angular框架來創建一個全面的酒店客房預訂應用程序。在這篇文章中，我們的目標是創建一個看起來像這樣的應用程序：

Angular酒店預訂應用將能夠顯示酒店房間、房間類型、房間狀態、特定日期的預訂和預訂狀態，該應用程序還允許執行CRUD操作。

如果您剛開始配置DHTMLX Scheduler來預訂房間或將其集成到Angular應用程序中，我們還為您提供了專門的教程：

• Configuring DHTMLX Scheduler for Hotel Booking
• Integrating DHTMLX Scheduler into an Angular App

Step 0 – 前提條件

在開始之前，請確保您已經有了Node.js和Angular CLI。

Step 1 – 準備應用程序

要創建應用程序，使用如下命令：

ng new room-reservation-angular

操作完成后，我們可以進入app目錄并運行應用程序：

cd room-reservation-angular
ng serve

現在如果打開打開http://127.0.0.1:4200，應該看到初始頁面。ng serve命令將監視源文件，并在必要時修改和重建應用程序。

Step 2 – 創建數據模型

讓我們定義Reservation、Room、RoomType、CleaningStatus和BookingStatus模型，執行如下命令：

ng generate interface models/reservation model
ng generate interface models/room model
ng generate interface models/roomType model
ng generate interface models/cleaningStatus model
ng generate interface models/bookingStatus model

在models文件夾中新創建的reservation.model.ts文件中，我們將添加以下代碼：

export interface Reservation {
id: number;
start_date: string;
end_date: string;
text: string;
room: string;
booking_status: string;
is_paid: string;
}

在room.model.ts、room-type.model.ts、cleaning-status.model.ts、booking-status.model.ts文件中，添加下面的代碼行：

export interface Room {
id: number;
value: string;
label: string;
type: string;
cleaning_status: string;
}

export interface RoomType {
id: string;
value: string;
label: string;
}

export interface CleaningStatus {
id: string;
value: string;
label: string;
color: string;
}

export interface BookingStatus {
id: string;
value: string;
label: string;
}

Step 3 – 創建Scheduler組件

下載DHTMLX Scheduler PRO版最新的試用版（直接戳這里>>），將下載的包解壓縮到本地機器的項目根文件夾中。為了能夠將Scheduler嵌入到應用程序中，您應該獲得DHTMLX Scheduler代碼。執行如下命令：

npm install ./scheduler_6.0.5_trial

創建一個新的組件，為此運行以下命令：

ng generate component scheduler --skip-tests

在scheduler文件夾中新創建的scheduler.component.html文件將包含調度器的模版，讓我們添加下一行代碼：

<div #scheduler_here class='dhx_cal_container' style='width:100%; height:100vh'>
<div class='dhx_cal_navline'>
<div style='font-size:16px;padding:4px 20px;'>
Show rooms:
<select id='room_filter' [(ngModel)]='selectedRoomType' (ngModelChange)='filterRoomsByType($event)'></select>
</div>
<div class='dhx_cal_prev_button'> </div>
<div class='dhx_cal_next_button'> </div>
<div class='dhx_cal_today_button'></div>
<div class='dhx_cal_date'></div>
</div>
<div class='dhx_cal_header'></div>
<div class='dhx_cal_data'></div>
</div>

使用ngModel和ngModelChange指令來建立組件中select元素和數據之間的交互，請將FormsModule模塊添加到app.module.ts文件中。

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';

import { AppRoutingModule } from './app-routing.module';
import { AppComponent } from './app.component';
import { SchedulerComponent } from './scheduler/scheduler.component';

import { FormsModule } from '@angular/forms';

@NgModule({
declarations: [
AppComponent,
SchedulerComponent
],
imports: [
BrowserModule,
AppRoutingModule,
FormsModule
],
providers: [],
bootstrap: [AppComponent]
})
export class AppModule { }

將在名為scheduler.component.css的單獨文件中聲明scheduler樣式，央視可以以下面的方式呈現：

@import '~dhtmlx-scheduler/codebase/dhtmlxscheduler_flat.css';
:host {
display: block;
position: relative;
height: 100%;
width: 100%;
}
html, body {
margin: 0;
padding: 0;
height: 100%;
overflow: hidden;
}
.dhx_cal_container #room_filter:focus {
outline: 1px solid #52daff;
}
.timeline-cell-inner {
height: 100%;
width: 100%;
table-layout: fixed;
}
.timeline-cell-inner td {
border-left: 1px solid #cecece;
}
.dhx_section_time select {
display: none;
}
.timeline_weekend {
background-color: #FFF9C4;
}
.timeline_item_cell {
width: 32%;
height: 100% !important;
font-size: 14px;
text-align: center;
line-height: 50px;
}
.cleaning_status {
position: relative;
}
.timeline_item_separator {
background-color: #CECECE;
width: 1px;
height: 100% !important;
}
.dhx_cal_event_line {
background-color: #FFB74D !important;
}
.event_1 {
background-color: #FFB74D !important;
}
.event_2 {
background-color: #9CCC65 !important;
}
.event_3 {
background-color: #40C4FF !important;
}
.event_4 {
background-color: #BDBDBD !important;
}
.booking_status,
.booking_paid {
position: absolute;
right: 5px;
}
.booking_status {
top: 2px;
}
.booking_paid {
bottom: 2px;
}
.dhx_cal_event_line:hover .booking-option {
background: none !important;
}
.dhx_cal_header .dhx_scale_bar {
line-height: 26px;
color: black;
}
.dhx_section_time select {
display: none
}
.dhx_mini_calendar .dhx_year_week,
.dhx_mini_calendar .dhx_scale_bar {
height: 30px !important;
}
.dhx_cal_light_wide .dhx_section_time {
text-align: left;
}
.dhx_cal_light_wide .dhx_section_time > input:first-child {
margin-left: 10px;
}
.dhx_cal_light_wide .dhx_section_time input {
border: 1px solid #aeaeae;
padding-left: 5px;
}
.dhx_cal_light_wide .dhx_readonly {
padding: 3px;
}
.collection_label .timeline_item_cell {
line-height: 60px;
}
.dhx_cal_radio label,
.dhx_cal_radio input {
vertical-align: middle;
}
.dhx_cal_radio input {
margin-left: 10px;
margin-right: 2px;
}
.dhx_cal_radio input:first-child {
margin-left: 5px;
}
.dhx_cal_radio {
line-height: 19px;
}
.dhtmlXTooltip.tooltip {
color: #4d4d4d;
font-size: 15px;
line-height: 140%;
}

要使scheduler容器占據主體的整個空間，您需要在src文件夾下的styles.css文件中添加以下樣式：

body,
html {
width: 100%;
height: 100%;
margin: unset;
}

要繼續，我們需要導入所需的模塊，并將必要的代碼行添加到scheduler.component.ts文件中：

請在GitHub上查看scheduler.component.ts 的完整代碼。

現在讓我們將新組件添加到頁面中，為此打開app.component.html(位于src/app中)并在其中插入scheduler標簽:

<scheduler></scheduler>

在下文中，我們將為大家繼續介紹如何加載和保存數據，記得持續關注哦~

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

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

廣告彈窗曾經在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 是為了吸引用戶注意力并且增加用戶使用他們的機會，當鼠標懸?；蛘哌x擇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) 用戶改變彈窗的顯示大小

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

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

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

3) 拖拽移動彈窗

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

4) 彈窗的防錯功能

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

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

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

7. 多個彈窗

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

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

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

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

1）非線形關系

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

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

2）線形關系

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

1. A容器中彈出B容器
2. 同一容器不同內容
3. 關閉A容器后，彈出B容器

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

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

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

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

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

05 彈窗的使用場景

我們從對話框傳遞的信息的性質和來源， 可以將對話框分為系統彈窗、信息展示彈窗、操作彈窗?！禔bout 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 協議

期開始嘗試將新文章預發表，預發表的文章僅展示在公眾號主頁（不會群發），以供提前預覽，想要看新文章的可以在主頁查看，有問題歡迎隨時指出。新文章會在合適的時間群發給各位小伙伴！

全文約 5800 字，預計閱讀需要 20 分鐘

作為一名前端開發，Chrome Devtools 是最常用的工具之一，它提供了很多實用的調試功能。Chrome 團隊也在一直積極地更新新版本，本文就來盤點自 Chrome 110 以來，Devtools 中新增的實用調試功能，總有一個你用的上！

Chrome 118

Elements > Styles 中自定義屬性查看

該版本中，在Elements面板的Styles選項中新增了一個自定義屬性部分。通過使用@property CSS 規則，可以明確地定義CSS自定義屬性，并在樣式表中進行注冊，而無需編寫任何JavaScript代碼。

通過在Elements > Styles中懸停在屬性名稱上，可以查看其描述符并通過工具提示來查看已注冊屬性的詳細信息。點擊工具提示中的鏈接可以展開顯示已注冊屬性的部分。

搜索增強

現在搜索結果會顯示每行代碼中找到的所有匹配項。之前，每行代碼只顯示第一個匹配項。這種新的行為在搜索壓縮文件時特別有用。當點擊搜索結果時，它會在編輯器中打開文件，并且不僅在垂直方向上滾動到匹配位置，還會在水平方向上進行滾動。

此外，搜索功能得到了速度提升。下面是改變前（左側）和改變后（右側）的對比。

另外，搜索功能現在支持忽略列表，并且不會顯示已忽略文件的搜索結果。

Sources 面板改進

現在可以通過拖放的方式重新排列 Sources 面板左側的邊欄。

現在，Sources面板具備以下功能：

• 對于以下腳本類型，可以對其中的內聯JavaScript進行打印美化：module、importmap、speculationrules。
• 對于包含JSON的importmap和speculationrules腳本類型，可以突出顯示其語法。

輔助功能改進

DevTools 現在支持更多的導航按鍵操作：

• CSS Overview：使用上下箭頭在左側邊欄中導航到各個部分。
• Memory：在左側邊欄中，使用Tab鍵聚焦到快照旁邊的保存按鈕，然后按Enter鍵選擇文件夾。

Chrome 117

更快地本地覆蓋網頁內容

優化了本地覆蓋功能，因此可以在沒有訪問權限的情況下，通過 Network 面板輕松模擬遠程資源的響應頭和網頁內容。

要覆蓋網頁內容，需要打開 Network 面板，右鍵點擊一個請求，然后選擇“Override content”。

如果已經在DevTools中設置了本地覆蓋但將其禁用了，現在 DevTools 會自動啟用本地覆蓋功能。如果尚未設置本地覆蓋，DevTool s會在操作欄中提醒你選擇一個文件夾來存儲覆蓋內容，并授權 DevTools 訪問該文件夾。

設置完本地覆蓋后，DevTools 會進入 Sources > Overrides > Editor 頁面，可以進行網頁內容的覆蓋操作。

請注意，在 Network 面板中，被覆蓋的資源會以“Saved.”的標識顯示。將鼠標懸停在圖標上可以查看哪些內容被覆蓋了。

覆蓋XHR和fetch請求內容

現在還可以覆蓋XHR和fetch請求的內容。通過這樣的覆蓋，即使后端和API尚未準備好，也可以模擬API的響應來調試網頁。

DevTools 目前支持以下請求類型的內容覆蓋：圖像（例如avif、png）、字體、fetch和XHR、腳本（css和js）以及文檔（html）。對于不支持的類型，DevTools 現在會將“Override content”選項置灰。

隱藏Chrome擴展請求

為了幫助開發者專注于編寫代碼，因此，Network 面板新增了一個過濾器，過濾掉了可能在Chrome中安裝的擴展程序發送的無關請求。要過濾掉所有發送到chrome-extension:// URL的請求，可以勾選“Hide extension URLs”選項。

此外，DevTools 現在不會嘗試加載擴展程序的源映射文件，因此將不會看到與代碼無關的“無法加載源映射”警告。另外，由代碼導致的類似警告現在會顯示在Sources面板底部的信息欄中，而不是控制臺中顯示。

HTTP狀態碼可讀性更強

現在在請求的頭部中，HTTP狀態碼旁邊會顯示易于理解的文本，以便更快地了解請求的處理情況。以往只能看到數字狀態碼，現在還提供了相應的可讀性更強的描述性文本，使得解讀和理解請求的處理結果更加方便。

還可以將鼠標懸停在請求表中的狀態碼上，以查看相同的文本信息。

JSON 子類型響應格式美化

現在在請求的響應選項卡中，對于具有應用程序/[子類型]+json MIME子類型（如ld+json、hal+json等）的請求，會正確解析響應并提供更美觀的顯示效果?？梢詫憫獢祿M行格式化，使其更易讀和易于理解。以前可能只能以原始的、緊湊的形式展示 JSON 數據，而現在提供了更好的可視化格式化效果。

性能改進：查看網絡事件的獲取優先級變化

Performance 面板現在在網絡軌跡中的事件摘要中顯示兩個優先級字段：初始優先級和（最終）優先級，而不僅僅是單一的優先級。通過這個額外的字段，可以看到事件的獲取優先級是否發生了變化，并調整下載順序。

此外，還可以在 Network 面板的優先級列中找到相同的信息，并通過啟用“Big request rows”設置來查看。

默認啟用的源代碼設置：代碼折疊和自動文件顯示

現在，默認情況下啟用了 Settings > Preferences > Code folding 選項。該選項允許折疊代碼塊。

如果需要折疊代碼塊，將鼠標懸停在代碼塊開始旁邊的行號上，然后單擊折疊圖標即可。再次單擊{...}以展開該代碼塊。

此外，Settings > Preferences > Automatically reveal files in the sidebar選項現在也默認啟用。該設置使得在切換標簽頁時，Sources -> Page 中的文件樹會選擇當前在編輯器中打開的文件。

在 Application 面板中調試預加載

Chrome 團隊正在重新引入用戶可能導航到的未來頁面的完全預渲染。為了進行調試，開發者工具將在 Application 面板中添加Preloading 部分。新的預取和預渲染（統稱為“導航預加載”）使用了 Speculation Rules API，而不是基于鏈接的資源提示。

在下面的演示中，在 Application > Preloading 部分，可以檢查以下內容：

• Speculation Rules（規則推測）：列出當前頁面上找到的所有規則集。
• Preloads（預加載）：列出來自規則集的所有預取和預渲染的URL。
• This Page（此頁面）：列出當前頁面的預渲染狀態。

新顏色

DevTools 現在有一個與Chrome更好對齊的全新外觀，并使用了全新的配色方案。使用新顏色前后的對比如下圖所示。

Chrome 116

改進缺失樣式表的調試

DevTools 進行了多項改進，可幫助您更快地識別和調試缺少樣式表的問題：

1. Sources > Page tree 現在只顯示成功部署和加載的樣式表，以減少混淆。
2. Sources > Editor現在會對失敗的@import、url()和href語句進行下劃線和內聯錯誤提示框的顯示。

• 控制臺現在除了提供指向失敗請求的鏈接外，還提供指向未能加載的樣式表引用的精確行號的鏈接。

• Network 面板始終在"Initiator"列中提供了指向引用未能加載的樣式表的精確行號的鏈接。
• Issues 面板列出了所有加載樣式表的問題，包括損壞的URL、請求失敗以及錯位的@import語句。

在Elements > Styles中的 Easing Editor（緩動編輯器）中，現在支持線性時間函數。

使用 Easing Editor，可以輕松地通過點擊調整過渡時間函數和動畫時間函數的值。在這個版本中，Easing Editor 得到了線性時間函數的支持。

要配置線性時間函數，點擊線性選擇器按鈕。要添加控制點，請在線上任意位置單擊。要刪除控制點，可以雙擊它。還可以選擇預設之一：linear, elastic, bounce, emphasized。

存儲桶支持和元數據視圖

Application > Storage部分現在支持存儲桶。存儲桶是彼此獨立的，因此可以為數據片段指定驅逐優先級，并確保最有價值的數據不會被刪除。每個存儲桶可以存儲與已建立的存儲API（如IndexedDB和CacheStorage）相關的數據。

打開DevTools，導航到Application > Storage > Indexed DB，并運行代碼。DevTools 現在會顯示存儲桶及其內容。選擇一個存儲桶以查看其元數據。

現在，統一的元數據視圖也適用于本地存儲（local storage）、會話存儲（session storage）和緩存存儲（cache storage）部分。

Chrome 115

新的 CSS 子網格標志

Elements 面板中為子網格（subgrid）添加了一個新的標志。這個功能目前在Chrome Canary中處于實驗階段。要檢查和調試嵌套的子網格，它從父網格繼承軌道的數量和大小，點擊標志即可。它會切換一個覆蓋層，在元素視口的頂部顯示列、行及其編號。

查看選擇器特異性

在Elements > Styles中，將鼠標懸停在選擇器名稱上，可在工具提示中查看它的特異性權重（優先級）。

查看自定義 CSS 屬性值

在Elements > Styles中，將鼠標懸停在自定義CSS屬性名稱上，可以查看其取值。

Sources 面板改進

Sources 面板對于預處理的CSS文件，例如SASS、SCSS和LESS，增加了以下功能：

• 語法高亮：可以對CSS代碼進行語法突出顯示，提高可讀性。
• 內聯編輯器支持：這些編輯器類似于Elements > Styles中的編輯器，例如顏色選擇器和緩動編輯器。可以直接在 Sources 面板中進行編輯，方便修改CSS樣式。

設置條件斷點的快捷方式

現在可以使用快捷方式更快地設置條件斷點。要打開斷點對話框，請按住 Command (MacOS) 或 Control (Windows / Linux)，然后單擊 Sources > Editor 左側的行號。

默認情況下忽略內容腳本

現在 Settings > Ignore List > Content scripts injected by extensions默認情況下是啟用的。啟用此設置后：

1. 調試器會忽略這些腳本，并不會在其拋出的異常處中斷。
2. 在"Sources > Call Stack"面板中，會跳過被忽略的幀。要在此處關閉跳過，勾選"Show ignore-listed frames"。
3. 在 Console 中，在堆棧跟蹤中折疊被忽略的幀。點擊"Show N more frames"進行展開，點擊"Show less"進行折疊。

此外，忽略列表的選項有了更清晰的文本。

Network > Response 格式美化

默認情況下，Network > Response 現在會對壓縮過的響應體進行格式美化，與 Sources 面板類似。

此外，SVG 文件還具有語法突出顯示功能。

Chrome 114

支持調試 WebAssembly

Devtools 默認開啟 Settings > Experiments > WebAssembly Debugging: Enable DWARF support 。

這個實驗特性可以讓開發者在 Wasm 應用中暫停執行和調試 C 和 C++ 代碼，同時提供了所有的調試信息：

• 使用DWARF調試信息映射的原始源代碼。
• 可理解的函數名稱在調用堆棧中。
• 支持斷點等功能。

使用Elements面板和Issues標簽調試自動填充

Chrome的自動填充功能可以根據保存的信息（如地址或支付信息）自動填寫表單。為了幫助開發者輕松調試與自動填充相關的問題，Elements面板現在可以用紅色波浪線突出顯示這些問題。

要查看此功能，需要啟用設置：Settings > Experiments > Highlights a violating node or attribute in the Elements panel DOM tree 。

在DOM樹中將鼠標懸停在突出顯示的問題上，然后點擊"View issue"，就會打開Issues標簽頁，其中列出了所有檢測到的問題并提供關于出錯原因的線索。

Recorder 支持斷言

現在，Recorder 面板允許在錄制過程中添加斷言，并提供所有運行時數據。

要添加斷言，需要開始新的錄制，與頁面進行交互，然后點擊"Add assertion"。Recorder 會插入一個waitForElement類型的步驟，可以進行自定義。

還可以配置用來斷言的步驟，例如JavaScript中的條件語句、節點的子元素數、元素可見性等。

Chrome 113

覆蓋網絡請求響應頭

現在可以在 Network 面板中覆蓋響應頭。之前，需要訪問Web服務器才能嘗試更改HTTP響應頭。

通過響應頭覆蓋，可以在本地原型化修復各種頭部，其中包括但不限于：

• 跨域資源共享頭
• 權限策略頭
• 跨域隔離頭

要覆蓋一個頭，可以導航至 Network > Headers > Response Headers，將鼠標懸停在頭部的值上，點擊編輯，并進行修改。

也可以添加自定義頭：

要在一個地方編輯所有的覆蓋設置，請編輯Sources > Overrides中的".headers"文件。在這個文件中，還可以點擊 Add override rule，使用通配符(*)來覆蓋多個請求。

Nuxt、Vite、Rollup 調試改進

為了幫助開發者在調試過程中更快地找出問題，增強的堆棧跟蹤現在隱藏了來自 Nuxt 3.3 或更高版本生成的源代碼中的幀。DevTools會跳過這些幀：

• 在控制臺跟蹤中，在Show N more frames鏈接下方。
• 在"Sources > Call Stack"中，在Show ignore-listed frames下方。

為了實現這些改進，DevTools、Nuxt、Vite 和 Rollup 團隊合作采用了"X-Google-IgnoreList"源映射擴展：

• Nuxt 3.3 Release
• Vite Server Options
• Rollup Configuration Options

Elements > Styles 中 CSS 改進

為了幫助開發者更快地診斷CSS問題，Styles 面板現在會在以下情況下劃掉CSS屬性和值：

• 當CSS屬性無效時，會劃掉整個CSS聲明（屬性和值）。
• 當CSS屬性有效的，但值無效時，只會劃掉值部分。

現在，[animation](https://developer.mozilla.org/docs/Web/CSS/animation)簡寫 CSS 屬性中包含了指向對應 @keyframes 規則的鏈接，這樣可以更快地在 Styles 面板中導航。

新增控制臺設置：回車時自動完成

從之前的版本（112）開始，可以配置開發者工具控制臺在按下回車鍵時應用自動完成建議。

默認情況下，要接受自動完成建議，可以按Tab鍵或右箭頭。為了也能夠使用回車鍵進行自動完成，需要啟用設置Settings > Console > Accept autocomplete suggestion on Enter.

此外，另一個設置的文本現在更加用戶友好：Treat code evaluation as user action.

命令菜單強調編寫的文件

命令菜單中的快速打開對話框現在會將列入忽略列表的第三方文件變灰，以更加強調編寫的文件。

Chrome 112

使用 Lighthouse 分析導出為 Puppeteer 腳本

Recorder引入了一個新的導出選項：Puppeteer（包括 Lighthouse 分析）。使用Puppeteer，您可以自動化和控制 Chrome。借助 Lighthouse 可以捕獲并提高網站的性能。

打開錄制，在點擊下載按鈕。選擇 Export 選項，然后保存為 .js 文件。

運行Puppeteer腳本，以獲得一個Lighthouse報告，并保存在flow.report.html文件中。

CSS 文檔

現在，Elements > Styles 面板在鼠標懸停在屬性上時會顯示一個簡短的描述。

工具提示中還有一個“ Learn more”鏈接，該鏈接會轉到該屬性的MDN CSS參考文檔。

如果對CSS非常了解，可能會覺得這個提示很煩人。可以勾選 Don't show 來關閉所有工具提示。

要重新打開它們，就需要進行如下設置：Settings > Preferences > Elements > Show CSS documentation tooltip。

CSS 嵌套支持

Elements > Styles 面板現在支持CSS嵌套語法，并將嵌套樣式應用于相應的元素。

在控制臺中標記日志點和條件斷點

進一步改進增強的斷點用戶體驗，控制臺現在標記由斷點觸發的消息：

• console.* 調用帶橙色問號的條件斷點？
• 帶粉紅色兩個點的日志點消息..

現在，控制臺會給出適當的源文件中斷點的錨鏈接，而不再是Chrome創建的用于在V8上運行任何JavaScript片段的VM<number>腳本。

單擊斷點消息旁邊的鏈接可直接跳轉到斷點編輯器。

調試時忽略不相關的腳本

為了幫助開發者專注于代碼的關鍵部分，現在可以直接從Sources > Page面板上的文件樹中將不相關的腳本添加到"忽略列表"中。

右鍵單擊任何腳本或文件夾，然后選擇與忽略相關的選項之一?？赡軙吹綄⒛_本或文件夾添加到列表中或從列表中移除的選項。調試器會忽略添加到列表中的腳本，并在調用堆棧中省略它們。

所有添加到忽略列表的腳本和文件夾在文件樹中都會顯示為灰色。

如果選擇了一個被忽略的腳本，點擊Configure按鈕會轉到 Settings > Ignore List。

Chrome 111

使用“Styles”調試高清顏色

在Web上，將引入新的CSS顏色類型和色彩空間，DevTools 也引入了新工具來幫助開發人員創建、轉換和調試高清色彩。Styles面板現在支持CSS顏色級別4規范中提到的12種新色彩空間和7種新色域。

以下是使用color()、lch()、oklab()和color-mix()的CSS顏色定義例子。

使用 color-mix() 函數時，可以在Computed邊欄中查看最終顏色輸出。

顏色選擇器支持所有新的顏色空間，并有更多的功能。例如，點擊 color(display-p3 1 0 1) 的顏色色塊。還增加了一條色域邊界線，區分了 sRGB 和 display-p3 色域，以便更清楚地了解你所選顏色的色域。

DevTools 支持在不同的顏色格式之間進行轉換?？梢允褂?#34;更改顏色格式"圖標來訪問轉換彈窗，或者在Styles面板中按住Shift鍵并點擊顏色進行轉換。

在進行轉換時，了解是否對顏色進行了裁剪以適應空間尺寸非常重要。DevTools會在轉換后的顏色旁邊放置一個警告圖標，提醒該顏色是否被裁剪。

此外，還可以使用新的快捷鍵從屏幕上拾取顏色。按下"c"鍵激活吸管工具，按下Escape鍵取消激活。吸管工具僅在sRGB色彩空間中采樣顏色。例如，如果嘗試采樣超出sRGB色彩空間的color(display-p3 1 0 1)顏色，吸管工具將會將該顏色裁剪為sRGB空間中最接近的顏色，即洋紅色(color(display-p3 0.92 0.2 0.97))。

最后，顏色格式設置現已被棄用，為新的高清色彩格式騰出空間。

增強的斷點用戶體驗

重新設計的斷點邊欄允許快速訪問常用功能，特別是停用、編輯和刪除斷點。

以下是一些亮點：

• 兩個暫停異常選項都移到了 斷點 窗格中，并標上了文字，使其更易于解釋。

• 斷點按文件分組，按行號或列號排序，并且是可折疊的。

• 將鼠標懸停在斷點或文件上時，可以使用新選項來停用、刪除和編輯斷點。

• 單擊編輯斷點按鈕打開斷點編輯器。從這里，可以輸入斷點條件或切換到日志點。

自定義 Recorder 快捷鍵

使用快捷鍵可以更快地記錄和重放用戶流程。Recorder 引入了幾個方便的快捷鍵，可加快用戶流程的錄制和重放速度。忘記快捷鍵了？沒問題，隨時點擊"?"按鈕查看所有快捷鍵。

也可以通過Settings菜單自定義這些快捷方式。

如果正在使用其他面板中，并且想要開始錄制用戶流程，可以使用DevTools中的命令菜單中的"Create a new recording"命令來開始錄制。

在 Application 面板中重新組織緩存

現在可以在 Application 面板的 Cache 部分找到 Cache Store ，而 Back/forward cache已移至Background Services部分。