Tablet

ultrahand: tablet

Entwerfen Sie Tablet-Bildschirme als interaktives Claude-Artefakt. Das Artefakt wechselt zwischen iPad- und Android-Tablet-Größen in beiden Ausrichtungen, rastet auf Split-Breiten (1/3, 1/2, 2/3) ein und fließt live neu, während Sie ein Fenster von voller Breite auf 320 ziehen. Jede von Ihnen angewandte Regel befindet sich in references/principles.md, und jede Regel zitiert references/sources.md. Die Größen, Splits und Größenklassen befinden sich in references/presets.md.

1. Anforderungen sammeln

Fragen Sie nur nach dem, was Sie nicht ableiten können. Klären Sie Folgendes, bevor Sie zeichnen:

• Plattform: iPadOS, Android oder beides. Wenn beides, verwenden Sie 48-Einheiten-Ziele und plattformneutrale Muster.
• Umfang: Ein Bildschirm oder ein Ablauf. Bei einem Ablauf listen Sie die Bildschirme auf und wie Personen zwischen ihnen navigieren: Seitenleiste oder Rail, Liste zu Detail, Sheet, Popover oder neues Fenster.
• Primäre Aufgabe: Der eine Zweck jedes Bildschirms und welches kanonische Layout dazu passt (Liste-Detail, Unterstützungsbereich, Feed oder ein einzelner Bereich).
• Echte Inhalte: Namen, Längen, Anzahlen und die längsten plausiblen Zeichenfolgen. Nicht mit Lorem Ipsum entwerfen.
• Datenzustände: Was lädt, was leer sein kann und was fehlschlagen oder offline gehen kann.
• Eingaben: Nur Touch oder auch Tastatur, Trackpad, Maus oder Pencil. Gehen Sie von allen Möglichkeiten aus, sofern nicht anders angegeben.
• Multitasking: Was Personen neben dieser App tun (Referenz nebeneinander, Inhalte hinein- oder herausziehen). Erwarten Sie Fenster von 320 Breite bis Vollbild.
• Einschränkungen: Markenfarben, Schriftarten, ein vorhandenes Designsystem und ob es sich um eine native App oder das Web handelt.
• Theme: Suchen Sie nach dem Theme des Projekts (design/THEME.md, *.tokens.json; siehe shared/theme/README.md), bevor Sie Farben, Größen oder Abstände wählen. Wenn es eines gibt, entwerfen Sie damit: Führen Sie node "${CLAUDE_PLUGIN_ROOT}/shared/theme/css.mjs" <tokens.json> --style --out theme.html aus, übergeben Sie --head theme.html an den Build, verwenden Sie nur dessen benutzerdefinierte Eigenschaften (var(--color-surface), var(--space-gap-group)) und verwenden Sie die Komponenten aus seinem Bestand wieder. Wenn das Design etwas benötigt, das das Theme nicht bietet, verwenden Sie das nächstgelegene Token und listen Sie die Ergänzung unter offenen Fragen auf; erfinden Sie keinen Wert. Ohne Theme befolgen Sie die unverhandelbaren Regeln in shared/theme/rules.md und bieten Sie die Fähigkeit theme an.

2. Referenzen lesen

Lesen Sie references/principles.md und references/presets.md, bevor Sie entwerfen. Verwenden Sie die plattformeigenen Muster (Seitenleiste oder Rail, Split View, Popover, Menüleistenbefehle), anstatt neue zu erfinden.

3. Bildschirm zusammensetzen

Komponenten, die jeweils ihre Prüfungen bestehen, können dennoch einen unübersichtlichen Bildschirm ergeben. Bevor Sie bauen, planen Sie, wie sie Abschnitte bilden und wie die Abschnitte den Bildschirm bilden, unter Verwendung der Kompositionsregeln des Plugins in shared/composition/principles.md:

