White Rose设计与架构的想法分享

  • White Rose设计与架构的想法分享已关闭评论
  • 18 次浏览
  • A+
所属分类:Web前端
摘要

在七牛云校园黑客马拉松中,一款设计优秀、逻辑清晰的白板作品脱颖而出,获得第二名的好成绩,这就是来自郑州大学Since团队的White Rose白板,以下是他们的设计和架构分享。

在七牛云校园黑客马拉松中,一款设计优秀、逻辑清晰的白板作品脱颖而出,获得第二名的好成绩,这就是来自郑州大学Since团队的White Rose白板,以下是他们的设计和架构分享。

White Rose设计与架构的想法分享

一、前言

White Rose是参加七牛云hackathon比赛的作品,赛题的主要内容是开发一个「多人协作白板」,旨在鼓励在校大学生用编程创造价值。

赛题核心需求包含三个:

  1. 多人可以加入一个房间,同时进行绘画(尽可能多的形状随意绘制)
  2. 所有操作可以撤销和恢复
  3. 可以创建不同页面,支持只读模式(页面锁定后,所有人不可编辑)

二、产品设计

(1)愿景

基于hackathon的比赛要求,我调研了一些白板软件,这些软件不乏有一些「操作困难」「功能繁杂」等问题。所以,我定下一个产品愿景:「做一款从两岁到八十岁都能用的白板」

(2)追求

基于以上愿景我也设立了几条产品追求:「功能一键即达」「界面极致简洁」「内容高度自由」

作为乔布斯的粉丝,印象中乔布斯当年设计iphone时,要求工程师所有的功能操作不能超过3步,而对于白板一个单独的软件来说「进入」一步,「功能选择」一步,所以留给我的只有一步了。

(3)界面

为了让界面足够简洁,我将所有「扩展」功能全部放到了「上下左右」四个隐藏菜单里,从而让整个页面除了四个「必要数据」外,就只有一块“纯粹的白板”。

  • 对于两岁的小朋友来说进入就可以直接随意的涂鸦。
  • 对于八十岁老教授来说,这用起来跟教室的黑板一样。

下面分别是整体的界面效果。

White Rose设计与架构的想法分享

无论多大的屏幕,什么形状的屏幕,都会无失真的自动扩张,因为它本质是一个高宽100%的矢量图。

因为不同屏幕的大小限制,这样的设计可能回导致小屏幕的人看到的内容没有大屏幕的「完整」。

对于有些软件的处理可能会有利用「拖拽页面」功能来确保每个人所能接收到的数据一致,这将意味着,用户的每次触屏操作,软件都要区分用户是想「拖拽页面」还是想「绘画」,而用户也需要在两个功能间频繁切换。

而我的理解:“白板”本质是一个大号的草稿纸,当我们给一群人讲一些内容的时候,「演讲者」可能随手会在白板上写下他讲的关键词「power point」,一般作为「演讲者」会写在一个大家都能看到的地方,这对「演讲者」不会增加太大负担,而对于「听众」一边听内容,还要一边还要拖拽页面去确认演讲者写在那里,这个负担更大。

回想一下我们在教室上课的时候,老师会尽量把内容写在中间靠上的位置,而不是底部,因为前排同学会挡到内容。

所以我摒弃了「拖拽页面」的功能。

当然「缩放」也不乏是另外一种解决方案,但是也会徒增操作者(缩放)的使用负担,并且还会引入另外一个问题就是「失真」。

关于颜色:

其实在选择白板的底色的时候,可能就是一个白色,但是其实白色也是五彩斑斓的,该用什么呢?

我想到一个词「青红皂白」,索性我就用「青红」和「皂白」调制了一个对眼睛更加柔和的 「青红皂白色」作为白板的底色。

(4)拓展功能

设计好了整个页面,接下来就是功能设计,我在设计界面的时候,预留了4个隐藏菜单栏来放拓展白板功能,为了让所有功能「一键即达」,并且更简单的使用,我采用了icon + 文字描述的方式,让用户更易理解。

整体展开如下图所示:

White Rose设计与架构的想法分享

为什么是这样的摆放呢?

