本文以 EasyTwin（易知微旗下的数字孪生仿真渲染引擎） 为例，阐述整个属性面板重构的设计目标、思考过程以及具体的设计决策方案。
EasyTwin 提供低代码化场景搭建、要素构建、场景渲染、动画配置、业务开发的功能，帮助企业及个人更低成本、高效率实现数字孪生可视化场景。
随着功能的拓展，我们不断地在属性面板中添加新的配置项类型。然而这些新增的配置项样式并未遵循一套统一的规则，这就导致属性面板的屏效和规范性呈直线下降趋势。
在我们产品业务快速发展进程中，上述问题愈发凸显。为了解决这一问题，我们决定对属性面板进行全面Redesign。重构的目标是提升属性面板的屏效和一致性，以更好地满足用户的需求和期望，确保新设计能够为用户带来更优质的体验。
“属性面板“用于显示当前选定对象的属性，并将属性的修改应用至对象。
这些属性可以是对象的大小、颜色、位置、样式等各种属性；用户可以通过属性面板直观地修改对象的属性，无需深入到代码或者其他高级设置中。
EasyTwin 与市面上大部分低代码搭建系统基本类似，左侧为组件列表，中间是画布区域，右侧是属性面板；属性面板是承载了产品多数低代码化功能的编辑界面/入口，需要在配置面板实现对场景环境、材质、贴图、组件状态以及样式、镜头动画、点位、数据等修改。
EasyTwin 属性面板中，每个富交互的配置项都是由 易知微UI组件库 中的通用组件拆分拼装而成，每项都包含其特有属性并且反映了当前组件的各种状态。
属性面板应该是语义化的，任何用户都可以通过属性面板的操作区直观的了解一个组件的属性，以及如何使用和编辑。
1.
label
：属性名称，帮助用户直观的理解属性的用途和定义，比如元素的位置、尺寸、缩放值等； EasyTwin 中，属性层级包含三个层级，每一层级都支持提示信息和子集箭头的显隐配置
2.
description
：属性的描述信息；是对属性名称的额外说明或解释，用来提供更详细的信息；
描述信息（description）的实际业务场景示例
3.
content
：属性渲染器；用户可以基于此实现对属性的修改，最常见的有 input、inputNumber、select 等；
4.
error
：属性校验信息；当用户输入了错误格式或冲突参数后，给予适当的错误提示信息；
JavaScript 中，一共有七种数据类型，字符串（String）、数字(Number)、布尔(Boolean)、空（Null）、未定义（Undefined）、Symbol 和对象（Object）。其中对象类型包括：数组（Array）、函数（Function）、还有两个特殊的对象：正则（RegExp）和日期（Date）。
以下的 5 种数据类型基本能够全覆盖 EasyTwin 中的所有（通用型）渲染器类型
易知微拥有自研的设计系统中，其中包含 116 个基础token，61 个 design token，支持配置主题；
组件库 30+ 组件类型，1700+ 总原子数，可覆盖企业全线产品设计；
组件库中 token 中组件尺寸的定义有 4 类，分别是 large、medium、small、mini；对于 EasyTwin 的产品表达上来说，希望整个产品（主属性面板）呈现尽量的简洁、紧凑、秩序的同时也要保证信息量展示最大化以及整体的视觉舒适度；
基于 EasyTwin 的产品属性以及后续产品发展，最终敲定出 EasyTwin 的组件尺寸，应用 size-small 变量；尽量减少配置项项间间距，去传达 紧凑 的视觉语言；
为了使信息量展示最大化，统一了配置项的横纵向间距为 8px，那么单个配置项 block 高度由 44px 缩减至 36px，屏效较原先提升了 8%；
在原先的版本当中，也存在着这样一类 [底部标签] 的组件形式，为了贴合这次重构的设计语言，新版本中尽量地用文字或icon形式的组件 [前缀] 去代替 [底部标签] ，如下图的开始结束时间、字距行距等；
过程中也会有一些特殊情况被暴露出来，例如下图的参考点配置项，设计过程中发现经纬度作为前缀值展示后，可输入的字符变得十分有限，而这里的实际场景需要保留到小数点后 6 位，最终做出了“规范性”的牺牲，配置项改为上下堆叠以保证最重要的阅读体验和效率：
定下组件尺寸后，下一步该明确各个组件的具体宽度，首先穷尽配置项各 columns 的形态，columns 的值为1、2、3、4，如果希望属性面板具有强秩序性，需要保证除方形组件外的最窄组件的宽度保持一致，也就是最右侧的 columns 为定值（除columns为1或2的情况），那么怎样确定这个定值呢？
当 columns 为 4 时，也就是上图的 2 个方形按钮，2 个 input 组合的配置项，组件横向间距为 8 ，假设 input 宽度为
X
，那它的总长为
28*2+X*2+8*3
；
当 columns 为 3 时，平分 3 等份，那它的宽度为
X*
3+8*
2
；
当 columns 为 2 时，两种情况，要么均分，要么固定右侧为
X
；
得到公式：
28*2+X*2+8*3 = X*3+8*2 → X = 64px
当我们得到
X
的值后，整个配置项的组件宽度就可以确定为 208px ，在 EasyTwin 中，属性面板总宽为定值 320px（所有设计思考都是基于定宽这个前提之上的，至于为什么不做成可变宽度让配置项自适应，那是第 2 步），减去左右 padding 各 12px ，那么配置项的总宽为
320-12*2=296px
；
重构时在考虑按钮的位置时，置左，牺牲属性标签长度，改变部分用户已养成的使用习惯；
置右，压缩配置项组件长度（总长为定值 208px）可能造成输入框内数值展示不完全的同时破坏一定的配置项纵向规范和视觉整体性；
衡量上述权重，也考虑使用场景多为 [尺寸] 、 [缩放] 这样两个字符长度的配置项，最终决定按钮置左，限制属性标签长度（实际业务场景上还是可以展示完全），保留配置项的纵向排版规则；
上面有讲到配置项最小宽度为 64px ，那么应该如何设计一个 slider + input 的组合呢？是遵循 64px 的最小宽度，还是压缩数值的显示程度，项间间距是否还保留 8px ？
几种方案尝试之后，决定舍去 [:] 符号，压缩项间间距至 4px，这样就能减少一定的字符限制，时间的整体输入框的总宽等同与最小组件宽度，幸运的是剩下的 30px 足够展示所有时间场景，所以做设计还是需要一点运气在的；
看到这里你可能会发出疑问，时间选择其实很多大厂是有相关通用控件 [TimePicker] 的，为什么直接用现有组件样式？
一是因为这里的时间配置并不是一个严谨的时间选择器，不需要过于精确时分秒，大部分情况下用户拖动 slider 对照着场景中的光照，达到预期效果后，那就是一个“正确答案”，所以时间选择器在这个需要实时预览效果的场景下，显得尤其“重”了；
其次 [TimePicker] 中输入器的符号 [:] 是可以做删除的，那这里还伴随着一定的错误格式风险和报错，给用户带来不必要的理解成本；
在一的思考下，放弃了使用标准组件的做法，那就引发了上述的符号 [:] 和 input 宽度的取舍的问题，舍弃 [:] 会不会给用户“把设计的规范性看得比表达准确性更重要”的感受，面对这样的质疑，我的脑海中总是有个观点支撑着我“两个输入框比冒号更能表达时间”，至于为什么犹豫了半天也没写出来；
下意识的触发屏幕右下角启用屏保，准备闭眼好好想一想为什么，这不，我用了“半辈子”的屏保给了我答案。
在重构属性面板的过程中，也遇到通用组件交互的限制性，导致在实际业务场景中体验感较差的情况；
比如 inputNumber 组件，通用组件中仅支持上下箭头控制数值的增减，在 EasyTwin 中，对于元素的尺寸、位置、缩放、强度等配置项增加了更友好更符合业务场景的滑动增减数值和一些基础的数学运算。
EasyTwin 中多点巡航镜头指通过在环境中预先设定一组镜头点位，按照特定顺序自动切换这些视角，形成动态、连贯的视觉巡游效果，在一些需求下，多点巡航镜头可以需要根据业务编排镜头切换；
根据这一场景，在原固定排列（按创建时间）中新增排序功能，便于确保镜头转换符合预期的视觉叙事，提升用户体验。
EasyTwin 中的自定义动画列表也存在着配置上的局限性，原先先配置动作到动作，最后是修改动作整体的过渡方式和时间，为更加符合动画配置逻辑优化为每个动作到每个动作之间皆可进行时间和动画策略的配置；
为给予用户更多的配置灵活性和自由度，不限制创建时间来排序，也需要新增上述“拖拽”的交互功能，但由于动画的各个步骤约束了起始跟结束的时间，拖拽的会影响正确的动画节奏，最终采用了 [交换位置] 的设计方案，提高容错率、更方便进行动作管理。
状态机是 EasyTwin 实现场景交互的重要功能之一，环境切换、数字要素的状态变化、镜头切换等均基于状态机实现。状态的管理以及状态下配置的复用就尤为关键；
属性面板中状态机在绝大多数场景中由tabs组件呈现，支持双击重命名、右键支持更多操作、可增删、hover 箭头显示未暴露的状态dropdown、点击箭头切换状态；
但在数据面板中会存在着一二十条数据的情况，这时候 tabs 的形式显然会对用户的操作成本造成很大压力；
特殊情况特殊处理，重构时在数据面板中新增状态机的展示形式：纵向（列表），认其为默认展示形式并支持折叠以便用户更好的查找和阅读。
EasyTwin 原属性面板中模块与模块间区域性不强，重构后新增规定：以标题区分各模块、hover某模块配置项时 ，增加底色、模块间增加分割线，以保证用户的功能定位和阅读体验。
我们不仅仅是设计师，我们也是数学家，我们需要详尽地计算每个原子的状态个数，精确地量化应用组件的规格尺寸，利用我们的专业知识、严谨的思维、以及对细节的关注，权衡着各种交互的利弊并选择出最适合的答案；
但设计从来没什么对错，让我们继续探险吧。
本文设计都是在产品现结构限制上，从设计师的视角出发改版优化的尝试；但仍有许多地方需要具体的数据或指标来支持改进和验证，未来，我们也会持续通过一些量化手段进行调整和完善，确保这些设计更易用、通用，并更好地符合用户需求，不断进化，欢迎大家体验和反馈。