• Schreiben Sie die Abschnittskarte. Listen Sie für jeden Bildschirm seine Abschnitte auf (eine Seitenleiste, ein Listenbereich, ein Detailbereich mit seiner Symbolleiste und ein Inspektor), die einzelne Aufgabe eines jeden, seine Mitglieder geordnet nach Nutzungshäufigkeit und seine eine Hervorhebung. Sagen Sie, was primärer Inhalt und was Chrome ist: Der Inhalt dominiert und das Chrome tritt zurück.
• Gruppieren Sie mit Abstand. Lücken innerhalb einer Gruppe sind deutlich kleiner als Lücken zwischen Gruppen; fügen Sie nur dann einen Container hinzu, wenn der Abstand die Gruppe nicht zeigen kann.
• Ein Look pro Rolle, eine Betonung pro Abschnitt. Gleiche Rolle, gleicher Stil; Status und Beschriftungen sehen nie aus wie Schaltflächen; die starke Akzentuierung gilt einer Sache pro Abschnitt, und ausgewählte Zustände verwenden eine ruhigere Behandlung.
• Halten Sie es klein. Etwa drei Schriftgrößen, eine Tatsache an einem Ort, häufige Mitglieder im Blick und seltene hinter einem Menü. Wenn eine Änderung etwas hinzufügt, reorganisieren Sie zuerst und fügen Sie nur das hinzu, was seinen Platz verdient.

4. Canvas-Artefakt bauen

Bauen Sie auf der shared resizable Canvas des Plugins (shared/canvas/; seine README.md enthält den vollständigen Vertrag). Schreiben Sie den Bildschirm als screen.html und die designeigenen Einstellungen als config.json in einen Arbeitsordner und bauen Sie dann:

node "${CLAUDE_PLUGIN_ROOT}/shared/canvas/build.mjs" \
  --presets "${CLAUDE_PLUGIN_ROOT}/skills/tablet/references/presets.md" \
  --config config.json --screen screen.html \
  --title "<Designname>" --out index.html

Veröffentlichen Sie index.html als Artefakt. Aus references/presets.md erhält die Canvas:

• Vollbild: ipad-mini 744, ipad 820, ipad-13 1032 und android-tablet 800. Drehung gibt jedes im Querformat.
• Split View: ipad-split, ipad-13-split und android-split, das Querformatgerät mit Ihrer App auf einer Seite eines Teilers. Der Teiler rastet auf 1/3, 1/2 und 2/3 ein (ziehen Sie ihn oder fokussieren Sie ihn und drücken Sie die Pfeiltasten); Full ist die Vollbildvorgabe im Querformat.
• Freie Größenänderung: Ziehpunkte von der voreingestellten Größe bis zu 320 × 450.
• Prüfungen: 320 breiter Neufluss und Querformat mit eingeblendeter Tastatur (1180 × 420).

Während des Ziehens muss das Layout live neu fließen. Der Übergang von voller Breite zu halber Breite muss kontinuierlich neu rendern, die Breakpoints 840 und 600 ohne Neuladen und ohne Zustandsverlust überschreiten. Die Anzeige zeigt die aktuelle Breite und ihre Größenklasse (compact, medium, expanded, large).

