Desktop

ultrahand: desktop

Entwerfen Sie Desktop-App- und Web-App-Bildschirme als interaktives Claude-Artefakt. Das Artefakt ist ein Fenster, das Sie auf jede beliebige Größe zwischen dem von Ihnen gewählten Minimum und Maximum ziehen können, mit Voreinstellungen für gängige Laptops, Monitore und angedockte Hälften, und das Layout fließt beim Ziehen live neu. Jede von Ihnen angewandte Regel ist in references/principles.md, und jede Regel zitiert references/sources.md. Die Größen, Grenzen 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 diese Punkte, bevor Sie zeichnen:

• Plattform: macOS, Windows, eine Web-App oder mehrere. Eine native macOS-App erhält eine Menüleiste; Windows- und Web-Apps erhalten eine Befehlsleiste oder Symbolleiste mit Überlauf.
• Umfang: ein Bildschirm oder ein Ablauf. Bei einem Ablauf listen Sie die Bildschirme auf und wie man sich zwischen ihnen bewegt: Seitenleiste, Tabs, Liste zu Detail, Seitenpanel, Dialog oder neues Fenster.
• Primäre Aufgabe: die eine Sache, für die jeder Bildschirm da ist, und welches Layout dazu passt (Listen-Detail, unterstützender Bereich, Feed oder ein einzelner Dokumentbereich).
• Echte Inhalte: Namen, Längen, Anzahlen, Spaltensets und die längsten plausiblen Zeichenfolgen. Nicht mit Lorem Ipsum entwerfen.
• Datenzustände: was lädt, was leer sein kann und was pro Bereich ausfallen oder offline gehen kann.
• Fenstergrenzen: die minimale Fenstergröße, die maximale und die maximale Inhaltsbreite. Standardmäßig 640 × 480 für eine native App und 320 × 256 für eine Web-App (siehe presets.md).
• Eingaben: Zeiger und Tastatur immer; Touch, falls es auf 2-in-1-Geräten oder Touch-Laptops laufen kann. Welche Befehle sind häufig genug, um eine Tastenkombination zu verdienen?
• Fenster: ein Fenster oder mehrere (Dokumente, Inspektoren, abgelöste Panels)?
• Einschränkungen: Markenfarben, Schriftarten, ein bestehendes Designsystem oder eine Komponentenbibliothek.
• Theme: Suchen Sie nach dem Theme des Projekts (design/THEME.md, *.tokens.json; siehe shared/theme/README.md), bevor Sie eine Farbe, Größe oder einen Abstand 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 nicht verhandelbaren Regeln in shared/theme/rules.md und bieten Sie den Skill theme an.

2. Die Referenzen lesen

Lesen Sie references/principles.md und references/presets.md, bevor Sie entwerfen. Verwenden Sie die plattformeigenen Muster (Menüleiste, Symbolleiste, Seitenleiste, geteilte Ansicht, Kontextmenü, Sheet, NavigationView), anstatt neue zu erfinden.

3. Den 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 Symbolleiste in höchstens drei Gruppen, eine Seitenleiste, einen Inhaltsbereich und einen Inspektor), die jeweilige einzelne Aufgabe, seine Mitglieder geordnet nach Häufigkeit der Nutzung und seine eine Hervorhebung. Sagen Sie, was primärer Inhalt und was Chrom ist: Der Inhalt dominiert und das Chrom tritt zurück.
• Gruppieren Sie mit Abstand. Abstände innerhalb einer Gruppe sind deutlich kleiner als Abstände zwischen Gruppen; fügen Sie einen Container nur hinzu, wenn der Abstand die Gruppe nicht zeigen kann.
• Ein Look pro Rolle, eine Hervorhebung pro Abschnitt. Gleiche Rolle, gleicher Stil; Status und Beschriftungen sehen niemals aus wie Schaltflächen; die starke Akzentuierung geht an eine 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 in Sichtweite 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. Das Canvas-Artefakt bauen

Bauen Sie auf der gemeinsam genutzten, in der Größe veränderbaren Leinwand des Plugins auf (shared/canvas/; seine README.md enthält den vollständigen Vertrag). Schreiben Sie den Bildschirm als screen.html und die eigenen Einstellungen des Designs als config.json, dann bauen Sie:

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

Veröffentlichen Sie index.html als Artefakt.

• config.json legt title, states (z.B. standard, laden, leer, fehler) und die limits des Designs fest: { minWidth, minHeight, maxWidth, maxHeight }. Die Leinwand lässt Sie jede Größe zwischen ihnen ziehen. Für eine Web-App setzen Sie auch "initialPreset": "browser".
• Voreinstellungen (aus presets.md): Laptops (1366 × 768, 1536 × 864, MacBook 1440 × 900), Monitore (1920 × 1080, 2560 × 1440), angedockte Hälften (960 × 1080, 720 × 900) und ein Browserfenster (1280 × 720). Prüfungen: Ihr minimales Fenster, ein kurzes 1366 × 600 Fenster und 400 % Zoom bei 320 × 256.
• Bildschirmvertrag: ein <template id="uh-screen"> mit [data-screen] Abschnitten und data-nav, data-nav-back und data-show-state für Klicks. Auf Größe reagieren mit @container screen (width >= …), nicht mit @media. Text in rem; Trefferflächen, 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, Zustandsauswahl und Antippziele (24 px Mindestgröße für Desktop). Rufen Sie canvas.refresh() auf, nachdem Sie ein Menü oder Popover geöffnet haben, damit die Zielüberlagerung es sieht.
• Lassen Sie es wie eine Desktop-App funktionieren: Hover-Zustände, ein Kontextmenü bei Rechtsklick (und Umschalt+F10), sichtbarer Fokus, funktionierende Tab- und Pfeiltasten-Navigation, Tastenkombinationshinweise in Menüs und Tooltips, Bereiche, die ein- und ausgeblendet werden, und Teiler, die ziehbar sind. Verwenden Sie niemals alert, confirm oder prompt; zeichnen Sie Dialoge im Bildschirm.

