In-App Notification Center
アプリ内通知センター
アプリ内通知センターは、有用な更新を一か所にまとめて保持します。各項目は何が変更されたか、いつ変更されたか、および未読かどうかを表示します。
もう一つの例
チームメイトがコメントでMayaに言及します。Mayaは今すぐ読むことも、未読リストから後で戻ることもできます。
主な部分
- 01未読数
- 02通知アイテム
- 03ソースと時間
- 04転送先リンク
- 05優先設定コントロール
以下の場合に使用します
重要な製品アップデートがバナー消失後も検索可能である必要がある場合に使用します。
以下の場合は使用しないでください
同じイベントを何度も繰り返したり、プライベートな詳細を公開したりしないでください。ユーザーに通知の制御を与えてください。
コードで使用する名前
event + recipient + unread state + dedupe + deep link + preferences 出荷前に
Before release, check the page structure, keyboard access, visible focus, contrast, and zoom. Also check loading, empty, error, success, cancel, and reduced-motion states.
Outcome：Complete the task with アプリ内通知センター (In-App Notification Center)。 User context：チームメイトがコメントでMayaに言及します。Mayaは今すぐ読むことも、未読リストから後で戻ることもできます。 Recommended pattern：アプリ内通知センター (In-App Notification Center)。 Why it fits：重要な製品アップデートがバナー消失後も検索可能である必要がある場合に使用します。 Do not use it when：同じイベントを何度も繰り返したり、プライベートな詳細を公開したりしないでください。ユーザーに通知の制御を与えてください。 Product requirements: Define the default, loading, empty, error, success, and recovery states. Keep user input. Give clear feedback after every action. Accessibility and resilience: Use semantic HTML, full keyboard access, and visible focus. Make the layout work when zoomed and support reduced motion. Follow the project’s current rules. Do not add a new UI library unless the project already uses it. Acceptance criteria: The main task works with keyboard only and at 320px width. Focus and status changes are announced. Check loading, failure, retry, cancel, and reduced-motion paths. Evidence and limits (evidence boundary)：単一の公式標準が全体の用語を管理するわけではありません。その意味はチーム、プラットフォーム、またはフレームワークによって変わる可能性があります。 Unknowns to confirm: Product wording, data source, analytics events, supported devices and languages, and platform limits.
このリクエストを確認する
Review how アプリ内通知センター (In-App Notification Center) is used now. Definition: アプリ内通知センターは、有用な更新を一か所にまとめて保持します。各項目は何が変更されたか、いつ変更されたか、および未読かどうかを表示します。 Release checks: Before release, check the page structure, keyboard access, visible focus, contrast, and zoom. Also check loading, empty, error, success, cancel, and reduced-motion states. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.