feedback-states

フィードバックの状態

時間がかかるすべての操作には、いくつかの共通した状態がありますが、多くのアプリでは成功時の状態しか設計されていません。あなたの役割は、1つの機能を選び、起こりうるすべての状態を洗い出して、それぞれを明確にすることです。ユーザーに何が表示されるか、状態がどう遷移するか、ユーザーがどう感じるか、そして何と伝えるかを確認します。60fps ライブラリには実際の参考例があります。

一度に扱うのは、保存、送信、購入、検索、あるいは画面上のデータの読み込みなど、1つの機能または画面だけです。ユーザーが対象を指定していない場合は、どれを扱うか尋ねてください。ステップ5まではコードを変更しないでください。

1. コードからトリガーと状態を洗い出す

機能のビューと処理を行うコード（ビューモデル、async 関数、ネットワーク呼び出し）に加えて、アプリにすでにある共通の読み込み、エラー、新鮮さを示すビューやモディファイアも確認します。

まず、何が処理を開始するのか、そして処理が始まる場所をすべて列挙してください（ボタンとセルの両方から同じ項目を追加できる場合もあります。複数の開始箇所があると競合が発生します）。ユーザーの操作（保存をタップするなど）は、トリガーの1つです。画面の読み込みには、画面を開く、アプリに戻る、タイマー、フィルターの変更、引っ張って更新、更新ボタンや再試行ボタンなど、複数のトリガーがあることもよくあります。トリガーによってフィードバックは異なるため、分けて扱ってください。

現在描画されている状態だけでなく、機能が実際に到達しうるすべての状態を列挙してください。

• 処理中、表示するものがない：初回読み込み、またはユーザーの操作が進行中の状態です。所要時間がどれくらいか、1秒未満、数秒、またはそれ以上かを記録してください。
• 処理中、保存済みデータを表示している：新しいデータの読み込み中に、以前のデータを表示している状態です。データ画面では、これが最も重要な状態です。
• 成功：処理が成功した状態です。次のステップがあるのか、それともユーザーは現在の画面にとどまるのかを確認してください。
• 一部成功：主要な処理は成功したものの、副次的な処理に失敗した状態です（保存はできたが、エクスポートできなかったなど）。
• 空：処理は成功したものの、表示するものがない状態です。
• エラー：処理に失敗した状態です。オフライン、サーバー、入力検証、権限など、起こりうるエラーと、保存済みデータが画面に残っているかを確認してください。
• 再試行：再試行したときに何が起こるか、再試行も失敗したときにどうなるかを確認してください。
• 中断：処理中に画面を離れる、アプリをバックグラウンドにする、フィルターを変更する、もう一度タップするといった状態です。

写真ピッカー、カメラ、共有シートなど、スタイルを変更できないシステム画面内の状態は対象外です。システム画面が閉じた後の動作を設計してください。

操作によって既存のデータが置き換えられたり削除されたりする場合は、失敗しても古いデータが保持されることをコードで確認してください（新しいデータが安全に保存される前に削除されていないか）。データの喪失は、状態の欠落よりも深刻です。

それぞれについて、ファイルと行番号、現在ユーザーに何が表示されるかを記録してください。実行されることのないフィードバックコード（すでに閉じたシート内のオーバーレイなど）も記録し、削除できるようにしてください。また、表示される文言で約束していることが、コード上でも実現されているか確認してください。「オンラインに戻ったら更新します」と伝えるなら、ネットワークを監視する処理が必要です。実際にアプリを動かさないと状態の見た目が判断できない場合は、「未確認」と記載してください。

すでに適切に処理されている状態には 維持 と記し、次に進んでください。レポートでは不足している点を取り上げます。

2. 各状態を判断する

フロー全体を落ち着いて、すばやく保ちます。ほぼすべての場面で当てはまるルールは次のとおりです。

