从今天起，我们开始介绍iOS和Android设计规范中的各种控件。掌握它们，能有效地帮你你设计出一个高质量的交互稿。今天我们要介绍的是提示框，英文是toast。
交互设计师在设计交互稿的时候，时常需要一些反馈手段，以提示用户操作的结果。Toast是其中很常用的一种：它简单、小巧、对用户的打扰小。然而现在很多应用中，存在对于toast过度使用的情况，并且常常出现Android样式的toast出现在iOS应用中（反之亦然）的情形。在研究了iOS和Android的规范之后，笔者惊人地发现iOS中其实是没有toast这种部件的。到底我们在设计的时候应该处理这种部件呢？且看下面的分解。
Material Design Guidelines
Google的Material Design规范中，是把toast和snackbars归为一类的。下面是规范中对snackbars的定义：
Snackbars包含一行与进行的操作直接相关的文案（文案前不可有icon）。它可以包含一个操作。
Snackbar示例
规范中对toast的定义：
Toast优先适用于系统提示。它也在屏幕下方出现，但是不能被划出屏幕外（而被清除）。
Toast示例
行为：Snackbars/toast从屏幕底部向上出现，经过设定的秒数后消失，或者用户进行了别的操作它们也会消失。
Snackbar的出现和消失
简洁：提示的文案要简短，包含的操作按钮最多只有一个，或者没有。（注意，snackbar不能包含使其消失的“取消”按钮！）
左边是正确的，右边是错误的（因为多了“取消”按钮）
不可重叠：snackbar与floating action button不能重叠
一次只出现一个：如果出现了一个snackbar，这时候用户进行了操作，需要出现另一个，则第一个snackbar从上向下退出，之后第二个snackbar从下向上出现。
反例：不能同时出现两个snackbars
以上是Google Material Design中对于snackbars和toast的定义。
iOS Human Interface Guidelines
对于iOS系统，在研究了iOS的规范之后，笔者有个惊人的发现：严格地说，iOS规范中没有Toast这个部件。笔者找遍了iOS的人机交互设计规范，都没有找到对于Toast这种部件的介绍，与之最为接近的，是Alert（警告框）。但警告框的使用场景与Toast不同，之后将另开一篇文章介绍。在iOS系统中，与toast对应的是“HUD”（透明指示层）。
iOS系统中的HUD弹窗
知识运用
请回答一下两个问题，这将帮你更好理解这周的主题。
1. 既然iOS的设计规范不鼓励使用toast，那么在日常的设计中，toast应该在什么情况下使用？
2. 请查看你手机里的APP，尝试找到一个toast使用错误的地方，和使用正确的地方。这将帮你理解如何正确地使用toast。
