feedback-states

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Feedback states

反馈状态

Every action that takes time has the same few states, and most apps only design the happy one. Your job is to take one feature, find every state it can be in, and make each one clear: what the user sees, how it moves, what they feel, and what it says. The

60fps

library supplies real references.

Work on one feature or screen at a time: a save, a send, a purchase, a search, or how one screen loads its data. If the user did not name one, ask which. Do not change code until step 5.

每个耗时的操作都只有少数几种状态，而大多数 app 只设计了顺利成功的那一种。你的工作是选定一个功能，找出它可能处于的所有状态，并让每种状态都清晰明确：用户看到什么、界面如何运动、用户感受到什么，以及界面说了什么。

60fps

库提供真实上线 app 的参考案例。

一次只处理一个功能或屏幕：保存、发送、购买、搜索，或某个屏幕如何加载数据。如果用户没有指定，就先询问选择哪一个。在第 5 步之前不要修改代码。

1. Map the triggers and the states from the code

1. 从代码中梳理触发条件和状态

Read the feature's view and the code that does the work (the view model, the

async

function, the network call), plus any shared loading, error or freshness views and modifiers the app already has.

First list what starts the work, and every place it can start from (a button and a cell can both add the same thing, and two entry points are how races happen). A user action (a tap on Save) is one trigger. A screen load often has several: opening the screen, coming back to the app, a timer, changing a filter, pull to refresh, a Refresh or Try again button. Feedback differs by trigger, so keep them apart.

Then list every state the feature can actually reach, not just the ones it draws today:

Working, nothing to show yet: the first load, or a user action in progress. Note how long it can take: under a second, a few seconds, or longer.
Working, saved data on screen: showing what was there before while fresh data loads. For any data screen this is the most important state.
Success: it worked. Is there a next step, or does the user stay put?
Partial success: the main thing worked but a side effect failed (saved, but not exported).
Empty: it worked but there is nothing to show.
Error: it failed. Which errors are possible (offline, server, validation, permission), and is saved data still on screen?
Retry: what happens when they try again, and when that fails too.
Interrupted: they leave, background the app, change the filter, or tap again while it works.

States inside a system screen you cannot restyle (the photo picker, the camera, a share sheet) are out of scope: design what happens after it closes.

If the action replaces or deletes something, check in the code that the old data survives a failure (is it removed before the new data is safely saved?). Losing data is worse than any missing state.

For each, note the file and line and what the user sees today. Note feedback code that can never run (an overlay inside a sheet that is already closed) so it can be removed. Also check that every promise in the words is true in the code: "we will refresh when you are back online" needs something that watches the network. If you cannot tell a state's look without running the app, say "not verified".

If a state is already handled well, mark it Keep and move on. The report is about the gaps.

阅读该功能的视图和执行工作的代码（view model、

async

函数、网络调用），以及 app 已有的共享加载、错误或数据新鲜度视图及 modifier。

首先列出是什么启动这项工作，以及它可能从哪些位置启动（按钮和 cell 都能添加同一种内容，而两个入口正是竞态发生的原因）。用户操作（点击

Save

）是一种触发方式。屏幕加载通常有多种触发方式：打开屏幕、返回 app、计时器、更改筛选器、下拉刷新、

Refresh

或

Try again

按钮。反馈因触发方式而异，所以应将它们分开。

然后列出该功能实际可能到达的所有状态，而不只是当前已经绘制出来的状态：

执行中，尚无内容可显示：首次加载，或用户操作正在执行。记录可能耗时多久：不到一秒、几秒，还是更久。
执行中，屏幕上已有保存的数据：在加载新数据时显示之前已有的内容。对于任何数据屏幕，这是最重要的状态。
成功：操作成功。是否还有下一步，还是用户可以停留在当前界面？
部分成功：主要操作成功，但某个附带操作失败（已保存，但未导出）。
空状态：操作成功，但没有内容可显示。
错误：操作失败。可能出现哪些错误（离线、服务器、验证、权限），屏幕上是否仍保留已保存的数据？
重试：用户再次尝试时会发生什么，如果再次失败又会怎样？
中断：用户离开、将 app 切到后台、更改筛选器，或在工作进行期间再次点击。

