B端内容配置场景下的组件化设计思考

正文

请到「今天看啥」查看全文

在业务用例收集到一定程度后，开始对内容维度自上而下分层进行归纳，抽象出各类展示/题目组件，和不同组件的构成、样式与附加逻辑（有点类似HTML、CSS和JS的关系），对信息结构逐渐形成清晰的理解。

在不同维度的内容层级梳理清楚后，便基于此搭建 B 端配置页面的布局框架，这个过程让配置步骤从毫无重点优先级（比如在一个表单里同时混杂了构成、样式与逻辑相关的配置项，低频的逻辑配置操作出现在前置显眼位置）变为自上而下层层递进（激活框架-添加组件-插入构成元素-更改样式-设置附加逻辑），关联信息配置的联动映射关系也更清楚。

基于梳理出来的组件样式类型与逻辑配置项，又可以进一步定义映射到 C 端组件的视觉与交互规范，而 B 端用户只能基于规范已有的内容进行有限的选择（比如定义某段文本属于「标题样式」还是「正文样式」），不能随心所欲地自定义控制样式（如随意更改文本的字号、颜色）等。

大量级数据的编辑效率提升

前面梳理内容层级时，构成部分我拆成了常量（手动输入的数据）和变量（本地上传的数据），而变量这个概念的引入则和大量级（1K+、1W+）数据导入的业务场景紧密相关。

举个例子，如果 1 个 B 端用户想通过任务发放收集 1000 条不同文本的语音朗读数据，如果没有变量（本地上传的数据）的概念，就意味着他需要手动选择或复制 1000 次文本朗读组件，而每次更改的只有朗读对象这一个字段。但如果选择从本地导入这 1000 条文本的表格数据并统一命名为变量 text，编辑朗读对象时插入这个叫 text 的变量，则只需要编辑 1 次文本朗读组件就够了，系统会根据变量值的个数自动生成 1000 个任务发放给 C 端用户，大大提升了任务配置效率。

这里对于设计的挑战在于怎么让选择和插入变量的过程更直观、易用。在产品之前的配置流程里，是通过让用户输入 $content.image 或者 {{text}} 一类的字符串来实现变量的插入，这个过程存在一定的学习成本（为了区分于普通输入文本，字符串的格式通常需要设计得比较复杂和特殊），对用户也不够直观；而市场上其他一些竞品则是提供下拉选择框，让用户从中选择导入的变量名，这需要用户记住自己导入的每一个变量和其对应的值具体是什么（不能预览变量内容），也无法满足常量和变量灵活组合展现的业务需求（比如插入字段「品牌名：阿迪达斯」，其中品牌名为常量，阿迪达斯为变量）。

请到「今天看啥」查看全文