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

news2024/11/23 15:52:15

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

一、前言

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

赛题核心需求包含三个：

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

二、产品设计

（1）愿景

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

（2）追求

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

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

（3）界面

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

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

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

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

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

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

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

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

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

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

关于颜色：

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

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

（4）拓展功能

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

整体展开如下图所示：

为什么是这样的摆放呢？

1、功能分类

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

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

2、何处安放

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

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

（5）自由布局

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

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

三、架构设计

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

（1）整体架构

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

整体架构图如下图所示：

（2）交互模型

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

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

整体交互结构如下：

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

这样做的两个好处：

所有消息有一个统一的时序（即服务端时间）
后端完全无需关注「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」，这样就确定下来个每个用户正在操作什么。

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