GH GambleHub

Centrum powiadomień i wydarzenia

1) Cel

Centrum powiadomień zapewnia informacje zwrotne między systemem a użytkownikiem bez zakłócania przepływu działań. Rejestruje asynchroniczne zdarzenia (zakłady, transakcje, bonusy, statusy KYC) i zapewnia jedno miejsce do wyświetlania powiadomień, filtrowania i zarządzania nimi.

Główne zasady:
  • Informuj bez odwrócenia uwagi.
  • Priorytet, nie duplikat.
  • Należy podjąć odpowiednie działania.

2) Rodzaje powiadomień i ich stosowanie

TypPrzykładStosowanie
Toast/SnackbarAkceptacja oferty, błąd sieciPowiadomienia krótkoterminowe przez 3-5 sekund; znikają sami.
Trwały baner„Wymagana aktualizacja KYC”Ważne, ale nie pilne; pozostają przed akcją użytkownika.
Odznaka/wskaźnikna ikonie „”Sygnał nowych wydarzeń.
Skrzynka odbiorcza/paszowaCentrum powiadomieńLinia czasowa i historia powiadomień.
Modal systemowyWyloguj się, błąd płatnościAwarie krytyczne; wymagają potwierdzenia.

3) Priorytety i poziomy znaczenia

1. Krytyczny (błąd, awaria, bezpieczeństwo) - należy natychmiast zwrócić uwagę (Modal/Banner).
2. Ważne (płatność, zakład, cashout) - Toast + wpis w centrum powiadomień.
3. Informacyjne (aktualności, bonusy) - Odznaka i taśma.
4. Social (przyjaciele, czaty, turnieje) - zgrupowane powiadomienia, które nie blokują interfejsu użytkownika.

Zasada UX: „Nie więcej niż jedno aktywne powiadomienie na ekranie”.

Jeśli jest ich więcej, połączyć: „3 nowe wydarzenia”.

4) Architektura centrum powiadomień

4. 1 Źródło zdarzenia

Backend → Event Bus → Notification Service → UI.
Zdarzenia klasyfikuje się: 'typ', 'dotkliwość', 'kontekst', 'ttl',' اId'.
Przechowywany w 'notification _ store' (Redis + DB).

4. 2 Przepływ klienta

WebSocket/SSE дла w czasie rzeczywistym.
Stan lokalny → leniwe załadunek 10-20 powiadomień.
Push API (mobile/browser) - opcjonalnie, za zgodą użytkownika.

4. 3 Model danych (przykład)

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) Elementy interfejsu użytkownika

5. 1 Ikona i odznaka

Pokazuje liczbę nieprzeczytanych („≤ 99”).
Po kliknięciu otwiera panel/centrum powiadomień.
„aria-label =” Są nowe powiadomienia „”; przy zero - 'aria-hidden =' true ''.

5. 2 Panel notyfikacyjny

Lista kart: ikona → nagłówek → krótki tekst → czas → CTA.
Status: nowy, odczyt, błąd dostawy, pobrany z archiwum.
Grupa według daty: Dziś, Wczoraj, Wcześniej.

5. 3 Karta powiadomienia

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) Państwa i działania

Nowy: zaznaczony kolorem/płytą tła.
Czytaj: paler; Nie ma odznaki.
Błąd: ikona + Retry.
System: nie usunięty, tylko archiwizowany.

Działania:
  • Swipe (mobile) → usuń/przeczytaj.
  • Guziki: „Więcej”, „Powtórz”, „Ukryj”.
  • Masowe działania: Mark All Read, Clear All.

7) Zasady wizualne

Maksymalnie 3 wiersze tekstu w powiadomieniu.
Tytuł jest śmiały, do 50 znaków.

Kodowanie kolorów:
  • Sukces - zielony/„ akcent-sukces ”
  • Błąd - czerwony/„ akcent-niebezpieczeństwo ”
  • Informacje - niebieski/„ akcent-informacje ”
  • Uwaga - pomarańczowy/„ akcent-ostrzeżenie ”
  • Kontrast ≥ AA, cienie są minimalne.
  • Animacje: blaknięcie/zjeżdżalnia ≤ 160 ms, bez stałych ruchów.

8) Czas i wyświetlanie

Toast: 3-5 sekund, z przerwą w zawisie.
Baner: przed akcją.
Jak dotąd są nieprzeczytane.
Skrzynka odbiorcza: pamięć TTL (na przykład 14-30 dni).
Automatycznie zamknij, gdy ostrość ekranu zostanie utracona - ostrożnie (nie trać ważnych statusów).

9) A11y i klawiatura

Toast ma 'role =' status '(lub' alert 'dla błędów).
Centrum powiadomień - 'rola =' region 'z' aria-label = 'Notification Center' '.
Obsługa nawigacji strzałek i Tab/Shift + Tab.
VoاOver: czytanie nowych powiadomień po dodaniu ('aria-live =' grzeczny ').
Focus nie „skakać”, gdy pojawia się - tylko wtedy, gdy toast jest krytyczny.

10) Wydajność