1、功能分类

根据赛题要求的功能,我将所有功能分为了四类。

  1. 形状拓展:用户可以选择圆、长方形、菱形、三角形、直线等形状。
  2. 颜色拓展:用户可以修改所有形状轨迹的颜色。
  3. 大小拓展:图形的大小和线条的粗细可以切换。
  4. 页面拓展:页面可以添加删除和切换,另外页面的内容支持撤销和恢复。

2、何处安放

我在想这个问题的时候,想象了在一张纸上作画的场景。

  • 一般我们习惯在桌子右侧放上各式各样的水彩笔,方便我们切换颜色,所以我将「颜色拓展」放在了右侧。
  • 我们习惯在桌子的上方和左侧放尺子、圆规之类的用来拓展图形和丰富绘画形状的工具,所以我将「形状拓展」「大小拓展」放在了左侧和上侧。
  • 当我们要做翻书、撕页等页面操作时,一般会从右下角开始,所以我将所有的「页面拓展」放置到了下侧,同时右下角有一个对应页面的页码,也因为大多数书的页码在这个位置。

(5)自由布局

上面讲到,我根据我个人的想法将各个功能进行了分类,并且按照我所理解的「更方便的布局」进行了排放,但在实际操作过程可能并不符合一些其他用户的操作习惯,比如:左撇子。

因此我将每个功能做了集成,并且可以随意的改变不同功能所在的位置,也就是所有的功能布局,用户可以根据自己的想法进行布局上的DIY。

三、架构设计

因为本次开发的周期只有21天,另外工作日的白天还需要上班,非常紧迫。所以需要采用非常简单且高效的架构设计,当然也需要考虑一些后续扩展的可能。

(1)整体架构

为了更好的「持续集成」我们采用自建的gitlab管理代理,并使用gitlab-runner完成自动化部署。

整体架构图如下图所示:

White Rose设计与架构的想法分享

(2)交互模型

对于后端来说,为了更加高效的沟通,我将整个交互模型,定义为一个群聊,群内所有人的消息统一发给服务端,然后服务端再统一转发给其他人。

后端只需要确认三点:1.谁发的消息。2.发到那个群里的。3.消息类型。

整体交互结构如下:

{ "type": 1234,  // 操作类型 "fromId": 123, // 发送人id "roomId": 1234,// 所在房间 "time": 152150025421564 //时间戳,前端不需要发送 "data": {} // 操作内容 }  

这样做的两个好处:

  1. 所有消息有一个统一的时序(即服务端时间)
  2. 后端完全无需关注「data」的具体内容。只根据type区分「接收」「分发」「存储」操作。

(3)data模型

data模型主要是前端所发送的和接收到的message里的data结构。

data里面该放什么?我将用户的所有操作定义为option,将用户的所有option放到data里面完成用户操作的转发。option的结构如下:

interface Op { type: number // 页面操作or图形操作 graph?: { op: number // 添加、旋转、缩放、平移 type?: string // 图形类别 key?: string // 图形所对应的key page?: number // 图形所对应的页面 content?: any // 图形内容 } page?: { op: number //添加、删除、切换页面 key?: number // 页面对应的key content?: any // 页面对应的内容 } }  

这样的每个option,我们都会存放到操作栈里面,结合另外一个缓存栈,即可实现撤销和恢复。

(4)多人协同

对于多人的操作,其实是多个人对多个图形的操作,人与当前所操作的图形是一一对应的。

所以我通过一个令牌集的概念,来存放「所有的用户id」,以及每个用户当前「所操作的图形id」,这样就确定下来个每个用户正在操作什么。

不同用户的操作通过以下流程完成:

  1. 操作者设定当前所操作图形的id,并更新令牌集。
  2. 接收者同步更新令牌集。
  3. 操作者发送操作数据(option)。
  4. 接收者根据用户信息从令牌集中确定所操作的图形,再根据option修改具体的svg数据。

整体白板从产品的设计到架构的设计就结束了。

欢迎体验:http://whiterose.cf.since88.cn

前端代码:https://lab.since88.cn/whiterose/frontend

后端代码:https://lab.since88.cn/whiteros