• 触覚フィードバックはタッチへの応答です。 成功、エラー、確認の触覚フィードバックは、その結果がユーザーの直前の操作（保存、更新、再試行）への応答となる場合に限ります。処理に数秒かかった場合も同様です。画面を開く、タイマー、アプリに戻るなど、自動的に始まった読み込みでは決して使いません。また、1つのイベントに対して触覚フィードバックを2回発生させないでください。成功パスに到達するすべての触覚フィードバック呼び出しを、ファイルをまたいで検索してください。ビューとセルの両方がそれぞれ追加していることがよくあります。
• 処理中：約400 ms未満なら、スピナーは表示しません（ちらつきは不具合のように見えます）。ただし、ユーザーが要求した読み込みでは、実行されたことがわかる控えめな表示が必要です。それより長い場合は、全画面をブロックせず、処理対象の上に進行状況をその場で表示します。約3秒を超えたら、何が起きているかを説明します。
• 保存済みデータが画面に表示されている：新しいデータを読み込む間も、データは見える状態で読みやすく保ち、更新中であることを控えめに示します。データが表示されていた画面を空白にすることは決してありません。
• 成功：ユーザーがタッチしたコントロール上で、その場で確認を示し、すぐに邪魔にならないようにします。
• 空の状態：なぜ空なのか、次に何をすればよいかを伝えます。静止したイラストは問題ありませんが、ループするアニメーションはたいてい余計なノイズになります。
• エラー：ユーザーが入力または選択した内容を維持し、保存済みデータも画面に残します。何が起きたのか、どうすればよいのかを平易な言葉で伝えます。タップへの応答であれば、エラーの触覚フィードバックと、そのコントロールを軽く短く揺らすだけで十分です（約6ポイント、3往復、0.3秒）。誰もタップしていない場合は、触覚フィードバックも揺れも不要です。落ち着いた通知だけで十分です。
• 一部成功：うまくいった内容を確認し、その後、うまくいかなかった内容を控えめに伝えます。ほとんど成功したものに対して、失敗をタイトルにしたアラートを表示してはいけません。
• 再試行：再試行する方法がない場合（「再試行」とだけ表示されるアラートなど）は、その方法を追加し、ユーザーの入力をメモリに保持して、最初からやり直さずに再試行できるようにします。再試行中はボタンに処理中の状態を表示します。2回目の失敗は、1回目とは異なる見え方にします（「まだオフラインです。14:05に試しました。」など）。そうしないと、タップしても何も起きなかったように見えます。
• 中断：処理が停止した後もスピナーを回し続けてはいけません。また、遅れて届いた結果で新しい結果を上書きしてはいけません。

アプリのトーンに合わせ、新しいものを提案する前に、既存の共有ビューやモディファイアを再利用します。すべてのモーションに、視差効果を減らす設定に対応したバージョンを用意します（クロスフェード、またはモーションなし）。

3. 参考例を探す

変更する状態のうち、モーションが必要なものだけを検索します。通常は成功と再試行、ときどき処理中です。「維持」とマークされた状態や、モーションが不要な状態はスキップします。

60fps_search_shots を呼び出す際は、モーション、タイミング、トーンを平易な言葉で指定します（「保存後、その場で落ち着いたチェックを表示」「再試行中、ボタンに小さなスピナーを表示」など）。ウィジェットや設定など、表示面の名前から始めないでください。結果はタイトル、要約、intensity、mood を見て自分で判断します。スコアは適切な候補とそうでない候補をほとんど区別できません。このライブラリには、お祝いの演出やボタンのフィードバックは豊富ですが、落ち着いたエラー、再試行、オフライン通知、読み込み中のスケルトンはあまりありません。それらについては検索は多くても1回にし、「近い候補なし」と表示されたうえで、モーションを言葉で説明したものが答えになると想定してください。

4. 報告する

まず、問題点を1〜3文で、重大なものから順に示します（誤った触覚フィードバックや約束された動作の不履行は、アニメーションの欠落より重大です）。続けて、ユーザーが各状態に遭遇する順に、次の表を1つだけ示します。

状態	場所	現状	対応内容	触覚フィードバック	文言	ショット

すでに適切な状態には 維持 を使い、モーションがない状態ではショット列に「不要」と記載します。エラーがすでにメッセージに対応付けられている場合は、アプリ独自のエラーメッセージを再利用します。表の下には、まずデータ損失のリスクを挙げ、その後に削除する不要なフィードバックコードを列挙します。続けて、視差効果を減らす設定に対応したバージョンを1行で示し、実装するかどうかを尋ねます。

5. 指示されたら実装する

状態はブーリアンの集合ではなく、列挙したケースを持つ列挙型として明示的にモデル化してください。そうすれば、あり得ない組み合わせを防げます。60fps_get_motion_breakdown と 60fps_get_motion_code は、ユーザーが選んだショットに限って取得し、見た目ではなくタイミングを調整してください。ユーザーのデザインシステムを維持してください。コンパイルできることを確認してください。

簡潔に書いてください。短い文と一般的な単語を使ってください。全角ダッシュは使わないでください。

対象外

Android、Flutter、React Native、Webは対象外です。アプリ全般でどこにアニメーションを追加すべきかを判断する場合は、find-animation-opportunities を使ってください。