Optimistic UI是什么?
Optimistic UI是Meteor提出的一种前端界面快速响应用户交互的概念, 先放官方解释:
Your app should be able to respond to user inputs faster than it takes to make a whole roundtrip to the server — we call this Optimistic UI updating.
![](https://img.haomeiwen.com/i144922/3dbc90b8d7d7a44b.png)
一般来说,户输入信息,信息要从客户端先到服务器,一系列计算完成以后,才会从服务器返回到客户端,在屏幕上做出更新。
那么问题来了:一是用户感觉滞后,操作了却不能立刻看到反馈;二是有时候界面更新结果和用户输入不一致。还有,由于移动网络 (cellular networks) 不稳定,有时候从服务器端返回结果的时间要花一秒或更多的时间。可见,这种前端界面响应策略是不利于交互体验的。
于是,Optimistic UI出现了。这个名字很有意思,目前没有官方中文名称,在知乎上有人译成积极的界面更新,我觉得还不错。为何说它积极呢?Optmistic UI即刻响应用户操作,不再等着信息从客户端到服务器跑一个来回再更新界面。对比下面两个例子:
![](https://img.haomeiwen.com/i144922/af692e7f039f718f.gif)
![](https://img.haomeiwen.com/i144922/58074ec15609d818.gif)
同样的使用情景,用户输入文字-点击发送,图一是先出现滚轮,再看到对话信息,让用户陷入被动等待(passive waiting)。图二则是用户一操作,界面就做出了响应,服务器自己在后面完成任务。
简而言之,Optimistic UI就是玩儿了个花样,在服务器端确认更新完成前就主动在界面上做出更新。当然,这个概念提出也是基于一个乐观假设:对于97%-99%的用户操作,服务器都可以成功完成确认更新。
我们为什么需要Optimistic UI?
Optimistic UI对于用户满意度有着重大影响:
更快: 用户每一次操作都能即刻看到结果,整个app操作感更敏捷。服务器端完成上一任务的时候,用户就可以进行下一任务了。
更流畅:有了Optmistic UI,用户不用再去看霸占整个屏幕的进度条或其他无关信息,这些都让操作体验更简洁流畅。
还有,视觉设计师也可以少调几张图了~
现实应用
Optimistic UI经常应用于即时通信工具(messenger) 或者社交应用。iOs还有macOS都使用了这个概念:
![](https://img.haomeiwen.com/i144922/2dcfef37b027c61a.gif)
![](https://img.haomeiwen.com/i144922/5e4e0c476e32d990.gif)
除此以外,Optimistic UI还有其他的使用场景,我们来看看Amazon旗下有声书Audible 的ios 应用界面:哪怕只有一小部分书下载完成,你都可以点击“Ready to play"来播放了。这个的设计初衷就是希望app在你听书的时候把剩下的下载完成。
![](https://img.haomeiwen.com/i144922/5c2df500633b726f.png)
再看项目协作工具Trello,用户一拖拽卡片,界面就做出响应,不会等到服务器端确认更新完成才在前端界面更改卡片的位置。
![](https://img.haomeiwen.com/i144922/3ed5398b1307968d.gif)
进度显示
有时候,直接在界面显示最终状态会让用户感到困惑,你还是要给他们一些温和的进度提示。这对操作错误及之后的差错处理都尤为重要。
操作时长与进度提示的明显度成正比。像点赞这种短时操作就不需要进度提示,但是对上传照片这种要花点时间的,就一定要显示进度了。
有的app 利用Optimistic UI针对用户的操作即刻做出界面更新,同事在更新的部分旁边显示进度提示:
![](https://img.haomeiwen.com/i144922/58162d7e047570e8.png)
Facebook Messenger在每条发送了的信息旁边放一个迷你状态icon:
![](https://img.haomeiwen.com/i144922/9b1ad76cb6c16c74.png)
iOS的Message在窗口顶部设置进度条,上传照片时候会特别明显:
![](https://img.haomeiwen.com/i144922/7e10fd611a9b21f2.png)
关于差错处理
那要是出错了咋办?
设计错误信息 (Error Message)重在两点:
明显 (Salience): 信息必须可见,用户不能错过。
诱发 (Causality): 用户要一看就明白是哪一步操作导致了这个错误。对用户来说,这个界面一旦更新,那操作就结束了。
差错处理是Optimistic UI的最大挑战.
最简单的办法当然就是Good Old bLocking Error Message (GOLEM),姑且翻译为传统的弹出阻断式报错窗口:
![](https://img.haomeiwen.com/i144922/12ef45b4698ef666.gif)
这种报错设计符合第一点,够明确,没人会错过这么霸道的居中报错窗,更何况它还野蛮地阻断了之后所有的交互。
但是在第二点上,这个设计输了。这种错误信息常常随意弹出(而且还老写点吓人的话),没法让用户把错误信息和之前的操作步骤联系起来。
另一种比较受欢迎的设计方案就是在我们发送失败的信息旁边放个按钮或者icon:
![](https://img.haomeiwen.com/i144922/c4bdfedabf72b2ec.png)
这种方案很好的让用户意识到是什么操作诱发了错误,但是并没有那么明显。如果用户在不同屏幕浏览,或者滑动屏幕速度快了点儿,就很容易错过这个错误信息。
为了让报错更可见,iOS上的Message把错误信息显示到了app icon上,这样就算用户退出app也不会错过消息了。
![](https://img.haomeiwen.com/i144922/cd3d40a196f3bbc4.png)
总结
Optimistic UI让你的app操作更流畅、直接,为用户带来愉悦的使用体验。
Optimistic UI在你的服务器端特别慢的时候尤其有用。
Optimistic UI的使用是有前提的。如果你的服务器超级不稳定,切忌滥用Optimistic UI。它可能会蹦出一串烦人的阻断式报错窗口,也可能在用户错过错误信息的情况下造成数据丢失。
要记得这些原则,把Optimistic UI用到靠谱儿的地方。
文章第一部分整理自Optimistic UI with Meteor
案例编译自Optimistic UI in under 1000 Words
感谢我的老师Spell姐姐的推荐。
网友评论