Finsweet Client-First est-il pour vous ? Avantages et limites

L'expression « L'avenir du développement Webflow » est peut-être un peu dramatique, mais qui n'aime pas un titre accrocheur ? Certes, nous pourrions rêver de fonctionnalités plus avancées, comme le support multilingue, des limites CMS élargies ou des fonctions d'espaces membres plus poussées. Pourtant, nous sommes de fervents défenseurs de Webflow et persuadés que ces évolutions arriveront en temps voulu. Revenons donc à nos moutons… et concentrons-nous sur les outils disponibles qui peuvent rendre notre parcours Webflow plus fluide. (Mise à jour : Webflow a depuis lancé la Localisation native, exactement ce dont nous rêvions, et ce site fonctionne avec.)

La question est la suivante : Client-First est-il le bon choix pour tous les designers ou développeurs Webflow ? Nous allons passer en revue les bases de Client-First, peser ses avantages et ses inconvénients, et vous aider à décider s'il vous convient. Alors plongeons dans le Client-First de Finsweet !

Comprendre Client-First

Client-First est une philosophie et un ensemble de bonnes pratiques conçus pour aider les développeurs Webflow à créer des sites organisés, évolutifs et faciles à maintenir. L'approche repose sur une série de principes et de stratégies qui privilégient la facilité d'utilisation, tant pour le développeur que pour le client. En adoptant Client-First, les développeurs Webflow peuvent :

Gagner du temps et économiser des ressources en rationalisant le processus de développement.
S'assurer que leurs projets sont faciles à comprendre et à maintenir pour les membres de l'équipe comme pour les clients.

Pour une introduction plus approfondie, vous pouvez écouter l'explication de Joe, de chez Finsweet :

Les avantages d'adopter Client-First

Un flux de travail fluide : suivre les bonnes pratiques de Client-First permet de supprimer les étapes inutiles et favorise un développement plus efficace et mieux organisé. Des projets livrés plus vite et moins d'obstacles en chemin, pour ne citer que quelques atouts.
Une collaboration sans effort : avec Client-First, les projets sont structurés de façon claire et facile à prendre en main, ce qui simplifie la collaboration, même avec de nouveaux collègues ou clients.
Une meilleure maintenabilité : l'un des principes clés de Client-First est de concevoir les sites en pensant à leur maintenance future. Les clients gèrent ainsi plus facilement leur site, ce qui améliore leur expérience globale.
La cohérence : Client-First fournit des lignes directrices claires qui garantissent que tous vos projets Webflow suivent une structure et un design cohérents, un aspect essentiel pour les agences et les grandes équipes.
L'accessibilité : l'un des grands axes de Client-First est l'accessibilité. La méthodologie utilise principalement des REM plutôt que des pixels, ce qui permet à tout de s'agrandir et de rétrécir avec la taille du texte dans le navigateur.

Les inconvénients d'adopter Client-First

Une courbe d'apprentissage : comme toute nouvelle méthodologie, Client-First demande un temps d'apprentissage. Les développeurs doivent investir du temps pour se familiariser avec l'approche, ce qui peut ralentir leur progression au début.
Pas idéal pour tous les projets : Client-First s'adresse aux développeurs Webflow qui privilégient l'organisation et la maintenabilité. Cependant, les sites plus petits ou plus simples n'ont peut-être pas besoin d'un tel niveau de structure.
Un changement d'état d'esprit : adopter Client-First oblige à abandonner ses vieilles habitudes et à porter un regard neuf sur le développement Webflow. Ce changement peut être difficile pour les développeurs habitués à une approche plus libre.

Faut-il utiliser Client-First ?

La décision d'adopter Client-First dépend en fin de compte de vos préférences personnelles et des besoins précis de vos projets. Si vous appréciez l'organisation, l'efficacité et la maintenabilité à long terme, Client-First pourrait changer la donne dans votre façon de développer sous Webflow.