• config.json setzt title und states (z. B. default, loading, empty, error). Für ein Android-only-Design setzen Sie "initialPreset": "android-tablet"; für iPadOS und Android zusammen setzen Sie "minTarget": 48.
• Bildschirmvertrag: Ein <template id="uh-screen"> mit [data-screen]-Abschnitten und data-nav, data-nav-replace, data-nav-back und data-show-state für Klicks. Layout nach Größenklasse mit @container screen (width >= 600px) und (width >= 840px) oder dem Viewport-data-width-class, niemals nach Voreinstellung oder @media. Ränder mit var(--uh-safe-*) auffüllen, deklariert auf [data-screen] (:host kann sie nicht sehen). Text in rem; Trefferbereiche, Symbole und Rinnen in px, damit 200% Text die Wörter vergrößert, nicht die Bedienelemente. Farben mit light-dark(). Verhalten in window.ultrahandSetup = function (canvas) { … }.
• Eingebaute Umschalter: Hell/Dunkel, 200% Text, die Zustandsauswahl und Trefferziele anzeigen. Bauen Sie keine eigenen. Rufen Sie canvas.refresh() auf, nachdem Sie ein Sheet, Popover oder Menü geöffnet haben.
• Zeiger und Tastatur sind immer aktiv: Der Betrachter steuert das Artefakt mit Maus und Tastatur, geben Sie daher jedem Steuerelement einen Hover-Zustand, ein Rechtsklick-Kontextmenü, wo die Plattform eines hat, sichtbaren :focus-visible-Fokus und Tastenkombinationshinweise. Überprüfen Sie Touch mit der Trefferziel-Überlagerung. Verstecken Sie nichts davon hinter einem eigenen Umschalter.
• Halten Sie in iPad-Fenstermodi die führenden Symbolleistenschaltflächen frei von den oberen Fenstersteuerelementen.
• Machen Sie den Hauptfluss anklickbar: Navigation wechselt, Zeilen wählen aus oder schieben, Bereiche werden ein- und ausgeblendet, und Sheets und Popover öffnen und schließen sich. Verwenden Sie niemals alert, confirm oder prompt.

5. Jede Größenklasse entwerfen

Arbeiten Sie von breit nach schmal und beheben Sie jedes Problem bei der Größe, bei der es auftritt:

1. Expanded / large, Querformat Vollbild (z. B. ipad 1180): Wählen Sie die Bereiche, Navigation (Seitenleiste oder Rail) und Dichte. Begrenzen Sie Zeilenlängen und Steuerelementbreiten.
2. Medium, Hochformat Vollbild und 2/3 Split (z. B. 820, 787): Reduzieren Sie auf weniger Bereiche, mit einer Rail oder einer oberen Registerkartenleiste.
3. Compact, 1/2 und 1/3 Split (z. B. 590, 393): Das Telefonlayout mit einer unteren Leiste oder Registerkartenleiste, jeweils ein Bereich und Zurück zur Liste.
4. Ziehen Sie langsam von voller Breite auf 320 und zurück. Überprüfen Sie, ob Auswahl, Bildlaufposition und eingegebener Text erhalten bleiben. Überprüfen Sie, dass Liste-Detail das geöffnete Detail beim Verkleinern behält und dieses Element beim Vergrößern auswählt.

Überprüfen Sie dann die zusätzlichen Fälle: 320 breiter Neufluss, Querformat mit eingeblendeter Tastatur und die android-tablet-Voreinstellung (falls Android im Umfang ist) in beiden Ausrichtungen.

6. Selbstprüfung vor der Präsentation

Gehen Sie jeden Punkt durch. Beheben Sie jeden Fehler oder benennen Sie ihn und sagen Sie, warum er akzeptabel ist.

Komposition (führen Sie das Kompositionsaudit durch, node "${CLAUDE_PLUGIN_ROOT}/shared/input/drive.mjs" do "${CLAUDE_PLUGIN_ROOT}/shared/composition/audit.mjs", bei der größten und kleinsten Größe, oder prüfen Sie mit dem Auge):

• Unscharf zeigt der Bildschirm die beabsichtigten Abschnitte, und der primäre Inhalt zieht zuerst den Blick auf sich. Kein unbeabsichtigter heller Fleck.
• Jeder Abschnitt hat eine Aufgabe, seine Mitglieder nach Funktion und Häufigkeit gruppiert, mit Lücken zwischen Gruppen, die deutlich größer sind als Lücken innerhalb.
• Jeder Abschnitt hat höchstens ein stark hervorgehobenes Element; ausgewählte Zustände sind ruhig.
• Ein Stil pro Rolle: Zählen Sie die Steuerelementstile in jedem Abschnitt und begründen Sie jeden zusätzlichen. Keine Beschriftung oder kein Status sieht aus wie eine Schaltfläche.
• Zeilen und Abschnitte richten sich an gemeinsamen Kanten aus; etwa drei Schriftgrößen auf dem Bildschirm.
• Keine Tatsache wird zweimal gezeigt, und nichts auf dem Bildschirm dient nicht einer Aufgabe hier.
• Nach einer Runde von Änderungen: Listen Sie auf, was hinzugefügt wurde; der Bildschirm ist nicht überladener als nötig.
• Nur Theme-Werte: keine Rohfarben, keine Abstände außerhalb der 8-Punkt-Skala, keine Schriftgrößen außerhalb der Skala, und Bestandskomponenten werden wiederverwendet statt neu erstellt (shared/theme/rules.md NN-1, NN-2, NN-6, EV-4).

