组件规范：反馈与通知（一）
反馈与通知类组件，主要作用是向用户传达操作结果或系统当前的状态。通常分类两个大类：模态与非模态。
模态弹窗带有半透明黑色遮罩，会“劫持”当前界面和任务流程，要求用户先处理完弹窗，才能继续进行原来的操作。非模态弹窗，则是在不打断主要任务的前提下，提供额外信息或操作入口，用户可以选择稍后处理甚至忽略。
非模态组件
Toast
在不打断用户当前操作流的情况下，提供临时的、轻量级的信息反馈
核心用途
1、操作成功的即时反馈
用户完成一个操作后，系统给予一个积极的确认，告诉用户操作已成功。例如：“保存成功”、“关联成功”、“已复制到剪贴板”
2、操作失败或异常的轻度警告
对于不那么严重、不阻塞流程的错误可以用Toast提示。例如：“加载失败，请稍后再试”、“请输入正确格式”。（⚠️ 用户必须处理的错误，应该用对话框）
3、轻量的系统状态通知
当系统后台发生了一些状态变化，或有一些不那么重要但用户可能需要知道的信息时使用。例如：“正在后台同步”
注意事项
1、不要用于传递严重错误或需要用户立即处理的信息。toast为非模态组件，容易被用忽略。此类场景下应使用模态类组件，强制用户处理；
2、不要在toast里放置操作项；
3、使用简洁的语句。toast驻留时间很短（2~4秒），不适合承载复杂的长本文；
4、避免同时弹出多个toast。如果用户短时间内触发了多个事件，应按队列顺序依次显示。
交互细节
出现/消失动效：淡入淡出，通常位于页面中心，也可见于页面顶部、底部，持续时间3s；
关闭方式：超时自动消失。
平台差异
iOS：非系统原生组件，需要开发者自定义或调用第三方库。iOS有个类似的组件：UIProgressHUD；
Android：系统原生组件，可直接调用。
补充：触发时机
1、与服务器/数据库交互后
当App向服务器发起一个请求，这个过程是异步的，需要等待服务器的响应，此时，toast就是将这个异步操作的结果反馈给用户。
2、纯本地操作后
不涉及网络请求，完全在设备本地完成，toast用来确认这个操作已经生效，常见：复制文本。
Snackbar
在屏幕底部出现，提供临时的、轻量级的信息。Snackbar相比于Toast最大的区别是：Snackbar可以包含一个操作项
核心用途
1、可撤销的操作确认
用户完成一个操作后，Snackbar弹出提示操作完成，并提供一个“撤销”按钮。通常用于破坏性的操作，例如：“已取消关注设备【撤销】 ”、“邮件已删除【撤销】”
2、提供相关快捷操作
为前序动作提供一个相关的快捷操作。例如：收藏视频后，提示“收藏成功【去看看】”、“已将歌曲添加至播放列表【查看】”
注意事项
1、不要用于传递严重错误或需要用户立即处理的信息。Snackbar为非模态组件，容易被用户忽略。此类场景下应使用模态类组件，强制用户处理；
2、不要在Snackbar里放置两个及以上的操作项；
3、Snackbar不宜长时间驻留，通常5s后自动消失；
4、不要同时弹出多个Snackbar。如果用户短时间内触发了多个事件，应按队列顺序依次显示；
5、状态文本与操作按钮应有明确区分，让用户知道一个是“信息”，一个是“操作”。
交互细节
出现/消失动效：从屏幕底部向上滑入，然后向下滑出；
关闭方式：1、超时自动消失；2、用户点击操作按钮后立即消失。
平台差异
iOS：非系统原生组件，需要开发者自定义或调用第三方库；
Android：系统原生组件，可直接调用。
NoticeBar 通知栏
嵌入屏幕顶部，用于传达持续性状态或重要信息的组件
核心用途
NoticeBar介于Snackbar（过于短暂）和Dialog（打断性强）之间。当一个信息足够重要，需要用户持续感知，但又没到必须立即处理的程度时，适合使用NoticeBar。
1、连接性与环境状态
常用于系统状态的通知，包含系统状态和解决方式。例如：“请检查你的网络设置 >”、“当前无法接收新消息通知【去设置】”
2、发布应用级的通知
当有影响整个应用或大部分功能的重要信息时。例如：“发现新版本，建议更新以体验最新功能【立即更新】”、“服务器正在维护，暂时无法使用”
3、提示账户相关的非阻塞性问题
例如：“您的会员将于3天后到期 【立即续费】”、“请完成身份验证以确保账户安全【去验证】”
4、营销场景下的广告或促销信息展示
在特定时期，向所有用户推广重要的活动或优惠。例如：“限时优惠，全场商品5折起”
注意事项
1、不适合用于展示临时的、轻量级的信息；
2、不要用于传递严重错误或需要用户立即处理的信息。NoticeBar为非模态组件，用户可忽略，此类场景下应使用模态类组件，强制用户处理；
3、避免多个NoticeBar堆叠。一个界面只显示一个NoticeBar，建立信息优先级，只展示最重要的那一个；
4、必须提供关闭按钮。若信息处理后能自动消失，需提供明确的操作入口，引导用户去处理；
交互细节
出现/消失动效：从顶部向下滑入，动画快速平滑。在用户关闭或处理后，再向上滑出或直接淡出；
位置：位于屏幕顶部、导航栏下方。目前常见两种布局方式：
- 推挤式：将下方的页面元素整体向下挤；
- 覆盖式：不影响页面元素布局，但会遮挡页内顶部区域，设计时需预留安全空间。
平台差异
iOS：非系统原生组件，在iOS平台实现完全依赖于自定义开发
Android：非系统原生组件，但有一个非常相似的的原生组件：Banner，因其容易营销型Banner（轮播图）混淆，实际使用中很少会提到。
Popover 气泡弹出框
一种临时性浮层视图，用于展示与当前对象相关的一组操作选项或信息
核心用途
1、收纳次要操作或更多功能
这是Popover在移动端的核心核心用途。受限于移动端有限的屏幕空间，我们可以使用Popover将一些非核心的功能收起来。在各大主流设计规范中，也根据不同用途赋予了这类Popover更具体的命名——Action Menu（动作菜单）、Overflow Menu（溢出菜单）、Dropdown Menu（下拉菜单）
2、提供上下文信息或解释
当一个功能或字段需要向用户提供补充说明时，可以设置“❓”图标，用户点击后弹出Popover展示更多信息：
注意事项
1、不要用于承载核心操作或导航。Popover只适合轻量、快速的交互；
2、不要用于需要用户明确感知的关键信息。Popover通常需要手势触发，较为隐藏，很多用户可能会忽略；
3、避免滥用。Popover更适合在桌面端使用，在移动端其通常应由Action Sheet替代，后者从屏幕底部滑出，更符合移动端操作习惯。
交互细节
触发方式：点击触发；
出现位置：应靠近触发的元素，智能判断位置，避免超出屏幕或被用户手指遮挡；
消失时机：点击触发——点击或滑动屏幕消失。
平台差异
iOS：常见于iPadOS中，在移动端通常会用action sheet代替，或开发者自定义创建；
Android：非系统原生组件，需要开发者自定义或调用第三方库。
Tooltip 提示
用户通过“长按”手势触发的小巧浮层，用于上下文解释和信息展示，是一种解释性、辅助性的组件
核心用途
1、为无标签的图标按钮提供说明
这是Tooltip在移动端最主要的用途。当界面为了简洁使用纯图标按钮时，Tooltip提供了必要的可访问性，告知用户这个图标的含义
2、显示被截断的本文
当文本因空间限制被截断时，可通过Tooltip显示完整文本内容
3、在数据图中显示精确值
长按图表中的数据点，弹出Tooltip显示其具体数值
特殊场景
为用户提供轻量的引导
这是一种Tooltip的变体。其触发机制是“主动推送 (Push)”，而不是由用户“主动拉取 (Pull)”，是一种主动的、非模态、瞬时性的弱引导，常用于：
a). 在表单中提供关键提示：在用户填写复杂表单时，适时地提示某个字段的填写规则或注意事项；
b). 引导用户发现隐藏或不明显的功能；
注意事项
1、尽量避免在移动端使用。Tooltip更适合桌面端的鼠标交互，非APP端设计的常规选项；
2、不要用于承载核心操作或导航。Tooltip只用于“解释”，而不是“操作”，需要放操作项，请使用Popover；
3、不要用于需要用户明确感知的关键信息。Tooltip需要“长按”触发，用户发现成本高，且很容易与其他长按功能冲突；
4、不要用于解释显而易见的图标。例如“垃圾桶”，这类常规图标如果加上Tooltip，会显得多此一举。
交互细节
触发手势：长按触发、自动触发；
出现位置：应靠近触发的元素，智能判断位置，避免超出屏幕或被用户手指遮挡；
消失时机：长按触发——抬起手指后消失；自动消失——超时自动消失。
平台差异
iOS：非系统原生组件，需要开发者自定义或调用第三方库；
Android：Material Design规范中定义了标准的 Tooltip。
Context Menu 上下文菜单
一种由“长按”手势触发的临时性视图，提供与用户当前选中对象直接相关的快捷操作指令。Context Menu原是桌面端的交互组件，由鼠标右键触发。而在移动端，“长按”手势被用来代替鼠标右键成为了 “上下文菜单触发器”
核心用途
1、对列表项进行快捷操作
一个列表的各项往往存在相同的操作集时，使用上下文菜单可以避免重复放置操作按钮。例如，在邮箱APP中，长按一条邮件，弹出“归档”、“标记为未读”等选项
2、对文本、图片、视频等内容块进行操作
例如，在聊天界面，长按具体消息气泡，弹出“复制”、“转发”、“收藏”等选项
注意事项
1、不要用它承载主要或唯一途径。Context Menu本质是一种“快捷方式”，其提供的应该是次要或不常用的功能；
2、不要滥用，避免功能过于隐藏。Context Menu需要“长按”触发，用户发现成本高；
3、注意与Popover区分。有时候两者样式上很接近，但核心目的、触发对象、交互手势等方面都不一样。
交互细节
触发方式：长按触发；
出现位置：应靠近触发的元素，智能判断位置，避免超出屏幕或被用户手指遮挡；
消失时机：点击菜单外的区域或选择其中一个操作项后。
平台差异
iOS：系统原生组件，可直接调用；
Android：系统原生组件，可直接调用。
Progress Indicators 进度指示器
进度指示器是一种“过程状态”反馈组件，用于管理用户的等待预期
Progress Indicators分为两大类：确定型和不确定型：
一、确定型
核心用途
任务的总时长或总量是可预知的，能以百分比等形式展示给用户。最典型的组件：Progress Bar 进度条，多用于文件传输、资源加载、多步骤流程引导等
注意事项
1、不要用于时长不可预估的任务。一个假的进度条会毁灭用户信任；
2、不要用于页面内容加载。在加载内容卡片时，骨架屏 (Skeleton Screen)是更好的选择；
3、不要让它永久停留。任务完成后，进度条必须立即消失，或转变为一个“完成”状态；
4、必须考虑失败/错误状态：如果任务失败（如网络中断），进度条必须停止，改变状态，并伴随一个清晰的错误信息和“重试”或“取消”按钮。
二、不确定型
核心用途
任务的所需时长完全无法预估，通过一个loading动画告知用户“系统正在处理中”，但并不告知任务何时能完成，它的核心价值是安抚焦虑。典型代表：Spinner 加载指示器、Skeleton Screen 骨架屏
注意事项
1、不要用于时长可预估的任务。如果一项任务的进度是可知的，必须使用进度条 (Progress Bar)；
2、不要用于页面内容加载。在加载内容卡片时，骨架屏 (Skeleton Screen)是更好的选择；
3、不要在 1 秒内的操作中使用，据尼尔森·诺曼集团 (Nielsen Norman Group) 的经典研究，1 秒内的响应用户是能接受的；
4、必须考虑超时与失败的边界情况：
- 超时：如果一个 Spinner 转动时间过长，系统应有超时机制，自动中止任务；
- 失败：加载失败后，必须隐藏 Spinner，并在原位显示一个清晰的错误提示，并提供“重试”按钮。
Badge 徽标
依附于其他界面元素（如tab图标、头像）上，用于提示状态变化或数量的异步组件
核心用途
Badge主要分为两种形态：圆点式徽标和带数字的徽标
1、圆点式徽标：非量化的提示
适合用户只需关注是否有状态/数量变化，具体数量不重要时使用。例如：设置里检测到新版本、朋友圈有新动态
2、带数字的徽标：显示需要处理的具体数量
适合数字本身对用户存在明确价值使用。例如：“消息”tab上显示有多少条新消息、新收到的评论、点赞数量
注意事项
1、不要在数字徽标中显示过大的数字。当数量超过99条时，应显示“99+”；
2、避免滥用，全是重点便没有重点。
交互细节
出现位置：通常位于元素右上角；
清除逻辑：1.点击父元素就清除（进入标签页后就清除）；2.处理完后清除（需要点进具体的消息详情里或“批量已读”后才清除）。
平台差异
iOS：系统原生组件，可直接调用；
Android：系统原生组件，可直接调用。
