速いUIと正しいUIのあいだで、どのズレを許容するか
https://res.cloudinary.com/zenn/image/upload/s--cza4OA_n--/c_fit%2Cg_north_west%2Cl_text:notosansjp-medium.otf_55:%25E9%2580%259F%25E3%2581%2584UI%25E3%2581%25A8%25E6%25AD%25A3%25E3%2581%2597%25E3%2581%2584UI%25E3%2581%25AE%25E3%2581%2582%25E3%2581%2584%25E3%2581%25A0%25E3%2581%25A7%25E3%2580%2581%25E3%2581%25A9%25E3%2581%25AE%25E3%2582%25BA%25E3%2583%25AC%25E3%2582%2592%25E8%25A8%25B1%25E5%25AE%25B9%25E3%2581%2599%25E3%2582%258B%25E3%2581%258B%2Cw_1010%2Cx_90%2Cy_100/g_south_west%2Cl_text:notosansjp-medium.otf_37:uchay%2Cx_203%2Cy_121/g_south_west%2Ch_90%2Cl_fetch:aHR0cHM6Ly9zdGF0aWMuemVubi5zdHVkaW8vdXNlci11cGxvYWQvYXZhdGFyLzVlMWE1MmJjNjkuanBlZw==%2Cr_max%2Cw_90%2Cx_87%2Cy_95/v1627283836/default/og-base-w1200-v2.png?_a=BACMTiGT
速いUIと正しいUIのあいだで、どのズレを許容するか
現代フロントエンドにおける速いUIと正しいUIのあいだに生じる整合性のズレ設計
速いUIと正しいUIの衝突構造知覚時間の重要性
ユーザー操作とシステム確定の時間差による不整合発生現在のページ
表示整合性・操作整合性・業務整合性の3分類
従来のloading/success/errorでは足りない途中状態の多様性現在のページ
stale: 表示中のデータはあるが、最新とは限らない
refreshing: 既存データを見せながら再取得している
optimistic pending: 成功した前提で見せているが、まだ確定していない
streaming: UIの一部だけが先に届いている
partially hydrated: HTMLは見えているが、まだ完全には操作できない
offline queued: 操作は受け付けたが、送信は再接続後になる
retrying: 失敗したが、自動または手動で再試行できる
optimistic update・debounce・startTransition・Suspense・stale while revalidateの各技術が許容するズレの違い
eventual consistencyを前提としたUIの説明責務現在のページ
skeleton・pending・retryなどの途中状態UIは説明可能性のためのUI
実務判断の軸は「どの整合性を守り」「どのズレを許容し」「どう戻すか」
技術選定は不整合の許容範囲から逆算する設計思考
速いUIとはAPI速度ではなく、適切な反応・説明・整合性管理による体験設計