阅读 45

运营场景下的可视化页面搭建

可视化搭建的局限性

可视化页面搭建这个领域由来已久,从早期的 Dreamweaver 到这些年各种基于 BS 架构的搭建平台层出不穷,但又好像没有一个一家独大,久负盛名。原因在于该类产品不具有通用性,面对不同的业务场景(B类表单后台、C类静态页面)、不同的使用者(研发、UED、运营),产品使用方式都可能不一致,另外该类产品解决的问题比较局限,本质上都是设计一种配置协议来实现界面效果,超出设计范围的需求就比较棘手。

运营场景的适用性

运营场景下,多是营销活动类静态展示页面,比较适合用可视化方式来搭建,另外,使用角色为运营等非技术同学,可视化搭建工具不能太复杂,理想的方式是可以通过搭积木的方式搭建出一个页面,而这里的积木就是组件的概念,所有的组件由开发者提供。所以这个可视化搭建平台满足以下功能即可:
1. 对运营来说只需要添加组件,像搭积木一样
2. 开发者注册和维护组件,维护组件和组件之间的关系
3. 运营可对组件进行个性化配置

undefined

交互方式

理想的组件化搭建方式即:

组件上下流式排列,可在某个组件后插入新组件,可排序,整体可视化操作非常简单。如果某个组件是相对屏幕定位的布局方式,则在组件内部处理即可,使用者无需感知。

有时候,两个组件需要呈左右分布,这个时候就需要一种布局组件来实现了,先添加一个左右布局组件,产生两个「坑位」,在具体的「坑位」里添加需要的组件:

布局组件的重要功能在于充分利用已有的组件进行不同的组合。有时候为了简化可视化操作,开发者也会开发一个新组件在组件内部去实现。

技术实现

整体组件开发、组件以及搭建平台的关系如下:

Untitled Diagram (2).svg

多人协作页面搭建过程时,可针对其他人对页面进行锁定,当然也不能锁死,强制编辑可给出确认提示。

组件配置:从数据到表单

大部分组件都需要一些配置,对组件来说,需要的配置就是一个 JSON 化的数据结构,如果直接让运营同学填写 JSON 数据内容显然不太合适,这时需要一种可以把 JSON 数据转换成表单的 JSON Schema,同时支持将表单结果返回成起初的 JSON 源。

aform 很好的处理了这个问题

比如描述如下这样的数据:

{
  "name": "hello"
}
复制代码
Copy

使用 aform schema 是这样描述的:

{
  "fields": {
    "name": {
      "label": "名称",
      "defaultValue": "hello",
      "type": "text"
    }
  }
}
复制代码
Copy

实际呈现给使用者的配置方式:

数据表单化,表单数据化,一种 schema 定义方式既满足非技术同学的配置要求,又满足程序的数据结构要求。

数据驱动式组件

电商运营类场景商品组件的需求较多,组件UI也各不相同:

但是这类组件的数据层都是一致的,无非就是字段多少的区别,所以数据层的字段定义、逻辑处理可以统一来做

{
  offerId: dataSource.offer_id,
  offerTitle: dataSource.offer_title,
  price: parseFloat(dataSource.price.toFixed(2)),
  ...
}
复制代码
Copy

结合上层组件的配置到渲染结果,整体流程如下:

Untitled Diagram (3).svg

关于商品组件(不仅仅是运营场景)这块的详细设计:商品组件设计1.0 以及 商品组件设计2.0

另外,不仅仅是商品组件,任何数据源相似的一系列组件都可以参考这种方式来实现。

模版

一件事情即使再简单,也比不上使用现成的模版。

模版本质上就是一个页面,任何一个页面可以当成模版存储起来供使用。

页面搭建过程中,我们也沉淀了不同场景、不同业务的模版,包括行业频道、专题活动、大促等

undefined

总结

  1. 运营场景下的可视化页面搭建使用上要求简单,拒绝学习成本高的产品
  2. 搭积木(组件)的方式也比较符合正常人的思维
  3. 复杂的组件逻辑放在组件内部由开发人员处理,对使用者来说与其他组件相同
  4. 组件的接口(配置项)符合非技术同学思维,简单易懂
  5. 搭建过程中沉淀可复用的模版