luizhrocha/design-engineering

Design engineering

Les bonnes interfaces sont faites de nombreux petits détails que les utilisateurs ne remarquent jamais un par un. Chaque détail ci-dessous a une raison d'être. Appliquez-le là où la raison s'applique, et étudiez pourquoi les interfaces que vous admirez procurent la sensation qu'elles ont.

Choisir la compétence adaptée

• Une animation à construire : animate.
• Une différence dont le mouvement nécessite un verdict : review-animations.
• Une base de code dont le mouvement doit être audité et planifié : improve-animations. Les endroits qui devraient commencer à bouger : find-animation-opportunities. Les animations à supprimer : remove-animations.
• Plusieurs éléments se déplaçant ensemble : choreograph. Une animation qui saute des images : animation-performance.
• Glisser, balayer et feuilles sur le web : gestures.
• Un composant à tester avec des données défavorables : break-ui.
• Gestes, ressorts, matériaux et typographie au niveau d'Apple : apple-design.
• Une application web qui semble incorrecte sur un téléphone : mobile-native.
• Une bibliothèque de composants à choisir : pick-ui-library.
• Plusieurs directions pour une même pièce d'UI : prototype.

Cette compétence couvre le reste : le polissage des composants et une revue UI qui examine plus que le simple mouvement.

Règles qui couvrent la plupart des problèmes

1. Décidez si elle doit animer ou pas. Une action vue 100 fois ou plus par jour, ou déclenchée depuis le clavier, ne reçoit aucune animation.
2. Nommez les propriétés exactes. Jamais transition: all.
3. Entrée et sortie avec ease-out ou une courbe personnalisée forte, comme cubic-bezier(0.23, 1, 0.32, 1). Jamais ease-in sur une UI.
4. Gardez les animations UI sous 300 ms. Un menu déroulant prend 150 à 250 ms ; le retour de pression prend 100 à 160 ms.
5. Donnez à chaque élément pressable un état :active, comme transform: scale(0.97).
6. Ne jamais entrer depuis scale(0). Commencez par scale(0.95) avec opacity: 0.
7. Les popovers se mettent à l'échelle depuis leur déclencheur (transform-origin: var(--transform-origin) dans Base UI). Les modales restent centrées.
8. Utilisez des transitions, pas des keyframes, pour tout ce qu'un utilisateur peut déclencher à nouveau en plein vol. Elles se recentrent sur la valeur actuelle.
9. Animez uniquement transform et opacity. Dans Motion, utilisez la chaîne transform complète au lieu des raccourcis x et y.
10. Honorez prefers-reduced-motion avec un mouvement plus doux, pas aucun, et placez les effets de survol à l'intérieur d'un @media (hover: hover) and (pointer: fine).

Lorsque la sensation ne peut pas être jugée à partir du code, dites-le. Jouez l'animation à 2 à 5 fois sa durée ou image par image dans DevTools, testez les gestes sur un appareil réel, et regardez à nouveau le lendemain.

Format de revue

Une revue UI est un tableau markdown avec les colonnes Avant, Après et Pourquoi, une ligne par problème. N'écrivez jamais "Avant :" et "Après :" sur des lignes séparées.

Avant	Après	Pourquoi
transition: all 300ms	transition: transform 200ms ease-out	Nommez les propriétés ; all anime ce que vous n'aviez pas l'intention d'animer
transform: scale(0)	transform: scale(0.95); opacity: 0	Rien dans le monde réel n'apparaît de rien
Pas d'état :active sur un bouton	transform: scale(0.97) sur :active	Une pression nécessite un retour instantané

La référence

Pour une correction rapide d'un symptôme courant (nombres qui sautent, avatar écrasé, "1 membres"), consultez d'abord references/ui-cheatsheet.md.

Lisez references/craft.md pour les raisons et le code derrière chaque règle : le cadre de décision d'animation, les ressorts, les principes de composants (infobulles, flou plutôt qu'un fondu, @starting-style), les transformations, les motifs clip-path (onglets, maintenir pour supprimer, révélations d'images, curseurs de comparaison), la gestion du glisser et des gestes, la performance, l'accessibilité, les principes pour les composants que les gens aiment, le décalage, le débogage, et la liste de vérification de la revue.