5. Jede Größenklasse entwerfen

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

1. Groß / Extra-groß (laptop-125, desktop-fhd): Wählen Sie die Bereiche, Navigation, Symbolleistengruppen und Dichte. Begrenzen Sie die Inhaltsbreite; zusätzliche Breite geht an Bereiche, nicht an längere Zeilen.
2. Erweitert (snap-half, ~960): Reduzieren Sie den Inspektor oder sekundären Bereich, verwandeln Sie die Seitenleiste in eine Leiste und beginnen Sie, Symbolleistenelemente in der geplanten Reihenfolge in den Überlauf zu verschieben.
3. Mittel und Ihr Minimum (mac-half, die Min-Fenster-Prüfung): Ein oder zwei Bereiche, eine Menü- schaltfläche oder Leiste für die Navigation, und jeder Befehl bleibt über Menüs erreichbar.
4. Ziehen Sie langsam vom Maximum zum Minimum und zurück. Auswahl, Scrollposition, eingegebener Text und geöffnete Panels müssen jeden Breakpoint überleben.

Führen Sie dann die Prüfungen durch: das kurze Fenster (klebende Leisten, Fokus nicht verdeckt) und für Web-Apps 400 % Zoom bei 320 × 256 (eine Spalte, nur vertikales Scrollen).

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

Komponenten und Plattform:

• Das Design gibt seine minimale und maximale Fenstergröße und seine maximale Inhaltsbreite an. Nichts überlappt oder wird am Minimum abgeschnitten, und nichts dehnt sich am Maximum.
• Das Layout wechselt nach Fensterbreite (Material 600 / 840 / 1200 oder Windows 641 / 1008), nicht nach Gerät. Jede Funktion ist in jeder Größe erreichbar.
• Größenänderung fließt live neu und behält Auswahl, Scrollen, Eingabe und geöffnete Panels bei.
• Bereiche folgen einem kanonischen Layout, Teiler sind ziehbar, Bereiche können per Schaltfläche, Menü und Tastenkombination ausgeblendet werden, und kein Bereich ist jemals leer ohne Erklärung.
• Fließtext bleibt bei oder unter 80 Zeichen pro Zeile.
• Jeder Befehl befindet sich in einem Menü (der Menüleiste unter macOS) oder im Symbolleistenüberlauf; nicht verfügbare Menüpunkte sind deaktiviert, nicht ausgeblendet; Befehle, die eine Eingabe erfordern, enden mit „…".
• Symbolleistenelemente laufen in einer geplanten Reihenfolge über, wenn das Fenster schmaler wird, mit höchstens drei Gruppen.
• Rechtsklick öffnet ein kurzes, relevantes Kontextmenü, und jeder seiner Befehle existiert auch woanders.
• Alles funktioniert mit der Tastatur ohne Fallen; Fokus ist immer sichtbar und niemals unter einer klebenden Leiste; Standardshortcuts werden nicht zweckentfremdet; Shortcuts werden in Menüs und Tooltips angezeigt.
• Nichts ist nur bei Hover verfügbar. Hover- und Fokusinhalte sind mit Esc schließbar, hoverbar und persistent; Tooltips enthalten keine lebenswichtigen Informationen.
• Ziele sind mindestens 24 × 24 px (etwa 40 × 40, wo Touch wahrscheinlich ist).
• Scrollen: Nur Inhalte scrollen, keine verschachtelten Scrollbereiche in derselben Richtung, Tabellenköpfe bleiben eingefroren, und kein kritisches Bedienelement sitzt am unteren Fensterrand.
• Bearbeitung verwendet das leichteste passende Muster: inline für ein Feld, ein Seitenpanel für einen Datensatz, ein Sheet oder Dialog für eine kurze blockierende Aufgabe, ein Fenster oder eine Seite für lange Abläufe. Bestätigungen sind nur für zerstörerische, irreversible Aktionen; alles andere bietet Rückgängig.
• Jedes Drag-and-Drop hat eine Nicht-Drag-Alternative.
• 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 das Fenster.
• Web-Apps: funktioniert bei 320 × 256 (400 % Zoom) ohne zweiseitiges Scrollen und hat einen Skip-Link.

7. Präsentieren

Teilen Sie den Artefakt-Link. Geben Sie in wenigen Zeilen die Abschnittskarte an (Aufgabe und Hervorhebung jedes Abschnitts), die Fenstergrenzen und maximale Inhaltsbreite, die wichtigsten Entscheidungen und das Prinzip hinter jeder (zitieren Sie den Quellenschlüssel), wie sich das Layout in jeder Breitenklasse ändert, jeden Selbstprüfungspunkt, den Sie mit einem Grund akzeptiert haben, und alle vorgeschlagenen Themenergänzungen (für den Skill theme) sowie alle offenen Fragen.