Leniwe obciążenie i paginacja (po 20-30).
Kompresja danych ('gzip '/' br'), żądania grupowania.
Ponowne połączenie WebSocket + backoff.
Animacje tylko na „transformacji/nieprzezroczystości”.

11) Scenariusze iGaming

11. 1 Zakłady i wypłaty

„Zakład przyjęty”, „Współczynnik zmieniony”, „Cashout zakończony” - toast + nagrywanie taśmy.
W przypadku błędu - toast „Nie udało się zainstalować”, baner z Retry.

11. 2 Płatności

„Uzupełnienie udane” → toast.
Wyjście w procesie → wpis taśmy, ETA i przycisk Więcej.
Błąd PSP → czerwony toast + CTA Retry.

11. 3 Premie i promocje

Baner na ekranie głównym: „Nowy turniej”, „Bonus depozytowy”.
Centrum powiadomień przechowuje historię wszystkich promocji.
Możliwość ukrywania/rezygnacji z subskrypcji przed typami marketingowymi.

11. 4 KYC i bezpieczeństwo

Trwały baner do czasu zakończenia weryfikacji.
„KYC potwierdzone” → zielony toast + archiwum w taśmie.
„Dokument wygasł” → powiadomienie + aktualizacja CTA.

12) Metryka

Powiadomienia CTR (według typu).
Wskaźnik zwolnienia (ile zostało zamknięte bez działania).
Nieczytelna liczba avg - czas do odczytu.
Wskaźnik sukcesu dostawy (дла realtime).
Opóźnienie między zdarzeniem a pokazem (cel ≤ 300 ms).
Wskaźnik błędów/Retry w dostawie WebSocket/Push.

13) Anty-wzory

Dźwięki i pop-upy na każdym wydarzeniu.
Nieprzewidywalne automatycznie zamknięte zegary.
Powtórz te same powiadomienia.
Zrzuty ekranu bez przyczyny ("potwierdzić", "restart').
Używanie powiadomień jako spamu marketingowego.
Centrum niefiltrowane/wyszukiwalne na> 50 zdarzeń.

14) Żetony systemu projektowania

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) Lista kontrolna QA

Funkcjonalność

  • Dostawa w czasie rzeczywistym ≤ 300 ms.
  • Toast jest wyświetlany ≤ 100 ms po wydarzeniu.
  • Centrum jest zsynchronizowane (odczytane/nieprzeczytane).
  • Masowe „przeczytaj wszystko” działa.

UX

  • Nie więcej niż 1 toast na raz.
  • Czas trwania powiadomienia jest optymalny (3-5 sekund).
  • Ważne powiadomienia pozostają w toku.
  • Tekst ≤ 3 wiersze, CTA 1.

A11y

  • 'role =' status '/' aria-live 'są poprawne.
  • Działa nawigacja strzałek i kart.
  • Kontrast ≥ AA.

Wydajność

  • Paginacja i leniwe obciążenie.
  • Brak fryzes na> 100 powiadomień.
  • Kompresja danych i opóźnione oddawanie.

16) Dokumentacja w systemie projektowym

Кобонента: „Toast”, „ΔItem”, „Center”, „BadgeIndicator”.
Przewodniki: priorytety powiadomień, TTL, grupowanie, copywriting.
Wzory: toast za wydarzenia błyskawiczne, baner za ważne, centrum za historię.
Do/Don gallery: „powiadomienia o spamie” vs „spokojna świadomość”.

Krótkie podsumowanie

Centrum powiadomień to nie tylko skrzynka odbiorcza wydarzeń, ale architektura zaufania i przejrzystości. Dobrze zaprojektowane powiadomienia tworzą poczucie kontroli: wszystko co ważne jest dostarczane, nic nie jest tracone, hałas jest tłumiony. Ma to kluczowe znaczenie dla iGaming - ważne jest, aby użytkownik widział potwierdzenie zakładów, płatności i statusów bez odwracania uwagi od gry.

Contact

Skontaktuj się z nami

Napisz do nas w każdej sprawie — pytania, wsparcie, konsultacje.Zawsze jesteśmy gotowi pomóc!

Rozpocznij integrację

Email jest wymagany. Telegram lub WhatsApp są opcjonalne.

Twoje imię opcjonalne
Email opcjonalne
Temat opcjonalne
Wiadomość opcjonalne
Telegram opcjonalne
@
Jeśli podasz Telegram — odpowiemy także tam, oprócz emaila.
WhatsApp opcjonalne
Format: kod kraju i numer (np. +48XXXXXXXXX).

Klikając przycisk, wyrażasz zgodę na przetwarzanie swoich danych.