review

ultrahand: review

Überprüfen Sie ein UI-Design so, wie es ein erfahrener Inspektor tun würde. Gehen Sie jeden Ablauf, jede Interaktion und jedes Steuerelement anhand der Plattformprinzipien, Nielsens 10 Heuristiken und WCAG 2.2 AA durch, und prüfen Sie dann, ob das Design auch bei anderen Größen Bestand hat. Die Ausgabe ist eine Liste von Befunden, geordnet nach Schweregrad. Jeder Befund benennt das Element, das Prinzip und seine Quelle und gibt eine konkrete Lösung an.

Jede Prüfung befindet sich in references/checklist.md, und jede Prüfung verweist auf references/sources.md. Für die vertieften Plattformregeln verwenden Sie die eigenen Prinzipien der Design-Fähigkeiten: mobile, tablet und desktop. Für ein Projekt mit einem Thema überprüfen Sie das Design damit mit der Fähigkeit theme-review: Token-Verwendung, Wiederverwendung von Komponenten und Konsistenz über Bildschirme hinweg sind deren Aufgabe, nicht die dieser Fähigkeit.

1. Das Design abrufen und wissen, was es zeigen kann

Verwenden Sie das aussagekräftigste Material, das der Benutzer geben kann. Geben Sie an, welche Art Sie haben, da dies einschränkt, was Sie bestätigen können.

