从toast说起 闲聊app交互设计（雾

缘起：
在app的登录框，应该以何种方式提醒用户他们的帐号密码输入错误呢？

我的答案：
直接使用toast 但是需要稍微设置toast的出现时长。

这看似是一个简单的问题以及相当简单的回答，但是背后也能引申出不少关于app交互设计的细节以及思考。

之所以使用toast,我出于以下几个原因：
通用范式：
许多主流的app都采用了这种方式提醒用户，如twitter,手机qq等。既然那么多主流的app都采用这种方式，想必用户们早已习惯这种提醒方式。常用的设计并不一定是好的设计，因为他们可能因为其他强大而共通的推动力而成为通行凡是。但是在敏捷式迭代开发中优先遵循通用范式，至少能保证用户能从过往经验中提取出操作方式顺利使用产品。

如果用户以及情景等情况发生改变那么就可能要另辟蹊径，那么可能就需要谨慎的收集各种信息并且进行一定的测试——问题在于这个控件真的那么独特吗？这个情景/业务本身有如此的独特性吗？

平台规范：
在ios/android的人机交互指南业已指明使用这种控件对用户的操作进行提示。这意味着这些控件或多或少能得到开发者的认可并且是行业内顶级的专家设计的成果。平台规范与控件未必能比业务或是设计上的品牌统一性重要，然而仍然有必要对他们保持尊重。苹果设计规范内早已说明品牌标识等不应该以粗暴的方式展现，平台上的软件虽然有其特色但是最好都能与原生规范保持一定的一致性方便用户辨识与学习。
在我看来与所在平台的设计规范保持一定的一致性除了方便用户的学习以及开发等显性原因等，还有着更为深远的考虑。平台规范本身就是一种针对平台使用场景提出的通用指引。控件本身的简单或许并不是问题，最大的问题可能恰恰是我们搞不懂移动的情景以及特性仅仅因为业务与推广需求简单的往产品上乱堆东西。

节约开发资源：
原生控件，开发只需要定义字符串以及出现时长，相对于其他提醒方式——如在界面某处出现一串提示字符，更为简单方便因为他们多少都要对UI进行绘制。这样就会回到一个初始问题——这个控件的重要性如何以及相对于业务和其他控件的开发时间安排上投入资源的必要性。只有想明白这些问题，一个交互设计才顺畅的与开发与产品一起合作而不是执着于细枝末节。更何况交互设计也与工程开发一样存在重点，在有限的条件下过度纠结某些不那么重要的动效与提示可能会错过真正需要仔细设计下功夫的环节。

移动终端的特性：
空间：
智能手机上采用虚拟键盘进行输入，键盘本身会遮挡一部分的空间。如果绘制UI对用户进行提示，那么很可能因为键盘的遮罩导致这种提示本身并不可见（特别是在考虑android终端上形形色色的屏幕尺寸以及分辨率后。

情景：
的确，使用toast提示可能会对用户带来一定的阻断以及干扰。但是别忘了在移动终端上用户的注意力更不集中，他们身处的情景更加复杂，toast带来的操作阻断本身或许才是充分的提醒。况且toast相对于UI的变化而言是一种更为吸引人注意力的动画，其动效的特性能让它充分发挥提醒这一作用。

反思——这是回头路吗？
尤记得在几万年以前...桌面端设计中很流行使用弹窗的方式提醒用户的操作失误...这种方式因为阻断了用户的操作而后来被逐渐抛弃与替代。听起来如今的toast就是走了回头路，然而两者还是有着不少区别。
桌面端的弹框通常需要用户手动关闭而且他们还会改变用户的视线集中点。toast会自动消失而因为手机屏幕的大小原因，用户视线从输入框转移到toast的距离小于桌面端。其次桌面端上用户所在的情景更为单一一些，而移动端上的用户注意力更为分散因此toast本身的动画效果以及临时阻断操作本身都能帮助用户集中注意力。因此在这种条件下toast想对于不阻断的提醒可能更能帮助用户到达目标——完成指定操作。

余论：
桌面端设计与移动端设计是如此不同，以至于过往看似粗暴的方式在移动端改头换面就成为了一种相对较好的设计。历史并非简单重复或是改变，辨析此时与彼时的场景比起简单而死板的遵循不要阻断用户等交互规范重要。