从一个 UI BUG 想起

我们把界面上的各种“超出边界”、“挤在一起”、“互相挡住”等等问题,就叫 UI BUG 吧。前两天就看到了某应用的这样一个 UI BUG, 让我想到了一些东西。

1

这个用户的昵称,嗯,比较个性化一些 -_-|||,显然不太常见,以至于把他比较高的“顶”数都给挤出了边界。

而我们在或多或少的设计生涯里,或许都遇到过下面这样的尴尬:

2

设计稿是左边,测试或上线时候一看,成了右边。第一个通知卡片长的吓人,第二个因为姓氏太长被系统折行(浅灰色显示了不折行的效果,右边的 padding 不够了)。

PS: 我不是鄙视 Google 的 Material Design 模板,只是顺手拿这个改一下。

这个问题的根源就在于:设计前没有整理数据结构

我们所谓的数据结构

我们以一个简单的 Todo 应用为例,需要登录的那种。这个应用可以登录,然后可以增删事项,添加事项后,可以修改是否完成。事项可以是富文本,可以添加附件和设置提醒。这里面涉及哪些数据呢(我们仅考虑前端可能用到的)?

1、用户

属性 类型 限制 是否必须 备注
ID int 0 ~ ∞ yes 目前预测不会超过100W用户,也就是最多7位数字
用户名 string(英文,数字) 4 ~ 15 yes
密码 string(英文,数字,特殊符号) 6 ~ 16 yes
昵称 string(汉字,英文,数字,特殊符号,表情) 4 ~ 18 yes
邮箱 string 邮箱的限制 yes
是否验证 bool yes 是否验证邮箱
注册时间 Time YY-MM-DD HH:MM:SS yes

2、事项

属性 类型 限制 是否必须 备注
ID int 0 ~ ∞ yes
创建时间 Time YY-MM-DD HH:MM:SS yes
是否提醒 bool yes
提醒时间 Time YY-MM-DD HH:MM:SS no 如果是否提醒是false的话,就没有这一数据
标题 string 1 ~ 20 yes
内容 富文本(允许图片) 大约1 ~ 240 yes
附件 文件 限制格式jpg,png,rar
限制大小:<1MB
no 需要显示文件名和格式
是否完成 bool yes

大体上我们前端界面需要的就是这些了。嗯,看起来有点像开发脑海里“类”的精简版 + 人性版,只有属性。

怎么用这些整理结果

对于一个“类”,很简单的可以想到:

  1. 增:从哪里来?(系统生成?-> 怎么生成?;用户添加?->怎么添加?)什么时候会来?
  2. 删:可以删吗?谁可以?怎么删?什么时候删?
  3. 改:可以改吗?谁可以?怎么改?什么时候改?
  4. 查(展示):筛选条件是什么?谁可以查什么?字段可以截断吗?

让我们用一些假设的例子来看看字符串类型的设计思路:

先来看看昵称:它属于“用户”。昵称是用户在注册的时候通过表单添加的。不可以删,但是用户本人可以通过修改个人资料的表单在任意时刻修改。一般来说,我们认为截断用户的昵称不太礼貌和友好,所以必须考虑最长的情况。好在我们发现,需要限制昵称的地方只有个人资料页,单独给一行显示18个字节完全没有问题。

但是邮箱的问题就没这么简单了。理论上,邮箱地址@符号前面的 local part 可以有 64 个字符,@ 后面的 domain part 可以有 255 个字符,所以加起来一共有:320个字符。假设我们有下面这样一个抽屉导航,需要显示用户邮箱:

3

来自 Google Material Design 官方模板

我们可以看出这个位置显然显示不了 320 个字符。但是考虑到决大部分邮件运营商都会对 local part 部分有限制,比如 163 邮箱,最多 18, Gmail 最多30, domain part 部分,也少见那么长的域名。那我们就暂且留这一行吧(当然,除了两边的 padding 和向下三角的边距),可是万一真的有人邮箱那么长怎么办?这时候我们就要思考,这里显示邮箱的目的是什么?图上很明显:用于切换用户(为了想表达我想说的内容,就再给我们的 todo 加个切换用户的功能吧)。那么有这么多的字符,足以区别不同的邮箱了,所以,实在太长的,就在后面...吧。

不得不说在这个例子里,确实有可能存在即使显示了这么多字符还区分不开的极端情况。这时候问题就来了:

  1. 对于我们来说,这样的用户多吗?(同时拥有两个以上超长邮箱,且前几十个字符完全相同,并且都注册我们的APP,切换着用)
  2. 少的话,比例是多少(可能需要调查,嗯,或者拍脑袋)?我们要放弃他们吗(决策者)?如果我们不放弃,就不得不改变这个切换用户的控件。设计开发新控件的成本是多少(时间、人力、测试等等)?不放弃他们的话,换来了什么?(口碑?实实在在的利益,比如会员费?)这些利益和成本相比,谁更大呢?那么,我们还是不放弃他们吗?还有个简单而粗暴的方法,还是这个控件,直接折行,让它变大,把全部的邮箱地址都显示出来。对于这一小部分用户来说,牺牲一点用户体验,但是凑合还能用,这样可以吗?(实际上和前端开发时,浏览器兼容的优雅降级和渐进增强相似,只不过我们考虑的是主流用户和非主流用户。)
  3. (假设)多的话(虽然这个例子中,明显不多),如果我们不放弃,可能带来用户数量的大幅提升,为我们带来更多广告收入,为我们拉给更多投资,嗯,还可能是更多的会员费用,不放弃就必然要开发个新控件,老问题又来了:不放弃带来的好处和成本,谁更高?放弃的话,可能会被一大波人谩骂,节省的成本和失去的利益(经济利益,口碑等),谁更大?

布尔类型和时间类型其实很有发挥空间

如果不进行数据整理的话,只看产品的原型也好,文档也好,很容易感觉这个字段是 “是 / 否”,或者 “true / false” 。然而,布尔是两个状态,不是 truefalse 这两个单词,所以直接显示个 “”, “ ”就比较简单而平凡了。如果想在设计里出点亮点,布尔显然是个可以突破的地方。

比如:

  • 头像是积极色彩和消极色彩
  • 文本的积极色彩和消极色彩
  • 项目(列表项,卡片)的消极配色,积极配色
  • 不同的动画形式
  • 不同的位置和形态
  • 不同的控件设置。不如在消极状态下,多出控件和描述,引导用户改变成积极状态等等。

时间类型也一样,它的本质是时间,不是 “2016-10-29 12:23:23” 这几个“字”。所以怎么表达时间呢?展示方式就多了,不再赘述。

总结

所以,在动手设计界面之前,要先总结数据。主要包括数据模型、字段类型、限制等。

一、它可以帮助你提前考虑各种极端情况,边界条件,做好预防。

二、防止设计过程中遗忘某些数据的处理。

三、有助于发挥创意。

四、有助于早日迈入信息架构设计的大门。(以后有空再说这个。)