troogs
e6cd5f5a1d
Dieser PR setzt die Usability-Maßnahmen U01–U16 und die Nacharbeit an Betragseingabe, Toasts und Aktionsleisten um. Analyse: `docs/usability-analyse.md`; Plan und fortlaufendes Prüfprotokoll: `docs/usability-umsetzung.md`.
- **U01–U03:** konsistente SQLite-Sicherung der aktiven Daten einschließlich WAL, geprüfte Wiederherstellung mit Rückfallsicherung; strukturierte Dateioperationen; PDF-Auszüge nur mit wirksamen Buchungen, erklärtem Zeitraum, Kontostand und internen Umbuchungen.
- **U04–U07:** gemeinsamer Jahreskontext einschließlich Alle Jahre; Hinweise und Rückweg für abweichendes Buchungsjahr; Alltagssprache; erkennbare Konto-/Buchungsart und Validierung; Schutz vor mehrfacher Speicherung einschließlich Retry nach bereits bestätigtem Schreiben.
- **Nacharbeit:** gemeinsames Betragscontrol weist zusätzliche Nachkommastellen und ungültige Einfügungen vollständig ab, ohne zu kürzen oder zu runden. Globale stapelbare Toasts erscheinen oben, laufen zeitgesteuert ab und pausieren bei Hover/Fokus. Laufende Vorgänge bleiben bis Abschluss sichtbar. Einheitliche Aktionsbuttons reservieren Symbol und zwei Textzeilen. Debug-Datenordner für isolierte Frontend-Tests.
- **U08:** native Modaldialoge mit Fokus, inaktivem Hintergrund, Escape, Rückkehr zum Auslöser und Verlustschutz; semantische Kontolinks; sichere Bestätigungen starten auf Abbrechen.
- **U09:** größere beschriftete Zeilenaktionen mit Buchungsbezug und Kartenansicht im schmalen Fenster.
- **U10:** gelöschte Buchungen standardmäßig ausgeblendet, gezählt erreichbar und ausdrücklich nicht mitgerechnet; Bestätigungen erklären beide Transferkonten, gezieltes Rückgängig mit Zustandsprüfung.
- **U11:** dieselbe Von→Nach-Richtung auf beiden Seiten, festes/änderbares Konto und Minus/Plus-Vorschau; Dienst verhindert auch beim Bearbeiten gleiche Konten.
- **U12:** Anfangsbestand bei Einrichtung getrennt von späterer Korrektur. Korrektur zeigt Jahr/Konto und vorher/nachher, warnt vor Auswirkungen auf frühere/spätere Jahre und benötigt Zustimmung. Transaktionale Prüfung weist veraltete Vorschau ab. Die gemeinsame Bestandssemantik bleibt erhalten; keine Migration oder neue Jahresspeicherung.
- **U13:** lesbare Grundschrift, lokal gespeicherte Textgröße bis 200 %, umbrechende Namen, responsive Formulare/Karten und im Fenster scrollbar bleibende Dialoge. Stichproben der Text-/Betragsrollen mindestens 5,91:1 (hell) bzw. 8,37:1 (dunkel); primäre Aktionsfarben mindestens 6,47:1.
- **U14:** sichtbare lokale Hilfe und überspringbare Einführung mit gespeichertem Fortschritt: Vereinsname, eigenes Konto/Anfangsbestand, tatsächliche erste Buchung und Sicherung. Keine Registrierung oder automatisch erzeugte Beispielbuchungen.
- **U15:** Suche über Beschreibung, Nummer, Datum, Gegenkonto und deutschen Betrag; Sortierung nach Datum, vorzeichenrichtigem Betrag oder Beschreibung. Trefferzahl und wirksame Treffermengensumme sind vom unveränderten Kontostand getrennt. Reset erhält den gewählten Jahreskontext.
- **U16:** Bootstrap 5.3.3 und Bootstrap Icons 1.11.3 samt lokalen Schriftdateien und MIT-Lizenzen werden ausgeliefert; keine CDN-Ressourcen beim Start. Unerwartete Fehler bieten Wiederholung/Übersicht und kopierbare Referenz/Fehlertyp ohne Buchungsdaten. Nicht gefunden bietet Rückweg. Erwartbare Speicherfehler erhalten Eingaben.
Validierung: **60/60 Tests in Debug und 60/60 in Release**, einschließlich SQLite-WAL/Restore, PDF-Textextraktion, mehrjähriger Bestandskorrektur, Transferänderungen von beiden Seiten, Löschung/Undo beider Transferbuchungen, Formular-/Navigationsabläufen, Einführungsfortsetzung, Suche aus 400 Einträgen und anonymisierter Fehleranzeige. Nach jeder Maßnahme Desktop gebaut und Debug-Tests ausgeführt; final auch Release-Desktop-Build. Keine Buildwarnungen, `git diff --check` sauber. PDF-Einzelkonto, Übersicht und mehrseitiger Auszug visuell geprüft.
Computer Use mit künstlichem Bestand: zusätzliche Nachkommastelle abgewiesen, gültige 12,50-€-Einnahme gespeichert, Kontostand und Toast kontrolliert. U08-Fokus im Eingabefeld, ausschließlich modaler Accessibility-Baum und Escape-Schließen beobachtet. Nach erneuter Fensterzuordnung finale Anwendung mit lokalen Ressourcen gestartet; beschriftetes Zeilenmenü und korrekte Umbuchungsrichtung von der empfangenen Seite kontrolliert. Bestandskorrektur zeigt Konto/Jahr, Formel, Vorher/Nachher und Warnung für alle Jahre, ohne zu speichern. Dabei gefundene Textbindung im Betragsfeld korrigiert und als Regression geprüft; ebenso erklärter Leerzustand, sichtbares Undo-Refresh und zweites Escape im Verlustschutz.
Offline-Layoutprüfung: tatsächliche gerenderte Komponenten mit Produktions-CSS/Schriften in Headless Chromium, Browsernetz blockiert, **0 externe Requests**. **16 Kombinationen** bei 768 × 480 CSS-Pixeln, hell/dunkel und 100/125/150/200 % Textgröße bestehen; keine horizontale Seitenüberschreitung, Dialog im Fenster, Speichern/Abbrechen durch Scrollen erreichbar. Repräsentative PNGs visuell geprüft.
Grenzen: Browser-Textvergrößerung ist kein vollständiger Test realer Windows-DPI-Einstellungen. Keine vollständige Screenreader-/Zielgruppenabnahme und kein Nutzertest mit unerfahrenen Personen behauptet. Native Fensterzuordnung war zeitweise instabil; deshalb sind automatisierte Komponentenprüfungen und Browser-Layoutnachweise ausdrücklich von den beschriebenen nativen Beobachtungen getrennt. Keine Vereinsdaten geändert oder zurückgespielt, keine Bankvorgänge ausgeführt. Keine neue Jahres-Speichersemantik; Rückfallsicherungen werden nicht automatisch gelöscht. Vereinsname, Einführungsfortschritt und Darstellung gehören nicht zum Datenbank-Backup.
U08–U12 wurden einzeln committed und als Paket gepusht; U13–U16 ebenfalls in eigenen sachlichen Commits. Nacharbeit an Betragseingabe/Toasts/Aktionsleisten liegt in `86a73b8`. Plan und Prüfprotokoll: `docs/usability-umsetzung.md`. Kein Merge; zur manuellen Analyse durch den Auftraggeber.
Weitere Bedienkorrekturen nach manueller Analyse:
- Betragscontrol blockiert zusätzliche Nachkommastellen und ungültige Einfügungen jetzt ohne Warnmeldung.
- Jahreswechselhinweis als Warnbox mit Symbol, Datum und beiden Jahren. Er erscheint beim Verlassen des Datumsfelds; der native Kalender bleibt beim Blättern über den Jahreswechsel geöffnet. Submit ohne vorherigen Fokuswechsel prüft den aktuellen Datumsentwurf; Verlustschutz berücksichtigt ihn sofort. Gilt auch für Umbuchungen.
- Historie als beschrifteter Switch mit vertikalem Abstand. Direkt sichtbare Stift-/Papierkorbbuttons mit mindestens 44 × 44 Pixeln, Title und buchungsbezogenem Accessibility-Namen ersetzen das Zeilenmenü.
- Windows-Anwendungssymbol: ungenutzte native Photino-Benachrichtigungsregistrierung deaktiviert, damit sie die explizite Windows-App-ID nicht überschreibt und keine dotnet-Host-Verknüpfungen erzeugt. Bestehendes Icon bleibt in EXE und nativem Fenster eingebunden.
Zusätzliche Validierung: 60/60 Debug- und 60/60 Release-Tests; beide Desktop-Builds und eigenständige Windows-Einzeldatei ohne Warnungen/Fehler. Alle 16 Offline-Layoutkombinationen erneut bestanden. Computer Use bestätigt Switch, direkten Bearbeiten-Button, stille Abweisung der dritten Nachkommastelle und geöffneten nativen Kalender beim Blättern von Dezember 2026 nach Januar 2027; Warnbox erscheint nach Wechsel zur Beschreibung. Kein Speichern in diesem Prüflauf. Das aus der veröffentlichten EXE extrahierte Icon und das Titelleistensymbol wurden visuell geprüft; Taskleistendarstellung nicht separat erfasst. UI-Nacharbeit in aa39281; Windows-Zuordnung in eigenem Commit. Kein Merge.
Weitere UI-Korrekturen in 038fbc0: Stift-/Papierkorbsymbole horizontal und vertikal zentriert, Tabellenkopf mit Designfarben statt festem hellem Hintergrund. Alle sechs allgemeinen „Dateiaktion läuft“-Meldungen durch konkrete Angaben zu Sicherung, Wiederherstellung, PDF-Übersicht, Kontoauszug bzw. PDF-Öffnen ersetzt. 60/60 Tests in Debug und Release, beide Desktop-Builds ohne Warnungen/Fehler. Zusätzliche Browserprüfung bei 100/200 % in hell/dunkel: Symbolzentrierung innerhalb 0,6 Pixeln, mindestens 44 × 44 Pixel große Buttons, Headerkontrast 17,85:1 (hell) bzw. 12,89:1 (dunkel); alle 16 bisherigen Offline-Layoutkombinationen bestanden und dunkler Tabellenkopf visuell geprüft.
Textgröße um „Klein (75 %)“ ergänzt, einschließlich Speicherung und Wiederherstellung beim Start. Debug-Suite 60/60 bestanden, Desktop-Build ohne Warnungen/Fehler. JavaScript-Prüfung bestätigt 12-Pixel-Grundschrift bei 75 % und korrektes Speichern/erneutes Laden der Auswahl.
Anzeige gelöschter Buchungen dauerhaft und kontenübergreifend: gespeicherte benutzerweite Einstellung wird bei jedem Konto geladen und bleibt über Neustarts sowie „Filter zurücksetzen“ bestehen, bis der Switch ausgeschaltet wird. Neue Regressionen prüfen Kontowechsel, Reset, Ausschalten, Neustart und Erhalt anderer Einstellungen. 62/62 Tests jeweils in Debug und Release; Debug-Build ohne Warnungen/Fehler. Vorhandenen Publish-Task erfolgreich ausgeführt: Publish/Duempelkas-v26.306.exe. Die bereits vorhandene lokale Kontokarten-Anpassung des Auftraggebers ist in der lokalen Veröffentlichung enthalten und bleibt außerhalb dieses Commits.
Über-Dialog zeigt neben der Version das Builddatum im Format TT.MM.JJJJ. Zeitstempel wird beim Desktop-Build als Assembly-Metadatum eingebettet und funktioniert dadurch auch bei der Einzeldatei-Veröffentlichung. Eingebettetes Datum aus erzeugter Desktop-Assembly geprüft; 62/62 Tests jeweils in Debug und Release, Debug-Build ohne Warnungen/Fehler. Publish-Task erneut erfolgreich ausgeführt und Publish/Duempelkas-v26.306.exe aktualisiert.
Reviewed-on: #1
184 lines
24 KiB
Markdown
184 lines
24 KiB
Markdown
# Usability-Analyse: Dümpelkas für Menschen mit wenig Computererfahrung
|
||
|
||
Stand: 1. November 2026. Untersuchte Quellcodebasis: `9823945` auf `main`; laufende Windows-Debug-Anwendung: Version 26.305 aus `.artifacts/bin/Debug/net10.0`.
|
||
|
||
## Ziel und Ergebnis
|
||
|
||
Eine gelegentlich arbeitende Kassenführung soll ohne Fachwissen erkennen: Wo bin ich? Was muss ich eingeben? Hat das Speichern funktioniert? Wie komme ich nach einem Fehler zurück?
|
||
|
||
Dümpelkas hat dafür eine gute Grundlage: wenige Hauptansichten, große Schaltflächen für häufige Aufgaben, sichtbare Kontostände, Vorzeichen bei Beträgen und wiederherstellbare Buchungen. Die größten Verbesserungen liegen bei verständlichen Beschriftungen, verlässlichen Rückmeldungen, dem Jahreskontext und einer sicheren Datenrettung. Zusätzliche Rückfragen bei jeder gewöhnlichen Buchung würden den Alltag eher erschweren; Bestätigungen sollten auf folgenreiche Aktionen konzentriert bleiben.
|
||
|
||
**Empfohlener Start:** zuerst U01–U03 für verlässliche Daten und Ausgaben, danach U04–U08 für die tägliche Bedienung. U09–U16 ergänzen Orientierung, Lesbarkeit und Komfort. Die Priorität bezeichnet eine Empfehlung, keine bereits beschlossene Umsetzung.
|
||
|
||
## Vorgehen und Grenzen der Aussage
|
||
|
||
- Erneute Quellcodeprüfung von Startseite, Kontoansicht, Buchungs- und Umbuchungsdialog, Übertrag, Bestätigungen, Kontokarten, Buchungslisten, Layout, CSS, Datenpfad, Sicherung und PDF-Ausgabe.
|
||
- Erneute Live-Prüfung über den Computer-Use-Skill: Kontoansicht mit aktiven und gelöschten Zeilen, Öffnen des neuen Buchungsdialogs, Accessibility-Baum und Fokus, Escape-Verhalten und Abbrechen. Zusätzlich wurde der neue Umbuchungsdialog geöffnet, seine Felder geprüft und ohne Speichern geschlossen. Weitere Dialoge wurden in diesem Durchlauf anhand des Codes beurteilt.
|
||
- Die bestehende Testbuchung aus dem vorausgehenden Update ist vorhanden. Für diese Analyse werden keine neuen Buchungen angelegt und keine vorhandenen Daten geändert. Keine Sicherung wird zurückgespielt.
|
||
- Bestehende [Bedienungsanleitung](bedienungsanleitung.md) und [Programmstand](programmstand.md) dienen als Orientierung; die hier aufgeführten Codebefunde wurden erneut an den Quellen geprüft.
|
||
- Dies ist eine fachliche Oberflächenprüfung durch einen Reviewer, kein Nutzertest mit der Zielgruppe. Aussagen wie „kann verwirren“ sind begründete Hypothesen. Keine gemessenen Fehlerraten, keine behauptete Barrierefreiheitszertifizierung.
|
||
- Nicht in diesem Durchlauf geprüft: vollständiger Screenreader-Ablauf, Offline-Start, mehrere Bildschirm-Skalierungen, große Datenmengen, echte Wiederherstellung und neu erzeugte PDF-Dateien. Codebefunde dazu sind ausdrücklich von Live-Beobachtungen getrennt.
|
||
|
||
## Prioritäten und Aufwand
|
||
|
||
**P0:** vor einer verlässlichen Nutzung durch unerfahrene Personen beheben; Datenvertrauen oder Wiederherstellbarkeit betroffen. **P1:** hoher Nutzen für häufige Aufgaben und Fehlervermeidung. **P2:** Komfort und nachhaltige Einführung. Aufwand **S/M/L** ist eine relative Einschätzung für Implementierung einschließlich gezielter Prüfung, keine Zeit- oder Kostenzusage.
|
||
|
||
## Empfohlene Maßnahmen mit Umsetzungskriterien
|
||
|
||
### U01 · Sicherung und Wiederherstellung müssen dieselben aktiven Daten verwenden
|
||
|
||
**P0 · L · Codebefund.** [Programmstart](../src/Duempelkas.Desktop/Program.cs) öffnet `%APPDATA%/Duempelkas/duempelkas.db`; [BackupService](../src/Duempelkas.Infrastructure/Services/BackupService.cs) verwendet die Datei neben dem Prozessprogramm. Eine Person kann deshalb glauben, ihre Buchungen gesichert oder wiederhergestellt zu haben, obwohl eine andere Datei betroffen ist. Zusätzlich ist die rohe Dateikopie bei aktiver SQLite-Nutzung keine hinreichend geprüfte Sicherungsstrategie.
|
||
|
||
**Maßnahme:** eine gemeinsame Quelle für den aktiven Datenpfad; konsistente SQLite-Sicherung; Prüfung einer gewählten Sicherung vor dem Austausch; koordinierter Zugriff während der Wiederherstellung; automatische Rückfallsicherung der bisherigen aktiven Daten. Umfang verständlich erklären: derzeit enthält die Sicherung keine Vereinseinstellungen oder Darstellung. Eine automatische Sicherung beim Beenden erst ergänzen, wenn Fehlerbehandlung, Aufbewahrung und Wiederherstellbarkeit festgelegt sind. Eine Kopie auf derselben Festplatte nicht als Schutz gegen Geräteausfall darstellen.
|
||
|
||
**Abnahme:** Eine neue Testbuchung ist nach Sicherung, weiterer Änderung und Wiederherstellung in einer isolierten Testumgebung exakt im erwarteten Stand vorhanden. Beschädigte oder ungeeignete Dateien werden vor dem Austausch abgewiesen; die bisherigen Daten bleiben nutzbar. Auch bei SQLite-WAL-Nutzung gehen keine bestätigten Buchungen verloren. Dokumentieren, welche Einstellungen enthalten sind. Wiederherstellung niemals zur Abnahme auf dem echten Vereinsdatenbestand ausprobieren.
|
||
|
||
### U02 · Jede Dateioperation mit verständlichem Ergebnis abschließen
|
||
|
||
**P0 · M · Codebefund.** [Dashboard.HandleBackupAsync](../src/Duempelkas.App/Pages/Dashboard.razor.cs) zeigt nur Texte an, die „fehlgeschlagen“ enthalten. „Keine Datenbankdatei gefunden.“ und erfolgreiche Sicherungen bleiben damit unsichtbar. [FileSaveService](../src/Duempelkas.Infrastructure/Services/FileSaveService.cs) und PDF-Aufrufer bieten keinen durchgehenden nutzerfreundlichen Fehlerpfad.
|
||
|
||
**Maßnahme:** strukturierte Ergebnisse für Erfolg, Abbruch und Fehler; Meldung beispielsweise „Sicherung gespeichert: …“, mit „Ordner öffnen“. Abbruch neutral behandeln. Fehler nennen den nächsten sicheren Schritt, etwa einen anderen Speicherort wählen; technische Details nur auf Wunsch. Während längerer Aktionen Status und Sperre gegen mehrfaches Starten anzeigen.
|
||
|
||
**Abnahme:** Erfolg, Abbruch, fehlende Quelldatei, Schreibschutz und fehlgeschlagenes Öffnen sind unterscheidbar. Ein Fehler führt weder zu einer Erfolgsmeldung noch zum Verlust der aktuellen Ansicht. Die Meldung ist auch per Hilfstechnologie wahrnehmbar. Abhängig von U01.
|
||
|
||
### U03 · PDF und Bildschirmsummen müssen dieselbe Bedeutung haben
|
||
|
||
**P0 · M · Codebefund.** [GenerateStatementAsync](../src/Duempelkas.Infrastructure/Services/PdfStatementService.cs) druckt alle gelieferten Einträge, einschließlich gelöschter Zeilen, ohne Löschkennzeichnung. Die Saldenberechnung lässt gelöschte Einträge aus; die gemeinsame PDF filtert sie ebenfalls aus. Für eine Kassenführung sieht das wie ein Rechenfehler aus.
|
||
|
||
**Maßnahme:** normale Auszüge enthalten nur wirksame Buchungen. Falls eine Historie gewünscht ist, diese ausdrücklich als separaten Modus mit Status und erklärter Summenbildung anbieten. Zeitraum, Konto und Bedeutung des Endstands in jedem Export eindeutig nennen.
|
||
|
||
**Abnahme:** Beispiel mit Einnahme, Ausgabe, Umbuchung und gelöschter Buchung liefert erklärbar gleiche Summen in Kontoansicht, Einzelkonto-PDF und gemeinsamer Übersicht. Die unterschiedliche Darstellung interner Umbuchungen muss dabei ausdrücklich berücksichtigt werden. Tests prüfen Inhalte und Summen; eine visuelle PDF-Prüfung kontrolliert Lesbarkeit und Seitenumbrüche.
|
||
|
||
### U04 · Jahreskontext beim Navigieren und Buchen erhalten
|
||
|
||
**P1 · M · Codebefund.** [Dashboard](../src/Duempelkas.App/Pages/Dashboard.razor.cs) und [AccountDetail](../src/Duempelkas.App/Pages/Accounts/AccountDetail.razor.cs) starten jeweils unabhängig im aktuellen Jahr. Neue Dialoge verwenden immer das heutige Datum. Eine Buchung kann damit außerhalb des sichtbaren Jahres gespeichert werden; ein auf der Startseite gewähltes Jahr geht beim Kontoaufruf verloren.
|
||
|
||
**Maßnahme:** „Jahr: 2026“ statt „Ansicht 2026“, Filter beim Wechsel zwischen Übersicht und Konto erhalten, aktuellen Zeitraum neben Liste und Summen nennen. Bei abweichendem Buchungsjahr vor dem Speichern gezielt informieren und danach „Buchung im Jahr 2025 anzeigen“ anbieten. Kein stilles Umsetzen des Datums auf ein anderes Jahr. Bei leerer Liste zwischen „noch keine Buchungen“ und „keine Buchungen in diesem Zeitraum“ unterscheiden.
|
||
|
||
**Abnahme:** Jahr 2025 auf der Übersicht wählen, Konto öffnen und zurückkehren erhält 2025. Eine Buchung mit Datum 2026 wird im 2025-Filter erklärt und auffindbar gemacht. Auch „Alle Jahre“, Jahreswechsel und eine noch leere Jahresauswahl funktionieren. Ein fachlich unverändertes Datum darf nicht allein aus Bequemlichkeit umgeschrieben werden.
|
||
|
||
### U05 · Aufgaben in Alltagssprache benennen und gewichten
|
||
|
||
**P1 · S · Code und sichtbare Kontoansicht.** Große Schaltflächen sind bereits hilfreich; „Buchung“, „PDF“, „Restore“, „Saldo“ und „Umsätze“ verlangen jedoch Vorwissen. Auf der Startseite stehen häufige und seltene Aktionen gleichberechtigt nebeneinander.
|
||
|
||
**Maßnahme:** „Einnahme oder Ausgabe erfassen“, „Geld zwischen Konten verschieben“, „Als PDF speichern“, „Sicherung erstellen“, „Sicherung zurückspielen“. „Kontostand“ statt „Saldo“; „Änderung im Jahr“ statt des uneindeutigen Netto-Begriffs „Umsätze“. Eine konsistente Anrede verwenden. Sicherung zurückspielen unter klar benannten weiteren Aktionen platzieren, weiterhin auffindbar. Sichtbarer Hinweis beim Kontenverschieben: „Erfasst nur die Buchung. Führt keine Banküberweisung aus.“
|
||
|
||
**Abnahme:** Beschriftungen passen ohne Abschneiden in die überarbeitete Leiste; die bisherige feste Breite von 75 px muss dafür angepasst werden. Eine Testperson findet Erfassen, PDF und Sicherung ohne Erklärung von Symbolen. Vertraute Begriffe wie „Umbuchung“ können als ergänzende Erläuterung erhalten bleiben.
|
||
|
||
### U06 · Buchungsformular erklärt Konto, Art und ungültige Eingaben
|
||
|
||
**P1 · M · Code und Live-Dialog.** Der neue Dialog zeigt „Neue Buchung“, standardmäßig Einnahme, Betrag 0 und einen deaktivierten Hinzufügen-Knopf. Es fehlt ein sichtbarer Grund für die Sperre; das betroffene Konto steht nicht im Dialog. Beim Bearbeiten fehlt die Art-Auswahl vollständig.
|
||
|
||
**Maßnahme:** Konto im Titel nennen, Einnahme/Ausgabe deutlich auswählbar machen und beim Bearbeiten wenigstens sichtbar anzeigen. Beispiele wie „Mitgliedsbeitrag“ oder „Porto“; Hinweis „Betrag ohne Minuszeichen“. Feldnahe Hinweise bei fehlender Beschreibung, ungültigem Datum oder Betrag. Eingaben `12,50`, `12.50` und eingefügte Beträge bewusst spezifizieren und ohne heimliche Wertänderung behandeln. Eine versehentlich falsche Buchungsart braucht einen verständlichen Korrekturweg; vor einer direkten Änderung fachliche Regeln festlegen.
|
||
|
||
**Abnahme:** Leeres Formular erklärt, was fehlt. Deutsche Dezimaleingaben und mehr als zwei Nachkommastellen haben ein definiertes, geprüftes Verhalten. Negative Beträge werden verständlich behandelt. Das Speichern bleibt nach Fehlern mit erhaltenen Eingaben möglich; die Buchungsart ist jederzeit erkennbar.
|
||
|
||
### U07 · Speichern bestätigen und Doppelbuchungen verhindern
|
||
|
||
**P1 · M · Codebefund.** [AddEntryDialog](../src/Duempelkas.App/Components/Dialogs/AddEntryDialog.razor.cs) und [AddTransferDialog](../src/Duempelkas.App/Components/Dialogs/AddTransferDialog.razor.cs) haben keinen sichtbaren Speichervorgang und keine eigene Sperre gegen erneutes Auslösen. Nach Erfolg schließt der Dialog ohne ausdrückliche Bestätigung auf der Kontoseite.
|
||
|
||
**Maßnahme:** während des Speicherns „Wird gespeichert …“, Aktion gegen Mehrfachauslösung schützen, nach Erfolg „Einnahme über 12,50 € gespeichert“ und die neue Zeile kurz hervorheben. Bei Fehlern Eingaben erhalten. Für Serienerfassung optional „Speichern und weitere erfassen“ ergänzen, ohne die normale Aktion zu verkomplizieren. Ähnliche Buchungen allenfalls als Hinweis behandeln, da gleiche Beträge legitim sind.
|
||
|
||
**Abnahme:** Doppelklick und wiederholtes Enter während einer verzögerten Speicherung erzeugen genau eine Buchung. Ein fehlgeschlagener Versuch erzeugt keine irreführende Bestätigung. Erneutes bewusstes Erfassen bleibt möglich. Kein zusätzlicher Bestätigungsdialog bei jeder normalen Einnahme.
|
||
|
||
### U08 · Dialoge und Kontokarten vollständig per Tastatur bedienen
|
||
|
||
**P1 · M · Code und Live-Teilprüfung.** Dialoge bestehen aus allgemeinen `div`-Elementen, Beschriftungen sind überwiegend nicht per `for`/`id` mit Feldern verbunden. [Kontokarten](../src/Duempelkas.App/Components/Accounts/AccountCard.razor) sind klickbare `div`s. Beim live geöffneten Buchungsdialog wurde kein Eingabefeld automatisch fokussiert; Escape schloss ihn nicht. Der Accessibility-Baum enthielt weiterhin Hintergrundelemente; ein vollständiger Screenreader-Test wurde nicht durchgeführt.
|
||
|
||
**Maßnahme:** semantische Links für Konten, echte Schaltflächen für Aktionen, Dialogrolle und beschrifteter Titel, Fokus ins erste sinnvolle Feld, Fokus im Dialog halten und beim Schließen zum Auslöser zurückgeben. Escape schließt unveränderte Dialoge. Bei veränderten Eingaben Verlust abfangen. Enter nur in passenden Formularen als Speichern, nie als unbeabsichtigte Löschbestätigung. Labels, Fehlermeldungen und Eingaben technisch verbinden.
|
||
|
||
**Abnahme:** Konto öffnen, Buchung eingeben und abbrechen sind ausschließlich mit Tab, Umschalt-Tab, Enter und Escape möglich. Während eines modalen Dialogs sind Hintergrundaktionen nicht bedienbar. Fokus ist sichtbar, Titel/Feldname/Fehler werden vorgelesen. Unsichere Bestätigungen starten auf Abbrechen.
|
||
|
||
### U09 · Kleine Symbolaktionen lesbar und leichter treffbar machen
|
||
|
||
**P1 · S · Code und Live-Ansicht.** Stift, Papierkorb und Wiederherstellen sind kleine Symbolknöpfe. Tooltips helfen erst beim Darüberfahren; in langen Zeilen ist die Zuordnung fehleranfällig. `title`-Attribute sind bereits vorhanden, ersetzen aber keine sichtbare Erklärung.
|
||
|
||
**Maßnahme:** größere Trefferflächen und sichtbare Texte oder ein pro Zeile beschriftetes Aktionsmenü. Als Projektziel etwa 40–44 CSS-Pixel hohe Trefferbereiche vorsehen. Eindeutige zugängliche Namen mit Buchungsbezug; Bearbeiten und Löschen mit ausreichend Abstand. Wiederherstellen als Wort anbieten.
|
||
|
||
**Abnahme:** ungeübte Mausbedienung trifft die gewünschte Aktion zuverlässig, auch bei Windows-Skalierung. Tab-Fokus nennt die zugehörige Buchung. Kein Verlust von Tabelleninhalt durch unnötig große Aktionsspalten; bei schmaler Ansicht ein geprüftes Alternativlayout.
|
||
|
||
### U10 · Löschen, Wiederherstellen und verbundene Umbuchungen erklären
|
||
|
||
**P1 · M · Code und sichtbare gelöschte Zeilen.** Durchgestrichene Buchungen bleiben zwischen aktiven Zeilen stehen. Die [Bestätigungen](../src/Duempelkas.App/Pages/Accounts/AccountDetail.razor) nennen nur den Titel; [EntryService](../src/Duempelkas.Infrastructure/Services/EntryService.cs) verändert bei Umbuchungen auch die Gegenbuchung.
|
||
|
||
**Maßnahme:** gelöschte Einträge standardmäßig ausblenden, mit „Gelöschte Buchungen anzeigen (2)“ erreichbar halten; sichtbarer Status „Gelöscht – zählt nicht zum Kontostand“. Bestätigung mit Datum, Betrag und Konto. Bei Umbuchungen beide betroffenen Konten und gemeinsame Wirkung nennen. Nach Erfolg eine klar zugeordnete Rückgängig-Aktion anbieten, soweit fachlich und technisch eindeutig.
|
||
|
||
**Abnahme:** Entfernen und Wiederherstellen einer Umbuchung aktualisiert beide Seiten nachvollziehbar; Bestätigung benennt dies vorab. Versehentliches Löschen ist ohne Fachwissen rückgängig zu machen. Eine sichtbare Historie darf nicht als mitgerechnete Buchung missverstanden werden. Abhängig von U03 für konsistente Exporte.
|
||
|
||
### U11 · Umbuchungen als Richtung zwischen zwei Konten zeigen
|
||
|
||
**P1 · M · Codebefund.** [AddTransferDialog](../src/Duempelkas.App/Components/Dialogs/AddTransferDialog.razor) zeigt nur „Zielkonto“. Beim Bearbeiten einer empfangenen Buchung ist das angezeigte verknüpfte Konto jedoch das abgebende Konto. Das begünstigt eine falsche Interpretation.
|
||
|
||
**Maßnahme:** immer „Von: Barkasse → Nach: Girokonto“ zeigen; auf beiden Buchungsseiten dieselbe fachliche Richtung. Den festen bzw. änderbaren Teil ausdrücklich benennen. Kurze Zusammenfassung „Barkasse −50,00 €, Girokonto +50,00 €; Gesamtsumme unverändert“. Bei nur einem vorhandenen Konto erklären, warum keine Umbuchung möglich ist.
|
||
|
||
**Abnahme:** Öffnen von beiden Seiten zeigt dieselbe Richtung. Änderungen betreffen die beabsichtigte Seite und behalten die Verknüpfung. Gleiche Quelle und Ziel werden auch im Dienst abgewiesen. Geld wird nicht doppelt als Vereinseinnahme dargestellt.
|
||
|
||
### U12 · Anfangsbestand und Jahresübertrag vor unbeabsichtigter Änderung schützen
|
||
|
||
**P1 · L · Codebefund.** [UpdateCarryoverAsync](../src/Duempelkas.Infrastructure/Services/AccountService.cs) verändert den gemeinsamen Anfangsbestand anhand des gewünschten Jahresübertrags. Der [Dialog](../src/Duempelkas.App/Components/Dialogs/EditCarryoverDialog.razor) zeigt weder Jahr noch Folgen. Ein scheinbarer lokaler Jahreswert kann andere Jahre beeinflussen.
|
||
|
||
**Maßnahme:** Einrichtung eines neuen Kontos und spätere Bestandskorrektur getrennt erklären. Einfache Formel anzeigen: „Anfangsbestand + Einnahmen − Ausgaben = Kontostand“. Spätere Änderung als bewusste Korrektur mit vorher/nachher und Hinweis auf betroffene Jahre. Ob künftig jahresbezogene Korrekturen statt eines gemeinsamen Anfangsbestands gebraucht werden, muss fachlich entschieden werden; das ist keine reine Textänderung.
|
||
|
||
**Abnahme:** Eine Testperson kann die Wirkung vor dem Speichern richtig erklären. Automatisierte Mehrjahresbeispiele prüfen die vereinbarte Semantik. Bei Änderung der Speicherung sind Datenmigration und Bestandserhalt eigene Abnahmepunkte.
|
||
|
||
### U13 · Schrift, Kontrast und Fenstergröße an reale Arbeitsplätze anpassen
|
||
|
||
**P1 · M · CSS und Live-Ansicht; keine gemessene Kontrastbewertung.** [app.css](../src/Duempelkas.Desktop/wwwroot/css/app.css) verwendet viele kleine Schriftgrößen und halbtransparente gelöschte Zeilen. Die Dialoge haben feste Mindestbreiten und keine eigene begrenzte Höhe mit Scrollbereich. Im aufgenommenen dunklen Fenster sind Zusatztexte und Symbolaktionen deutlich kleiner als die Hauptsumme.
|
||
|
||
**Maßnahme:** gut lesbare Grundschrift, weniger kleine Großbuchstaben, skalierbare Abstände und optional „Schriftgröße: normal/groß“. Beide Farbdarstellungen mit gemessenem Kontrast prüfen, Zeichen und Text zusätzlich zu Farben erhalten. Dialoge müssen innerhalb des verfügbaren Fensters scrollbar bleiben; wichtige Knöpfe dürfen nicht außerhalb des sichtbaren Bereichs liegen.
|
||
|
||
**Abnahme:** alle Hauptaufgaben im unterstützten Mindestfenster 768 × 480 sowie bei 125/150/200 % Windows-Skalierung prüfen. Lange Namen, Beträge und Fehlermeldungen bleiben lesbar; kein verdecktes Speichern/Abbrechen. Helle und dunkle Darstellung getrennt kontrollieren. Kein Versprechen vollständiger Barrierefreiheit allein aufgrund dieser Stichprobe.
|
||
|
||
### U14 · Erste Nutzung und Hilfe direkt am Bedarf anbieten
|
||
|
||
**P2 · M · Codebefund.** Die leere Startseite fordert zum ersten Konto auf; der Kontodialog fragt nur nach einem Namen. Die vorhandene ausführliche Anleitung ist im [Layout](../src/Duempelkas.App/Components/Layout/MainLayout.razor) nicht als Hilfe erreichbar.
|
||
|
||
**Maßnahme:** überspringbare kurze Einführung: Vereinsname, erstes Konto mit Beispielen, erklärter Anfangsbestand, erste Buchung, Sicherung. „Hilfe“ sichtbar anbieten, lokal verfügbar und passend zur Programmversion. Kurze Beispiele direkt bei Übertrag und Umbuchung; vollständige Anleitung ergänzend. Keine Pflichtregistrierung und keine langen Erklärungen vor jeder Buchung.
|
||
|
||
**Abnahme:** eine neue Person richtet mit selbst gewählten Angaben ein Konto ein und findet die Hilfe ohne Internet. Überspringen und späteres Fortsetzen funktionieren. Keine automatischen Beispielbuchungen im echten Datenbestand. U01 und U12 vor einem geführten Sicherungs-/Anfangsbestandsablauf umsetzen.
|
||
|
||
### U15 · Buchungen ohne langes Scrollen wiederfinden
|
||
|
||
**P2 · M · Codebefund.** [EntryTable](../src/Duempelkas.App/Components/Accounts/EntryTable.razor) bietet keine Suche und keine bedienbare Sortierung. Bei vielen Einträgen reichen Jahresfilter und fortlaufende Nummer allein nicht aus.
|
||
|
||
**Maßnahme:** einfache Suche nach Bezeichnung oder Buchungsnummer, optional Datum und Betrag. Aktive Filter mit „Filter zurücksetzen“ sichtbar machen. Falls später Seitennavigation nötig wird, Trefferzahl und Position zeigen. Bei gefilterter Liste eindeutig zwischen Kontostand des Jahres und Summe der Treffer unterscheiden.
|
||
|
||
**Abnahme:** eine bekannte Buchung wird aus einem größeren Beispieldatenbestand ohne Durchscrollen gefunden. „Keine Treffer“ enthält eine Rückkehr zur vollständigen Liste. Suchen ändert den Kontostand nicht stillschweigend. Sonderzeichen und deutsche Betragsnotation sind berücksichtigt.
|
||
|
||
### U16 · Offline-Betrieb und verständliche Fehlerauswege absichern
|
||
|
||
**P1 · M · Codebefund, Offline-Auswirkung noch zu prüfen.** [index.html](../src/Duempelkas.Desktop/wwwroot/index.html) lädt Bootstrap und Symbole von externen CDNs. Das allgemeine Fehlerbanner spricht von einem „unbehandelten Fehler“. Die Nicht-gefunden-Ansicht bietet keinen eigenen Rückweg.
|
||
|
||
**Maßnahme:** benötigte Darstellungsmittel lokal mitliefern, wenn das Kassenbuch offline nutzbar sein soll. Fehlertexte mit „Was ist passiert?“ und sicherer nächster Aktion; keine technischen Stapelspuren als einzige Hilfe. Eingaben nach erwartbaren Speicherfehlern erhalten. Für unerwartete Fehler einen Hinweis zur Meldung, mit optional kopierbaren technischen Details ohne unnötige personenbezogene Buchungsdaten. Nicht gefunden: „Zur Kontenübersicht“ anbieten.
|
||
|
||
**Abnahme:** Start ohne Netz und mit leerem WebView-Cache zeigt lesbare, bedienbare Oberflächen einschließlich Symbolen. Simulierter Speicherfehler bewahrt Eingaben; Neuladen behauptet keinen unbestätigten Speichervorgang. Offline-Verhalten ist vor einer entsprechenden Produktzusage getestet.
|
||
|
||
## Vorschlag für spätere Umsetzungspakete
|
||
|
||
Die IDs bleiben stabil, damit dieser Pull Request als Diskussions- und Auswahlgrundlage dienen kann. Eine Auswahl bedeutet noch keine abgeschlossene Umsetzung.
|
||
|
||
- [ ] **A – Verlässliche Daten:** U01, U02, U03; isolierte Sicherungs-/Restore-Tests und PDF-Inhaltsprüfung zuerst.
|
||
- [ ] **B – Sicher erfassen:** U04, U06, U07, U11, U12; Jahreskontext, Eingabe und fachliche Auswirkungen gemeinsam behandeln.
|
||
- [ ] **C – Verständlich bedienen:** U05, U08, U09, U10, U13; konsistente Komponenten für Dialoge und Aktionen verwenden.
|
||
- [ ] **D – Selbstständig arbeiten:** U14, U15, U16; Offline-Grundlage U16 kann wegen P1 vorgezogen werden.
|
||
|
||
**Bewusst zurückstellen:** Bankanbindung, umfangreiche Kategorien, neue Auswertungszentralen, automatische fachliche Korrekturen und ein vollständiger Umbau der Oberfläche. Dafür liegt hier kein belegter Bedarf vor. Auch eine Jahressperre wäre ein eigener fachlicher Auftrag, keine beiläufige Usability-Änderung.
|
||
|
||
## Validierung mit der tatsächlichen Zielgruppe
|
||
|
||
Vor größerer Umsetzung drei bis fünf Personen mit geringer Computererfahrung an einem separaten Beispieldatenbestand beobachten. Diese kleine Runde liefert qualitative Hinweise, keine repräsentativen Kennzahlen. Hilfestellung erst geben, wenn eine Aufgabe sonst abgebrochen würde; Stellen und Gründe protokollieren.
|
||
|
||
1. Ein Konto öffnen und seinen Kontostand erklären.
|
||
2. Einen Mitgliedsbeitrag von 12,50 € und eine Ausgabe von 4,20 € erfassen.
|
||
3. Eine Buchung aus dem Vorjahr finden und erklären, weshalb sie im aktuellen Jahr nicht sichtbar ist.
|
||
4. Eine versehentlich erfasste Buchung korrigieren; Löschen und Rückweg verstehen.
|
||
5. 50 € von Barkasse nach Girokonto umbuchen und beide Kontostände sowie die Vereinssumme erklären.
|
||
6. Einen Jahresauszug speichern und die Datei wiederfinden.
|
||
7. Eine Sicherung erstellen, deren Speicherort nennen und in einer isolierten Testumgebung den vorherigen Stand wiederherstellen.
|
||
|
||
Je Aufgabe festhalten: ohne Hilfe abgeschlossen, Zahl der nötigen Hilfen, Fehlbuchungen, verlorene Eingaben, subjektive Sicherheit sowie auffällige Begriffe. Zeiten können Orientierung geben; zunächst keine willkürlichen Zeitgrenzen als Erfolgsversprechen setzen. Ziel ist, dass die Kernaufgaben ohne Erklärung der Symbole und ohne Eingriff einer technischen Hilfsperson gelingen.
|
||
|
||
## Prüfnachweis für diesen Dokumentations-PR
|
||
|
||
Nur Analyse und Planung; keine Änderung am Programmverhalten. Vor Veröffentlichung Markdown-Verweise auf lokale Quellen, eindeutige Maßnahmen-IDs und `git diff --check` prüfen. Automatisierte Anwendungstests werden für diese reine Dokumentationsänderung nicht erneut ausgeführt; die vorherige Prüfung des Basiscommits bestand mit 12/12 Tests in Debug und Release. Das ersetzt keine spätere Abnahme der hier empfohlenen Änderungen.
|