通知和事件中心
1）任命
通知中心在系統和用戶之間提供反饋,而不中斷活動流。它捕獲異步事件（投註，交易，獎金，KYC狀態），並提供單個位置來查看通知，過濾和管理通知。
主要原則：- 在不分心的情況下通知。
- 優先級而不是重復。
- 在適當的地方采取行動。
2）通知類型及其應用
3）優先次序和重要程度
1.Critical（錯誤、故障、安全）-需要立即註意（Modal/Banner）。
2.Important（付款、出價、現金）-Toast+寫入通知中心。
3.Informational（新聞、獎金）-徽章和磁帶。
4.Social（朋友、聊天室、錦標賽）-不阻止UI的分組通知。
UX規則：「每個屏幕不超過一個活動通知」。
如果它們更多-合並：「3個新事件」。
4）通知中心架構
4.1事件來源
Backend → Event Bus → Notification Service → UI.
事件分類為「類型」，「severity」，「context」，「ttl」，「userId」。
保存在「notification_store」 （Redis+DB）中。
4.2客戶端流
WebSocket / SSE для real-time.
本地狀態→ lazy裝載10-20個通知。
Push API（移動/瀏覽器）-經用戶同意可選。
4.3數據模型（示例）
json
{
"id": "n12345",
"type": "deposit_success",
"severity": "info",
"title": "Replenishment successful,"
"message": "You made 500 ₴ through Papara,"
"timestamp": "2025-11-03T19:20:00Z",
"context": { "transactionId": "tx123" },
"read": false,
"action": {"label": "View," "url": "/wallet/history "}
}5） UI組件
5.1圖標和徽章
顯示未讀數（「≤ 99」）。
單擊時,將打開通知面板/中心。
'aria-label='有新的通知'；在nule-'aria-hidden=」true」。
5.2通知面板
卡片列表：圖標→標題→短文本→ CTA →時間。
狀態：新,讀取,交付錯誤,從歸檔下載。
按日期分組：今天，昨天，早些時候。
5.3張通知卡
html
<article class="notif new" role="article">
<div class="icon success"></div>
<div class="content">
<h4> Replenishment successful </h4>
<p> 500 ₴ via Papara </p>
<time datetime =" 2025-11-03T19: 20"> 5 min ago </time>
</div>
<button class =" icon" aria-label = "Delete"> </button>
</article>6）狀態和行動
新增：以顏色/背景色調突出顯示。
閱讀：蒼白；沒有徽章。
錯誤：圖標+Retry。
系統：不刪除,僅存檔。
- Swipe （mobile） →刪除/讀取。
- 按鈕：閱讀更多,重復,隱藏。
- 大規模行動：記下所有已閱讀的內容，清除所有內容。
7）視覺原理
通知中最多3行文本。
標題粗體，最多50個字符。
- 成功-綠色/'accent-success'
- 錯誤-紅色/'accent-danger'
- 信息-藍色/'accent-info'
- 註意-橙色/'accent-warning'
- 對比≥ AA，陰影最小。
- 動畫：fade/slide ≤ 160毫秒，沒有永久性移動。
8）時間安排和顯示
Toast：3-5秒，暫停。
橫幅：在行動之前。
Badge：雖然有未讀。
收件箱：TTL存儲（例如14-30天）。
在失去屏幕焦點時自動關閉-小心（不要失去重要狀態）。
9）A11y和鍵盤
Toast具有'role='status'（或錯誤的'alert'）。
通知中心是'role='region' 's'aria-label='通知中心'。
支持箭頭導航和Tab/Shift+Tab。
VoiceOver：在添加時閱讀新通知（'aria-live='polite'"）。
焦點在出現時不會「跳躍」-僅在觸覺關鍵的情況下。
10）性能
懶惰的下載和分區（每個20-30）。
數據壓縮（「gzip」/「br」），查詢分組。
WebSocket reconnection + backoff.
僅在「轉換/操作性」上使用動畫。
11） iGaming腳本
11.1投註和現金
「接受率」，「系數更改」，「現金完成」-toast+錄制到磁帶中。
錯誤時-toast「無法交付」,帶有Retry的橫幅。
11.2付款
「補充成功」→ toast。
「處理輸出」→磁帶條目、ETA和更多按鈕。
PSP錯誤→紅色toast+CTA Retry。
11.3獎金和促銷
主屏幕上的橫幅：「新錦標賽」，「存款獎金」。
通知中心存儲所有促銷活動的歷史記錄。
能夠隱藏/取消訂閱營銷類型。
11.4 KYC和安全
在驗證完成之前的Persistent橫幅。
「KYC已確認」→磁帶中的綠色toast+存檔。
「文檔已過期」→通知+CTA更新。
12）度量標準
通知的CTR（按類型）。
Dismiss rate（有多少人在沒有動作的情況下關閉）。
Unread count avg и time-to-read.
Delivery success rate (для realtime).
事件和表演之間的偏差（目標≤ 300毫秒）。
WebSocket/Push交付時的錯誤/返回率。
13）反模式
每個事件中的聲音和彈出窗口。
不可預測的自動閉合計時器。
重復相同的通知。
無緣無故截圖器（「確認」，「重新啟動」）。
將通知用作營銷垃圾郵件。
14）設計系統令牌
json
{
"toast": {
"durationMs": 4000,
"maxWidth": 400,
"gap": 12,
"radius": 10,
"shadow": "var(--elev-3)"
},
"badge": {
"size": 18,
"color": "var(--accent-info)"
},
"panel": {
"width": 380,
"radius": 12,
"gap": 8,
"padding": "12 16"
},
"a11y": {
"ariaLive": "polite",
"contrastAA": true
}
}15） QA支票清單
功能性
- Real Time交付≤ 300毫秒。
- Toast在事件發生後顯示≤ 100毫秒。
- 中心已同步（read/unread）。
- 大眾的「閱讀一切」工作。
UX
一次不超過1次。
- 通知的壽命是最佳的（3-5秒）。
- 重要通知將在生效之前保留。
- 文本≤ 3行，CTA一行。
A11y
- 'role="status" "/'aria-live'是正確的。
- 箭頭導航和Tab工作。
- AA ≥的對比。
表演
- 分割和懶惰裝載。
- >100通知時不帶帶帶。
- 數據壓縮和延遲渲染。
16）設計系統中的文檔
Компоненты: `Toast`, `NotificationItem`, `NotificationCenter`, `BadgeIndicator`.
Gaids：通知優先級，TTL，grouping，文案寫作。
模式：即時事件的觸輪，重要事件的橫幅，歷史的中心。
Do/Do n't gallery：「垃圾郵件通知」vs「平靜的意識」。
簡短摘要
通知中心不僅是事件的「內幕」，而且是信任和透明的體系結構。設計精良的通知會產生一種控制感：所有重要的東西都交付，沒有消失，噪音被抑制。對於iGaming來說，這是至關重要的-用戶必須看到賭註，付款和狀態的確認，而不必被遊戲分散註意力。