• Ultrahand-Canvas-Artefakt (ein claude.ai-Artefakt-Link): Lesen Sie dessen HTML. Es enthält das Markup, die Labels, Farben und jeden Bildschirm und Zustand. Falls ein Browser-Tool verfügbar ist, öffnen Sie das Artefakt. Richten Sie jede Ansicht über window.ultrahandCanvas ein (siehe Canvas-README in shared/canvas/): usePreset(id), setSize(w, h), setScheme('dark'), setTextScale(2), setState('error'), navigate(id). Aktivieren Sie Tap-Ziele anzeigen und lesen Sie dessen Ergebnis (#uh-targets-result), das Ziele unter dem Plattform-Minimum zählt. Rufen Sie refresh() auf, nachdem Sie ein Blatt oder Menü geöffnet haben, damit die Zählung dies einschließt. Das Canvas-README listet die Element-IDs der Symbolleiste auf. Platzhalter eines Prototyps (kein echtes Netzwerk, keine Bildschirmtastatur) werden unter Nicht geprüft aufgeführt, nicht in den Befunden. Die Hardware-Tastatur ist real: Steuern Sie jeden Ablauf damit.
• Lokaler Canvas-Build (eine index.html aus build.mjs) oder jede Seite, die Sie öffnen können: Behandeln Sie es wie das Artefakt und verwenden Sie es mit dem Eingabetreiber (Schritt 4).
• Code (HTML, SwiftUI, Compose, Flutter usw.): Sie können Labels, Rollen, Fokus-Reihenfolge, Farben und Breakpoints prüfen, aber nicht das Aussehen, es sei denn, Sie können es ausführen.
• Screenshot oder Mockup: Sie können Layout, Hierarchie, Formulierung sowie ungefähren Kontrast und Größen beurteilen. Sie können Labels, Fokus-Reihenfolge oder Verhalten nicht bestätigen; markieren Sie diese Befunde als Wahrscheinlich oder listen Sie sie unter Nicht geprüft auf.

Markieren Sie die Beweislage jedes Befunds: Bestätigt (im Code gesehen oder auf dem Canvas gemessen) oder Wahrscheinlich (aus einem Bild abgeleitet). Präsentieren Sie niemals eine Vermutung über verborgenes Verhalten als Tatsache.

2. Den Kontext festlegen

Notieren Sie dies, bevor Sie etwas beurteilen; ein Befund ergibt nur vor diesem Hintergrund Sinn.

• Plattform: iOS, iPadOS, Android, macOS, Windows oder das Web. Lesen Sie es aus dem Canvas (size.platform), dem Code oder dem visuellen Stil ab. Falls unklar, fragen Sie einmal nach.
• Aktuelle Größe: Breite × Höhe und die Breiten-Größenklasse: kompakt < 600, mittel 600–839, erweitert 840–1199, groß 1200–1599, extra-groß 1600+. Höhe kompakt < 480, mittel 480–899, erweitert 900+. Notieren Sie die Ausrichtung und etwaige Teilungen.
• Eingaben: Berührung, Zeiger, Tastatur oder eine Mischung. Ein Tablet oder ein Touch-Laptop kann alle drei haben.
• Benutzer und Hauptaufgabe: Wer verwendet jeden Bildschirm und wofür er da ist. Fragen Sie, falls Sie es nicht ableiten können; eine Überprüfung ohne Aufgabe wird zu einer Liste von Meinungen.
• Produkt oder Werkzeug: Ein Design für Endbenutzer oder ein Werkzeug, das für den Eigentümer erstellt wurde (das Canvas selbst, ein Editor, ein Viewer). Ein Werkzeug ist eine Desktop-App, die in einem Browserfenster beliebiger Größe verwendet wird: Überprüfen Sie es mit den Desktop-Regeln und bestehen Sie Durchgang 8. Seine Chrom-Elemente erhalten die Prüfungen von Durchgang 7, die Durchgang 8 auflistet (Fenstergrößen, Browser-Zoom, eigene Designs), nicht die Voreinstellungen des Designs, und den Kompositionsdurchgang wie jeder Bildschirm.

Wählen Sie die Plattformregeln nach Fenstergrößenklasse und Eingabe aus, nicht nach Gerätenamen: Kompakt, Berührung → Mobile Prinzipien; Mittel und Erweitert, Berührung, oder jede Teilung → Tablet; Ein Fenster mit Zeiger und Tastatur → Desktop. Ein responsives Design erhält alle Sätze, die seine Größen abdecken.

3. Das Design inventarisieren

Listen Sie jeden Bildschirm und Zustand, jeden Ablauf zwischen Bildschirmen, die Abschnitte jedes Bildschirms (Symbolleisten und deren Gruppen, Bereiche, Bereichsüberschriften, Formulargruppen, Karten, Listen, Leisten) und jedes interaktive Steuerelement in jedem Abschnitt (Schaltflächen, Links, Felder, Schalter, Tabs, Menüs, Gesten, Drag-Ziele) auf. Das Inventar ist die Abdeckung der Überprüfung: Ein Abschnitt oder Steuerelement, den Sie nicht aufgelistet haben, ist einer, den Sie nicht geprüft haben.

Überprüfen Sie auf drei Ebenen: Den gesamten Bildschirm, jeden Abschnitt und jede Komponente. Ein Bildschirm, dessen sämtliche Steuerelemente bestehen, kann dennoch überladen, ungeordnet und verwirrend sein; das ist ein eigener Befund, keine Nachbesserung.

4. In Durchgängen inspizieren

Arbeiten Sie die Durchgänge in references/checklist.md in der Reihenfolge ab. Gehen Sie das Design zweimal durch: einmal, um es zu lernen, einmal, um Probleme zu finden.

Verwenden Sie jedes Steuerelement mit echten Eingaben, bei mehreren Größen. Das Lesen des Markups oder das Aufrufen von el.click(), dispatchEvent oder eines Setters überspringt Hit-Testing, Fokus, Standardaktionen und Scroll-Verkettung, sodass eine verdeckte Schaltfläche oder ein blockiertes Rad immer noch in Ordnung aussieht. Verwenden Sie die Seite so, wie es ein Mensch tut: vertrauenswürdige Maus-, Rad-, Tasten- und Berührungsereignisse von node "${CLAUDE_PLUGIN_ROOT}/shared/input/drive.mjs" (dessen README die Schritte und Rezepte enthält), oder echte Klicks und Tasten eines Browser-Tools. Skripte dienen nur zum Einrichten einer Ansicht und zum anschließenden Auslesen des Zustands.

• Führen Sie es bei drei oder mehr Größen durch: der größten, einer mittleren und der kleinsten unterstützten (für ein Design, seine Voreinstellungen; für ein Werkzeug, Browserfenster wie 1440×900, 1024×700 und 640×480).
• Listen Sie bei jeder Größe die Steuerelemente auf (controls), verwenden Sie dann jedes so, wie seine Art verwendet werden soll: Klicken oder Tippen, Tippen, Ziehen und mit Esc abbrechen, Rechtsklick, Öffnen und Schließen mit der Tastatur und Rad oder Wischen über jeden Scroller über sein Ende hinaus.
• Einige native Steuerelemente können nicht kopflos mit vertrauenswürdigen Eingaben gesteuert werden: das Popup einer Auswahlliste, Dateiauswahlen sowie Farb- und Datumsauswahlen. Wählen Sie eine Option einer Auswahlliste mit dem Schritt choose des Treibers aus und listen Sie den Rest unter Nicht geprüft auf.
• Lesen Sie jedes Ergebnis: Ein Steuerelement, das verdeckt ist, außerhalb des Ansichtsbereichs ohne Zugriffsmöglichkeit oder bei einer Größe fehlt; ein gescrollt, das ein blockiertes Rad anzeigt; Fokus, der auf body verloren geht; Seitenfehler. Jedes ist ein Befund bei dieser Größe.

1. Aufgaben-Durchlauf: Fragen Sie bei jedem Ablauf an jedem Schritt die vier kognitiven Walkthrough-Fragen.
2. Komposition: Jeder Bildschirm als Ganzes, dann jeder Abschnitt, anhand der Kompositionsregeln (shared/composition/principles.md). Führen Sie dessen Audit bei der größten und kleinsten Größe durch und lesen Sie zuerst den unscharfen Screenshot, bevor Sie ein einzelnes Steuerelement betrachten. Wenn Sie eine Überarbeitung prüfen, vergleichen Sie sie auch mit der vorherigen Version: Was hat die Runde hinzugefügt, und ist der Bildschirm dadurch überladener?
3. Steuerelement für Steuerelement: Jedes Steuerelement im Inventar anhand der Steuerelementprüfungen.
4. Heuristiken: Jeder Bildschirm anhand von Nielsens 10.
5. Barrierefreiheit: WCAG 2.2 AA. Berechnen Sie den Kontrast; schätzen Sie ihn nicht.
6. Plattform: Die Regeln für die Plattform und Größenklasse aus Schritt 2.
7. Größenänderung und Varianten: Jede Voreinstellung, die Teilungsbreiten, 320 breites Reflow, 200 % Text, Dunkelmodus, jeden Datenzustand und bei Touch-Geräten beide Ausrichtungen und die eingeblendete Tastatur (Desktop-Fenster drehen sich nicht: prüfen Sie stattdessen das Minimum, Maximum und kurze Fenster).
8. Werkzeuge: Bei einem für den Eigentümer erstellten Werkzeug bleibt die Arbeit bei jeder Fenstergröße im Blick, die Bühne schwenkt über ihre Ränder hinaus, Zoom hat Grenzen, und Tastenkombinationen und Ziehverhalten funktionieren.

Notieren Sie ein Problem in dem Moment, in dem Sie es sehen, mit dem Ort, an dem Sie es gesehen haben (Bildschirm › Element, plus Größe, Schema und Zustand). Ein Problem, das an mehreren Stellen auftritt, ist ein Befund mit mehreren Orten.

5. Schweregrad bewerten

Verwenden Sie Nielsens Skala von 0–4. Wägen Sie ab, wie viele Benutzer auf das Problem stoßen, wie sehr es sie beeinträchtigt und ob es sie weiterhin beeinträchtigt, sobald sie davon wissen. Siehe den Leitfaden zum Schweregrad in der Checkliste.

Bewertung	Bedeutung
4 Katastrophe	Verhindert, dass Personen eine Aufgabe abschließen, oder ihre Daten gehen verloren. Vor der Veröffentlichung beheben.
3 Schwerwiegend	Verlangsamt oder verwirrt viele Personen oder erfüllt WCAG AA in einem primären Ablauf nicht. Bald beheben.
2 Geringfügig	Verlangsamt einige Personen, oder es gibt eine offensichtliche Problemumgehung.
1 Kosmetisch	Nachbesserung. Beheben, wenn Zeit ist.

Melden Sie keine 0er. Ein WCAG-AA-Fehler liegt nie unter 2.

6. Bericht

Beginnen Sie mit einem einleitenden Absatz als Fazit: die Plattform, die geprüften Größen, die Ihnen vorliegenden Beweise, der erste Eindruck (was der unscharfe Bildschirm zeigt, und ob der Bildschirm organisiert oder überladen wirkt), die Anzahl nach Schweregrad und das wichtigste Problem. Wägen Sie eine unorganisierte primäre Oberfläche gleichwertig gegen Fehler ab: Sie verlangsamt jede Nutzung, nicht nur einen Pfad. Listen Sie dann die Befunde auf, beginnend mit dem höchsten Schweregrad und innerhalb eines Schweregrads in der Reihenfolge des Ablaufs, unter Verwendung der Vorlage in der Checkliste:

• ID und Schweregrad, z. B. R3 · 3 Schwerwiegend
• Element: Bildschirm › Abschnitt › Element (oder Bildschirm › Abschnitt, oder der gesamte Bildschirm, bei einem Kompositionsbefund), und die Größe, das Schema oder der Zustand, in dem es auftritt
• Beweislage: Bestätigt oder Wahrscheinlich
• Problem: Was für den Benutzer schiefgeht, in ein oder zwei Sätzen
• Prinzip: Die Regel, die es verletzt, mit ihrem Quellenschlüssel (WCAG 1.4.3, NNG-H4, tablet:AND-T2)
• Lösung: Eine konkrete Änderung mit Werten (das Label auf #595959 für 7.0:1 erhöhen, nicht Kontrast verbessern)

Schließen Sie mit dem, was gut funktioniert (kurz halten), was Sie nicht prüfen konnten und warum (Screenreader-Ausgabe, echte Geräte, Bewegung), und einem Hinweis, dass ein Prüfer Probleme übersieht, die andere erkennen, sodass ein zweiter Prüfer oder ein Usability-Test empfehlenswert ist.

Wenn der Bericht an jemand anderen geht, bieten Sie an, ihn als Artefakt zu veröffentlichen. Bieten Sie an, die Lösungen mit der passenden Ultrahand-Design-Fähigkeit anzuwenden.