En revanche, si vous travaillez sur de petits projets ou que vous avez déjà un flux de travail bien rodé qui répond à vos besoins, adopter Client-First sera peut-être moins utile. Dans les deux cas, nous vous recommandons d'explorer la méthodologie, de réfléchir à la façon dont ses principes pourraient enrichir votre approche actuelle, et de voir comment nous avons commencé à l'intégrer à notre flux de travail.

Le Client-First de Finsweet est une approche innovante du développement Webflow, qui vise à améliorer l'organisation, l'efficacité et la maintenabilité de vos projets. En suivant ses lignes directrices et ses bonnes pratiques, vous pouvez rationaliser votre flux de travail, améliorer la collaboration et offrir une meilleure expérience globale à vos clients.

Il est toutefois essentiel de se rappeler qu'aucune méthodologie n'est parfaite pour tous les développeurs ni pour tous les projets. Nous vous encourageons à explorer Client-First et à réfléchir à la manière dont ses principes pourraient s'intégrer à vos pratiques actuelles. Vous y trouverez peut-être la pièce manquante que vous cherchiez, ou vous constaterez qu'une approche hybride convient mieux à vos besoins. Au fond, Client-First est lui-même une approche hybride : on vous encourage à utiliser les éléments et la structure proposés et à les personnaliser, mais aussi à ajouter ce dont vous avez besoin quand il faudrait sinon empiler trop de styles.

En fin de compte, le plus important est d'évaluer et d'affiner sans cesse votre processus de développement pour livrer le meilleur travail possible à vos clients. Que vous adoptiez Client-First à fond, que vous n'en reteniez que certains éléments ou que vous gardiez votre approche actuelle, ne cessez jamais de chercher des moyens d'optimiser votre expérience de développement Webflow.

Que fait Milk Moon Studio ?

Client-First est arrivé au moment précis où nous commencions à faire beaucoup plus d'efforts pour être plus inclusifs, adopter l'accessibilité et rendre notre propre travail plus facile à comprendre pour les autres développeurs Webflow.

En tant que designers et développeurs Webflow, nous avons toujours essayé de nous impliquer dans la communauté Webflow, que ce soit en posant beaucoup de questions sur le forum ou en répondant et en aidant les autres quand nous le pouvons. Au fil des ans, nous avons aussi cherché à bloguer activement sur Webflow, pour aider les autres en leur montrant comment nous avons trouvé la solution à tel ou tel problème, en bricolant toutes sortes de choses avec du code personnalisé dans Webflow ou, en raison de mon propre parcours, en publiant pas mal de contenus Webflow liés à l'analytique. Derrière tout cela, il y a la conviction que notre travail doit être accessible, non seulement aux utilisateurs qui visitent les sites que nous construisons, mais aussi aux autres développeurs Webflow.

Nous ne voulons jamais prendre nos clients en otage. Dans un monde idéal, nous voulons qu'un client puisse nous remercier en plein milieu d'un projet, prendre le travail que nous avons fait pour lui, le confier à un autre développeur et que celui-ci poursuive ce que nous avons commencé sans perdre une minute.

Dès le départ, il y a quelques années déjà, nous avons essayé d'y parvenir au moins en donnant des noms de classes descriptifs, regroupés par section, à la manière de la structure de composants et de dossiers de Finsweet, pour que quiconque ouvre le projet sache ce qui se passait et ce qu'il était en train de modifier, de réutiliser ou autre. Nous voulions aussi que non seulement un développeur ou un designer Webflow comprenne, mais nos clients aussi. Nous y sommes parvenus dans une certaine mesure, il est toujours difficile de dire exactement à quel point on est efficace, mais je dirais que c'était plutôt bien.

La phase suivante pour nous, en tant que studio Webflow, en matière de croissance interne et de compétences, a été de mieux rendre nos sites accessibles pour l'utilisateur, là-bas dans la nature, ce qui touche à tout, des aria labels au contraste des couleurs, en passant par la taille du texte, les balises HTML et bien trop de choses pour les couvrir ici. Mais le grand chantier que nous n'avions pas mené dès le départ, c'était de tourner le dos au pixel. Alors, au moment où nous passions aux REM, Client-First venait de sortir, et son accent sur l'accessibilité, non seulement pour l'utilisateur qui consulte votre site sur le web, mais aussi pour un autre développeur qui regarde votre travail et pour qui on le rend accessible d'emblée, correspondait immédiatement à nos valeurs.

