App设计中Toast和Alert的那点事儿

很多人在设计App时纠结于使用Toast还是Alert（Android的版本为Dialog），这些其实是很小的事，很多人都不太在意，但是从优化用户体验的角度还是值得一探究竟的，本文旨在让大家对其有一个全面的了解，更深刻的理解其使用方法。

什么是Toast？

Toast,实在屏幕底部或中部显示1到3秒的提示信息，如下

它的信息传递是单向的，不会中断用户的操作，可以保证用户操作的流畅性，但有可能用户没有看清里面的内容，错过重要信息，或者不知道刚才发生了什么。

什么是Alert？

iOS叫Alert， Android叫Dialog，它会弹出一个对话框，同时遮住当前页面，用户必须点击对话框中的按钮，完成相应的动作才能回到原来的页面继续操作。

可见Alert会降低用户使用的流畅度，那么是不是我们不要用Alert了呢？显然不是，Alert在提示一些重要信息，让用户选择执行某一个动作时，还是很有用的，我们稍后再说。

总的设计原则

从上述的介绍，我们不难看出，在设计App时我们应该尽量使用Toast以保证用户体验的流畅性，除非有些必要信息需要用户确认，或选择执行某些动作时才退而求其次，选择使用Alert。

使用场景

关于Toast

主要用于事后告知用户执行某动作的结果，一般该动作是可重复执行，且其操作至少可分为有成功和异常两类以上。

什么是可重复执行的操作，如一个“保存”按钮，保存失败，还可以继续点击“保存”按钮。这样即使用户第一次没有看清Toast，可以多点几下“保存”按钮，以便看清究竟发生了什么。

为什么操作还要至少有异常情况，如果用户操作的这个动作每次成功都弹出Toast不行吗？

可以，但不够完美。想想看，如果你每次都执行一个100%成功的动作，而且每次都弹相同的Toast，你不觉得你的App被Toast污染了吗？他已经是一个没有任何信息量的Toast了。他同时也违背了App的简洁设计原则。这种情况我的建议就是不弹Toast，比如App的语言切换，缓存清楚等，因为即使你不弹任何信息，用户也可清楚的知道动作执行后的结果。

一般在做API请求异常时会弹Toast，告知用户发生了什么，成功的情况下建议不弹，除非成功后页面没有任何相应。不过这种设计显然是有问题的，一般用户在API成功后，看到页面有变化，或返回原始页面，或显示成功的最新结果。

Toast使用原则：

1. 文言提示尽量简短，可省略动作上下文，如主语，长度控制在一行以内；有时我们为了说清楚，故意将提示文言写的很长，而用户只有3秒钟查看文言，文言太长导致用户还没有读完就已经消失；其实文言很短也能说清楚，省略上下文，也能表达很清楚。如“删除失败”，不用再具体说“***删除失败”，因为你很清楚删除的对象是谁。
2. 不要滥用Toast，不要每一个动作的相应都要有Toast，对于一些页面100%成功，或有已经有页面相应动作的结果的，可不用Toast；如果动作失败，页面有没有任何变化，则必须弹出Toast告知异常信息。
3. 如果确实提示文言较长，用户无法在3秒内读完，则应使用Alert提示。

关于Alert

主要用于事前，使用方式包括：

1. 两个按钮及以上的Alert，提示用户，并让用户选择执行某动作；
2. 提示重要信息，只有一个按钮“确定”。如果单纯提示重要信息，也可用于事后，告知执行的结果。

第一种方式，应该很常见于一些不可逆的操作，如删除操作，一般都会弹出让用户选择删除还是取消；还有一些情景让用户打开某些权限，如访问位置信息等；类似这样的选项提示用很多，都可以使用Alert来实现。

第二种方式，主要用于提示重要信息，或者不想让用户错过提示信息。比如文言太长，如果使用Toast提示，用户无法3秒内读完，这样可以弹出一个带有“确定”按钮的提示，用户在读完后点击确定关闭Alert。

Alert使用原则：

1. 不要过度使用Alert，不要重复提醒相同的Alert，如弹出Alert要求访问位置服务，如果用户选择取消，说明用户不想打开位置服务，App就不应该每次都弹出这个Alert骚扰用户，很有可能用户会因为你的过度骚扰而卸载该App。
2. 不要连续弹出多个Alert，用户在选择了一个Alert按钮后，又弹出一个Alert，这种情况会大大降低用户体验，我们应该讲多个Alert合并成一个，相应的按钮会增加成多个，我们可以使用iOS的AlertController的style为UIAlertControllerStyleActionSheet如下图:

​​​​​​​

总之，在选用Alert和Toast时应该遵循上述的大原则，而具体应用场景和使用方法还要结合App自身特点和具体情况得出自己的结论，上述场景和原则不是绝对的。

以上都是本生的经验之谈，难免有疏漏之处，还请大家多多交流，不吝赐教。

转载于:https://my.oschina.net/u/726807/blog/1807478