关于前端:大屏拓扑三维编辑器的设计与思考

2次阅读

共计 2820 个字符,预计需要花费 8 分钟才能阅读完成。

从去年年初开始,咱们团队外部就在做两个编辑器:

  • 3d 编辑器 反对搭建 3d 场景。
  • 拓扑 / 大屏编辑器 反对搭建大屏 / 拓扑 / 组态场景。

开发编辑器的次要目是为了进步团队外部我的项目的交付效率,目前 两个编辑器都援用到团队的相干我的项目中。当然,编辑器目前也反对和其余公司的我的项目单干。上面是几个我的项目的示例图:

两头是一个三维场景,应用三维编辑器编辑而成,周边是一些大屏元素,应用大屏编辑器编辑。

和个别的大屏编辑器不同,咱们的大屏编辑器不仅反对大屏元素的排布,也反对分层拓扑图,架构图,交通图等,以及组态性能。基于 canvas + HTML5 元素共同开发,可能反对更多丰盛的性能和成果。比方上面的拓扑成果:

还有轨道交通,地铁,交通线路图等:

当然还有组态图,比方上面的电力一次接线图等。

在编辑器的开发过程中,经验了很屡次的迭代,自我否定,而后是一直的成长。产品的开发过程中,咱们须要对产品的设计进行深刻的探讨。上面是一些感悟,和大家分享。本文次要是分享产品功能设计层面,而非软件开发架构。

易用性

易用性是一个很宽泛的概念。但其的确是一个产品设计中,最重要的一个因素,甚至能够说,易用性决定了产品的成败。产品是帮忙用户来达到某个工作的,因而首先产品须要有可用性,可用性就是通过产品某项性能,可能达到逾期的目标。比方用户须要能够配置一个 chart 图表,而在编辑器中有 chart 图表配置的性能。产品的可用性就是要确保该产品可能失常的实现工作,这是最根本的要求。

然而光有可用性是远远不够的,要想一个产品可能失去认可,肯定要在易用性下面下狠功夫。易用性是指最终给到用户应用的产品是否容易应用,通常状况下,易用性越差,用户越难以承受一款产品。

咱们的产品在易用性方面也是做了很多致力的。比方编辑器中提供了一些罕用的复制性能,是否不便使用者提高效率和精确度:

  • 各种对齐性能
  • 均匀散布
  • 等距排布
  • 网格,主动吸附
  • 批量复制
  • 拖拽复制
  • 组合与打散
  • 锁定
  • undo redo
  • 。。。

以上性能,都是为了可能让使用者在应用的过程中更加容易。

要做好易用性的工作,除了一些罕用的辅助性工作外,还须要听从一些其余的规定。比方

  • 直观性 有时候,会不盲目的实现很多暗藏的性能,比方应用快捷键或者右键菜单。应用快捷键或者右键菜单要审慎,比拟禁忌的是一个性能,只有快捷键能力调出,而没有直观的按钮。并且快捷键没法疾速查看,传递给用户的设计就是更为蹩脚的。当然快捷键在有直观传递的状况下,有时候是能够减少用户应用效率的。
  • 明确性,防止模糊性和歧义性 性能点的设计应该明确,不应该表白不清.
  • 简略性 每个性能点 应该设计的绝对简略,不应该把多个性能通过逻辑开关的形式整合在一起。

当然还有更多的易用性,前面波及到的在做介绍。

通用性

有时候在遇到一些需要的时候,咱们须要把具体的需要形象成更形象的需要;把特 殊的需要,进步成更加通用的需要。看似是把把简 单的需要复杂化了,但的确很有必要,因为其能够放弃软件自身不会变的越来越臃肿。

比方已经有这样的一个组件需要:

相似于进度条的需要。要说实现这个组件自身,难度并不大,应用 canvas 的绘制,反复绘制很多矩形,通过数据来定义矩形反复的数量,即可达到。

