在配置的過程中踩了很多坑，還是太菜，有些東西弄不明白什么意思。
運行項目時的報錯可直接到最下面看vite.config.js文件的注釋
目前項目用到的模塊并不多，package.json文件如下
-
{
-
"name": "PsWebV3Abb",
-
"version": "0.0.0",
-
"scripts": {
-
"dev": "vite",
-
"build": "vite build"
-
},
-
"dependencies": {
-
"@vitejs/plugin-vue": "^1.0.0",
-
"axios": "^1.2.1",
-
"element-plus": "^2.2.26",
-
"vite": "^4.0.3",
-
"vue": "^3.0.4",
-
"vue-router": "^4.1.5"
-
},
-
"devDependencies": {
-
"@vue/compiler-sfc": "^3.0.4"
-
}
-
}
其實主要還是這些模塊的版本兼容問題
vite的版本最開始是1.0.0，后面很多地方搞不下去了才卸載了重裝新的版本
當然還是建議仔細閱讀一下官方文檔，其實很多重要的點都講的很清楚，只不過是遇到問題的時候才會注意到。官方文檔請移步這里
下面簡單的說一下這個文件，
首先是文件的位置，放在其他位置是無效的：
運行vite項目的時候，就會自動解析根目錄下面的這個文件
我這里的主要目的還是解決項目運行時的跨域問題
下面是封裝的一個簡單的請求示例，其中service是一個封裝好的axios實例，可以指定一下baseurl，以及請求和響應攔截。
其他的API都可以像這樣通過給getItem添加方法的方式實現
-
import service from '../utils/requests.js'
-
-
const getItem = {}
-
-
getItem.getppitem = function (params) {
-
return service.get('api/AutoSimple/getdata', params)
-
}
-
-
export default getItem
vite.config.js 具體的配置如下
-
import { defineConfig } from 'vite'
-
import vue from '@vitejs/plugin-vue'
-
// import eslintPlugin from 'vite-plugin-eslint'
-
// https://vitejs.dev/config/
-
-
// 這個配置文件可能出現的問題：
-
// 首先是此文件放置的位置
-
// 1.未安裝 @vitejs/plugin-vue
-
// 處理方法：npm i @vitejs/plugin-vue@1.0.0
-
// 由于本項目vite版本1.0限制，只能用了plugin-vue的1.0.0版本,但在運行的時候又導致了問題2，
-
// 于是直接卸載vite重新安裝最新的3.0.4,這個版本直接install plugin-vue仍然不行，還是要用1.0.0版本
-
// 2.顯示不存在函數 defineConfig
-
// 在此之后npm run dev,又報了一個錯：Cannot find module 'node:path'
-
// 在掘金上看到是和node版本有關，更新后就可以正常運行了
-
-
export default defineConfig({
-
plugins: [
-
vue()
-
// 檢查代碼格式
-
// eslintPlugin({
-
// include: ['src/**/*.js', 'src/**/*.vue', 'src/*.js', 'src/*.vue']
-
// })
-
],
-
server: {
-
// 默認打開的端口和本地
-
// host: '0.0.0.0',
-
port: 3000,
-
https: false, // 不支持https
-
proxy: {
-
'/api': {
-
target: 'http://10.200.20.80/BARCODESERVICE', // 實際請求地址
-
changeOrigin: true, // 是否跨域
-
rewrite: (path) => path.replace(/^\/api/, '') // 對什么類的服務器匹配
-
},
-
}
-
}
-
})
-
在部署生產環境時，又遇到了兩個問題：
客戶環境是IIS服務器，為了節省端口，在部署的時候選擇在同一個網站下添加多個應用程序的方式，這就使得在部署時，需要添加公共的基礎路徑，這一點在官方文檔中有詳細的說明。
解決方案：
在package.json中配置
-
"scripts": {
-
"dev": "vite",
-
"build": "vite build --base=/PsWebDand/ "
-
}
vite.config.js 中的server的proxy無效，此時跨域的問題需要通過在后端服務中配置來解決
IIS服務器
-
<httpProtocol>
-
<customHeaders>
-
<add name="Access-Control-Allow-Headers " value="Content-Type,api_key,Authorization" />
-
<add name="Access-Control-Allow-Methods" value="GET,POST,PUT,DELETE,OPTIONS" />
-
<add name="Access-Control-Allow-Origin" value="*" />
-
</customHeaders>
-
</httpProtocol>
定義 Proxy 代理對象的 set 的時候，
要返回 return true 。
特別是在嚴格模式下，否則，會報錯 'set' on proxy: trap returned falsish for property 'message'
let handler = { get(obj, property) { }, set(obj, property, value) { return true; } } new Proxy({}, handler);
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作，也請與我們聯系01063334945。
分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司。
$emit，父組件傳data給子組件，子組件通過$emit來觸發父組件中綁定在子組件身上的事件，達到改變父組件中的data的方法。下面介紹$emit傳值的幾種方法：
一：$emit傳遞單值
子組件Test.vue：
-
<template>
-
-
<div>
-
-
<div>子組件</div>
-
-
<button @click="changeFather">點擊我向父組件傳遞參數</button>
-
-
</div>
-
-
</template>
-
-
-
-
<script>
-
-
export default {
-
-
methods: {
-
-
changeFather() {
-
-
this.$emit("changeEvent",'1');
-
-
}
-
-
}
-
-
};
-
-
</script>
-
-
-
-
<style>
-
-
</style>
父組件：App.vue
-
<template>
-
-
<div id="app">
-
-
<p>這是父組件</p>
-
-
<div>{{myString}}</div>
-
-
<Test @changeEvent="changeMyString" />
-
-
</div>
-
-
</template>
-
-
-
-
<script>
-
-
import Test from "./components/Test";
-
-
export default {
-
-
name: "App",
-
-
components: { Test },
-
-
data: function() {
-
-
return {
-
-
myString: ''
-
-
};
-
-
},
-
-
methods: {
-
-
changeMyString(val) {
-
-
console.log(val);
-
-
this.myString=val;
-
-
}
-
-
}
-
-
};
-
-
</script>
-
-
-
-
<style>
-
-
#app {
-
-
font-family: Avenir, Helvetica, Arial, sans-serif;
-
-
-webkit-font-smoothing: antialiased;
-
-
-moz-osx-font-smoothing: grayscale;
-
-
text-align: center;
-
-
color: #2c3e50;
-
-
margin-top: 60px;
-
-
}
-
-
</style>
點擊按鈕效果如圖：
二：$emit傳遞多個值
子組件Test.vue:
-
<template>
-
-
<div>
-
-
<div>子組件</div>
-
-
<button @click="changeFather">點擊我向父組件傳遞參數</button>
-
-
</div>
-
-
</template>
-
-
-
-
<script>
-
-
export default {
-
-
methods: {
-
-
changeFather() {
-
-
this.$emit("changeEvent",'1','2');
-
-
}
-
-
}
-
-
};
-
-
</script>
-
-
-
-
<style>
-
-
</style>
父組件App.vue:
-
<template>
-
-
<div id="app">
-
-
<p>這是父組件</p>
-
-
<div>{{myString}}</div>
-
-
<Test @changeEvent="changeMyString" />
-
-
</div>
-
-
</template>
-
-
-
-
<script>
-
-
import Test from "./components/Test";
-
-
export default {
-
-
name: "App",
-
-
components: { Test },
-
-
data: function() {
-
-
return {
-
-
myString: ''
-
-
};
-
-
},
-
-
methods: {
-
-
changeMyString(val0,val1) {
-
-
console.log(val0,val1);
-
-
this.myString=val0+val1;
-
-
}
-
-
}
-
-
};
-
-
</script>
-
-
-
-
<style>
-
-
#app {
-
-
font-family: Avenir, Helvetica, Arial, sans-serif;
-
-
-webkit-font-smoothing: antialiased;
-
-
-moz-osx-font-smoothing: grayscale;
-
-
text-align: center;
-
-
color: #2c3e50;
-
-
margin-top: 60px;
-
-
}
-
-
</style>
點擊按鈕，效果如下：
$emit傳遞多個值時，還可以采用數組的形式：
修改子組件Test.vue:
-
<template>
-
-
<div>
-
-
<div>子組件</div>
-
-
<button @click="changeFather">點擊我向父組件傳遞參數</button>
-
-
</div>
-
-
</template>
-
-
-
-
<script>
-
-
export default {
-
-
methods: {
-
-
changeFather() {
-
-
this.$emit("changeEvent",['1','2']);
-
-
}
-
-
}
-
-
};
-
-
</script>
-
-
-
-
<style>
-
-
</style>
父組件App.vue:
-
<template>
-
-
<div id="app">
-
-
<p>這是父組件</p>
-
-
<div>{{myString}}</div>
-
-
<Test @changeEvent="changeMyString" />
-
-
</div>
-
-
</template>
-
-
-
-
<script>
-
-
import Test from "./components/Test";
-
-
export default {
-
-
name: "App",
-
-
components: { Test },
-
-
data: function() {
-
-
return {
-
-
myString: ''
-
-
};
-
-
},
-
-
methods: {
-
-
changeMyString(val) {
-
-
console.log(val);
-
-
this.myString=val[0]+val[1];
-
-
}
-
-
}
-
-
};
-
-
</script>
-
-
-
-
<style>
-
-
#app {
-
-
font-family: Avenir, Helvetica, Arial, sans-serif;
-
-
-webkit-font-smoothing: antialiased;
-
-
-moz-osx-font-smoothing: grayscale;
-
-
text-align: center;
-
-
color: #2c3e50;
-
-
margin-top: 60px;
-
-
}
-
-
</style>
點擊按鈕，效果如下：
三：子組件通過$emit傳遞給父組件傳遞值，并且父組件有自定義參數時：
子組件Test.vue:
-
<template>
-
-
<div>
-
-
<div>子組件</div>
-
-
<button @click="changeFather">點擊我向父組件傳遞參數</button>
-
-
</div>
-
-
</template>
-
-
-
-
<script>
-
-
export default {
-
-
methods: {
-
-
changeFather() {
-
-
this.$emit("changeEvent",1,2);
-
-
}
-
-
}
-
-
};
-
-
</script>
-
-
-
-
<style>
-
-
</style>
父組件：App.vue
-
<template>
-
-
<div id="app">
-
-
<p>這是父組件</p>
-
-
<div>{{myString}}</div>
-
-
<Test @changeEvent="changeMyString('myParameter',...arguments)" />
-
-
</div>
-
-
</template>
-
-
-
-
<script>
-
-
import Test from "./components/Test";
-
-
export default {
-
-
name: "App",
-
-
components: { Test },
-
-
data: function() {
-
-
return {
-
-
myString: ''
-
-
};
-
-
},
-
-
methods: {
-
-
changeMyString(...args) {
-
-
console.log(args);
-
-
this.myString=args;
-
-
}
-
-
}
-
-
};
-
-
</script>
-
-
-
-
<style>
-
-
#app {
-
-
font-family: Avenir, Helvetica, Arial, sans-serif;
-
-
-webkit-font-smoothing: antialiased;
-
-
-moz-osx-font-smoothing: grayscale;
-
-
text-align: center;
-
-
color: #2c3e50;
-
-
margin-top: 60px;
-
-
}
-
-
</style>
點擊按鈕，效果圖如下：
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作，也請與我們聯系01063334945。
分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司。
演出項目可分為【有座項目】和【無座項目】兩種類型，有座項目又可分為【選座售賣項目】和【非選座售賣項目】。
大部分話劇、音樂劇、舞蹈芭蕾項目都是選座售賣項目?？蛻魜淼截堁劭蛻舳酥羞x擇想看的項目，選定座位并下單，最后檢票入場觀演，完成閉環。其中選座體驗是客戶轉化重要的一環，影響客戶決策。
為了提升用戶體驗，提升數據轉化，我們對貓眼目前選座體驗進行走查，探討問題原因，找到產品痛點和機會點，為產品優化做準備。
貓眼客戶端選座體驗問題：
1.自營項目無法直接選座，無論場館大小必須先選擇區域再選擇座位
如下圖，無法選擇圖中的座位，點擊座位跳轉到對應區域的座位圖，需要再次點擊選擇。
2.無法根據場館座位分布全局選座
如下圖，選擇A區后僅能查看到A區座位，無法看到其他區域座位和舞臺。
3.場館分區圖風格樣式不統一
如下圖，繪制精細程度不一，風格樣式不一。
這些問題產生的原因：
問題1：產品結構規劃上將場館分為區域和座位兩個層級，未根據場館規模分級別展示，例如大型場館先選區域再選擇座位，小型場館直接選擇座位。
問題2：B端后臺性能問題阻礙了客戶端全局查看選座。
問題3：區域圖依靠B端后臺上傳，沒有統一的繪制標準約束，故客戶端的樣式不統一。
通過以上原因可以看出客戶端選座體驗很大程度上取決于B端后臺的配置，所以要從B端配置入手，從根源上解決體驗問題。
本次研究目的
研究對象
我們通過產品研究和用戶訪談形式，結合業務需求，對產品功能進行審視走查，希望能挖掘出產品痛點和機會點。
B端場館圖繪制及座位配置的主要用戶是運維人員，所以我們對運維人員進行了深度訪談，主要目的：
1.了解用戶使用貓眼B端的操作行為和痛點；
2.觀察用戶使用相似產品【城市售票網B端系統】的行為和痛點。
演出項目座位配置業務流程
商務與場館洽談好合作后，會提交添加/修改場館座位模板的郵件給到運維人員，由運維人員在B端后臺中進行創建和修改。商務可在B端后臺創建項目關聯到對應場館配置票價等。
在這條業務流程中，涉及到B端選座配置的部分：
1.創建/維護場館分區模板；
2.創建有座項目、關聯對應場館、配置票價、配置預留。
一、創建/維護場館分區模板
創建場館分區模板主要分為兩個步驟：
創建場館分區：包含兩個主要頁面和一個彈窗，承載創建分區圖和設置分區信息功能。創建分區支持上傳底圖、SVG圖，編輯器繪制。
創建分區座位：包含一個主要彈窗，承載畫座位、座位編號、移動座位、統計座位等功能。
1. 創建分區體驗痛點
1.1 使用SVG編輯器繪制場館分區圖操作不便
嵌入式畫圖工具僅能繪制較為簡單的圖形，門檻高且繪制成果不理想，對于復雜場館無法滿足繪制需求，無法與演出業務很好的結合。
1.2 運維使用第三方工具，繪制風格差異大
由于畫圖工具繪制不理想，運維人員自學AI、Coreldraw等繪制后上傳到后臺系統。人和工具的不同導致座位圖風格差異較大。
1.3 項目變動維護不便
項目調整需通過第三方繪制工具修改或重新繪制導出后上傳到后臺，修改流程長且重復操作過多。
2. 創建座位體驗痛點
2.1 畫座方式不支持繪制傾斜、曲度、錯位的座位
固定的座位方格坐標對坐標，自由度差，無法自定義座位角度和排布形式。無法精準還原場館座位分布。
2.2 不支持自定義舞臺方向和位置
舞臺位置方向固定，無法滿足多個舞臺、座位包圍舞臺配置。
2.3 繪制座位交互操作單一
僅支持鼠標在方格內拖動繪制，效率低，增刪改操作麻煩。
2.4 交互流程不通順
編號、移動等功能先切換功能再選擇座位的順序不符合用戶行為，符合用戶操作的順序是先選擇座位再點擊對應操作配置。
座位編號、移動、統計功能不適合tab形式，交互組件使用不當。
2.5 交互界面表達有誤
座位編號分為排編號和列編號兩種方式，選擇一種并填寫配置參數。系統界面中兩種方式都有*（必填）容易引起誤導。
2.6 刪除編號語義不明確
選擇座位后點擊刪除編號按鈕后座位和編號都被刪除，按鈕語義與實際意思不符。并且誤刪除座位還會增加重新繪制工作量。
3. 產品結構體驗痛點
3.1 分區形狀與座位分布關聯度低
分區的大致形狀應由分區座位的排布所決定，而產品中分區形狀與分區座位形狀并無直接的關聯，導致用戶在選座時產生較大的割裂感。
3.2 不支持直接選座
為了讓客戶更直觀的掌握場館座位分布，運維人員繪制時會盡可能還原，但客戶選擇時還要進入分區后才能選擇座位，且僅能查看到一個分區的座位，不能全局選座。
4. 框架和容器動線體驗痛點
4.1 分區配置位置分散，操作效率低
分區繪制與信息配置分散在兩個頁面和1個彈窗中，頁面布局分散，動線復雜多變。
4.2 座位配置比重弱
座位配置權重高且操作復雜，不適合使用彈窗承載，位置層級太深。
5. 產品與業務關聯體驗痛點
5.1 座位配置功能單一，缺少輔助操作
繪制座位圖是一項龐大的工程，系統內大型場館的座位達到4-9萬個，例如鳥巢、梅賽德斯奔馳文化中心。繪制大型場館需要花費3-4天時間，座位分布復雜的場館需要花費更長時間。目前系統僅有單一拖動方格的繪制方式，缺少提升繪制效率的輔助工具，例如撤回、復制座位、多種對齊/翻轉方式等。
6. 體驗優點
6.1 繪制場館分區圖時支持導入SVG
方便繪制大型復雜的場館。
6.2 系統穩定
復雜的場館繪制時間長且操作復雜，系統未產生過崩潰或其他終止情況。
二、配置票價和預留
配置票價和預留主要分為三個步驟：
選定場館分區：確認場館并選擇場館內分區
配置票價：選擇座位配置票價。
配置預留：選擇座位配置預留。
1. 框架和容器動線體驗痛點
1.1 頁面結構相似，內容重復
票價和預留頁面重復度高，都包含分區預覽、選座情況、分區座位圖模塊。
2. 交互細節體驗痛點
2.1 同樣功能不同頁面交互和視覺不一致
兩個頁面都包含分區預覽模塊，但交互視覺差別較大，交互視覺操作不統一。
2.2 內容表達不清晰
設置預留操作中，“對象”文案語義表述不清晰、“貓眼”和“釋放”不屬于同一層級且語義表達不清楚；新增預留標記按鈕位置有誤，應該放置在自定義預留下方，而不是與“對象“平級。
2.3 設置預留后無法查看座位編號
設置預留后，座位編號被預留標簽替換，從而看不到座位編號，影響識別。
3. 產品功能體驗痛點
3.1 不支持導出票務方案圖
在項目洽談后、正式開票前，報批時需要提供給主辦和公安票務方案圖，供主辦審核，目前需要運維自行制作不支持導出。
一、維護場館分區模板
1. 產品結構
與貓眼B端后臺相同，城市售票網在繪制場館分區圖時也是分為兩個步驟，先配置區域再配置座位。
區域配置：支持上傳底圖并通過繪制工具畫出區域形狀，繪制完成后可直接配置區域信息。
座位配置：通過繪座工具畫出區域座位，選座工具和配置工具進行輔助繪制。
2. 產品布局
2.1 區域與座位配置結構清晰，頁面布局規整；
2.2 區域和座位配置兩步銜接緊密，操作動線流暢。
3. 區域配置功能分析
優點：
1）支持上傳底圖及調整比例；
2）繪制工具易用性較高；
3）繪制風格統一；
4）分區配置動線流暢。
痛點：
1）不支持上傳SVG圖；
2）繪制POH(區域)的工具少，僅鋼筆工具；
根據產品定義，繪制座位分區使用區域工具，繪制舞臺、樓梯、出入口等場館輔助設施使用形狀工具。根據業務實際情況，區域繪制為主，形狀繪制為輔。然而區域繪制工具僅有一個鋼筆工具，Shape(形狀)繪制工具有三個，主次顛倒。
3）區域和形狀繪制工具容易混淆。
左側工具欄中兩類繪制工具未明確分開，非熟練人員操作時會誤用兩種工具。
4. 座位配置功能分析
4.1 創建座位
優點：
1）工具繪制靈活自由；
2）支持旋轉座位。
痛點：
1）需要熟悉繪制工具交互操作，有一定的上手門檻；
2）單個座位工具、路徑繪制工具在繪制結束需要鼠標雙擊，在無指導的情況下用戶很難發現。交互操作缺少說明文字或圖片解釋。
4.2 選擇座位
優點：
1）多種輔助工具提升繪制效率；
2）支持區域內復制黏貼座位。
痛點：
1）僅能在區域內復制黏貼座位，不具備區域之間座位復制或復制區域的能力。
對稱布局是場館中常見的一種布局形式，繪制好一個區域座位后復制并翻轉就可以快速畫完另一個區域。
如下圖所示，當前在G區域編輯座位，雖然可以復制G區的座位黏貼，但僅在G區能看到，無法復制到C區圖層內。
2）不支持設置弧度座位。
如下圖所示場館無法在系統內完全還原。
4.3 座位編號
優點：
1）編號方式支持字母、數字、字母數字結合形式，符合多種場景需求。
痛點：
1）編號受限于繪制時的分組；
繪制座位需要根據座位編號邏輯繪制分組，不可以一次性全部繪制完后分開編號。
若第一次繪制有遺漏座位，第二次補充后，無法整體編號。
2）無法取消編號。
編號僅能修改，不能刪除
5. 產品視圖分析
5.1 編輯座位視角
缺點：
1）僅支持在預覽功能時查看創建的全部座位。繪制某一區域座位時無法看到其他區域座位，缺少全局參考。
二、配置票價和預留
1. 產品布局
優點：
1）票檔和預留配置與場館座位配置結構相似，布局和操作統一，易于理解。
2）票價和防漲配置在一個頁面內完成，簡單清晰。
2. 票價及預留配置功能分析
痛點：
1）設置預留后無法查看到座位編號
如下圖中A標記的座位是預留座位，無法查看座位編號
2）預留模式下，選中已設置票檔、未設置預留的座位時，無法區分票檔
如下圖選中狀態下1-6號座位無法區分票檔A/B
3. 總結
城市售票網B端系統的在繪制場館圖上靈活度自由度高，界面布局規整，動線清晰，產品功能適用于多元復雜場景，不過需要用戶具有一定的繪圖基礎或熟悉成本。
通過以上分析，我們總結出貓眼B端系統后續的優化方向，框架和容器動線上需要提高用戶瀏覽和操作效率，頁面進行歸類整合，布局樣式統一；繪制環境上需要為用戶提供靈活自由的區域座位繪制工具，配備高效的選座和輔助工具。
一、整體布局
1）打破現有的分區與座位不平衡布局模式，梳理動線
二、功能
1. 場館分區設置
1）提供與業務關聯度高的、易用的分區繪制工具；
2）支持多種類型分區，例如舞臺區、座位區、舞池區等；
3）提高分區與座位繪制還原度；
4）確立場館規模分級，客戶端根據級別展示座位層級或直接進入分區層級。
2. 場館座位設置
1）提供易用度高的座位繪制工具或座位添加方式；
2）支持靈活選座，靈活編號；
3）支持調整座位角度、弧度、間距參數；
4）提供提升繪制效率的輔助工具；
5）支持跨區復制座位或復制區域功能；
6）提升座位配置頁面權重，完善座位配置界面。
3. 配置票價和預留
1）整合票價和預留頁面；
2）修正界面交互視覺問題；
3）支持設置預留后查看座位號；
4）增加導出票務方案圖功能。
這次研究我們從業務、產品功能、用戶三方面對選座配座模塊進行走查，抓住產品痛點，為后續改造指明了方向；對同類型產品的選座配座解決方案進行分析，幫助我們獲得新思路。
隨著沉浸式劇場、互動型劇場等新型演出的發展，場館座位布局不再是單一的座位正對舞臺，多個舞臺、座位多角度圍繞舞臺的布局形式不斷出現，今后還會有更多新型座位布局出現。設計適用于多種業務場景、頁面動線清晰、繪制功能好用的后臺工具不僅能提升運維人員的操作效率，也能提升客戶端用戶選座體驗和購票轉化，從而提升產品的市場競爭力。隨著演出行業的逐步復蘇，大量選座項目上線，改造選座模塊是我們工作重中之重。
筆者在車聯網行業任職HMI視覺設計師，由于HMI設計發展的較晚，所以基本上在開始進入到這個領域的人，大多來自于互聯網行業。由于互聯網行業發展的比較早，形成了一套成熟的工作流程，即：分工明確的遞進式協作：交互設計師要等到產品PRD評審結束才開始介入需求，然后交付黑白線框稿等給到視覺設計師繼續跟進。這種工作模式可以讓每個人在自己的崗位上做得更加專業，成為垂直領域的專家。在車聯網行業發展初期的時候，這種工作模式對于傳統行業的來講，比較新穎、高效，所以在一定程度上促進了行業發展，但汽車操作系統的設計還是有很多不同于互聯網設計的地方，所以本文旨在討論HMI工作流程，如何分工，怎樣高效的進行設計協同，以期望探索更適合車聯網行業的設計協同方案，希望對你可以有所助益。
對于HMI設計來講，需要了解很多專業知識，比如：屏幕、硬件、三電、法規……這些東西都會影響到設計的視覺表達，所以設計協同就顯得尤為重要，那么什么是設計協同呢？指設計師在設計之初，即可開啟分享與協作，讓協同者盡可能早的參與到設計中，通過提供一系列工具，讓協同者有更加友好地體驗，保證每個人都可以準確找到相應需求的內容，并且快速提出修改意見與反饋。簡單地講，就是讓每個人都參與到設計過程中，以使最終的結果能夠滿足用戶的需求。
從產品功能邏輯層面來講，HMI設計的“復雜度”是具有有一定的“限制性”的，即保證安全第一，過度復雜的設計必然影響駕駛和乘坐人的安全。所以對于設計，是需要進行全方位評估的，必然會涉及到不同的角色。同時隨著項目的不斷發展，設計團隊也在不斷壯大，設計師之間的協作也越來越多，相應的溝通和協作成本就會不斷增加。如何才能更高效的合作，并把設計質量和一致性做得更好，是我們需要解決的問題。所以設計協同的最終目的是為了解決問題，做正確的事，讓設計師做真正該做的事情。
讓設計師專注于真正重要的事情，而不是把精力放在可以自動化處理的事情上。對所有人員的工作進行集中化管理，所有人員基于統一數據源進行協作。
通過構建團隊資產庫，比如設計規范、控件組件庫等，通過建立健全設計規范，讓數據沉淀，一方面讓設計師的設計有據可依，提升設計的專業性，另一方面，減少因為人員變動造成的數據丟失。
在設計之初，就讓協同者參與到設計之中，保證每個人都可以準確的找到他們的需求內容，并快速提出修改意見與反饋，讓設計師更有針對性的解決問題，讓設計師無需做重復性的工作。
在HMI設計的工作流程中，主要涉及到的角色有產品經理、交互設計師、視覺設計師、研發工程師、測試工程師、項目經理。
不同角色主要工作內容是：
圍繞著HMI設計的整個工作流程是：
產品經理確認需求，輸出PRD文檔；交互設計師收到PRD文檔以后，基于需求，梳理功能，完善業務流程，完成交互文檔的制作，輸出UE文檔；視覺設計師在收到UE文檔以后，針對交互文檔中的流程頁面，進行視覺設計，輸出UI文件給到研發同學；研發同學根據UI文件和交互文檔進行代碼化，完成以后進入測試環節，測試工程師和產品、交互、視覺都需要參與到測試過程中，當完成測試工作以后進行發版。
涉及角色
自己、設計師小團隊。
痛點
工作中很多重復的內容，比如：Button、List等使用的地方很多，如果每個元素都重新繪制，勢必會投入很多時間，同時因為人為因素，難免會出現不統一的地方。那么怎么樣解決這個問題呢？
協同方式
當團隊初期發展的時候，或者整個團隊只有少數幾個設計師的時候，通過匯總通用樣式和組件，形成視覺指導Guide，方便通用樣式的復用，減少重復工作量，達到快速完成視覺設計的目的。
優點
通過樣式庫和控件組件庫的搭建，形成了一定的共有樣式，方便復用，有效的減少了重復工作量。
缺點
由于控件組件庫是在設計進行到一定程度以后提煉的，會存在滯后性，并且隨著設計工作越來越往后，會發現前期的控件組件存在不合適的地方，需要對之前的工作進行修正。
涉及角色
設計團隊內部。
痛點
當公司發展到一定的階段：
當設計團隊越來越大，大家分工越來越細，想法越來越多，就會發現，復制粘貼guide的方式，已經無法滿足團隊的發展了，經常出現組件不能滿足使用的情況，或者是組件相似但不知道怎么選擇等問題。
同時因為沒有統一的流程，會發現不同的業務對于同一功能交互邏輯的不統一現象，比如：搜索是很多業務都會使用的功能，因為沒有統一定義，有的業務會采用即時搜索模式，有的業務必須點擊搜索以后才可以進行搜索，并且這種問題，前期很難發現，只有到了中后期走查的時候才會發現。
所以在后期會針對每一個差異點進行統一，需要全流程重新來一遍，費時費力。那么怎么才可以避免這種情況的發生呢？答案就是構建設計系統。
協同方式
設計系統不同于guide的地方是：樣式，控件組件只是設計系統中的兩個組成部分，除此以外，設計系統還包括了一系列的標準來指導設計。比如：圖標、動效、音效等。這些標準記錄了設計團隊內達成一致的一系列的決定，比如如何選擇控件，如何在不同的控件中選擇。正是這些標準才確保了設計方案不僅僅只解決一個問題，而是可以被復用的。這些標準也是為什么用戶能獲得一致的體驗的原因。
通過設計系統的建立，讓設計規?；?，繼而進一步強化車機系統的統一性，同時為設計師在做設計時提供一個很好的指導方向，讓團隊內不同成員的設計在風格上保持一致，提升設計團隊的專業度。關于設計系統的建立本文就不再過多描述，后續會出專門的文章進行詳述，這里主要是講述設計系統搭建以后的協同方式。
設計系統的搭建需要專門的人或者團隊進行，當搭建完成以后，需要輸出的資源有：UE控件組件庫、顏色/字體樣式庫、UI控件組件庫、UI控件組件說明文檔。這些資源各有什么用呢，接下來進行詳細說明：
UE控件組件庫
提供給交互設計師，基于提供的內容，交互可以快速的構建界面、交互和流程等，就像搭樂高一樣?？梢钥焖俚臉嫿ㄒ恍┊a品原型或者是實驗性的功能，來進行測試以快速驗證想法。
顏色/字體樣式庫、UI控件組件庫
提供給UI設計師，形式可以是Sketch Libraries，一方面方便設計師調用，使不同的設計師的設計變得更加統一，且更加可預測，同時組件也可以讓設計師更多的時間專注于如何構建更好的用戶體驗，而不是去糾結于樣式的調整。
UI控件組件說明文檔
提供給研發，可以是pdf之類的文檔形式，主要是詳細的描述每一個組件的各種屬性，以及里面包含的交互邏輯等，幫助研發搭建起研發自己的底層代碼平臺。
那么這些資源和不同的角色之間是怎么協作呢？UE控件組件庫不需要常常更新，完成后給到交互設計團隊，供交互設計師使用搭建UE文檔。在項目開始之前，負責設計系統的UI團隊進行顏色/字體樣式庫、UI控件組件庫制作，完成以后分享到團隊內，供業務設計師使用進行界面設計，同時進行UI控件組件說明文檔的編撰，完成以后提供給相應的平臺研發，讓平臺研發進行組件代碼化。當代碼實現以后進行走查，檢查是否按照UI準確的實現。當業務設計師完成了業務的界面設計以后，進行評審，輸出給對應的業務研發，研發對于相應的視覺界面進行對應的代碼化，使用組件的地方直接調用平臺代碼，剩下的由業務研發進行代碼化。
優點
組件由專門的UI設計師和研發團隊負責，當出現設計變更以后，業務設計師可以快速通過組件庫更新最新的視覺樣式，同時和平臺研發對接，進行代碼修改，而不需要每個業務研發單獨修改，大大減少了跨部門的協作溝通成本。
缺點
團隊內需要專門的設計師構建設計系統并負責日常維護。
涉及角色
設計、交互團隊。
痛點
由于需求的不確定性，以及車聯網項目周期較長等特點，會出現需求經常變更的情況，那么交互就需要不停的更新交互文檔，UI也需要不停的輸出視覺文檔，往往一個項目結束以后，會有幾十份甚至上百份的設計文檔的情況出現。
協同方式
隨著云端化辦公軟件Figma的興起，為多角色協作提供了可能性，目前主流的工具有：Figma、MasterGo、Pixso、即時設計等在線軟件。
設計文件現在是一個鏈接，這意味著：
UI設計師不必再等到交互完成評審，輸出交互文檔以后進行視覺設計，交互和設計完全可以合二為一，輸出一份高保真交互流程文檔，并且輸出的文檔可以供研發直接瀏覽器查看，而不需要像之前一樣，不停的進行設計資源的輸出。極大的節省了設計師輸出時間。優化了協作工作流。
優點
協作設計，云端辦公，多角色參與。
一鍵獲取文件，不需要通過其他平臺轉化，步驟簡單；自動生成代碼與標注。設計稿修改后自動更新，無需重復下載。
缺點
云端保存，會有數據泄露的風險。
必須在線操作。
涉及角色
UE、UI、研發。
痛點
由于公司發展，業務線增加了很多適配線，這塊的工作基本上屬于：把已有的UI適配到另一個屏幕尺寸下，需要設計的地方不太多，需要花更多的時間去重新按照最新的屏幕尺寸搭建一遍UI界面，屬于用時間換業績，為了達到這個目標，可以采取的方式大致分為兩種：
第一種是增加更多的人力，不管是招更多的人，還是增加更多的供應商人員，都會增加業務支出，并且由于業務無法一直保證飽和，所以會出現一段時間忙的要命，招了很多人員，過了這段時間，業務不太多了，大家都閑了下來，但是開支還是必要的，所以這算是一種沒有辦法的辦法，對于團隊或是公司來講，并不可持續。
另外一種方式就是重新梳理工作流，減少一些重復無意義的工作，比如像是系統設置等瀑布流式的界面，不同車型下的區別只來自于功能的有無，界面上并無太大區別，這里所說的工作，不僅僅指設計師的界面設計工作，同時也包括了研發同學的研發落地工作，同時因為研發同學的適配，也會造成測試走查環節，這些都是一些重復性的工作量，所以是否有一種更好的協作方式可以避免這種情況的發生呢？
答案就是我們接下來要講的一種全新的工作模式：C2D2C模式。
協同方式
由于設計團隊在早期的發展中，積累了大量的設計資產。這些設計資產的沉淀就是設計標準化的基礎，將設計資產轉為封裝好的代碼組件，也就是C2D的過程。然后將封裝好的組件通過低代碼平臺進行屬性配置、搭建頁面、布局調整實現頁面的設計就是 D2C 的過程。通過平臺設定交互行為和綁定后臺數據，完成整個系統，最后再進行站點發布，就實現了 C2D2C 的完整流程。
C2D2C（Code to design to design）的模式，簡單講就是研發同學把設計資產通過設計標準化和研發工業化的方式完成代碼化，然后讓設計師調用已經代碼化的設計資產進行設計工作，這樣子當設計師完成了界面設計的時候，相當于同時完成了前端開發，接下來研發同學只需要根據拿到的界面添加簡單的邏輯就算完成了研發工作，實現中后臺設計研發流程的整體提效。
優點
由于樣式、組件已經完成了代碼化，那么在適配工作中，控件組件化高的界面就可以直接生成代碼，不需要設計師重復設計，同時由于減少了設計師和研發的參與，節省了大量溝通成本，也減少了很多因為人為因素而產生的bug。
由于設計師減少了重復工作量，可以有更多的時間集中在視覺表現上，有效提升了設計輸出的質量，保證了產品的設計感。
對于大量適配項目的團隊，可以由設計師直接配置項目組件，無需經過研發，減少出錯概率，極大提升工作效率。
缺點
前期需要研發同學代碼化基礎控件，所以需要投入人力、精力進行前期的工作。
由于控件提前進行了代碼化，后續可能會出現無法滿足業務需求等情況出現，所以需要有人及時對代碼進行維護更新。
涉及角色
產品、UE、UI、研發、測試。
痛點
基于上面講述的C2D2C模式，已經完成了一個共享平臺的搭建，由于配置需要研發的參與，所以始終需要研發同學作為集成人員，并不利于其他角色的使用，那么怎么樣可以讓產品同學，設計同學，或者說是普通用戶使用呢？
協同方式
一個優秀的共享平臺是需要所有人都可以在其中使用的，所以，當公司或者團隊發展到穩定階段，我們需要重構工作流，以需求為導向，搭建全員工作平臺，基于設計師和研發搭建的平臺基礎上，提煉需求，強化個性化和定制化，滿足品牌產品的個性化需求，具體來講，就是把UI界面中元素提煉出相應的功能，生成功能清單，通過選擇不同的功能，生成相對應的界面。
當完整的共享平臺搭建完成以后，團隊中的每個角色的工作內容都發生了變化，產品的工作是構建更多的需求，交互設計師的工作是構建更多的交互形式，產品架構，UI設計師的工作是設計更多更好的界面布局，視覺表現，然后研發把上述內容通過代碼匯總進我們的需求池中，擴展我們的平臺豐富度。
HMI設計工作，就變成了：客戶在我們的配置面板中選擇需要的需求，喜歡的布局，想要的視覺，點擊完成，就可以即刻看到高度定制化的一套系統。
優點
讓每個人回歸工作的本質，不需要為了一些重復的繁雜的內容而疲于奔命，做更有價值的工作，實現工作的價值
賦能行業，可以滿足車企定制化的需求，提供車企一套完整的車機系統解決方案。
缺點
投入大，對于小體量的業務來講短期無法創造價值。
對于現在的行業環境，增速提效已經達成了基本共識，設計協同就成了一個大課題，但是不同的企業，不同的團隊面對的具體問題不一樣，可使用的資源也不太一樣，那么采用哪種協同方式并無定式，需要根據實際情況，進行具體分析，畢竟效率的提升是為了創造最大的價值。我們所有的努力最終目的是為了解決問題，做正確的事。
作者：菘藍C 來源：站酷網
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作，也請與我們聯系01063334945。
分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司。
最近 AI 繪畫越來越成熟，能做的事情也越來越多，很多同學經常在群里或私信中問我關于對 AI 繪畫的觀點和看法，以及 AI 繪畫對 UI 設計師有什么影響，所以今天獨立寫一篇內容，來具體討論下這個話題。
首先輸出一個太長不看版的結論：
AI 繪圖可以協作 UI 設計師更快地完成一些邊角料工作，但無法取代 UI 設計師的核心價值，不會對 UI 崗位造成大范圍沖擊……
那下面就來具體討論吧！
相信大家都有這種感覺，2022年開始，AI 繪畫突然就毫無征兆地火起來了，用火遍大街小巷來形容一點也不過分，當我走在地鐵和機場等公共場所都能隨處可見 AI 繪畫作品的展示。
其實AI繪畫這個技術一直都有，比如 OpenAi 的 Dall·E，但真正產生質變的時候是從 2022 年2月 Disco Diffusion 發布以后，讓 AI 繪畫的能力得到了質的飛躍。
隨后一些使用它創作的作品開始流通，且在美國的某數碼繪畫比賽中由 AI 作品獲得冠軍，徹底吸引了公眾的視線。隨后，一系列新的 AI 繪畫工具開始開發和上線，包括目前為大家所熟知的 Stable Diffusion 和 Midjourney、NovelAI。
從上線到現在不到1年的時間里，這些軟件都完成了多次的大版本更新和迭代，讓 AI 繪圖的能力越來越強，準確性越來越高，我們甚至很難想象再過五年以后會發展到什么可怕的地步。
除了目前已經正式發布的繪圖工具外，還有很多新的產品正在熱火朝天的開發階段，如巨頭 Adobe 的 Firefly ，Stability 的新產品 REimagine 等。
產品的多樣性，差異化，以及本身的進化，為視覺設計和藝術創作提供了全方位的支持和可能性，也對相關行業產生了巨大的沖擊。
我們不得不面臨一個很現實的問題，AI 是不是會取代大多數插畫、設計師？
這是很有可能的，不管是從網上，還是認識的朋友學員那邊獲得的反饋，高度依賴插畫、場景建模的行業，都在受到 AI 的劇烈沖擊，有的將接入 AI 制定成 KPI 要求全團隊 ALL IN，有的在跑通AI工作流以后直接啟動裁員進程或關閉外包渠道。
AI 的出現對于美術行業，就像燃油車出現對馬車的革命，照相機的出現對手繪的沖擊，是非常值得思考的，因為我們或多或少也身在其中。
因為在產品方向，Midjourney 已經可以通過指令生成用戶界面了，試用 ChatGPT-4 已經可以用指令10秒創建一個可以操作和訪問的網頁，看起來未來已經提前朝我們走來。
所以 UI 設計師是不是很快也要被取代直至消亡？
相信有長期看我們公眾號分享和公開課的同學，應該知道我一直在強調，界面對于 UI 設計師的工作只是必要但占比并不高的部分，如果認為我們的工作價值僅僅是最后產出的視覺界面，那淘汰多數 UI 設計師的方式根本輪不到 AI 來動手，按目前市面流通的前端框架和組件庫就夠了。
之所以有大量的現成素材、模版、組件庫，還不能淘汰 UI 設計師，原因就是整個項目設計過程中所需的變通、靈活性、抽象思維要求，是它們完全無法覆蓋的。
一個稍微成熟點的項目設計圖產出和交付，是需要經過下面這個流程的：
從這個簡化的流程模型里，大家要明白專業的設計稿輸出是有 “黑箱” 加工步驟的，要在這階段，對工作的需求進行大量的研究、分析，并做出決策確定出設計目標或者方案。
在現代設計團隊中，直接拿到需求就做設計稿的模式是很難產出高質量設計的，或者應對更專業嚴格的要求。設計師需要在這個階段投入大量精力，盡可能提升設計產生的價值，減少出現不良影響的風險，以及 —— 說服團隊接受當前的設計思路。
而這是 AI 繪圖完全無法實現的東西，我們使用 AI 繪畫僅僅是輸入做好的決策，讓它生成結果，但沒辦法通過輸入業務、需求的疑問，讓它給出一個有詳盡理由和邏輯的設計成果。
可能有同學會下意識的想到，那我們用 ChatGPT 這樣的工具，提出問題，讓它自己給出解答并直接給出繪圖指令操作繪圖工具生成界面，順帶再自己開發號產品，不就行了，一個人就是一個團隊，人人都是產品經理終于實現……
這個業務模型非常合理，看起來似乎完全可以實現。但真的有項目經驗的自己去思考一下，就會發現中間存在的問題無窮無盡。
第一點，“黑箱” 是給出問題答案的分析處理過程，ChatGPT 再怎么神通廣大，也需要我們去給到有效的問題和需求，它才能給你有用的答案。那么問題來了，你怎么和它描述具體的業務需求、產品需求、體驗問題和各類用戶痛點？
以上一篇分享為例，我們優化 Stable Diffusion 的輸入框，光和 AI 說優化輸入框約等于廢話，你得告訴它怎么優化，那怎么優化這件事不就是得去找出原產品問題的缺陷嘛？如果我自己去找完缺陷了，那最后畫那點圖例的工作量有什么了不起的呢？
更何況一些復雜的業務，尤其是B端行業，完全無法用簡單的幾句話描述清楚，要搭配各種框架圖和流程圖，光開一個業務評審和培訓的會議，可能就要花非常長的時間。
所以該用什么形式去和 AI 描述這些抽象的信息內容？
第二點，還是以上面案例為例，在這個輸入框中，包含很多交互的小細節，輸入框內光標的操作，鍵盤的操作邊界在哪里，輸入文字后提示關聯的邏輯，不同輸入指令類型要區分怎么和 AI 描述，全都成為問題。
所以光生成一個界面是沒有意義的，這個界面做的再好看再美觀，也不代表它有真實落地的可能，只是完成了設計工作的一小部分而已。所以看到這里是不是感覺很熟悉？和我們在追波上看到的各類飛機稿案例沒有太大的區別。
第三點，上面的模型只是一個非常簡化的流程，有過真實的項目經驗就應該知道流程中會有反復拉鋸的事件，需求的變動，設計稿的修改，方案的調整，這些零碎的工作去和 AI 提，你會發現有輸入問題的時間，可能設計早就修改完了。
尤其在最終的標注和切圖環節，涉及到設計時對設計稿的制定，標注和切圖實際上有很多主觀性和經驗化、場景化的輸出要求，它需要設計師在經歷整個項目流程后自行判斷。
除了以上三點，還有很多其它的問題難以解決，而這些問題的總和，決定了沒有出現真正的人工智能之前，使用 AI 來輸出 UI 界面是一件不靠譜的事情。
只有視覺領域沒有前期那么多條條框框，也沒有后續一系列交付和維護需求的場景，才是 AI 真正產生價值和影響的方向。
用 AI 做 UI 設計不靠譜，但是不代表對UI設計師沒價值。這話聽著可能挺拗口的，但事實如此，因為在國內的UI設計環境中，UI 設計師的工作內容往往不局限于產品設計一個領域內。
還包含下面這些操作：
我相信大多數 UI 設計師做平面和運營設計的感受就和上墳的狀態是一樣的，上墳起碼是懷有對先人獻花，做平面和運營設計只會產生對自己深深的唾棄……
所以 AI 的出現可以很好的處理這部分的需求，比如一些雖然用處不大，但就是甲方還是老板就是想用的 3D 風格圖標。
或者，在登陸頁用的比較濫俗的 3D 場景背景，為了這樣的東西花很長的時間去建模和渲染，投入和收益是完全不成正比的。所幸使用 AI 也可以幫助我們非常短的時間內獲取想要的效果。
還有就是各類運營設計圖，互聯網運營設計和一般的品牌廣告視覺比較起來，就是對創意性的忽視，畫面并不需要埋伏大量的隱喻、內涵或故事，就是單純的應景和吸引用戶注意力，這恰恰也是 AI 最適合輸出的東西。
包括廣告 Banner、H5、啟動頁等，都可以通過 AI 快速生成一些高質量的插畫，來替代我們自己從頭開始繪制的苦惱。
所以你看，對于我們職業價值不高的這些雜活，AI 都可以很好的去完成，而且可以肯定未來可以完成得越來越好，我們就可以節省更多的時間，不管是投入精力給體驗和交互，還是準點下班，都符合我們自身的利益。
所以，UI 設計師對 AI 的態度并不是敵視和悲觀，而是要把它當作救星和幫手，把我們從運營設計的水火中拯救出來……
不僅是觀念上的調整，掌握一定的 AI 繪制技巧也是必要的，將他們融入到你正式的工作流程中，所需投入的精力也遠遠小于你從頭開始學插畫和 3D 渲染。
相信不久的將來，UI 設計師的招聘中部分要求手繪和建模的 JD，會替換成熟練使用 AI 繪圖。
作者：酸梅干超人 來源：站酷網
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作，也請與我們聯系01063334945。
分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司。
看完本篇文章，你會學到以下內容：
1，什么是彈窗？
2，彈窗的規范如何定義？
3，彈窗使用規則是什么？
4，什么是抽屜？和彈窗對比優缺點是什么？
一、什么是彈窗？
彈窗是在保留當前頁面狀態的情況下，告知用戶并承載相關操作。
思考：彈窗里面哪些構成原件可以根據業務屬性可以有可以沒有呢？
答案：標題區和操作區。
二、彈窗的規范如何定義？
1、定義彈窗的大小規范
彈窗的的大小有兩種定義方式。一種是固定大小，一種是自定義大小。需要根據自己的業務場景二選一。
彈窗寬度一般定義為三種。分別為560px，720px，960px，都是8的倍數方便記憶。尺寸并不是定死的，可以根據自身業務場景調節。
彈框固定高度會有一個最小高度200px，一個最大高度560px。在其之間的高度是由內容區的內容決定，超過最大高度560px時出滾動條。
彈窗自定義高度，只定義最大高度，隨著頁面拉升縮小，彈窗邊距不變。
2、定義彈窗內容規范
定義：標題欄操作欄高度，內容區邊距。
3、彈窗類型
彈框類型是根據使用場景區分提示彈窗，自定義彈窗兩種
彈窗優點：沒有跳出父級頁面，彈窗任務完成后仍然會留在父頁面進行操作，減少用戶操作中步驟體感
彈窗缺點：信息承載量少，信息內容過多的時候會出現上下左右滾動條，彈窗會降低用戶操作效率
三、彈窗使用規則是什么？
1、不超過兩種操作選項
假如承載的操作項比較多，建議新跳轉一個落地頁。
2、多步驟操作，選擇用頁面承載
3、盡量避免彈窗疊彈窗
第一個彈窗的內容考慮用頁面承載或者第二個彈窗是否可以用氣泡或者下拉來承載。
假設一定要疊，二級彈窗的復雜度要低于一級彈窗，滿足形式上的平衡，遵循從大到小的邏輯或者是覆蓋上級，完成任務后點“返回”返回。
四、什么是抽屜？和彈窗相比優缺點是什么？
抽屜是信息承載量和頁面比肩，又兼具彈窗的優點。
作者：鯤sky 來源：站酷網
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作，也請與我們聯系01063334945。
分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司。
看完本篇文章，你會學到以下內容：
1， 什么是表單頁？
2，表單頁設計原則
3，表單的構成
4，表單的交互
5，頁面布局
6，提升表單易用性
7，體驗衡量指標
1、采集/錄入數據信息。2、編輯數據信息。3、特殊的條件設置。后臺產品的本質是針對數據的增、刪、改、查。而增、改、查都可以用表單完成。
OA系統里面的請假申請，報銷申請，錄入員工，新建會議。教育類的創建課程。HRM系統里面發布職位以及物聯網管理系統新建設備等等。
用戶快速定位重要信息和目標選項同時文案和組件能夠準確傳達相應含義
整體表單排布有合理的交互形式；科學的信息布局和組織形式；盡可能“少操作一步”用戶在面對50和表單和500個表單的心理壓力是不一樣的。
操作前：提示和防錯。
操作中：實時反饋與糾錯
操作后：合理的保存、清空、取消、撤銷機制。
表單通常由表單標簽、表單域、提示提示、操作按鈕四部分構成。
左標簽
優點：表意明確，節約縱向空間，多用于web端
缺點：不太適用于移動端等狹長空間
頂標簽
優點：對齊舒適，節約橫向空間，多用于移動端及英文場景下。
缺點：縱向空間利用率不高
行內標簽
優點：最節省空間，多用于注冊登錄
缺點：輸入狀態標簽消失，用戶陷入迷茫
左對齊標簽
視線從標簽移動到表單域時間為500ms，這比右對齊標簽所用的時間長的多，所以更適合閱讀，用于詳情的陳列。
特點：閱讀效率高，操作效率較低；
右對齊標簽
視覺動線參差不齊，不適合高效閱讀，但適合高效操作，更適合表單填寫。
特點：閱讀效率不高，標簽指向明確，操作效率高
步驟一：根據業務已經有的字段長度定義4-5種寬度規范，建議寬度可以是8或者是40的倍數。
步驟二：根據你要搭建的表單，選用合適的規范，長度與輸入預期成正比。有人會說排出來的表單左邊沒對齊，右邊也沒對齊，其實這就是B端產品特征那就是是好用大于好看，就要給用戶一種心智那就是給你的這個長度那就是要輸入一個這么長的內容。
避免“正確的廢話”：給不到用戶任何的幫助還增加了用戶的閱讀成本。
按鈕常見位置：一般出現在頁面頂部、跟隨表單里的內容、表單內容底部、頁面底部。
按鈕閱讀順序：按鈕出現頁面右上角或右下角時，閱讀順序是從右往左，這符合pc端操作習慣以及人閱讀習慣。按鈕跟隨表單內容或在表單內容底部時，閱讀順序為從左往右，這符合人的填寫順序從上往下，從左往右。
底部按鈕右對齊：一般用在彈框，因為彈框頁面比較小，右對齊比較符合操作習慣。
底部按鈕居中：一般用在頁面中，因為右下角操作距離會有點遠，所以表單用頁面承載的話按鈕建議居中。
表單中字體全部統一采用14px。表單上下間距一般有三種，1.內容與內容間距為24px。2.內容與說明文案間距為4px。3.內容與子內容間距以及及子內容之間的間距為8px。
表單交互方式有四種。1.原位編輯；2.氣泡卡片；3.彈窗/抽屜；4.頁面跳轉。
原位編輯
編輯內容即為展示內容，容量低于5個時使用。
氣泡卡片
設置項與看板內容緊密相關時使用氣泡卡片，建議設置項低于5個。
彈窗/抽屜
設置項與看板內容可以有關聯也不可以沒有，大于三個以上的錄入項使用。
如果錄入項較多，用彈框承載出現翻頁的情況下可考慮使用抽屜。
頁面跳轉
如果容量超出了彈框/抽屜的承載量并且錄入項與看板沒有那么強的關聯性可采用頁面跳轉的方式。
頁面布局方式有四種。1.分組；2.錨點定位；3.標簽頁；4.分步驟
5.1.1標題分組
設置項超過7個；彼此間的關聯性較弱且可以分類去歸納
5.1.2卡片分組
有多個設置項，多個分類；彼此之間的關聯性更弱，分類明確
有多個分類的情況可通過錨點定位迅速找到相關信息
彼此之間沒有特定的相關性，可以獨立設置。每個設置包含了多個錄入項且使用了標題分組。
小結
當錄入項少于7個時使用基礎布局；當錄入項在7-15個時可采用標題分組，卡片分組、錨點定位布局；當錄入項大于15個時需采用標簽頁布局。
利用步驟條將大型，復雜任務拆解為多個部分，并按照相關性分組。
建議3種分組依據
1.采用必填項劃分，把必填的選項分在一起；2.采用相關性劃分；3.以操作成本劃分。把好填的簡單的表單放在前面，復雜的放在后面。
提升表單易用性方式有5種。1.信息降噪；2.清晰易讀；3.高效智能；4.防錯糾錯；5.所見即所得
場景一：當表單中大多數都是必填只有極少數非必填時
場景二：表單項非必填項比較多，可將低頻的非必填項收起
場景一：盡量采用單列布局，視覺動線流暢，不容易遺漏信息；按enter鍵換行。
場景二：如果出于業務方需要，必須在橫向添加內容，那最好有一定的分組依據。但這樣就不應該出現豎向分組，以免遺漏信息。
6.3.1根據上下文信息可以自動獲取的，無需用戶再次填寫。
例如根據手機號帶出用戶姓名；根據地址帶出郵政編碼；根據身份信息帶出生日。
6.3.2提供合適的“默認項”。
例如根據行業現狀提供常規的比例分配；根據定位把地區做默認的填充。
6.3.3提供搜索、聯想，自動顯示匹配的信息
用戶在進行輸入等操作時可以提供智能輔助，例如表單填寫時對需要錄入信息的區域提供輔助提示，通過自動補全或聯想詞來幫助用戶快速錄入信息，在保持用戶的操作自由度的情況下提效。
6.3.4 OCR識別文件內容
對于一些標準證件信息的錄入，可以通過OCR識別文件內容。當用戶上傳圖片后，運用圖像識別技術提取關鍵信息并自動填入結果。
6.4.1對于長數字，四位一空格，用來分段
例如輸入銀行卡號；充值場景下輸入手機號等
6.4.2為用戶封閉不正確道路
將超出時間選擇范圍的日期置灰。電話號、身份證錄入時只允許輸入數字同時設置字數上限。
6.4.3告訴用戶哪里錯了，而非簡單粗暴的錯誤提示
表單頁對填寫的物料內容進行映射，展示真實效果預覽，降低用戶心理的不確定性。適合對移動端、小程序、H5頁面的設置。
體驗衡量指標有4種。1.任務完成率；2.任務完成時長；3.必填項目數；4.易用度評分
7.1任務完成率
7.2任務完成時長
7.3必填項目數
結合業務場景給出最適合的必填項設定，提高用戶填寫效率。
7.4易用度評分（用戶完成某項任務的難易程度）
易用度可通過調研問卷和評分量表獲取。
作者：鯤sky 來源：站酷網
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作，也請與我們聯系01063334945。
分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司。
設計做到極致注重的就是對于細節的把控力，大廠的設計師之所以比較優秀，就是他們具備很好的細節把控力。想要提高產品設計的能力，發現設計細節和思考設計深入的能力至關重要。
最近在體驗產品的時候，發現了一些設計細節做得比較好的優秀案例，分享給大家學習一下。
分享目錄
一、Banner 輪播轉場的品牌化
二、情感化的彈窗設計
三、最小化顯示提高空間利用率
四、動態化的設置引導
五、沉浸式的活動氛圍設計
六、人性化的提示設置
七、動態感知的溫度設計
八、無處不在的廣告位開發
九、主題化的圖標設計
十、新穎的卡片式設計
一、Banner 輪播轉場的品牌化
立足于品牌做設計，才能強化自身產品的差異化。如何在更多設計場景中融入品牌基因，是設計師需要深入思考的關鍵。
最近在使用騰訊視頻 APP 時，發現首頁 Banner 圖在輪播的轉場過程中，以品牌 LOGO 造型作為轉場過度。一個小小的細節強化了用戶對于品牌的記憶度，也體現出專屬的設計差異。
二、情感化的彈窗設計
通過彈窗設計可以提高用戶操作效率，也是傳播信息（活動/廣告）最直觀的形式。但是體驗多了用戶便會開始排斥，提高彈窗的情感化設計變得尤為重要，降低用戶的排斥感才能提高彈窗的作用。
很多娛樂影視等 APP 都會有“青少年模式”彈窗提示，抖音將彈窗視覺表達融入了精美的國風插畫。也通過針對性的內容作為設置的引導，提高了用戶對“青少年模式”的深入理解，增強了體驗的積極性。
插畫的形式在彈窗設計中表現比較突出，比如嘀嗒出行 APP 將“推送通知”的彈窗設計運用插畫增強情感化表達。相較于生硬的表達方式用戶更能接受，通過營銷的文案引導用戶授權，提高了產品的感官體驗。
三、最小化顯示提高空間利用率
對于工具型產品不同用戶的操作焦點不同，更多定制化的體驗才能提高用戶的操作效率。
釘釘 APP 在協作欄目中，默認展示的各類工具可以進行收起，實現最小化顯示。用戶可以根據使用習慣和操作方式選擇收起/展開，提高了當前空間的利用率，自定義的功能設計可以提高用戶的操作體驗。
四、動態化的設置引導
為了提高用戶隱私權益，手機系統針對產品調用權限進行了阻力設計，需要用戶的授權操作。提高用戶的各類功能授權就需要設計師探索，降低用戶的排斥感和提高授權的利好政策才能獲得授權。
抖音在引導用戶開啟通知權限的設計中，采用了動態畫面的表達來強調開啟通知的利好政策，以此來攻破用戶的心理防備。相較于生硬的彈窗提示，動態的表達和引導性的文案更能拉近與用戶的距離感。
五、沉浸式的活動氛圍設計
沉浸式的體驗可以帶給用戶更好的場景感，提高用戶的參與度。在活動的設計中，不斷向游戲化和沉浸式方向加強體驗，提高活動的趣味性和強化用戶參與的積極性。
騰訊視頻在情人節的互動活動設計中，就將搶紅包的活動融入到當前的界面中，紅包雨鋪滿整個屏幕，以趣味性的形式滿足用戶心理。不隔斷與界面之間的聯系，降低活動對用戶的干擾，進而提高活動氛圍感和參與度。
六、人性化的提示設置
短視頻近些年改變了大家的生活方式和娛樂形式，也有用戶容易過度依賴進而影響休息質量。
抖音作為短視頻領域的頭部產品之一，在增強用戶體驗的同時也要起到良性的引導作用。當用戶刷短視頻一定時間后會彈窗提示休息，而提示時間用戶可以根據自己的實際情況進行設置，靈活的設置可以讓用戶合理分配時間。健康使用的引導可以讓用戶感受到產品的溫度，提高用戶體驗的認可度。
七、動態感知的溫度設計
天氣預報是用戶關注度較高的信息，對于溫度的感知可以讓我們出行更容易把控。在產品中顯示天氣情況也是一種情感化的升級，可以帶給用戶更有溫度的體驗。
利用餓了么 APP 點餐之后，首頁會顯示配送情況和當前的天氣溫度，背景以動態的天氣畫面增強視覺感知。也希望用戶可以根據天氣情況對外賣員多一份理解，加強人與人之間的寬容心，帶給用戶更強的情感化體驗。
最近在使用愛奇藝 APP 時，發現左上角的品牌位置也結合了天氣情況，結合頂部視覺區域的流體漸變，新增的天氣預報和品牌 LOGO 完美的通過動效過度。整個設計表達流暢自然，感官體驗也是非常值得學習的。
八、無處不在的廣告位開發
廣告是眾多產品實現流量變現的方式之一，廣告位的開發也是見縫插針，如何在僅有的空間增加更多廣告位，產品設計師也在不斷探索。
最近在使用騰訊視頻 APP 時，進入到個人中心時會默認有個下拉廣告。這個見縫插針的廣告位新增，對于設計師來說讓我感受到了廣告的無處不在，不過對于用戶來說是否會心生排斥感得通過數據去驗證。但是作為產品設計師這也是一個啟發，將有限的空間進行深度開發，還不會影響已有的結構布局，這也是一個啟發性的案例。
九、主題化的圖標設計
圖標是產品中不可或缺的存在，圖標設計的研究也是設計師需要重點對待的技能范圍。精美的圖標不僅可以提高產品的感官體驗，也能吸引用戶的關注度，進而提高業務模塊的點擊欲。
最近在使用順豐速運小程序時，寄快遞欄目的各業務入口圖標設計非常引人注目，結合主題化的圖標設計突出了活動傳播力度。對于工具型產品而言，強化氛圍感可以打破用戶原有的認知，不僅可以突出活動主題，也能強化用戶對產品的視覺感知。
十、新穎的卡片式設計
卡片式設計已經流行好幾年了，目前依然是非常普及的 UI 設計趨勢之一。如何進一步強化卡片式設計的創新度，我們需要不斷的嘗試和總結。
嘩哩嘩哩 APP 的創作中心設計也許是一個不錯的啟發，卡片內部右上角的視覺強化使得原本普通的表達變得更有視覺感。突出的設計也成功的吸引了 UP 主的注意力，強化了該入口的點擊欲。這樣的設計表達在保留卡片式設計的基礎上，也是一種新穎的視覺表現，可以作為突出業務入口的表現方式進行探索。
作者：黑馬青年 來源：站酷網
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作，也請與我們聯系01063334945。
分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司。
背景：項目中通過攝像機提供的rtsp流來顯示畫面，但是在編寫項目中，需要將rtsp實時流畫面傳輸到web前端頁面中。于是找了很多方法，都是后臺轉碼轉成rtmp來播放，現在大部分插件和瀏覽器都是支持使用rtmp播放視頻流。而rtsp隨著flash的退出而被復雜化了。網上都是1、通過ffmpeg轉碼后輸出，2、通過攝像機指定的web插件轉碼輔助播放，如?？?，大華攝像機；3、還有個猿大師播放器基于猿大師中間件提供的內嵌網頁播放（沒用過，不知道行不行，原本想用現在這個方法行不行的，若不行就用這個猿大師了的）
安裝成功以后，你重新打開一個命令行終端，輸入：ffmpeg -h，如果能輸出 ffmpeg 的相關信息出來，則證明你的電腦安裝 ffmpeg 成功。
創建了一個vuecli（vue2）項目，名稱不要起rtsp2web，與src文件夾同級
下創建一個serve文件夾
-|public
|-favicon.ico
|-index.html
-|src
-|serve
-|.gittignore
-.....
npm init --yes
npm install rtsp2web
//index.js
const RTSP2web = require('rtsp2web')
//服務端的端口號，端口號可以自定義
const port = 8033
new RTSP2web({
port
)}
運行命令：node index.js
在public的index.html中
其中jsmpeg.min.js通過src引入，可以用jsmpeg.js或者jsmpeg.min.js都行
<!DOCTYPE html>
<html lang="">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width,initial-scale=1.0">
<link rel="icon" href="<%= BASE_URL %>favicon.ico">
<!--v jsmpeg.min.js文件用在這 v-->
<script src="https://jsmpeg.com/jsmpeg.min.js" charset="utf-8"></script>
<title><%= htmlWebpackPlugin.options.title %></title>
</head>
<body>
<noscript>
<strong>We're sorry but <%= htmlWebpackPlugin.options.title %> doesn't work properly without JavaScript enabled. Please enable it to continue.</strong>
</noscript>
<div id="app"></div>
<!-- built files will be auto injected -->
</body>
<script>
var rtsp = 'rtsp://username:password@ip:port/live'
window.onload = () => {
//這里的port要與index.js的port保持一致
new JSMpeg.Player("ws://localhost:8033/rtsp?url="+btoa(rtsp), {
canvas: document.getElementById("canvas")
})
}
</script>
</html>
#####在vue頁面中用canvas中播放視頻
如 在App.vue中這樣用：
<template>
<div id="app">
<!-- <img alt="Vue logo" src="./assets/logo.png">
<HelloWorld msg="Welcome to Your Vue.js App"/> -->
<canvas id="canvas" style="width: 600px; height: 600px;"></canvas>
</div>
</template>
為什么node index.js之后沒反應？
—檢查端口號是否填寫對應，index.js中的端口要與script里的端口保持一致
|
為什么長時間未顯示圖像？
—需要等待大概1-2分鐘，就會顯示畫面。至于這么長時間未顯示，小弟也不知道啊。。希望大佬指點。。
完事了就，這是我歷經千辛萬苦找到的方法，弄這個vue中播放rtsp搞了好久，技術太拉了我，只能用這些小玩意來搞。原本打算用java或者python通過拉rtsp流解析成rtmp的，奈何能力不足，也懶得思考懶得搞懶得弄，所以擺爛了QAQ
若哪里有講的不妥和使用不當的地方還請您告知一下，萬分感謝大佬指點，小弟深表感謝<抱拳>
-----------------------------------------------------------------------------------------------------------
https://zhuanlan.zhihu.com/p/531899593 ??
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作，也請與我們聯系01063334945。
分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司。
藍藍設計的小編 http://www.syprn.cn