演出项目可分为【有座项目】和【无座项目】两种类型，有座项目又可分为【选座售卖项目】和【非选座售卖项目】。
大部分话剧、音乐剧、舞蹈芭蕾项目都是选座售卖项目。客户来到猫眼客户端中选择想看的项目，选定座位并下单，最后检票入场观演，完成闭环。其中选座体验是客户转化重要的一环，影响客户决策。
为了提升用户体验，提升数据转化，我们对猫眼目前选座体验进行走查，探讨问题原因，找到产品痛点和机会点，为产品优化做准备。
猫眼客户端选座体验问题：
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咨询、用户体验公司、软件界面设计公司。
设计做到极致注重的就是对于细节的把控力，大厂的设计师之所以比较优秀，就是他们具备很好的细节把控力。想要提高产品设计的能力，发现设计细节和思考设计深入的能力至关重要。
最近在体验产品的时候，发现了一些设计细节做得比较好的优秀案例，分享给大家学习一下。
分享目录
一、Banner 轮播转场的品牌化
二、情感化的弹窗设计
三、最小化显示提高空间利用率
四、动态化的设置引导
五、沉浸式的活动氛围设计
六、人性化的提示设置
七、动态感知的温度设计
八、无处不在的广告位开发
九、主题化的图标设计
十、新颖的卡片式设计
一、Banner 轮播转场的品牌化
立足于品牌做设计，才能强化自身产品的差异化。如何在更多设计场景中融入品牌基因，是设计师需要深入思考的关键。
最近在使用腾讯视频 APP 时，发现首页 Banner 图在轮播的转场过程中，以品牌 LOGO 造型作为转场过度。一个小小的细节强化了用户对于品牌的记忆度，也体现出专属的设计差异。
二、情感化的弹窗设计
通过弹窗设计可以提高用户操作效率，也是传播信息（活动/广告）最直观的形式。但是体验多了用户便会开始排斥，提高弹窗的情感化设计变得尤为重要，降低用户的排斥感才能提高弹窗的作用。
很多娱乐影视等 APP 都会有“青少年模式”弹窗提示，抖音将弹窗视觉表达融入了精美的国风插画。也通过针对性的内容作为设置的引导，提高了用户对“青少年模式”的深入理解，增强了体验的积极性。
插画的形式在弹窗设计中表现比较突出，比如嘀嗒出行 APP 将“推送通知”的弹窗设计运用插画增强情感化表达。相较于生硬的表达方式用户更能接受，通过营销的文案引导用户授权，提高了产品的感官体验。
三、最小化显示提高空间利用率
对于工具型产品不同用户的操作焦点不同，更多定制化的体验才能提高用户的操作效率。
钉钉 APP 在协作栏目中，默认展示的各类工具可以进行收起，实现最小化显示。用户可以根据使用习惯和操作方式选择收起/展开，提高了当前空间的利用率，自定义的功能设计可以提高用户的操作体验。
四、动态化的设置引导
为了提高用户隐私权益，手机系统针对产品调用权限进行了阻力设计，需要用户的授权操作。提高用户的各类功能授权就需要设计师探索，降低用户的排斥感和提高授权的利好政策才能获得授权。
抖音在引导用户开启通知权限的设计中，采用了动态画面的表达来强调开启通知的利好政策，以此来攻破用户的心理防备。相较于生硬的弹窗提示，动态的表达和引导性的文案更能拉近与用户的距离感。
五、沉浸式的活动氛围设计
沉浸式的体验可以带给用户更好的场景感，提高用户的参与度。在活动的设计中，不断向游戏化和沉浸式方向加强体验，提高活动的趣味性和强化用户参与的积极性。
腾讯视频在情人节的互动活动设计中，就将抢红包的活动融入到当前的界面中，红包雨铺满整个屏幕，以趣味性的形式满足用户心理。不隔断与界面之间的联系，降低活动对用户的干扰，进而提高活动氛围感和参与度。
六、人性化的提示设置
短视频近些年改变了大家的生活方式和娱乐形式，也有用户容易过度依赖进而影响休息质量。
抖音作为短视频领域的头部产品之一，在增强用户体验的同时也要起到良性的引导作用。当用户刷短视频一定时间后会弹窗提示休息，而提示时间用户可以根据自己的实际情况进行设置，灵活的设置可以让用户合理分配时间。健康使用的引导可以让用户感受到产品的温度，提高用户体验的认可度。
七、动态感知的温度设计
天气预报是用户关注度较高的信息，对于温度的感知可以让我们出行更容易把控。在产品中显示天气情况也是一种情感化的升级，可以带给用户更有温度的体验。
利用饿了么 APP 点餐之后，首页会显示配送情况和当前的天气温度，背景以动态的天气画面增强视觉感知。也希望用户可以根据天气情况对外卖员多一份理解，加强人与人之间的宽容心，带给用户更强的情感化体验。
最近在使用爱奇艺 APP 时，发现左上角的品牌位置也结合了天气情况，结合顶部视觉区域的流体渐变，新增的天气预报和品牌 LOGO 完美的通过动效过度。整个设计表达流畅自然，感官体验也是非常值得学习的。
八、无处不在的广告位开发
广告是众多产品实现流量变现的方式之一，广告位的开发也是见缝插针，如何在仅有的空间增加更多广告位，产品设计师也在不断探索。
最近在使用腾讯视频 APP 时，进入到个人中心时会默认有个下拉广告。这个见缝插针的广告位新增，对于设计师来说让我感受到了广告的无处不在，不过对于用户来说是否会心生排斥感得通过数据去验证。但是作为产品设计师这也是一个启发，将有限的空间进行深度开发，还不会影响已有的结构布局，这也是一个启发性的案例。
九、主题化的图标设计
图标是产品中不可或缺的存在，图标设计的研究也是设计师需要重点对待的技能范围。精美的图标不仅可以提高产品的感官体验，也能吸引用户的关注度，进而提高业务模块的点击欲。
最近在使用顺丰速运小程序时，寄快递栏目的各业务入口图标设计非常引人注目，结合主题化的图标设计突出了活动传播力度。对于工具型产品而言，强化氛围感可以打破用户原有的认知，不仅可以突出活动主题，也能强化用户对产品的视觉感知。
十、新颖的卡片式设计
卡片式设计已经流行好几年了，目前依然是非常普及的 UI 设计趋势之一。如何进一步强化卡片式设计的创新度，我们需要不断的尝试和总结。
哗哩哗哩 APP 的创作中心设计也许是一个不错的启发，卡片内部右上角的视觉强化使得原本普通的表达变得更有视觉感。突出的设计也成功的吸引了 UP 主的注意力，强化了该入口的点击欲。这样的设计表达在保留卡片式设计的基础上，也是一种新颖的视觉表现，可以作为突出业务入口的表现方式进行探索。
作者：黑马青年 来源：站酷网
蓝蓝设计建立了UI设计分享群，每天会分享国内外的一些优秀设计，如果有兴趣的话，可以进入一起成长学习，请加微信ban_lanlan，报下信息，蓝小助会请您入群。欢迎您加入噢~~
希望得到建议咨询、商务合作，也请与我们联系01063334945。
分享此文一切功德，皆悉回向给文章原作者及众读者. 免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的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.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务、UI设计公司、界面设计公司、UI设计服务公司、数据可视化设计公司、UI交互设计公司、高端网站设计公司、UI咨询、用户体验公司、软件界面设计公司。
搜索“视频传输协议”，一般会搜出来RTP，RTSP，UDP等等。光看这些协议，可能有些人会觉得奇怪为什么要把udp也往上放一起，rtp不是可以基于udp？！同时，很多文章主要去讲解各个协议之间的差异，而没有从更为宏观的角度来考虑。本文将结合OSI的分层思路，将不同协议之间的关系都梳理清楚；同时也从视频传输与组网角度进行介绍。
再者，视频有很多封装格式，比如m3u8，mp4等；也有很多音视频编码格式，比如h264，h265等，那为何有这么多的封装格式类型和音视频编码格式类型呢？一方面是解决存储的问题；另一方面是支持不同播放器的解析；但更重要的是不同的传输协议可以支持的音视频编码格式有差异，这也是由于不同的应用场景下形成的历史原因。
流媒体（streaming media），是指将一连串的媒体数据包从服务器端发送到客户端，可以实现边下边播，此技术使得数据包可以像流水一样发送。传统的方式需要在使用前下载整个文件，存储到本地后才能进行播放；而流媒体只允许下载一小部分（存在视频关键帧）就能进行播放。
流媒体技术不是一种单一的技术，它将网络技术、音视频技术还有终端缓存技术等有机地结合。也就是说，在网络上要实现流媒体技术，必须要先制作、发布、传输和播放等，这需要服务器端、终端以及网络都要能支持。当前很多的视频软件或者网站都是用到了这种技术。归结下来是：
1.内容的产生。这里是指将视频源制作成为可以对外发布的视频格式，以及适合在网络上传播的分辨率和码率。这主要用到了视频的编解码技术。考虑的输出参数，如分辨率、码率、音视频编码格式、封装格式等都需要结合应用场景和传输方式统一考虑。
2.对外发布。这里主要是指能够支撑服务器对外输出视频资源的技术，常见的有各种流媒体网络传输协议技术及其需要服务器端支撑的技术。这里的流媒体网络传输协议比如：
3.组网和传输。
这里的传输还得考虑一个概念，是服务器对外主动推数据，还是等待终端到服务器端拉数据，这是两个完全相反的处理方式。对于组播或者广播的组网方式，往往采用的是服务器主动对外推送数据；而对于单播来说主要是终端向服务器端主动拉数据。
这里涉及到的IP组网方式中的传输类型有：广播、单播、组播。
不管是什么类型的组网方式，在传输层就有UDP和TCP。下面也将从OSI等层面讲讲这些底层传输协议之间的关系。
4.视频播放。这里主要是从终端侧角度说，在不同操作系统中能够进行播放视频的播放器，比如vlc等，不同的播放器支持对不同类型的视频数据进行播放。
从图中也可以看到IP层（网络层）的上层是传输层，通过TCP和UDP等方式进行数据包的传输。
（PS：下图为网络中所找https://blog.csdn.net/yaopeng_2005/article/details/7064869）
结合上图，再补一个wiki上的互联网协议套组图，一看就更明白了。
从上面两个图中也可以很清楚地看到，TCP和UDP在接下去的内容有很重要的地位，这里也简单介绍下，深度知识请自行搜索。
组播（multicast）
又称为多点广播或群播，或多播，主要是指将信息同时传递给一组目的地址。消息在每个网络链路上只需传递一次，而且只有在链路分叉时，消息才会被复制，使用的效率是最高的。也正是因为这个原因，以前的广电网络中，针对直播多采用组播方式，流量的传输成本明显降低很多。
单播：
其实是组播的一种特殊方式，即常规的点到点信息传递。如果所有传输中是以单播的方式传递给多个接收方，必须向每个接收者都发送一份数据副本这么多。
广播
其实也算是组播的一种特殊方式，就是一对所有的通信方式，对每一台主机发出的信号都进行无条件复制并转发，所有的接收点都可以收到所有信息。
注意，组播一般指的是IP组播，常与RTP等音视频协议相结合。虽然组播的设计理念很好，但是它需要对网络内部的状态比单播要多得多。实际商用中，组播主要应用在较为简单的、只有单个源断的情况，如之前提到广电网络内部用到的组播方式，UDP组播。
以上是不同类型的IP组播方式，实际在采用中要结合具体情况进行调整。比如，如果非要使用广播，但是采用的场景不合适，也有可能产生广播风暴。
组播、广播、单播也介绍了基本的概念，但是他们与视频传输有什么关系呢？
文章上面也提到了，组播是从IP层面的传输策略，而所有的视频传输协议其数据包大部分都经过UDP和TCP，经由IP层进行传输到目的地。因此不同的IP传输策略与传输协议进行结合，就能够落地到具体的应用场景。
同时需要注意的是，采用组播方式可以通过设置网卡为混杂模式或为多播模式，具体也是根据网卡的特性进行差异处理。如果处理方式不当，比如设置成了广播，可能会导致在同网络下，你在播放视频，然后其他相同网络下接收端也将有相应的流量，而导致他们的对外服务网口的流量被占满。
从下图中可以看到，标红色的就是大家经常说的视频传输协议。但是从图中可以看到他们其实是有基于的关系，比如HLS都是基于HTTP进行传输，而HTTP在传输层都是依赖tcp数据包，再经由ip层进行分发。
1）UDP
基于UDP传输的视频数据，比如udp://238.123.45.1:3001，在网络可达的情况下，即可进行播放。可以采用vlc等播放器进行播放。
UDP视频数据传输可以采用单播，组播或广播的方式，具体采用哪种方式根据具体的组网情况进行控制。
上面也有提到过，广电网络中多采用组播的方式进行直播数据传输，这也是得益于广电网络的专网特性以及视频源输出可以控制到单一等特性。
UDP的组播大部分是采用MPEG TS流，广电网络中很多视频，其视频编码格式也大部分是mepg2
2）RTP
整个RTP协议包括RTP数据协议和RTP控制协议（RTCP）。此外，这里也将经常一起提的RTSP介绍下。
RTP（实时传输协议，Real-time Transport Protocol），是一种网络传输协议
RTP协议说明了传递音频和视频的标准数据包的格式。最早是作为多播协议的，后来主要应用在单播中。RTP是创建在UDP协议之上的，主要应用于流媒体、视频会议等系统业务上。
RTP为端到端的数据传输提供了时间信息和流同步，但不保证服务质量，而是由服务质量由RTCP。
在RTP的数据包封装中，包含了时间戳、标记位、同步源标识等信息。
RTP从上层接收到流媒体的数据（如H264），封装成RTP数据包，并将其发往UDP端口中的偶数端口。
RTCP（实时传输控制协议，Real-time Transport Control Protocol或RTP Control Protocol）
RTP的姐妹协议。RTP使用的是偶数UDP端口，RTCP采用的是RTP下一个端口，也就是下一个奇数的端口。RTCP也是基于UDP进行传输的。
RTCP本身不做数据传输，主要与RTP协作，将视频媒体数据打包和发送，并定期在流媒体会话参与者之间传输控制数据，并为RTP提供QoS反馈，简单点说是主要保证音视频的同步。
RTCP接收到控制信息后，封装为RTCP控制包，并发往RTP端口下一个偶数端口。
RTSP（实时流协议，Real Time Streaming Protocol）
RTSP是一种网络应用协议，主要来创建和控制流媒体服务器与终端之间的会话。控制类的请求主要走TCP协议。
通过RTSP对流媒体数据进行控制和播放，比如进行播放、暂停、快进等操作，它定义了具体的控制消息、操作方法和状态码等。
与RTP、RTCP配合，在广电网络内部主要应用在点播场景比较多，而直播主要走UDP组播。在互联网场景下，也有用于直播和点播的，但是相对来说使用较少。
请求的url为：rtsp://testdomain/test.mp4/streamid=0
需要服务器端和客户端都能够支持RTSP的控制。一般客户端采用vlc即可，而服务器端采用Darwin Streaming Server，ffmpeg等建立流媒体服务。
3）RTMP（实时消息协议，Real-Time Messaging Protocol）
包括RTMP、RTMPT等一系列的协议，Adobe为flash播放器和服务器之间音视频数据传输的协议。
4）HTTP
而基于HTTP协议的就更多了，如上图。如果服务器部署了流媒体的服务，如Nginx等，就可以对外提供视频播放服务了。
这里也需要说明，视频的播放一般分为点播和直播，有些协议作为直播的传输协议反而是更好的，比如RTMP，时延就比较低，但RTMP做CDN成本相对较高。CDN支持很好的HTTP如果能支持直播，当前也有很多协议能支持通过HTTP的方式实现直播流媒体。
自适性流媒体（adaptive bitrate streaming，ABS）也叫码流自适应，是流媒体服务器准备各种码流的视频流，所有的视频码流都是相同时段完全统一图像的音视频数据，客户端根据网络情况和CPU使用情况等进行动态调整。
主要有MPEG-DASH、HLS、HDS、MSS等技术方案，这几个也是上图中最上层的流媒体传输协议技术。通过这些传输协议封装的视频源，可以支持有多种码率，并支持播放器客户端在播放时，根据带宽情况自动调整码率以适应用户的最佳观看效果——不卡顿，不重新加载等。
这里也仅仅对码流自适应技术做了简单介绍，由于现在这种技术应用相当广泛，后面将详细介绍这种技术。
【说明】
文章转自，华为云社区，作者Higeeon，相关版权解释权归原作者所有。https://bbs.huaweicloud.com/blogs/fed3df04b1e011e9b759fa163e330718
蓝蓝设计建立了UI设计分享群，每天会分享国内外的一些优秀设计，如果有兴趣的话，可以进入一起成长学习，请加微信ban_lanlan，报下信息，蓝小助会请您入群。欢迎您加入噢~~
希望得到建议咨询、商务合作，也请与我们联系01063334945。
分享此文一切功德，皆悉回向给文章原作者及众读者. 免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务、UI设计公司、界面设计公司、UI设计服务公司、数据可视化设计公司、UI交互设计公司、高端网站设计公司、UI咨询、用户体验公司、软件界面设计公司。
JSON（JavaScript Object Notation, JS对象简谱）是一种轻量级的数据交换格式。它基于 ECMAScript（European Computer Manufacturers Association, 欧洲计算机协会制定的js规范）的一个子集，采用完全独立于编程语言的文本格式来存储和表示数据。简洁和清晰的层次结构使得 JSON 成为理想的数据交换语言。 易于人阅读和编写，同时也易于机器解析和生成，并有效地提升网络传输效率。
JSON源自于JavaScript，是一种轻量级（Light-Meight)、基于文本的(Text-Based)、可读的(Human-Readable)格式。
在现在的开发中，能够进行数据交换格式的，包括两个JSON XML。
JSON是存储和交换文本信息的语法，类似 XML，JSON比 XML更小、更快，更易解析。
那么，简而言之，对JSON的说明总结如下：
- JSON是独立于任何编程语言的数据格式
- 是一种用于存储和传输数据的轻量级格式
- 语法是自描述的，便于人类阅读和理解
- 数组（Array）用方括号 "[]" 表示
- 对象（0bject）用大括号 "{}" 表示
- 名称 / 值 对(name/value）组合成数组和对象
- 名称( name ）置于双引号中，值（value）有字符串、数值、布尔值、null、对象和数组
- 并列的数据之间用逗号 "," 分隔
- 名称/值对包括字段名称（在双引号中），后面写一个冒号，然后是值
需要注意的是：
JSON不支持注释。向 JSON添加注释无效
JSON文件的文件类型是
.jsonJSON文本的
MIME类型是application/json
json是以对象的形式存在的，直接获取JSON数据可通过如下方法：
1. json对象.键名
2. json对象["键名"]
3. 数组对象[索引]
4. 遍历
代码示例：
-
//定义基本格式
-
var person = { name: "张三", age: 23, gender: true };
-
var persons = [
-
{ name: "张三", age: 23, gender: true },
-
{ name: "李四", age: 24, gender: true },
-
{ name: "王五", age: 25, gender: false },
-
];
-
-
//获取person对象中所有的键和值
-
//for in 循环
-
/* for(var key in person){
-
//这样的方式获取不行。因为相当于 person."name"
-
//alert(key + ":" + person.key);
-
alert(key+":"+person[key]);
-
}*/
-
-
//获取persons中的所有值
-
for (var i = 0; i < persons.length; i++) {
-
var p = persons[i];
-
for (var key in p) {
-
console.log(key + ":" + p[key]);
-
}
-
}
输出结果为：
先在控制台中打印一下JSON对象，看看有什么，如图：
显而易见，在JavaScript中JSON对象仅有两个方法：parse和stringify。后面会详细介绍一下这两个方法
序列化的概念：序列化是将对象转化为字节序列的过程。对象序列化后可以在网络上传输，或者保存到硬盘上。
将对象序列化成json字符串： JSON.stringify(json对象)；
反序列化：将json字符串反序列化为对象: JSON.parse(str)
API介绍：用来解析 JSON字符串，构造由字符串描述的 JavaScript 值或对象，传入的字符串不符合 JSON规范会报错
语法：
JSON.parse(str, reviver);
str：要解析的 JSON字符串reviver：可选的函数function(key,value)，该函数的第一个参数和第二个参数分别代表键值对的键和值，并可以对值进行转换（函数返回值当做处理后的value）
代码示例：
-
// JSON.parse() 解析JSON字符串， 将JSON转换为对象
-
let json = '{"name": ["js", "webpack"], "age": 22, "gridFriend": "ljj"}';
-
console.log(JSON.parse(json));
-
// {name: Array(2), age: 22, gridFriend: 'ljj'}
-
-
// 第二个参数是一个函数，key和value代表每个key/value对
-
let result = JSON.parse(json, (key, value) => {
-
if (key == "age") {
-
return `年龄：${value}`;
-
}
-
return value;
-
});
-
console.log(result);
-
//{name: Array(2), age: '年龄：22', gridFriend: 'ljj'}
API介绍：将一个 JavaScript 对象或值转换为 JSON字符串
如果指定了一个 replacer 函数，则可以选择性地替换值，或者指定的 replacer 是数组，则可选择性地仅包含数组指定的属性
语法：
JSON.stringify(value, replacer, space)value：将要序列化成 一个 JSON 字符串的值
replacer：
- 如果该参数是一个函数，则在序列化过程中，被序列化的值的每个属性都会经过该函数的转换和处理
- 如果该参数是一个数组，则只有包含在这个数组中的属性名才会被序列化到最终的 JSON 字符串中
- 如果该参数为 null 或者未提供，则对象所有的属性都会被序列化
space：指定缩进用的空白字符串，用于美化输出
- 如果参数是个数字，它代表有多少的空格；上限为10。该值若小于1，则意味着没有空格
- 如果该参数为字符串（当字符串长度超过10个字母，取其前10个字母），该字符串将被作为空格
- 如果该参数没有提供（或者为 null），将没有空格
代码示例：
-
let obj = {
-
name: "jsx",
-
age: 22,
-
lesson: ["html", "css", "js"],
-
};
-
let json = JSON.stringify(obj);
-
console.log(json);
-
// {"name":"jsx","age":22,"lesson":["html","css","js"]}
-
-
// 第二个参数replacer 为函数时，被序列化的值得属性都会经过该函数转换处理
-
function replacer(key, value) {
-
if (typeof value === "string") {
-
return undefined;
-
}
-
return value;
-
}
-
let result = JSON.stringify(obj, replacer);
-
console.log(result);
-
// {"age":22,"lesson":[null,null,null]}
-
-
// 当replacer参数为数组，数组的值代表将被序列化成 JSON 字符串的属性名
-
let result1 = JSON.stringify(obj, ["name", "lesson"]);
-
// 只保留 “name” 和 “lesson” 属性值
-
console.log(result1);
-
// {"name":"jsx","lesson":["html","css","js"]}
-
-
// 第三个参数spcae,用来控制结果字符串里面的间距
-
let result2 = JSON.stringify(obj, null, 4);
-
console.log(result2);
-
/*{
-
"name": "jsx",
-
"age": 22,
-
"lesson": [
-
"html",
-
"css",
-
"js"
-
]
-
}*/
注意：如果replacer是一个函数，则该函数会进行深处理，即如果键值对的值也是一个数组，则也会执行该函数
- 转换值如果有
toJSON()方法，该方法定义什么值将被序列化- 非数组对象的属性不能保证以特定的顺序出现在序列化后的字符串中
- 布尔值、数字、字符串的包装对象在序列化过程中会自动转换成对应的原始值，undefined、任意的函数以及 symbol 值，在序列化过程中会被忽略（出现在非数组对象的属性值中时）或者被转换成 null（出现在数组中时）。函数、undefined 被单独转换时，会返回 undefined，如JSON.stringify(function(){}) or JSON.stringify(undefined)
- 对包含循环引用的对象（对象之间相互引用，形成无限循环）执行此方法，会抛出错误
- 所有以 symbol 为属性键的属性都会被完全忽略掉，即便 replacer 参数中强制指定包含了它们
- Date 日期调用了 toJSON() 将其转换为了 string 字符串（同Date.toISOString()），因此会被当做字符串处理
- NaN 和 Infinity 格式的数值及 null 都会被当做 null
- 其他类型的对象，包括 Map/Set/WeakMap/WeakSet，仅会序列化可枚举的属性
蓝蓝设计建立了UI设计分享群，每天会分享国内外的一些优秀设计，如果有兴趣的话，可以进入一起成长学习，请加微信ban_lanlan，报下信息，蓝小助会请您入群。欢迎您加入噢~~
希望得到建议咨询、商务合作，也请与我们联系01063334945。
分享此文一切功德，皆悉回向给文章原作者及众读者. 免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务、UI设计公司、界面设计公司、UI设计服务公司、数据可视化设计公司、UI交互设计公司、高端网站设计公司、UI咨询、用户体验公司、软件界面设计公司。
1.get请求一般是去取获取数据（其实也可以提交，但常见的是获取数据）；
post请求一般是去提交数据。
2.get因为参数会放在url中，所以隐私性，安全性较差，请求的数据长度是有限制的，
不同的浏览器和服务器不同，一般限制在 2~8K 之间，更加常见的是 1k 以内；
post请求是没有的长度限制，请求数据是放在body中；
3.get请求刷新服务器或者回退没有影响，post请求回退时会重新提交数据请求。
4.get请求可以被缓存，post请求不会被缓存。
5.get请求会被保存在浏览器历史记录当中，post不会。get请求可以被收藏为书签，因为参数就是url中，但post不能。它的参数不在url中。
6.get请求只能进行url编码（appliacation-x-www-form-urlencoded）,post请求支持多种（multipart/form-data等）。
深入理解
1…GET 和 POST都是http请求方式， 底层都是 TCP/IP协议；通常GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包（但firefox是发送一个数据包），
2.对于 GET 方式的请求，浏览器会把 http header 和 data 一并发送出去，服务器响应 200
（返回数据）表示成功；
而对于 POST，浏览器先发送 header，服务器响应 100， 浏览器再继续发送 data，服
务器响应 200 （返回数据）。
蓝蓝设计建立了UI设计分享群，每天会分享国内外的一些优秀设计，如果有兴趣的话，可以进入一起成长学习，请加微信ban_lanlan，报下信息，蓝小助会请您入群。欢迎您加入噢~~
希望得到建议咨询、商务合作，也请与我们联系01063334945。
分享此文一切功德，皆悉回向给文章原作者及众读者. 免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务、UI设计公司、界面设计公司、UI设计服务公司、数据可视化设计公司、UI交互设计公司、高端网站设计公司、UI咨询、用户体验公司、软件界面设计公司。
蓝蓝设计的小编 http://www.lanlanwork.com