Nous avons donc décidé de l'essayer sur un petit projet. Et après la première journée, nous avons abandonné pour revenir à nos habitudes, nommer les choses comme avant, en restant aussi inclusifs que possible, et nous étions alors déjà passés principalement aux REM de toute façon. C'était simplement plus rapide, avec moins d'éléments sur la page, et nous y étions habitués, donc c'était sûr.

Puis nous avons réessayé plus tard, avec des approches plutôt hybrides. Bref, avançons jusqu'à aujourd'hui. Client-First est une bête, il y a beaucoup de documentation, et il faut beaucoup de temps pour s'y habituer. Notre processus est différent de celui de beaucoup de monde. Nous concevons le moindre détail dans Figma d'abord (l'un de nos outils préférés pour les petites agences) et nous le prototypons pour les clients, puis nous construisons dans Webflow, une fois cela terminé, relu et approuvé. Nous construisons de zéro, pour correspondre exactement à ce que nous avons dans Figma, nous réalisons des sites web sur mesure.

Mais nous avons commencé à utiliser Client-First sur tous nos projets désormais. Ce n'est pas plus facile, je dirais que c'est toujours plus difficile. Nous ne pensons pas à Client-First quand nous concevons, nous offrons à nos clients de beaux sites, nous leur donnons ce qu'ils veulent, et ensuite, quand nous démarrons un nouveau projet, nous clonons Client-First et nous devons passer beaucoup de temps à tout faire ressembler et fonctionner exactement comme notre design. Personnellement, il est toujours plus rapide pour moi de construire comme avant, je dois me souvenir de tellement de choses en construisant un site avec Client-First. Ce n'était pas comme ça avant, j'inspectais simplement ce que nous avions fait dans Figma et je stylais en conséquence. Un seul élément sur la page pouvait faire ce que 5 font dans Client-First, dans une certaine mesure en tout cas. Maintenant, je dois me rappeler ce que j'ai utilisé sur une section d'une autre page pour le padding-top, ou aller voir.

Alors pourquoi le faire, si c'est plus rapide et moins fastidieux de s'en passer ? Eh bien, ils ont consacré beaucoup de temps et de réflexion aux bonnes pratiques, à la standardisation, au nommage, aux dossiers, à la structure des composants et des pages, à l'accessibilité, et à leur extension Chrome (Finsweet Extension), l'une des extensions Chrome essentielles pour Webflow à nos yeux. C'est rapide en termes de vitesse de page, avec moins de DOM, cela fonctionne à merveille avec Finsweet Attributes pour faire tout ce que Webflow ne fait pas d'emblée, toutes sortes de choses en fait, mais au fond, la raison pour laquelle nous y passons plus de temps… c'est l'adoption de ce qu'ils ont créé.

Aujourd'hui encore, je dirais probablement que si je construisais un site comme avant Client-First, mon client, cette personne dans son bureau qui ne connaît rien au CSS, à Flexbox ou à Grid, comprendrait mieux ce qui se passe que si je le faisais avec Client-First, et un développeur comprendrait certainement en lisant tous les noms de classes. Mais, et c'est là que l'adoption de Client-First prend tout son sens, très très peu de nos clients essaieront un jour de faire quelque chose dans le Designer, ils reviendront vers nous, chez Milk Moon Studio, ou iront voir un autre Webflow Expert ou Webflow Partner ou Webflow Designer ou simplement un gars qui s'y connaît un peu en Webflow, et ils ouvriront notre projet, et si nous avons utilisé Client-First, ils sauront ce qui se passe, instantanément, s'ils l'ont déjà utilisé, et beaucoup l'ont fait, parce qu'il est devenu très populaire. Tous les composants de Relume sont en Client-First, et c'est le cas de nombreuses autres bibliothèques.

Et s'ils ne le connaissent pas, eh bien, le nommage est standardisé et descriptif, ils s'y retrouveront très vite. Oui, nous avons franchi le pas vers Client-First. Même si cela a demandé un effort considérable et que ce n'est peut-être pas la méthode de construction la plus rapide, c'est très accessible pour les autres développeurs lorsqu'ils ouvrent le Webflow Designer. De plus, c'est plus accessible pour les internautes, en particulier ceux qui ont une déficience visuelle.

Derniers mots sur Client-First

Classes personnalisées : utilisez-les avec discernement : elles sont super flexibles, mais trop de bonnes choses tue les bonnes choses, non ? Oui, cela peut transformer vos feuilles de style en un joyeux fouillis, surtout sur les gros projets.
La courbe d'apprentissage ? Elle est bien réelle : apprendre Client-First, c'est un peu comme apprendre le skateboard. Vous risquez de tituber et de tomber au début, surtout si vous avez l'habitude de rouler autrement. Mais bon, c'est en forgeant qu'on devient forgeron, non ?
Changements globaux : une affaire délicate : rester simple avec les classes globales, c'est génial, mais parfois, c'est comme essayer de manœuvrer un énorme navire. Les grands changements peuvent se compliquer un peu.
Il n'y a pas de taille unique : Client-First est pratique pour le flux de travail, mais il ne plaira peut-être pas à tout le monde, surtout si vous êtes adepte du CSS à l'ancienne ou si vous aimez les approches utility-first.
Mélanger les styles : mélanger classes personnalisées, globales et utilitaires ? C'est un peu comme une danse où il faut surveiller ses pas pour ne pas marcher sur les pieds des autres. (C'est souvent la spécificité qui pose problème, alors notre guide sur la spécificité CSS dans Webflow peut vous aider.)
Gérer la variété des styles : quand les besoins de style de votre projet sont aussi variés qu'une énorme playlist Spotify, Client-First risque de ne pas taper juste à chaque note, comparé aux méthodes utility-first.

