From 317c696e70c4069585f3cbb2e8b854b896d1d6d7 Mon Sep 17 00:00:00 2001 From: troogs Date: Sun, 1 Nov 2026 20:16:57 +0100 Subject: [PATCH] Document usability findings and prioritized implementation measures --- docs/usability-analyse.md | 183 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 183 insertions(+) create mode 100644 docs/usability-analyse.md diff --git a/docs/usability-analyse.md b/docs/usability-analyse.md new file mode 100644 index 0000000..096459e --- /dev/null +++ b/docs/usability-analyse.md @@ -0,0 +1,183 @@ +# 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.