desktop

ultrahand : desktop

Concevez des écrans d'applications de bureau et d'applications web sous forme d'artefact Claude interactif. L'artefact est une fenêtre que vous faites glisser à n'importe quelle taille entre le minimum et le maximum que vous choisissez, avec des préréglages pour les ordinateurs portables, les moniteurs et les moitiés d'écran courants, et la mise en page se réorganise en direct pendant le glissement. Chaque règle que vous appliquez se trouve dans references/principles.md, et chaque règle cite references/sources.md. Les tailles, limites et classes de taille sont dans references/presets.md.

1. Recueillir les exigences

Ne demandez que ce que vous ne pouvez pas déduire. Réglez ces points avant de dessiner :

• Plateforme : macOS, Windows, une application web, ou plusieurs. Une application native macOS obtient une barre de menus ; les applications Windows et web obtiennent une barre de commandes ou une barre d'outils avec débordement.
• Périmètre : un écran ou un flux. Pour un flux, listez les écrans et la manière dont les personnes se déplacent entre eux : barre latérale, onglets, liste vers détail, panneau latéral, boîte de dialogue ou nouvelle fenêtre.
• Tâche principale : la seule chose pour laquelle chaque écran est conçu, et la disposition qui lui convient (liste-détail, panneau de support, fil d'actualité, ou un seul panneau de document).
• Contenu réel : noms, longueurs, nombres, ensembles de colonnes et les chaînes plausibles les plus longues. Ne concevez pas avec du lorem ipsum.
• États des données : ce qui se charge, ce qui peut être vide, et ce qui peut échouer ou être hors ligne, par panneau.
• Limites de la fenêtre : la taille minimale de la fenêtre, la taille maximale, et la largeur maximale du contenu. Par défaut, à 640 × 480 pour une application native et 320 × 256 pour une application web (voir presets.md).
• Entrées : pointeur et clavier toujours ; tactile si elle peut fonctionner sur des 2-en-1 ou des ordinateurs portables tactiles. Quelles commandes sont assez fréquentes pour mériter un raccourci ?
• Fenêtres : une fenêtre, ou plusieurs (documents, inspecteurs, panneaux détachés) ?
• Contraintes : couleurs de marque, polices, un système de conception existant ou une bibliothèque de composants.
• Thème : recherchez le thème du projet (design/THEME.md, *.tokens.json ; voir shared/theme/README.md) avant de choisir une couleur, une taille ou un espacement. S'il y en a un, concevez avec : exécutez node "${CLAUDE_PLUGIN_ROOT}/shared/theme/css.mjs" <tokens.json> --style --out theme.html, passez --head theme.html à la construction, utilisez uniquement ses propriétés personnalisées (var(--color-surface), var(--space-gap-group)), et réutilisez les composants de son inventaire. Lorsque la conception a besoin de quelque chose que le thème ne fournit pas, utilisez le jeton le plus proche et listez l'ajout sous questions ouvertes ; n'inventez pas de valeur. Sans thème, suivez les non-négociables dans shared/theme/rules.md et proposez la compétence theme.

2. Lire les références

Lisez references/principles.md et references/presets.md avant de concevoir. Utilisez les modèles de la plateforme elle-même (barre de menus, barre d'outils, barre latérale, vue divisée, menu contextuel, feuille, NavigationView) plutôt que d'en inventer de nouveaux.

3. Composer l'écran

Des composants qui réussissent chacun leurs vérifications peuvent néanmoins s'additionner pour former un écran en désordre. Avant de construire, planifiez comment ils forment des sections et comment les sections forment l'écran, en utilisant les règles de composition du plugin dans shared/composition/principles.md :

• Écrivez la carte des sections. Pour chaque écran, listez ses sections (une barre d'outils en au plus trois groupes, une barre latérale, un panneau de contenu et un inspecteur), le travail unique de chacune, ses membres ordonnés par fréquence d'utilisation, et son unique accent. Dites ce qui est contenu principal et ce qui est chrome : le contenu domine et le chrome s'efface.
• Groupez avec de l'espace. Les espaces à l'intérieur d'un groupe sont nettement plus petits que les espaces entre les groupes ; n'ajoutez un conteneur que lorsque l'espace ne peut pas montrer le groupe.
• Un seul aspect par rôle, un seul accent par section. Même rôle, même style ; le statut et les étiquettes ne ressemblent jamais à des boutons ; l'accent fort va à une seule chose par section, et les états sélectionnés utilisent un traitement plus discret.
• Gardez-le petit. Environ trois tailles de police, un seul fait à un seul endroit, les membres fréquents en vue et les rares derrière un menu. Lorsqu'un changement ajoute quelque chose, réorganisez d'abord et n'ajoutez que ce qui mérite sa place.

4. Construire l'artefact du canevas

Construisez sur le canevas redimensionnable partagé du plugin (shared/canvas/ ; son README.md contient l'intégralité du contrat). Écrivez l'écran sous forme de screen.html et les propres paramètres de la conception sous forme de config.json, puis construisez :

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

Publiez index.html en tant qu'artefact.

• config.json définit title, states (par exemple défaut, chargement, vide, erreur) et les limits de la conception : { minWidth, minHeight, maxWidth, maxHeight }. Le canevas vous permet de faire glisser n'importe quelle taille entre elles. Pour une application web, définissez également "initialPreset": "browser".
• Préréglages (à partir de presets.md) : ordinateurs portables (1366 × 768, 1536 × 864, MacBook 1440 × 900), moniteurs (1920 × 1080, 2560 × 1440), moitiés d'écran (960 × 1080, 720 × 900) et une fenêtre de navigateur (1280 × 720). Vérifications : votre fenêtre minimale, une fenêtre courte 1366 × 600 et un zoom 400% à 320 × 256.
• Contrat d'écran : un <template id="uh-screen"> avec des sections [data-screen], et data-nav, data-nav-back et data-show-state pour les clics. Répondez à la taille avec @container screen (width >= …), pas avec @media. Texte en rem ; zones de clic, icônes et gouttières en px, afin que le texte à 200% agrandisse les mots, pas les contrôles. Couleurs avec light-dark(). Le comportement va dans window.ultrahandSetup = function (canvas) { … }.
• Bascules intégrées : clair/sombre, texte 200%, sélecteur d'état, et cibles tactiles (24 px minimum pour le bureau). Appelez canvas.refresh() après avoir ouvert un menu ou un popover pour que la superposition de cibles le voie.
• Faites-le fonctionner comme une application de bureau : états de survol, un menu contextuel sur clic droit (et Shift+F10), focus visible, navigation par Tab et touches fléchées fonctionnelle, astuces de raccourci dans les menus et les infobulles, panneaux qui se cachent et s'affichent, et séparateurs qui se glissent. N'utilisez jamais alert, confirm ou prompt ; dessinez les boîtes de dialogue dans l'écran.

5. Concevoir chaque classe de taille

Travaillez du large à l'étroit, et corrigez chaque problème à la taille où il apparaît :

1. Grand / Très grand (laptop-125, desktop-fhd) : choisissez les panneaux, la navigation, les groupes de barres d'outils et la densité. Limitez la largeur du contenu ; la largeur supplémentaire va aux panneaux, pas à des lignes plus longues.
2. Élargi (snap-half, ~960) : réduisez l'inspecteur ou le panneau secondaire, transformez la barre latérale en un rail, et commencez à déplacer les éléments de la barre d'outils vers le débordement dans l'ordre prévu.
3. Moyen et votre minimum (mac-half, la vérification de la fenêtre minimale) : un ou deux panneaux, un bouton de menu ou un rail pour la navigation, et chaque commande toujours accessible via les menus.
4. Faites glisser lentement du maximum au minimum et inversement. La sélection, la position de défilement, le texte saisi et les panneaux ouverts doivent survivre à chaque point d'arrêt.

Ensuite, exécutez les vérifications : la fenêtre courte (barres collantes, focus non masqué) et, pour les applications web, zoom 400% à 320 × 256 (une colonne, défilement vertical uniquement).

6. Auto-vérification avant de présenter

Passez en revue chaque élément. Corrigez tout échec, ou nommez-le et dites pourquoi il est acceptable.

Composition (exécutez l'audit de composition, node "${CLAUDE_PLUGIN_ROOT}/shared/input/drive.mjs" do "${CLAUDE_PLUGIN_ROOT}/shared/composition/audit.mjs", à la taille la plus grande et la plus petite, ou vérifiez à l'œil nu) :

• Flouté, l'écran montre les sections prévues, et le contenu principal attire l'œil en premier. Aucun point lumineux involontaire.
• Chaque section a un seul travail, ses membres groupés par fonction et fréquence, avec des espaces entre les groupes nettement plus grands que les espaces à l'intérieur d'eux.
• Chaque section a au plus un élément fortement accentué ; les états sélectionnés sont discrets.
• Un style par rôle : comptez les styles de contrôle dans chaque section et justifiez tout supplément. Aucune étiquette ou statut ne ressemble à un bouton.
• Les lignes et les sections s'alignent sur des bords partagés ; environ trois tailles de police sur l'écran.
• Aucun fait n'est montré deux fois, et rien à l'écran qui ne sert pas une tâche ici.
• Après une série de modifications : listez ce qui a été ajouté ; l'écran n'est pas plus chargé qu'il ne doit l'être.
• Uniquement des valeurs de thème : pas de couleurs brutes, pas d'espacement hors de l'échelle de 8 points, pas de tailles de police en dehors de l'échelle, et les composants de l'inventaire réutilisés plutôt que reconstruits (shared/theme/rules.md NN-1, NN-2, NN-6, EV-4).

Composants et plateforme :

• La conception indique ses tailles de fenêtre minimale et maximale et sa largeur de contenu maximale. Rien ne se chevauche ou n'est coupé au minimum, et rien ne s'étire au maximum.
• La disposition change en fonction de la largeur de la fenêtre (Material 600 / 840 / 1200, ou Windows 641 / 1008), pas en fonction de l'appareil. Chaque fonctionnalité est accessible à toutes les tailles.
• Le redimensionnement réorganise en direct et conserve la sélection, le défilement, la saisie et les panneaux ouverts.
• Les panneaux suivent une disposition canonique, les séparateurs se glissent, les panneaux peuvent être masqués par bouton, menu et raccourci, et aucun panneau n'est jamais vide sans explication.
• Le texte du corps reste à 80 caractères ou moins par ligne.
• Chaque commande se trouve dans un menu (la barre de menus sur macOS) ou le débordement de la barre d'outils ; les éléments de menu indisponibles sont désactivés, pas masqués ; les commandes nécessitant une saisie se terminent par "…".
• Les éléments de la barre d'outils débordent dans un ordre planifié à mesure que la fenêtre se rétrécit, avec au plus trois groupes.
• Le clic droit ouvre un menu contextuel court et pertinent, et chacune de ses commandes existe également ailleurs.
• Tout fonctionne au clavier sans piège ; le focus est toujours visible et jamais sous une barre collante ; les raccourcis standard ne sont pas réaffectés ; les raccourcis s'affichent dans les menus et les infobulles.
• Rien n'est disponible uniquement au survol. Le contenu au survol et au focus peut être supprimé avec Esc, peut être survolé et est persistant ; les infobulles ne contiennent pas d'informations vitales.
• Les cibles mesurent au moins 24 × 24 px (environ 40 × 40 là où le tactile est probable).
• Défilement : seul le contenu défile, pas de zones de défilement imbriquées dans la même direction, les en-têtes de tableau restent figés, et aucun contrôle critique n'est situé au bord inférieur de la fenêtre.
• L'édition utilise le modèle le plus léger qui convient : en ligne pour un champ, un panneau latéral pour un enregistrement, une feuille ou une boîte de dialogue pour une tâche bloquante courte, une fenêtre ou une page pour les longs flux. Les confirmations ne sont que pour les actions destructrices et irréversibles ; tout le reste offre Annuler.
• Chaque glisser-déposer a une alternative sans glisser.
• La disposition survit à un texte à 200 %, et le contraste est d'au moins 4,5:1 pour le texte et 3:1 pour l'interface utilisateur en mode clair et sombre.
• Les états de chargement, vide et d'erreur sont conçus pour chaque panneau, pas seulement pour la fenêtre.
• Applications web : fonctionne à 320 × 256 (zoom 400 %) sans défilement bidirectionnel, et possède un lien d'évitement.

7. Présenter

Partagez le lien de l'artefact. En quelques lignes, indiquez la carte des sections (le travail et l'accent de chaque section), les limites de la fenêtre et la largeur maximale du contenu, les décisions clés et le principe derrière chacune (citez la clé de source), comment la disposition change à chaque classe de largeur, tout élément de l'auto-vérification que vous avez accepté avec une raison, et toute proposition d'ajout au thème (pour la compétence theme), et toutes les questions ouvertes.