无法重新设计样式的系统屏幕内部状态不在范围内，例如照片选择器、相机、分享面板。只需设计它们关闭后发生什么。

如果操作会替换或删除内容，检查代码中旧数据能否在失败后保留（是否在新数据安全保存前就将其删除？）。丢失数据比缺少任何状态都严重。

对每种状态，记录对应文件和行号，以及用户目前看到的内容。标出永远无法执行的反馈代码，例如已经关闭的 sheet 内的 overlay，以便将其删除。也要检查文案中的每个承诺是否符合代码事实：“恢复网络后我们会刷新”需要相应的网络监听实现。如果不运行 app 就无法确定某个状态的外观，请写明“未验证”。

如果某个状态已经处理妥当，请标记为 Keep 并继续检查。报告应重点说明存在的差距。

2. Decide each state

2. 决定每种状态的表现

Keep the whole flow calm and quick. Rules that hold almost everywhere:

Haptics answer a touch. Success, error and confirmation haptics only when the result answers something the user just did (Save, Refresh, Try again), even if the work took a few seconds. Never for a load that started on its own (opening the screen, a timer, coming back to the app), and never two haptics for one event: search every haptic call the success path reaches, across files, since a view and a cell often each add one.
Working: under about 400 ms, show no spinner (a flash reads as a glitch), but a load the user asked for still needs a small sign that it happened. Longer, show progress in place, on the thing being worked on, not a full screen blocker. After about 3 seconds, say what is happening.
Saved data on screen: keep it visible and readable while fresh data loads, with a quiet sign that it is updating. Never blank a screen that had data.
Success: confirm in place, on the control the user touched, then get out of the way.
Empty: say why it is empty and what to do next. A still illustration is fine; a looping one is usually noise.
Error: keep what the user typed or chose, and keep saved data on screen. Say what went wrong in plain words and what to do. If it answers a tap, an error haptic and a small, brief shake on that control are enough (about 6 points, 3 swings, 0.3 seconds). If nobody tapped, no haptic and no shake: a calm notice is enough.
Partial success: confirm what worked, then a quiet note about what did not. Never an alert titled as a failure for something that mostly worked.
Retry: if there is no way to retry (an alert that only says "try again"), add one, and keep the user's input in memory so retrying does not mean starting over. The button shows a working state while it tries. A second failure must look different from the first ("Still offline. Tried at 14:05."), or it looks like the tap did nothing.
Interrupted: never leave a spinner running when the work has stopped, and never let a late result overwrite a newer one.

Match the app's tone and reuse its own shared views and modifiers before proposing new ones. Every motion needs a Reduce Motion version (a crossfade, or no motion).

让整个流程保持平静和迅速。以下规则几乎适用于所有场景：

**触觉反馈用于回应触控。**只有当结果回应了用户刚刚执行的操作（
```
Save
```
、
```
Refresh
```
、
```
Try again
```
）时，才使用成功、错误或确认触觉反馈，即使工作耗时数秒。对于自动开始的加载，绝不要使用触觉反馈，例如打开屏幕、计时器触发或返回 app。绝不要为同一个事件触发两次触觉反馈：需要跨文件检查成功路径涉及的所有触觉反馈调用，因为 view 和 cell 经常会各自添加一次。
执行中：少于约 400 ms 时，不显示 spinner（闪现会像出现故障），但用户主动触发的加载仍需一个轻微提示，表明操作已经发生。加载时间较长时，应在操作对象原位显示进度，而不是使用全屏遮挡。超过约 3 秒后，说明正在发生什么。
屏幕上已有保存的数据：刷新数据时保持内容可见且可读，并用轻微提示表明正在更新。绝不要清空原本有数据的屏幕。
成功：在用户刚刚操作的控件上原位确认，然后不再打扰用户。
空状态：说明为什么为空以及接下来该做什么。可以使用静止插图，但循环动画通常是噪音。
错误：保留用户输入或选择的内容，并保留屏幕上的已保存数据。用直白语言说明出了什么问题以及用户该怎么做。如果错误是对一次点击的回应，错误触觉反馈加上控件轻微、短暂的抖动就足够了（约 6 points、3 次摆动、0.3 秒）。如果没有人点击，则不要触觉反馈，也不要抖动，平静地显示通知即可。
部分成功：确认已完成的部分，再用低调提示说明未完成的部分。对于大部分成功的操作，绝不要使用标题为失败的 alert。
重试：如果无法重试，例如 alert 只显示“再次尝试”，则应添加重试入口，并将用户输入保留在内存中，使重试不必从头开始。按钮在尝试时显示执行中状态。第二次失败必须与第一次呈现不同，例如“仍处于离线状态。尝试时间为 14:05。”，否则看起来就像点击没有生效。
中断：工作停止时，绝不要让 spinner 继续运行，也绝不能让迟到的结果覆盖更新的结果。