Alors, est-ce que ça vaut le coup ? Pour nous, oui. Cela correspond à nos valeurs d'accessibilité pour nos clients, les internautes et les autres développeurs Webflow. Que vous décidiez d'adopter Client-First à fond, d'en retenir certains éléments ou de garder votre approche actuelle, n'oubliez pas de chercher sans cesse des moyens d'optimiser votre processus de développement Webflow. Si vous voulez un point de départ pour nommer proprement vos classes avant de vous engager, nous avons aussi écrit sur le lancement d'un projet Webflow avec le guide de style Acme. Bonne conception !

FAQ sur Client-First

Qu'est-ce que Client-First dans Webflow ?

Client-First est un ensemble gratuit de lignes directrices et un système de nommage des classes pour Webflow, conçu et géré par Finsweet. Il couvre le nommage, les dossiers, la structure des pages, l'espacement et le dimensionnement en rem, afin que tout développeur qui ouvre le projet comprenne ce qui s'y passe.

Qui propose les meilleurs services de développement Client-First ?

Nous ne sommes pas neutres, mais nous construisons chaque nouveau projet avec Client-First, c'est donc un point de départ honnête. La réponse sincère est de chercher un studio ou un freelance Webflow qui livre réellement des projets Client-First, et de demander à en voir un.

Client-First utilise-t-il le rem plutôt que les pixels ?

Oui. Client-First dimensionne les éléments en rem, ce qui permet aux réglages de police du navigateur et au zoom de fonctionner correctement, et c'est le principal bénéfice du système en matière d'accessibilité.

Client-First vaut-il le coup pour les petits projets ?

Pas toujours. Pour un petit site simple, la structure peut dépasser vos besoins, et une approche hybride plus légère peut être plus rapide. Pour tout ce qu'un client ou un autre développeur continuera de modifier, cela en vaut la peine.