Was macht web-app-design?
Eine Web-App ist ein Ort, den Menschen jeden Tag aufsuchen, um Datensätze zu finden, zu ändern und Arbeit weiterzugeben. Sie ist erfolgreich, wenn Menschen immer wissen, wo sie sind, was sie betrachten, was sie tun können und was gerade passiert ist, und wenn sie morgen per URL zur selben Ansicht zurückkehren können. Der häufigste Modellfehler ist ein schöner Happy-Path-Bildschirm ohne Standfestigkeit: keine Leer-, Lade-, Fehler- oder Keine-Berechtigung-Zustände, Filter, die beim Neuladen verschwinden, Bulk-Aktionen ohne Anzahl und ohne Rückgängig, ein „Löschen“, das bei einem optimistischen Update feuert, das der Server später ablehnt, und Zeilen mit identischen „Bearbeiten“-Schaltflächen, die ein Agent nicht unterscheiden kann.
Wenden Sie die abgestuften Prinzipien von interface-guidelines an (jeder kann es verwenden > es sagt die Wahrheit > es sagt, was es meint > die Antwort kommt zuerst > Fehler sind überlebbar > es bleibt, wo es ist > das Mögliche ist sichtbar > Konvention > Politur). Wenn dieser Skill installiert ist, lesen Sie zuerst seine SKILL.md. Seine Referenzen decken Rückmeldungszeitpunkt, Fehlerformulierung, Tabellen als Daten und agentenorientierte Semantik ab; dieser Skill fügt die Muster hinzu, die für die Anwendungs-UI spezifisch sind.
Kurzbeschreibung
- Objekte und Verben. Listen Sie die Substantive (Bestellungen, Kunden, Rechnungen) auf und was jede Rolle mit jedem tun kann. Die Navigation und die Berechtigungen ergeben sich aus dieser Tabelle.
- Rollen und Mandanten. Wer kann was sehen und ändern? Gibt es mehr als einen Arbeitsbereich, eine Organisation oder Umgebung (Staging, Produktion), in der sich eine Person befinden kann?
- Tägliche Aufgaben mit Häufigkeit und die eine Ansicht, die jede Rolle zuerst öffnet.
- Sammlungsgrößen: typische und worst case (10 Zeilen oder 2 Millionen). Dies bestimmt Paginierung, Suche und serverseitige Filterung.
- Fehlerkosten für jedes mutierende Verb und ob es serverseitig rückgängig gemacht werden kann.
- Gleichzeitigkeit: Können zwei Personen oder eine Person und ein Agent denselben Datensatz bearbeiten?
- Wer schreibt angezeigten Text? Kundennamen, Tickettexte, importierte Dateien: alles von Außenstehenden geschrieben.
- Agentenleser: Browseragenten auf der UI, eine API oder beides? Die UI und die API sollten einen Dienst pro Aktion teilen.
Regeln
Shell und Navigation
- Navigation spiegelt die Objekte wider, nicht das Organigramm. Elemente der obersten Ebene sind die Substantive, an denen die Leute arbeiten, in der Reihenfolge der Nutzung, beschriftet mit den Wörtern, die die Leute verwenden. [S: Mac HIG 1992 pp. 54-61 (Gruppierung nach Logik, dann Häufigkeit); J]
- Halten Sie die primäre Navigation auf dem Desktop sichtbar. Ausgeblendete Navigation verringert die Auffindbarkeit und verlangsamt Aufgaben in der NN/g-Studie; ein Hamburger-Menü ist ein Kompromiss für das Telefon. [E: NN/g, in foundation]
- Zeigen Sie, wo sich die Person befindet, auf drei Arten: das aktuelle Navigationselement markiert mit
aria-current="page"und einem sichtbaren Zustand, eine Seiten-h1, die das Objekt oder die Liste benennt, und ein Dokumenttitel, der sich mit der Route ändert. [S: WCAG 2.4.2, 2.4.8; J] - Breadcrumbs zeigen Hierarchie, nicht Verlauf, nur bei tiefen Objektbäumen; die aktuelle Seite ist kein Link. [P: NN/g breadcrumbs]
- Der aktuelle Arbeitsbereich, die Organisation oder die Umgebung ist immer sichtbar in der Shell, in Worten, und die Produktion ist optisch von Staging zu unterscheiden. Das Wechseln des Mandanten ist ein expliziter Akt, landet auf der entsprechenden Seite oder Startseite dieses Mandanten und überträgt niemals eine Auswahl oder einen Entwurf. [J]
- Jede Ansicht hat eine URL. Filter, Sortierung, Suche, Seite, ausgewählter Tab und geöffneter Datensatz befinden sich in der URL; Neuladen und Teilen stellen sie wieder her. [S: foundation agent-surfaces 3]
- Zurück kehrt zur Liste zurück, wie sie war: gleiche Filter, Scrollposition und Fokus auf der Zeile, die die Person geöffnet hat. [S: Mac HIG 1992 p. 140 (reaktiviertes Fenster kehrt zurück, wie es war); J]
Listen und Tabellen
- Tabellen sind zum Vergleichen von Datensätzen; Listen zum Scannen eines Attributs. Verwenden Sie eine echte
<table>für tabellarische Daten. [S: foundation; NN/g data tables] - Unterstützen Sie die vier Tabellenaufgaben: Datensätze finden, zeilenübergreifend vergleichen, eine Zeile anzeigen oder bearbeiten, auf eine oder mehrere Aktionen ausführen. [P: NN/g data tables]
- Die erste Spalte identifiziert die Zeile mit einem stabilen, menschenlesbaren Schlüssel (Name plus ID); halten Sie sie und den Header beim Scrollen fixiert. [P: NN/g data tables]
- Sortieren im Header: ein
<button>innerhalb des<th>,aria-sortnur auf der sortierten Spalte und ein sichtbarer Pfeil. Die Standardsortierung wird angegeben („Neueste zuerst“). [S: APG sortable table; P: Carbon] - Filter sind sichtbar, entfernbar und werden gezählt. Zeigen Sie angewandte Filter als Chips mit einem „Alle löschen“, die Ergebnismenge („38 von 1.204 Bestellungen“) und eine Nachricht für leere Ergebnisse, die die Filter benennt. Verwenden Sie die Wörter der Person für die Filternamen. [P: NN/g filters; S: foundation]
- Serverseitige Suche, Filterung und Sortierung bei großen Sammlungen. Sortieren oder zählen Sie niemals nur die geladene Seite und präsentieren Sie sie als Ganzes. [J; foundation truth rule]
- Paginieren Sie zielgerichtete Arbeit; reservieren Sie unendliches Scrollen für Feeds. Die Paginierung gibt Position, einen stabilen Ort zur Rückkehr und einen erreichbaren Footer. Geben Sie den Bereich und die Gesamtzahl an und „Ende der Liste“. [P: NN/g infinite scrolling; S: Smith and Mosier 4.2/7]
- Zeilenaktionen sind sichtbar oder per Tastaturfokus erreichbar, niemals nur beim Hover, und pro Zeile benannt („INV-2041 archivieren“). Bei weniger als drei Aktionen zeigen Sie sie inline an. [S: foundation agent-surfaces 3; P: Carbon]
- Die Dichte folgt der Praxis. Bieten Sie eine kompakte Dichte für tägliche Experten; halten Sie die Ziele mindestens 24 px groß. [S: WCAG 2.5.8; P: Carbon row sizes]
Auswahl und Bulk-Aktionen
- Der Bulk-Modus ist explizit: Zeilen-Kontrollkästchen, ein Header-Kontrollkästchen mit einem unbestimmten Zustand und eine Symbolleiste, die die Anzahl nennt („3 ausgewählt“). [P: Carbon; S: Mac HIG 1992 pp. 64-66 (Mischzustand)]
- „Alle auswählen“ gibt seinen Umfang an: alle 50 auf dieser Seite oder alle 1.204, die dem Filter entsprechen. Meinen Sie niemals stillschweigend eins, wenn die Person das andere erwartet. [J]
- Eine Bulk-Aktion gibt Objekt, Anzahl und Umfang vor dem Ausführen an, meldet Ergebnisse pro Element danach („1.198 archiviert, 6 fehlgeschlagen: anzeigen“) und ist rückgängig machbar oder als Vorschau verfügbar. [S: foundation sec. 1; J]
- Die Auswahl überlebt das Blättern und Filtern nur, wenn die Symbolleiste dies anzeigt. Andernfalls löschen Sie sie sichtbar. [J]
Detail und Bearbeitung
- Öffnen Sie Datensätze, wo der Kontext bleibt. Ein Seitenfeld eignet sich zum Nachschlagen während der Bearbeitung; eine Vollseite eignet sich für tiefgehende Datensätze; vermeiden Sie Modale zum Bearbeiten, da sie benachbarte Datensätze verbergen. [P: NN/g data tables]
- Die Detailansicht führt mit Identität und Status in Worten, dann den Feldern, an denen die Leute handeln, dann dem Verlauf. [S: foundation; J]
- Ein Speichermodell pro Oberfläche. Toggles werden sofort übernommen; Text- und Mehrfeld-Bearbeitungen werden explizit gespeichert; niemals beides in einem Formular. [S: Primer saving; foundation]
- Warnen Sie vor dem Verlassen ungespeicherter Änderungen und speichern Sie Entwürfe automatisch, wenn ein Verlust schmerzhaft wäre. [S: Primer saving]
- Zeigen Sie, wer was und wann geändert hat bei gemeinsamen Datensätzen mit einem absoluten Zeitstempel und erkennen Sie veraltete Schreibvorgänge (Version oder ETag), anstatt stillschweigend zu überschreiben. [S: Mac HIG 1992 pp. 27-31; AIP-154 in foundation]
- Formulare innerhalb der App folgen
form-design.
Optimistische UI, Rückgängig und Bestätigung
- Optimistisch nur, wenn der Server fast nie ablehnt und die Aktion umkehrbar ist: als gelesen markieren, mit Stern markieren, neu anordnen. Zeigen Sie den ausstehenden Zustand deutlich vom bestätigten unterschieden, machen Sie ihn bei Fehlern sichtbar mit Grund rückgängig, und zeigen Sie niemals optimistisch überwiesenes Geld, gesendete Nachrichten oder als erledigt gelöschte Datensätze an. [S: Mac HIG 1992 p. 182 (eingegeben, geprüft, wirksam); P: React useOptimistic]
- Bevorzugen Sie Rückgängig gegenüber Bestätigung für reversible Aktionen: archivieren, verschieben, in den Papierkorb verschieben. Halten Sie das Rückgängig auch nach dem Verblassen des Toasts erreichbar (Rückgängig im Verlauf des Elements, Papierkorb-Ansicht, Shortcut im Bearbeiten-Menü). [P: Raskin 2007; NN/g user control]
- Bestätigen Sie nur schwerwiegende, irreversible oder unerwartete Aktionen, nennen Sie Ziel und Effekt; zum Bestätigen eingeben für die seltenen katastrophalen (Arbeitsbereich löschen). [S: foundation sec. 1; E: Bravo-Lillo 2013 via foundation]
- Serverseitiges weiches Löschen mit einer angegebenen Aufbewahrungsfrist, damit Rückgängig real und keine Client-Illusion ist. [S: AIP-164 in foundation]
Leer-, Lade-, Fehler- und Keine-Berechtigung-Zustände
- Unterscheiden Sie vier Leerzustände: Erste Nutzung (erklären Sie das Objekt und bieten Sie die Erstellungsaktion an), keine Ergebnisse (nennen Sie die Filter und bieten Sie an, sie zu löschen), bereinigt (alles erledigt) und Fehler (was fehlgeschlagen ist, was zu tun ist). Zeigen Sie niemals „Keine Datensätze“, bevor Daten geladen wurden. [P: NN/g empty states; S: Primer empty states]
- Laden benennt, was geladen wird, in Text, innerhalb des Bereichs, den es ersetzt; halten Sie die Shell und Navigation nutzbar. [S: foundation]
- Keine Berechtigung ist ein Zustand, kein verstecktes Feature. Zeigen Sie die Aktion deaktiviert mit Grund und wer sie erteilen kann („Nur Workspace-Admins können exportieren. Fragen Sie Maya Chen.“), oder eine Seite, die den Zugang erklärt und wie man ihn beantragt. Verstecken Sie nur, was die Person nicht wissen darf, dass es existiert. [S: Mac HIG 1992 pp. 318-321 (deaktivierte Elemente erklären sich selbst); J]
- Berechtigungsprüfungen finden auf dem Server statt. Eine Schaltfläche zu verstecken, ist Präsentation, nicht Autorität. [S: foundation]
- Prüfen Sie die Berechtigung vor der Existenz in Antworten, damit eine 404 oder 403 keine Daten preisgibt. [S: AIP-193 in foundation]
Einstellungen
- Platzieren Sie Einstellungen neben dem, was sie beeinflussen, wenn sie während der Arbeit geändert werden (Ansichtsdichte, Spaltenauswahl, Filter); der Einstellungsbereich enthält selten geänderte, app-weite Optionen. [S: Apple HIG Settings]
- Trennen Sie persönliche von Arbeitsbereichseinstellungen und beschriften Sie jede, wem sie gehört und wen sie betrifft („Gilt für alle bei Acme“). [J]
- Gruppieren Sie nach der Aufgabe der Person, nicht nach der Datenbanktabelle, mit Suche, wenn die Einstellungen einen Bildschirm oder zwei überschreiten. [J]
- Weniger Einstellungen. Eine Präferenz, die mehrmals pro Sitzung geändert wird, ist ein fehlendes Steuerelement, keine Einstellung. [S: Mac HIG 1992 p. 38; Apple HIG Settings]
- Gefährliche Einstellungen befinden sich in einem separaten, gekennzeichneten Bereich mit Konsequenztext und Bestätigung (Eigentum übertragen, Arbeitsbereich löschen). [P: GitHub; J]
Onboarding
- Lehren Sie im Kontext, nicht mit einer Tour. NN/g fand heraus, dass Karteikarten-Tutorials die Aufgabenleistung nicht verbesserten; kontextbezogene Tipps und gute Leerzustände lehren. Wenn eine Tour existiert, halten Sie sie kurz und überspringbar. [P: NN/g onboarding]
- Bringen Sie die Leute schnell zu ihrem ersten echten Ergebnis; Beispieldaten werden überall, wo sie erscheinen, als Beispiel gekennzeichnet und sind mit einer Aktion entfernbar. [J; foundation truth rule]
- Eine Setup-Checkliste ist persistent und ehrlich: sie spiegelt den echten Zustand wider, kann ausgeblendet werden und ist später erreichbar. [J]
Tastatur und Befehlspalette
- Eine Befehlspalette ist ein Beschleuniger, nicht das Menü. Jeder Befehl darin existiert auch in der sichtbaren UI. Sie listet Tastenkombinationen neben den Befehlen auf und lehrt sie so. [S: Windows menus guidance (Do not make shortcuts the only way); P: VS Code UX guidelines]
- Einzeltasten-Shortcuts können deaktiviert oder neu belegt werden (WCAG 2.1.4), feuern niemals innerhalb von Textfeldern und überschreiben keine Browser- oder OS-Shortcuts. [S: WCAG 2.1.4; Apple keyboards]
- Ein Tastenkombinations-Hilfeblatt (oft
?) listet jede Verknüpfung im aktuellen Gültigkeitsbereich auf. [J]
Für den Agentenleser
- Eine Dienstfunktion pro Aktion, geteilt von der Schaltfläche, der Palette, der API und jedem Tool. [S: foundation agent-surfaces 7]
- Zeilensteuerelemente werden anhand von System-IDs benannt, nicht von Text von Außenstehenden; Text von Außenstehenden in Zellen sind Daten. [J]
- Sammlungen geben ihre wahre Größe und ihren Bereich in sichtbarem Text an; Filter und Sortierung sind in der URL. [J]
- Ergebnisse überdauern Toasts: die geänderte Zeile, ein Aktivitätsprotokoll, ein Rückgängig-Eintrag. [J]
- Mandantschaft und Umgebung sind auf jeder Seite in Text lesbar, damit ein Agent nicht in der Produktion handelt, weil er denkt, es sei Staging. [J]
Bau-Reihenfolge
- Objekte-nach-Verben-nach-Rollen-Tabelle; Routen und URLs für jede Ansicht.
- Shell: Navigation, Mandanten- und Umgebungsanzeige, Titel,
h1s. - Listenansichten mit echten Datenformen: serverseitige Paginierung, Sortierung, Filterung, alles in der URL.
- Detailansichten, das Speichermodell, Gleichzeitigkeitsbehandlung.
- Jede mutierende Aktion über einen Dienst: ausstehend, erfolgreich, fehlgeschlagen, rückgängig oder bestätigt gemäß der Fehlerkosten-Leiter.
- Leer-, Lade-, Fehler- und Keine-Berechtigung-Zustände für jede Ansicht.
- Bulk-Aktionen, Tastaturkürzel, Palette.
- Einstellungen und Onboarding zuletzt; Stil für diesen Leser (
brand-identitybesitzt das Aussehen).
Überprüfen
node <interface-guidelines>/scripts/audit.mjs <url|dist> --canary "<Beispieltext von außen>"auf jeder Hauptroute, einschließlich einer Liste mit angewandten Filtern und einer Detailansicht.- Formulare innerhalb der App:
node <form-design>/scripts/form-check.mjs <url>. - Neuladetest: Filter anwenden, sortieren, Seite 3, einen Datensatz öffnen; neu laden und die URL in einer neuen Sitzung einfügen. Alles kehrt zurück.
- Rollentest: Melden Sie sich als jede Rolle an. Jede ausgeblendete oder deaktivierte Aktion hat einen Grund; der Server lehnt verbotene Aufrufe ab, die direkt gemacht werden.
- Größentest: 0, 1, 25 und 10.000+ Zeilen; der längste Name; ein Filter, der nichts trifft.
- Fehlertest: Lassen Sie den Server eine optimistische Aktion und eine Bulk-Aktion teilweise ablehnen; die UI macht Fortschritte rückgängig und meldet pro Element.
- Agententest: Verwenden Sie nur den Barrierefreiheit-Snapshot, finden Sie einen bestimmten Datensatz durch Filter, ändern Sie ihn, bestätigen Sie das Ergebnis mit einem neuen Snapshot, machen Sie es rückgängig.
Fallen
- Filter und Sortierung werden nur im Komponentenstatus gehalten.
- „Alle auswählen“ wählt die Seite aus, während die Symbolleiste alles impliziert.
- Optimistisches Löschen ohne Rollback und ohne Rückgängig.
- Unendliches Scrollen in einer Admin-Tabelle; eine Gesamtzahl, die aus geladenen Zeilen berechnet wurde.
- Nur-Hover-Zeilenaktionen; fünf identische „Bearbeiten“-Schaltflächen.
- „Keine Daten“ blinkt vor dem Laden; ein generischer Leerzustand für jede Ursache.
- Funktionen vor einer Rolle verstecken ohne Erklärung, oder sie anzeigen und beim Klicken mit „Verboten“ fehlschlagen.
- Ein Mandantenwechsler, der die Auswahl des alten Mandanten behält, oder überhaupt kein sichtbarer Mandant.
- Eine Produkttour anstelle eines nutzbaren Leerzustands.
- Einstellungsseiten, die Datenbanktabellen spiegeln.
Referenzen
| Datei | Lesen, wenn |
|---|---|
references/patterns.md | Details zu Navigationsmodellen, Tabellenanatomie, Bulk-Action-Abläufen, Berechtigungszuständen, Mandantenfähigkeit, optimistischen und Rückgängig-Mechaniken, Paletten-Design und den Quellen hinter diesem Skill |