去年在博客中发了两篇关于GIF动态生成的博客，GIF图像动态生成-JAVA后台生成和基于FFmpeg的Java视频Mp4转GIF初探，在这两篇博客中都是采用JAVA语言在后台进行转换。使用JAVA的同学经过自己的改造和开发也可以应用在项目上。前段时间有朋友私下问，有没有不使用Java，甚至不依赖于后台的，直接基于前端的GIF动图生成，有没有这种技术方案。博主个人对前端不是很擅长，后来也是在github上自习搜索了一番，发现了一个比较有意思的，可以直接在前端使用的gif动态图生成组件。本文重点聊聊gif.js组件，介绍一下gif这个组件的基本原理，在生产中如何进行使用。
gif.js在github的地址是：gif.js,打开它的官方网站，可以看到如下的介绍：
作为一款成熟的插件，在github上有4.5k的star，足以说明它的受欢迎程度。而且gif.js采用的是宽松的MIT协议，您可以随意下载这个插件，再此基础之上改造成自己的工具供别人使用。使用git clone将工程下载到本地后，可以看到gif.js的初始目录。
打开工程目录的package.json文件，这里定义了文件基础依赖。打开后可以看到如下的定义信息：
在GIFEncoder.js文件中定义了gif.js对象了基本一些属性，在上面的目录中打开目标文件后，可以看到属性定义方法：
核心方法API说明：您可以使用构造方法或者使用setOptions（）方法类设置相关的属性。详情可以看下面的说明：
|
Name |
Default |
Description |
|
repeat |
0 |
repeat count, -1 = no repeat, 0 = forever |
|
quality |
10 |
pixel sample interval, lower is better |
|
workers |
2 |
number of web workers to spawn |
|
workerScript |
gif.worker.js |
url to load worker script from |
|
background |
#fff |
background color where source image is transparent |
|
width |
null |
output image width |
|
height |
null |
output image height |
|
transparent |
null |
transparent hex color, 0x00FF00 = green |
|
dither |
false |
dithering method, e.g. FloydSteinberg-serpentine |
|
debug |
false |
whether to print debug information to console |
下面采用具体的代码进行一个实际例子的实践。
这里以video2.html为例，在这个工程中引入了gif.js和gif.worker.js。工程目录如下，Jquery.js作为非必须依赖。
-
<head>
-
<meta charset="utf-8">
-
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
-
<title>视频转GIF</title>
-
<meta name="description" content="Full-featured JavaScript GIF encoder that runs in your browser.">
-
<meta name="keywords" content="gif, encoder, animation, browser, unicorn">
-
<meta name="viewport" content="width=device-width">
-
<meta property="og:title" content="gif.js">
-
<meta property="og:url" content="http://jnordberg.github.io/gif.js">
-
<meta property="og:description" content="Full-featured JavaScript GIF encoder that runs in your browser.">
-
<meta property="og:type" content="website">
-
<link rel="stylesheet" href="main.css">
-
<script src="gif.js?v=3"></script>
-
<script src="video.js?v=3"></script>
-
</head>
-
gif = new GIF({
-
workers: 4,
-
workerScript: 'gif.worker.js',
-
width: 600,
-
height: 337
-
});
定义好了gif对象之后，还需要定义相应的响应事件，如下代码所示：
-
sample.addEvent('change', sampleUpdate);
-
-
button.addEvent('click', function() {
-
video.pause();
-
video.currentTime = 0;
-
gif.abort();
-
gif.frames = [];
-
return video.play();
-
});
-
-
gif.on('start', function() {
-
return startTime = now();
-
});
-
-
gif.on('progress', function(p) {
-
return info.set('text', "rendering: " + (Math.round(p * 100)) + "%");
-
});
-
-
gif.on('finished', function(blob) {
-
var delta, img;
-
img = document.id('result');
-
img.src = URL.createObjectURL(blob);
-
delta = now() - startTime;
-
console.log("done in\n" + ((delta / 1000).toFixed(2)) + "sec,\nsize " + ((blob.size / 1000).toFixed(2)) + "kb");
-
return info.set('text', "done in\n" + ((delta / 1000).toFixed(2)) + "sec,\nsize " + ((blob.size / 1000).toFixed(2)) + "kb");
-
});
代码有点长，这里不一一列出，需要源代码的可以私信。
使用nginx进行静态发布后，可以看到如下的效果：
点击执行按钮后，在网页下面生成gif动态图，如下所示：
实际生成的动态图会根据原始视频的大小，画质质量，清晰度等因素影响，执行时间也会有影响。在实际项目中需要根据需要调整相应的参数才可以。
以完成后渲染动图为例讲解合成过程，
可以在变量区看到客户端开启了多个Worker进行并行处理。
在这里进行数据合并处理，如下：
最终合成gif图片，在html中进行dom渲染。
以上就是本文的主要内容，本文重点介绍了一款前端基于Javascript的gif.js生成插件，分析了它的源码结构，最后通过一个实例进行了案例讲解，帮您快速的了解和掌握这个组件，文章行文仓促，如有错误，请留言交流。
蓝蓝设计建立了UI设计分享群，每天会分享国内外的一些优秀设计，如果有兴趣的话，可以进入一起成长学习，请加微信ban_lanlan，报下信息，蓝小助会请您入群。欢迎您加入噢~~
希望得到建议咨询、商务合作，也请与我们联系01063334945。
分享此文一切功德，皆悉回向给文章原作者及众读者. 免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务、UI设计公司、界面设计公司、UI设计服务公司、数据可视化设计公司、UI交互设计公司、高端网站设计公司、UI咨询、用户体验公司、软件界面设计公司。
卡片是一个UI组件，包含了某一个内容的信息和操作。卡片可以包含各种元素，但它们都应该属于同一个主题。
这样做的目的是为了避免冗长的文字，并呈现更多的内容。即使从设计的角度来看，用户可能不熟悉卡片的概念，但他们马上就知道如何使用它们，因为它们与实体卡片是一样的。（彩云注：这个就是用户心理学中隐喻的运用）
卡片之所以流行，是因为它们能更好的把控内容。卡片是模块化的，所以不同的内容可以堆叠在一起，而不需要注意它们的差异。
卡片通过强制内容适应卡片边界和卡片布局上的限制来聚焦内容。设计师喜欢通过卡片混排大量内容，而无需担心设计会变得杂乱无章。
卡片可以将内容分解成易于理解的小块，以便用户与之互动。通过给内容一个容器，卡片向用户表明内容是真实和感性的。
卡片 UI 设计流行的原因还有很多：
直观：卡片在界面中看起来与现实世界中的卡片相同，它们对用户来说似乎很常见。在卡片成为移动和网络应用中的流行元素之前，它们在现实生活中无处不在：名片、棒球卡、便签。卡片代表了一种有益的视觉类比，它允许我们的大脑直观地将卡片与其所代表的内容联系起来，就像在现实生活中一样。
易于阅读：卡片不占用太多空间，并敦促设计师优先考虑其内容。不同的是，每张卡片都变成了易于阅读的内容。卡片让用户更容易找到他们感兴趣的内容。
有吸引力且对用户更友好：基于卡片的设计通常非常依赖视觉效果（尤其是图片）；就信息架构而言，视觉层次会更加清晰。使用图片有助于使基于卡片的设计比不在卡片中排列的相同内容对用户更具吸引力。
有利于响应式设计：卡片是矩形的，可以平滑地调整大小，以适应不同屏幕的水平和垂直正面，这意味着用户可以在所有设备上获得统一的体验。
便于分享：卡片可以鼓励用户在社交媒体上分享内容，因为它允许用户只分享特定的内容，而不是整个页面。
什么时候应用卡片设计？
这通常是当你有:
基于搜索的界面: 卡片能通过模块的内容快速显示合适的内容，这使得用户可以深入了解自己的兴趣。基于卡片的设计是一种非常适合呈现这类内容的方式。
信息浏览：当用户浏览信息时，卡片的兼容性更好。
任务管理：当可以将流程中的单个任务作为卡片进行说明时， 可以轻松组织卡片以获取任务列表。任务管理应用在使用卡片式界面为用户创建仪表板方面做得很好，其中每张卡片代表一个单独的任务。
类似项目：卡片最适合于异构项目的集合（当并非所有内容都是相同的基本类型时）。
可视化分析: 仪表板通常在同一页上同时显示各种内容样本。在这种情况下，卡片类比可以帮助在不同物品之间创造出更明显的差异，其中每张卡片可以适应不同的角色。
卡片的布局可以不同，以支持它们包含的内容类别。下面的组件通常可以在多种卡片样式中找到。
(1)富媒体: 卡片可以包含缩略图，以显示图片，插图，头像，Logo，图标或图形。
(2) 标题: 标题文本可以包含相册或文章的名称或标题。
(3) 描述: 支持文本，如文章摘要或简短的描述。
(4) 行动按钮: 卡片可以包含用于操作的按钮。
(5) 副标题: 副标题文本可以包含详细介绍，如文章的署名或标记的位置。
(6) 图标: 卡片可以包含操作图标。
有一些小的技巧可以快速提高卡片设计细节。
1. 使用相关主题的图片
图片是卡片设计的主角，你需要一个高级的图片来吸引用户对每张卡片的注意。不仅是图像，卡片还可以包含插图、带有浅色背景框的图标或任何其他类型的富媒体，但需要与内容主题相关。
2. 增加视觉层次
卡片内的层次结构有助于引导用户对重要信息的阅读。将主要内容放在卡片的顶部，并使用排版来强化主要内容。使用空白和对比来分隔需要更多视觉分隔的内容区域。（彩云注：视觉层级对于信息表达至关重要！）
3. 限制内容长度
一张卡片应该只包含重要的信息，并提出一个相关的观点，以获取额外的细节，而不是完整的细节本身。当我们试图在一张卡片中放入太多内容时，卡片可能会变得很冗长，并失去与卡片类比的实际联系，因为它不再像一张卡片了。
4. 避免嵌入链接
不要包含内联链接，卡片应该自己链接。嵌入文字链接会让用户误操作。
5. 区分操作主次
包含不同操作的卡片应该在视觉上形成对比。在下面的例子中，我通过使用一种较轻的色调而不是主要的按钮风格来降低后续操作的视觉强度。
6. 去掉分割线
对于新手设计师来说，用分割线来区分内容是一种常见的方式，以此定义不同的组。这些边框会造成不必要的视觉干扰，从而影响内容。
APP中的卡片并不是纯粹的拟物概念，但通常情况下，使用一致的类比和物理原理能帮助用户理解界面并分析内容中的视觉层次。在卡片的情况下，你可以做几件事:
1. 使用圆角
在形态上与真实世界的卡片进行视觉对比。圆角更有效，因为它们让我们的眼睛容易跟随视觉动线，“因为它更适合头部和眼睛的自然运动”。
2. 增加一个轻微的外边框或者投影
增加一条淡淡的描边框或者增加一个淡淡的投影都是很好的做法。阴影在界面中创造了一个层次，这有助于我们区分UI元素。
然而，在设计中添加阴影并不像听起来那么简单。有时候设计师会过分强化投影效果，让原本看起来不错的设计看起来很廉价。避免使用纯黑色的阴影。
3.注意字体和留白
重要的是要让每一张卡片都能被人看到、阅读和理解。在每个块周围添加大量的空白，让用户有时间处理并进行视觉重置，有精力看完一张卡再到下一张。
选择简单和基本的字体，因为基本的排版最大限度地提高了可读性，并有助于浏览。
让我们看看一些真实项目中的卡片设计案例：
信息流中的卡片设计
保持信息流卡片简单是很重要的。它们应该有一个一致的、重复的结构，但是使用不同的图片和字体大小来代表卡片中最重要的和最不重要的元素，以使读卡片的人更容易理解它们。
由Diseno Constructivo和Webpixels设计
他们突出特色图片和标题作为最突出的元素，这能帮助用户决定文章或发布的内容是否适合他们。
电商卡片设计
产品卡片是一个很重要的东西，它可以帮助你将访问者转化为客户。一张优秀的产品卡片应该能够吸引人们的注意，激发人们获得产品的欲望，激励人们购买，并在搜索结果中得到高效推广。
由Webpixels设计
产品的名称应该放在最显眼的地方，这样参观者就会立刻明白他来对地方了。一个好的配图能告诉顾客胜过千言万语，所以你需要一个高质量的产品配图来设计完美的产品卡片。
如果产品有特价，不仅要在价格栏中注明促销价格，还要注明常规价格，以及客户可以节省多少钱。
个人中心卡片设计
简介卡已经成为一个应用或网站中的功能模板。随着个人品牌变得比以往任何时候都重要，卡片设计在这里也能发挥重要作用。
由Neelesh Chaudhary设计
就像每一张卡片一样，配置文件卡片也是一个UI组件，它包含了对它所代表的内容至关重要的信息。为了达到你的目标，你要向其他人推销你自己。
确保只包括必要的信息(例如，照片，名字，职业)，让你的“关于”页面有剩余的细节来完善你的个人资料。
仪表盘卡片设计
仪表板的设计可以有很大的不同。但是所有的仪表盘都是用卡片做的。根据仪表板的类型，每张卡片可能包括概要信息、通知、快速链接或导航设计元素、关键数据、图表和数据表。确保你为每个元素使用了正确类型的卡片。
由Simmmple设计
仪表盘卡设计允许用户决定他们想要关注哪些数据。易于理解的UI，允许用户精确地控制哪些数据需要在仪表板的前端做好。
只包括最相关的信息，为用户使用方便。当你的数据集在一起看更容易理解时，找到在一张卡片上显示它们的方法。但是要小心，不要让用户感到困惑。
日常计划卡片设计
看板任务卡似乎是一件非常简单的事情——拿一张便签，写下你需要做什么，然后把它贴在墙上。这些卡片必须包含需要行动的单位数量。它们还可能包含各种各样的其他信息，清楚地传达了必须做什么。
由Neelesh Chaudhary设计
卡片上包含的信息包括任务的名称和重要的细节，如任务的类型和谁拥有它。看板卡放在状态类别下。最基本的状态类别是“计划要做”、“正在进行中”和“完成”，但是状态可能因项目而异。
卡片结构最适用于添加或删除任务这样的小改变，而不是改变像你的总体目标这样的大想法。
有几种方法可以使卡片设计更加有效。通过最初定义和观察卡片，我们可以更好地了解跨行业的这种设计模式。这也让我们能够推测用户希望在这些卡片上采取什么行动。卡片在提供许多不同种类内容摘要的环境中尤其有效，而不是简单地作为内容列表的现代替代品。
在配置的过程中踩了很多坑，还是太菜，有些东西弄不明白什么意思。
运行项目时的报错可直接到最下面看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.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的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.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务、UI设计公司、界面设计公司、UI设计服务公司、数据可视化设计公司、UI交互设计公司、高端网站设计公司、UI咨询、用户体验公司、软件界面设计公司。
演出项目可分为【有座项目】和【无座项目】两种类型，有座项目又可分为【选座售卖项目】和【非选座售卖项目】。
大部分话剧、音乐剧、舞蹈芭蕾项目都是选座售卖项目。客户来到猫眼客户端中选择想看的项目，选定座位并下单，最后检票入场观演，完成闭环。其中选座体验是客户转化重要的一环，影响客户决策。
为了提升用户体验，提升数据转化，我们对猫眼目前选座体验进行走查，探讨问题原因，找到产品痛点和机会点，为产品优化做准备。
猫眼客户端选座体验问题：
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控件组件库
提供给交互设计师，基于提供的内容，交互可以快速的构建界面、交互和流程等，就像搭乐高一样。可以快速的构建一些产品原型或者是实验性的功能，来进行测试以快速验证想法。
颜色/字体样式库、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.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的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.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的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.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的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.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务、UI设计公司、界面设计公司、UI设计服务公司、数据可视化设计公司、UI交互设计公司、高端网站设计公司、UI咨询、用户体验公司、软件界面设计公司。
蓝蓝设计的小编 http://www.lanlanwork.com