匹配 app 的整体基调，并优先复用其现有的共享视图和 modifier，再提出新方案。每个动效都需要 Reduce Motion 版本，例如使用 crossfade 或不运动。

3. Find references

3. 查找参考案例

Search only for the states you are changing that need motion, usually success and retry, sometimes working. Skip states marked Keep and states with no motion.

Call

60fps_search_shots

with the motion, the moment and the tone in plain words ("calm in-place check after saving", "button shows a small spinner while it retries"). Do not lead with a surface name like widget or settings. Judge results yourself by title, summary,

intensity

and

mood

; the scores barely separate good from poor matches. The library is strong on celebrations and button feedback and thin on calm errors, retries, offline notices and loading skeletons: for those, search once at most, and expect "No close match" plus the motion described in words to be the answer.

只搜索正在修改且需要动效的状态，通常是成功和重试，有时也包括执行中。跳过标记为 Keep 的状态和不需要动效的状态。

用平实语言调用

60fps_search_shots

，描述动效、发生时刻和基调，例如“保存后平静的原位确认”“重试时按钮显示小型 spinner”。不要以 widget 或 settings 等界面名称作为搜索开头。根据标题、摘要、

intensity

和

mood

自行判断结果，这些评分几乎无法区分好匹配与差匹配。该库擅长庆祝效果和按钮反馈，但对平静的错误提示、重试、离线通知和加载骨架屏支持较少。对于这些情况，最多搜索一次，并预期会得到“No close match”，同时采用文字描述的动效作为答案。

4. Report

4. 报告

Lead with the gaps in one to three sentences, worst first (a wrong haptic or a broken promise beats a missing animation). Then one table, in the order the user meets the states:

State	Where	Today	What to do	Haptic	Words	Shot

Use Keep for states that are already right, and "Not needed" in the Shot column for states with no motion. Reuse the app's own error messages where it already maps errors to words. Below the table, list any data loss risk first, then dead feedback code to remove. Then the Reduce Motion version in one line, and ask whether to build it.

先用一至三句话指出差距，最严重的问题放在最前。错误的触觉反馈或未兑现的承诺比缺少动画更严重。然后按照用户遇到各状态的顺序列出一张表：

状态	位置	当前表现	处理建议	触觉反馈	文案	参考动效

对已经处理妥当的状态使用 Keep，在参考动效列中为不需要动效的状态填写“Not needed”。如果 app 已经将错误映射为文案，应复用其现有错误消息。表格下方先列出任何数据丢失风险，再列出应删除的无效反馈代码。然后用一行说明 Reduce Motion 版本，并询问是否开始构建。

5. Build it, when asked

5. 按要求构建

Model the states explicitly (an enum with the cases you listed) rather than a set of booleans, so impossible combinations cannot happen. Fetch

60fps_get_motion_breakdown

and

60fps_get_motion_code

only for the shots the user picked, and adapt their timing, not their look. Keep the user's design system. Make sure it compiles.

Write plainly: short sentences, common words. Never use em dashes or en dashes.

显式建模各种状态，使用包含所列 case 的

enum

，而不是使用一组布尔值，以防出现不可能的状态组合。仅针对用户选中的参考动效获取

60fps_get_motion_breakdown

和

60fps_get_motion_code

，并调整其时序，而不是外观。保留用户的设计系统。确保代码可以编译。

表达要平实：使用短句和常用词。绝不要使用长破折号或短破折号。

Not for

不适用于

Android, Flutter, React Native or web. Where an app should animate in general: use

find-animation-opportunities

Android、Flutter、React Native 或 Web。若需要处理 app 的通用动画设计，请使用

find-animation-opportunities

。