然而,其实能够从两头提前一个更加通用的规定,就是某个对象的反复绘制。在此,咱们把具体的矩形 形象成为更为形象的某个对象。而某个对象如何定义呢?其实很简略,能够把咱们现有的图元库中的所有图元作为“某个对象”,那么最终的需要就变成:

  • 对于图元库中的所有图元,能够进行反复绘制,反复的次数通过数据来定义。

于是咱们最终的定义了个 RepeatNode 的对象(反复节点的意思),RepeatNode 能够指定一个图元进行反复,如下图所示:

该节点对象,能够指定要反复的对象(后面红色框的矩形对象就是),能够指定反复此处,间距等等属性。当如反复次数还能够通过动态数据来驱动,以此达到动静的成果。

有了 repeatnode,咱们除了实现原始的需要成果外,还能够轻松的实现其余相似的成果,比方:

后续还有个相似 HTML5 中 tab 标签的性能需要,要求可能点击按钮进行页面切换:

编辑器后期是应用事件派发的机制来实现的,比方下面,点击保障措施,就脚本派发一个事件,而后相干的元素展现进去,而不相干的元素暗藏起来。

通过派发事件和承受事件来展现和暗藏内容,成果是能够的,问题在于易用性并不好,通过编辑器实现起来简单,个别的施行人员用起来难度大。因而,能够思考形象出一个 TabNode,有技术人员提出疑难是,tabNode 的题目局部并不固定,可能各种变动。然而实际上,咱们能够不依照一般的 Tab 的思路来做。TabNode 只是要给一个 Tab 容器,该容器能够配置指定哪些元素作为 tab 标签的题目(这个和后面的 RepeatNode 相似),这样就解决了 TabNode 的题目可能各种变动的问题。

实际上,还是能够复用本来的事件派发的机制来实现 TabNode 的切换。

灵活性和易用性

灵活性和易用性有时候是互相矛盾的。比方后面说的 TabNode 的问题,用事件派发的脚本机制,必定是最灵便的,因为脚本的机制能够实现简直所有的需要变动,然而易用性却不好了。

既要灵活性,也有易用性。应该如何做呢?我比拟认同的就是多层次的设计思路,最底层的是比拟灵便的实现形式;在灵便的底层的根底上,咱们在进一步的封装,把罕用的性能和元素封装得更加易用。

比方后面 TabNode 就是这个思路。

还有编辑器反对 echart 图表和 HtmlNode 性能。echart 的配置变幻无穷,如果把所有得配置项都抽出来,做成可视化得模式,工作量微小,因而编辑间接提供了 json 配置,就很灵便,然而易用性差;而 HtmlNode 相似于 Vue 的模板机制,也是须要比拟业余开发人员能力解决。

echart 图表和 HtmlNode 都是灵活性很好得元素,然而易用性差。那么怎么解决呢?咱们得思路是提供一个模板性能,把罕用的我的项目下面做得好得配置,做成模板,放到模板库外面。后续非专业人员,能够从模板库中去抉择,而不是手动去配置 json 或者 html 标签。

可扩展性

编辑器中最常见得变动就是图元得变动,因而咱们提供了图元编辑器。通过图元编辑器能够编辑出各种须要的图元,同时也反对 SVG 图像的导入解决等,比方如下图我的项目中用到的图元就是:

上述的图元都有动静的成果,比方第一个三段式的,每段长度是能够变动的。第二个数量可变,第三个数量和高度可变。

下面只是举例说明,理论的编辑的图元十分多,也很灵便:

同时,还提供了插件机制,能够适当的扩大本来的性能,便于实现我的项目的一些非凡的需要。

总结

下面是一些设计与思考,次要是基于拓扑 / 大屏编辑器的思考。为了有更好的产品,咱们始终在致力的架构,设计与思考。

无关三维编辑器,有很多相似的设计理念,当前又机会再说。如果大家有好的想法,能够邮件或者微信作者,一起探讨:
Email: terry.tan@servasoft.com, 微信:541002349。

正文完
 0