Komponenten und Plattform:

• Das Layout wechselt nach Breitenklasse (600 / 840), nicht nach Gerät. Jede Funktion ist bei jeder Breite von 320 bis Vollbild erreichbar.
• Größenänderung fließt live neu und behält Auswahl, Bildlauf, Eingabe und Wiedergabe. Nichts setzt an einem Breakpoint zurück.
• Navigation passt zur Breite: eine untere Leiste bei compact und eine Rail, obere Registerkartenleiste oder Seitenleiste darüber. Es gibt fünf oder weniger Registerkarten der obersten Ebene, keine versteckt oder deaktiviert.
• Mehrbereichslayouts folgen einem kanonischen Muster. Die Auswahl wird in jedem Bereich hervorgehoben, versteckte Bereiche haben mehr als einen Weg zurück, und kein Detailbereich bleibt leer.
• Nichts dehnt sich: Schaltflächen, Felder, Sheets, Dialoge und Bilder haben maximale Breiten, und Text hat eine lesbare Zeilenlänge.
• Antippziele sind mindestens 44 × 44 pt (iOS) oder 48 × 48 dp (Android) und niemals unter 24 × 24, selbst mit einem Zeiger. Primäre Inhalte liegen in der Mitte und häufige Steuerelemente sind von den Seitenkanten erreichbar.
• Nichts Interaktives befindet sich unter der Statusleiste, dem Home-Indikator, der Taskleiste oder den iPad-Fenstersteuerelementen, in keiner Ausrichtung.
• Zeiger: Jedes Steuerelement hat einen Hover-Zustand, Rechtsklick und Berühren-und-Halten öffnen ein Kontextmenü, und nichts ist nur bei Hover verfügbar.
• Wechseln von Elementen, Schließen eines Panels oder Verwerfen eines Sheets führt nie zu verlorenem eingegebenen Text; Rückgängig überlebt zwei aufeinanderfolgende Löschvorgänge und gibt das Element in seinen Bereich zurück.
• Tastatur: Hauptabläufe funktionieren mit Tab und Pfeiltasten, Fokus ist immer sichtbar, Standardtastenkombinationen funktionieren, und Esc schließt, bricht ab oder löscht.
• Jedes Drag-and-Drop hat eine Nicht-Drag-Alternative, zeigt gültige Ziele und kann rückgängig gemacht werden.
• Beide Ausrichtungen funktionieren, und das fokussierte Feld bleibt im Querformat mit eingeblendeter Tastatur sichtbar.
• Das Layout überlebt 200% Text, und der Kontrast beträgt mindestens 4,5:1 für Text und 3:1 für UI in beiden Modi, Hell und Dunkel.
• Lade-, Leer- und Fehlerzustände sind für jeden Bereich entworfen, nicht nur für den Bildschirm.
• Das Design funktioniert bei 320 breit ohne horizontales Scrollen.

7. Präsentieren

Teilen Sie den Artefakt-Link. Geben Sie in wenigen Zeilen die Abschnittskarte an (Aufgabe und Betonung jedes Abschnitts), die wichtigsten Entscheidungen und das Prinzip dahinter (zitieren Sie den Quellenschlüssel), wie sich das Layout bei jeder Breitenklasse ändert, jedes Selbstprüfungs-Item, das Sie mit einem Grund akzeptiert haben, und alle vorgeschlagenen Theme-Ergänzungen (für die Fähigkeit theme) sowie alle offenen Fragen.