Refactor backend CORS settings to include default origins and improve error handling in chat services: Introduce dynamic CORS origin handling, enhance RabbitMQ message sending with fallback mechanisms, and update WebSocket service to manage pending messages. Update UI components for better accessibility and responsiveness, including adjustments to dialog and navigation elements. Enhance styling for improved user experience across various components.
This commit is contained in:
401
docs/USABILITY_CONCEPT.md
Normal file
401
docs/USABILITY_CONCEPT.md
Normal file
@@ -0,0 +1,401 @@
|
||||
# Bedienbarkeitskonzept
|
||||
|
||||
## Ziel
|
||||
|
||||
Die Bedienbarkeit von YourPart soll systematisch verbessert werden, ohne die vorhandene Funktionsbreite oder den neuen UI-Stand wieder aufzubrechen. Der Fokus liegt auf Orientierung, Vorhersagbarkeit, Aufgabenfluss, Fehlertoleranz und effizienter Nutzung auf Desktop und Mobile.
|
||||
|
||||
Das Dokument ist bewusst als Arbeitsgrundlage aufgebaut:
|
||||
|
||||
- Was genau verbessert werden soll
|
||||
- nach welchen Prinzipien entschieden wird
|
||||
- in welcher Reihenfolge gearbeitet wird
|
||||
- woran ein Punkt als erledigt gilt
|
||||
|
||||
## Leitprinzipien
|
||||
|
||||
### 1. Weniger Reibung
|
||||
|
||||
- Haeufige Aufgaben muessen mit moeglichst wenig Entscheidungen und moeglichst wenig Klicks erreichbar sein.
|
||||
- Sekundaere Funktionen duerfen nicht die Kernaufgabe stoeren.
|
||||
|
||||
### 2. Klare Orientierung
|
||||
|
||||
- Nutzer muessen jederzeit erkennen:
|
||||
- wo sie sich befinden
|
||||
- was hier moeglich ist
|
||||
- was der naechste sinnvolle Schritt ist
|
||||
|
||||
### 3. Konsistente Interaktion
|
||||
|
||||
- Gleiche Interaktionsmuster muessen sich in der gesamten App gleich verhalten.
|
||||
- Buttons, Dialoge, Tabs, Listen, Formulare und Menues duerfen nicht je Bereich eigene Bedienlogiken entwickeln.
|
||||
|
||||
### 4. Fehlertoleranz statt Bestrafung
|
||||
|
||||
- Fehlbedienungen muessen auffangbar sein.
|
||||
- Kritische Aktionen brauchen klare Rueckmeldung, wo sinnvoll Bestätigung und wenn moeglich Undo oder sichere Rueckwege.
|
||||
|
||||
### 5. Geschwindigkeit fuer geuebte Nutzer
|
||||
|
||||
- Power-User sollen die App schnell nutzen koennen.
|
||||
- Haeufige Wege duerfen nicht durch uebermaessige Zwischenschritte ausgebremst werden.
|
||||
|
||||
## Nicht-Ziele
|
||||
|
||||
- Keine komplette Informationsarchitektur-Neuerfindung in einem Schritt.
|
||||
- Kein sofortiger Umbau jedes Workflows gleichzeitig.
|
||||
- Keine reine Accessibility-Checklistenarbeit ohne echten Nutzwert.
|
||||
|
||||
## Ausgangsprobleme
|
||||
|
||||
Aus dem aktuellen Projektstand und den bisherigen Umbauten ergeben sich fuer die Bedienbarkeit vor allem diese Problemklassen:
|
||||
|
||||
- Uneinheitliche Bedienmuster zwischen alten und neueren Bereichen
|
||||
- zu viele tiefe Menues und bereichsspezifische Sonderlogiken
|
||||
- einige Seiten mit hoher Funktionsdichte, aber schwacher Priorisierung
|
||||
- Mischformen aus statischen Shell-Bereichen und historischen inneren Scrollkonzepten
|
||||
- lokale Alt-Dialoge und Formmuster mit uneinheitlicher Rueckmeldung
|
||||
- Desktop-zentrierte Denkweise in Teilen von Admin, Minigames und Falukant
|
||||
|
||||
## Zielbild
|
||||
|
||||
Am Ende soll die App folgendes Nutzungsgefuehl bieten:
|
||||
|
||||
- Shell, Navigation und Dialoge verhalten sich vorhersagbar
|
||||
- jede Hauptseite zeigt klar eine Primaeraufgabe und erkennbare Sekundaeraufgaben
|
||||
- Formulare fuehren sauber durch Eingabe, Validierung und Abschluss
|
||||
- Statusaenderungen und Systemreaktionen sind sichtbar und verstaendlich
|
||||
- Falukant, Community, Blog und Lernen bleiben fachlich unterschiedlich, aber bedienbar aus einem Guss
|
||||
|
||||
## Arbeitsbereiche
|
||||
|
||||
### Bereich A: Navigation und Orientierung
|
||||
|
||||
Ziel:
|
||||
|
||||
- Nutzer finden schneller zum Ziel und verstehen Menuehierarchien besser.
|
||||
|
||||
Arbeitspunkte:
|
||||
|
||||
- Hauptnavigation auf tatsaechliche Primaerbereiche pruefen
|
||||
- Untermenues auf Redundanzen und Leerpfade pruefen
|
||||
- aktive Position und Kontext pro Bereich klarer machen
|
||||
- in tiefen Bereichen Rueckwege, Breadcrumb-artige Hinweise oder Bereichstitel konsistent gestalten
|
||||
- Schnellzugriffe nur dort einsetzen, wo sie echte Beschleunigung bringen
|
||||
|
||||
Abnahmekriterien:
|
||||
|
||||
- jeder Hauptmenuepunkt hat einen klaren Zweck
|
||||
- Menuepunkte ohne Untermenue verhalten sich direkt
|
||||
- tiefe Ansichten haben einen klaren Rueckweg
|
||||
- Nutzer muessen nicht raten, in welchem Bereich sie sich befinden
|
||||
|
||||
### Bereich B: Seitenhierarchie und Aufgabenfluss
|
||||
|
||||
Ziel:
|
||||
|
||||
- jede Seite hat einen erkennbaren Einstieg, eine Hauptaufgabe und einen lesbaren Aufbau
|
||||
|
||||
Arbeitspunkte:
|
||||
|
||||
- pro View Primaeraktion definieren
|
||||
- Informationsdichte dort reduzieren, wo gleichrangige Bloecke konkurrieren
|
||||
- visuelle Prioritaet zwischen Lesen, Auswaehlen, Bearbeiten und Absenden schaerfen
|
||||
- Tabellen, Listen und Karten jeweils auf ihren eigentlichen Einsatzzweck pruefen
|
||||
|
||||
Abnahmekriterien:
|
||||
|
||||
- Nutzer erkennen in wenigen Sekunden den Zweck einer Seite
|
||||
- Hauptaktionen sind oberhalb oder in unmittelbarer Naehe des relevanten Inhalts
|
||||
- Nebenfunktionen dominieren die Seite nicht mehr
|
||||
|
||||
### Bereich C: Formulare und Eingaben
|
||||
|
||||
Ziel:
|
||||
|
||||
- Formulare sollen verstaendlich, fehlertolerant und effizient sein
|
||||
|
||||
Arbeitspunkte:
|
||||
|
||||
- Labels, Hilfetexte, Pflichtfelder und Fehlermeldungen vereinheitlichen
|
||||
- Validierung naeher an den Eingabepunkt bringen
|
||||
- unklare Zustandswechsel vermeiden
|
||||
- Speichern, Abbrechen und gefaehrliche Aktionen konsistent platzieren
|
||||
- Checkboxen, Radios und Selects auf Lesbarkeit und Trefferflaechen pruefen
|
||||
|
||||
Abnahmekriterien:
|
||||
|
||||
- jeder Eingabefehler ist erkennbar und nachvollziehbar
|
||||
- Speichern fuehlt sich in allen Bereichen gleich an
|
||||
- keine Form wirkt wie ein historischer Sonderfall
|
||||
|
||||
### Bereich D: Dialoge, Feedback und Systemstatus
|
||||
|
||||
Ziel:
|
||||
|
||||
- Systemreaktionen muessen sichtbar, verstaendlich und nicht stoerend sein
|
||||
|
||||
Arbeitspunkte:
|
||||
|
||||
- Dialogarten unterscheiden:
|
||||
- bestaetigend
|
||||
- informierend
|
||||
- bearbeitend
|
||||
- kritisch
|
||||
- Messagebox/Dialog-Rueckmeldungen vereinheitlichen
|
||||
- Ladezustaende, Erfolg, Fehler und Leere Zustaende standardisieren
|
||||
- offene Dialoge und Fensterleiste auf Priorisierung pruefen
|
||||
|
||||
Abnahmekriterien:
|
||||
|
||||
- Nutzer verstehen, was gerade passiert ist oder noch passiert
|
||||
- kritische Aktionen sind klar markiert
|
||||
- Modale Interaktionen blockieren nur, wenn es wirklich noetig ist
|
||||
|
||||
### Bereich E: Mobile und kleine Viewports
|
||||
|
||||
Ziel:
|
||||
|
||||
- zentrale Aufgaben muessen auch auf kleineren Screens robust funktionieren
|
||||
|
||||
Arbeitspunkte:
|
||||
|
||||
- Shell mit Header, Navigation, Content und Footer auf reale Nutzungsszenarien pruefen
|
||||
- Tabellen und breite Steuermasken auf mobile Alternativen oder horizontale Strategien prüfen
|
||||
- Touch-Ziele und Abstaende angleichen
|
||||
- Hover-abhaengige Muster fuer Touch absichern
|
||||
|
||||
Abnahmekriterien:
|
||||
|
||||
- Kernaufgaben sind auf Tablet und Smartphone ohne Layoutbruch nutzbar
|
||||
- keine kritische Funktion ist nur via Hover oder Pixel-Präzision erreichbar
|
||||
|
||||
### Bereich F: Komplexe Produktbereiche
|
||||
|
||||
Ziel:
|
||||
|
||||
- Falukant, Vokabeltrainer, Minigames und Admin sollen fachlich komplex bleiben, aber leichter steuerbar werden
|
||||
|
||||
Arbeitspunkte:
|
||||
|
||||
- Falukant:
|
||||
- Schnellzugriffsleiste, Tab-Struktur, Statusfeedback und Arbeitsablaeufe priorisieren
|
||||
- Vokabeltrainer:
|
||||
- Lernpfad, Bearbeitung, Suche, Uebung und Fortschritt klarer trennen
|
||||
- Minigames:
|
||||
- Einstieg, Pause, Statusanzeige und Kampagnenfluss vereinfachen
|
||||
- Admin:
|
||||
- Such-, Editier- und Bestaetigungsfluesse entlasten
|
||||
|
||||
Abnahmekriterien:
|
||||
|
||||
- komplexe Bereiche sind ohne Einlernen nicht sofort trivial, aber deutlich besser fuehrend
|
||||
- wiederkehrende Aktionen sind schneller und sicherer bedienbar
|
||||
|
||||
## Methodik
|
||||
|
||||
### 1. Bedienbarkeits-Audit
|
||||
|
||||
Pro Hauptbereich wird ein kurzer Audit gemacht:
|
||||
|
||||
- Primaeraufgabe der Seite
|
||||
- haeufigste Nutzeraktion
|
||||
- groesste Reibung
|
||||
- groesstes Fehlerrisiko
|
||||
- mobile Schwachstelle
|
||||
|
||||
Empfohlene Cluster:
|
||||
|
||||
- Shell und Navigation
|
||||
- Home und Einstieg
|
||||
- Community/Social
|
||||
- Blog
|
||||
- Vokabeltrainer
|
||||
- Falukant
|
||||
- Admin
|
||||
- Minigames
|
||||
- Dialoge/Formulare
|
||||
|
||||
### 2. Aufgabenorientierte Review-Szenarien
|
||||
|
||||
Die App wird nicht nur nach Komponenten, sondern nach Aufgaben geprueft:
|
||||
|
||||
- registrieren und einloggen
|
||||
- Profil/Freunde finden
|
||||
- Forumsthema finden und beantworten
|
||||
- Vokabelsprache erstellen, abonnieren, lernen
|
||||
- Falukant-Status pruefen und Folgeaktion ausfuehren
|
||||
- Admin-Nutzer suchen und aendern
|
||||
- Match3 starten, pausieren, neu starten
|
||||
|
||||
### 3. Fix-Kategorien
|
||||
|
||||
Alle Probleme werden in vier Kategorien eingeordnet:
|
||||
|
||||
- P1: blockiert oder verwirrt Kernnutzung deutlich
|
||||
- P2: verlangsamt Nutzung oder erzeugt Fehlbedienung
|
||||
- P3: stoert Konsistenz oder Lesbarkeit
|
||||
- P4: Feinschliff ohne unmittelbaren Schaden
|
||||
|
||||
## Umsetzungsphasen
|
||||
|
||||
### Phase U1: Audit und Problemkatalog
|
||||
|
||||
Ergebnis:
|
||||
|
||||
- kompakte Liste realer Bedienprobleme pro Hauptbereich
|
||||
- priorisiert nach P1 bis P4
|
||||
|
||||
Arbeit:
|
||||
|
||||
- 1 Durchgang Desktop
|
||||
- 1 Durchgang kleiner Viewport
|
||||
- 1 Durchgang fuer Tastatur-/Dialognutzung
|
||||
|
||||
Aktueller Stand:
|
||||
|
||||
- abgeschlossen
|
||||
- Audit dokumentiert in `docs/USABILITY_AUDIT_U1.md`
|
||||
- priorisierte Folgephase: `U2 Shell, Navigation und Feedback`
|
||||
|
||||
### Phase U2: Shell, Navigation, Feedback
|
||||
|
||||
Ergebnis:
|
||||
|
||||
- globale Bedienmuster sind konsistent
|
||||
|
||||
Arbeit:
|
||||
|
||||
- Navigation
|
||||
- Rueckwege
|
||||
- Fokuslogik
|
||||
- Dialog-/Feedbacksystem
|
||||
- Lade- und Leerezustaende
|
||||
|
||||
Aktueller Stand:
|
||||
|
||||
- abgeschlossen
|
||||
- Shell-Kontextbereich mit Bereichstitel und Rueckweg umgesetzt
|
||||
- Navigation um klareren Seitenkontext ergaenzt
|
||||
- zentrales Feedback-API eingefuehrt
|
||||
- Standard-Feedbackdialoge visuell und technisch vereinheitlicht
|
||||
- Kernfluesse aus Auth und Settings auf das neue Feedbackmuster umgestellt
|
||||
|
||||
### Phase U3: Formulare und Abschlussfluesse
|
||||
|
||||
Ergebnis:
|
||||
|
||||
- Eingaben, Speichern, Validierung und Rueckmeldung sind vereinheitlicht
|
||||
|
||||
Arbeit:
|
||||
|
||||
- Auth
|
||||
- Settings
|
||||
- Admin
|
||||
- Falukant-Formulare
|
||||
- Vokabel-Bearbeitungsfluesse
|
||||
|
||||
Aktueller Stand:
|
||||
|
||||
- abgeschlossen
|
||||
- gemeinsames Formularmuster fuer Hinweise, Fehler und Action-Row eingefuehrt
|
||||
- Dialogbuttons respektieren Disabled-Zustaende
|
||||
- Auth-Dialoge, Account-Settings, zentrale Admin-/Falukant-Formulare und Vokabel-Bearbeitungsfluesse auf sichtbarere Validierung und konsistentere Abschlusslogik umgestellt
|
||||
|
||||
### Phase U4: Komplexe Fachbereiche
|
||||
|
||||
Ergebnis:
|
||||
|
||||
- Falukant, Vokabeltrainer, Minigames und Admin sind auf Nutzbarkeit statt nur Funktion geprüft
|
||||
|
||||
Arbeit:
|
||||
|
||||
- Arbeitsablaeufe entlasten
|
||||
- Primaeraktionen schaerfen
|
||||
- Informationslast reduzieren
|
||||
|
||||
Aktueller Stand:
|
||||
|
||||
- abgeschlossen
|
||||
- Vokabeltrainer als Aufgabenhub mit getrennten Bereichen fuer eigene und abonnierte Sprachen
|
||||
- Falukant-Uebersicht um Routinekarten, verdichtete Kennzahlen und schnellere Folgeaktionen erweitert
|
||||
- Match3-Spiel um Ziel-/Statusleiste fuer den naechsten sinnvollen Schritt ergaenzt
|
||||
- Match3-Admin um klaren 3-Schritt-Arbeitsfluss, Formzusammenfassung und sicherere Speicherlogik erweitert
|
||||
|
||||
### Phase U5: Mobile und Endabnahme
|
||||
|
||||
Ergebnis:
|
||||
|
||||
- Kernaufgaben sind auf Standard-Viewports belastbar
|
||||
|
||||
Arbeit:
|
||||
|
||||
- letzte Layoutkorrekturen
|
||||
- Touch und Fokus
|
||||
- Abschlussreview entlang echter Nutzerszenarien
|
||||
|
||||
Aktueller Stand:
|
||||
|
||||
- abgeschlossen
|
||||
- Hauptnavigation auf kleinen Viewports zu einer verlässlich aufklappbaren Mobilnavigation mit Touch-gerechten Zielgroessen umgebaut
|
||||
- Header und Footer auf kleine Breiten mit stabileren Status- und Linkblöcken angepasst
|
||||
- Dialoge fuer kleine Viewports auf sichere Maximalgroessen und mobile Button-Stacks begrenzt
|
||||
- breite Tabellen auf kleinen Screens per horizontalem Scroll-Fallback abgesichert
|
||||
- globale Touch-Ziele fuer Buttons leicht vergroessert und letzte Shell-Kanten geglaettet
|
||||
|
||||
## Konkreter Arbeitskatalog
|
||||
|
||||
### 1. Shell und Navigation
|
||||
|
||||
- Menuepunkte auf Nutzungsprioritaet sortieren
|
||||
- Untermenues auf direkte Zielerreichung pruefen
|
||||
- Bereichskontext pro Seite konsistent machen
|
||||
- globale Ruecksprunglogik definieren
|
||||
|
||||
### 2. Dialog- und Feedbacksystem
|
||||
|
||||
- Dialogtypen definieren und dokumentieren
|
||||
- Standard fuer Erfolg, Fehler, Warnung, Leere, Laden festlegen
|
||||
- Inline-Feedback vor modalem Feedback bevorzugen, wenn kein harter Block noetig ist
|
||||
|
||||
### 3. Formsystem
|
||||
|
||||
- ein gemeinsames Muster fuer Label, Hilfetext, Fehlermeldung, Pflichtfeld
|
||||
- ein gemeinsames Muster fuer Save/Cancel/Delete
|
||||
- ein gemeinsames Muster fuer Tabellenfilter und Suchformulare
|
||||
|
||||
### 4. Bereichsreviews
|
||||
|
||||
- Social/Friends/Search/Forum entlang echter Aufgaben pruefen
|
||||
- Vokabeltrainer entlang des Lernpfads pruefen
|
||||
- Falukant entlang taeglicher Routinen pruefen
|
||||
- Admin entlang Such-/Editier-Routinen pruefen
|
||||
- Minigames entlang Einstieg/Pause/Neustart pruefen
|
||||
|
||||
### 5. Mobile Review
|
||||
|
||||
- Header/Nav/Footer mit realen Hoehen pruefen
|
||||
- breite Inhalte auf kleine Screens pruefen
|
||||
- Dialoge und Tabellen fuer Touch pruefen
|
||||
|
||||
## Definition of Done
|
||||
|
||||
Das Bedienbarkeitsprojekt gilt als abgeschlossen, wenn:
|
||||
|
||||
- fuer alle Hauptbereiche ein Audit stattgefunden hat
|
||||
- P1- und P2-Probleme aus dem Audit abgearbeitet sind
|
||||
- Navigation, Formulare, Dialoge und Feedback nach gemeinsamen Regeln funktionieren
|
||||
- Kernaufgaben auf Desktop und kleinem Viewport ohne strukturelle Reibung moeglich sind
|
||||
- Restpunkte nur noch P3/P4-Feinschliff sind
|
||||
|
||||
## Empfohlene Reihenfolge
|
||||
|
||||
1. Audit ueber Kernaufgaben
|
||||
2. Shell/Navigation/Feedback
|
||||
3. Formulare und Abschlusslogik
|
||||
4. Falukant, Vokabeltrainer, Admin, Minigames
|
||||
5. Mobile Endabnahme
|
||||
|
||||
## Naechster konkreter Schritt
|
||||
|
||||
Der erste sinnvolle Umsetzungsschritt ist nicht sofort Code, sondern ein kurzer UX-Audit-Durchgang ueber die wichtigsten Aufgabenfluesse. Daraus entsteht ein priorisierter Problemkatalog, auf dessen Basis die Bedienbarkeitsarbeit strukturiert umgesetzt wird.
|
||||
Reference in New Issue
Block a user