Quatrième et dernière partie de mon histoire de redesign de teletravail.guru, cette fois-ci je vous raconte comment je suis passé d’un MVP en Nuxt+Vuetify avec de la search gérée par lunr, pour arriver à quelque chose de plus simple sur du Django.
Les parties précédentes:
- Refonte de télétravail.guru (3/4) - La tech
- Refonte de télétravail.guru (2/4) - Le Design
- Refonte de télétravail.guru (1/4) - Le Branding
- Refonte de télétravail.guru - Introduction
J’ai quand même un peu de chance, même si je ne comprends pas toute la tuyauterie de Django, globalement les templates sont assez simples à lire et à rédiger, donc je n’ai en fait même pas besoin de comprendre pour faire.
Mon idée de base, c’est d’utiliser ce que j’ai à disposition, soit les fondamentaux :
HTML / CSS et du JS si possible sans transpilation.
À ce moment, je retourne à mon framework de sélection :
- Je réduis mon champ des possibles en les ordonnant par celles que je maitrise le mieux (entendre celles qui me prennent le moins de temps)
- Et je réduis encore les possibilités offertes par le meilleur candidat, en utilisant un sous ensemble intelligible, pratique et que je maitrise bien si possible.
Ici, ce que je connais le mieux c’est Javascript, mais c’est aussi une source de complexité importante. Donc on va faire avec HTML et CSS. Globalement, pour HTML je vais tenter d’utiliser au maximum les bonnes pratiques, notamment en terme d’accessibilité. Reste la problématique du CSS…
Pour moi la solution est assez évidente : Tailwind CSS. C’est exactement un sous-ensemble cohérent et intelligible de CSS que je peux customiser à l’envie. En plus avec le nouveau moteur JIT je gagne vraiment en efficacité. Autre point fort, même s’il faut une pipeline de compilation, elle est très simple à mettre en place et assez souple pour s’adapter directement à mon projet en Django.
Dernier point, en développant, je commence toujours par créer plein de duplications pour dégager une généralisation. Dans mon cas, les composants répétés seront juste de bon vieux copier/coller.
Une fois la fonctionnalité d’autocomplete de la recherche enlevée, la page d’accueil n’a vraiment pas un design très compliqué. Avec tailwind la gestion du responsive est triviale, donc ça se fait bien.
Petit bémol : j’ai voulu utiliser une image de fond. Vous vous êtes renseigné de l’artillerie extrêmement lourde qu’il faut utiliser aujourd’hui pour avoir de bons score Lighthouse ? https://web.dev/serve-responsive-images/
Globalement, je n’avais pas les connaissances ni la patience de mettre ça en place. Par contre, je pouvais assez facilement générer une version dégradée de l’image en question et créer un composant custom de chargement fainéant (lazy-loading).
Plutôt que d’utiliser un framework, j’ai utilisé un Custom Element, qui tient sur 100 lignes.
Ça, c’était la partie simple. La partie compliquée c’est lorsqu’on doit afficher les annonces. Pour rappel, on utilise une navigation similaire à celle d’Indeed. Toutes les annonces correspondant à une recherche sur une barre de navigation latérale, et lorsqu’on clique, le détail de l’annonce s’affiche au centre. Ce concept me convient bien, puisqu’il permet de naviguer rapidement entre les annonces.
Seul problème: l’incompatibilité avec la navigation mobile.
En cherchant un peu j’ai trouvé un composant visuel qui conviendrait parfaitement, le bottom sheet. Pour moi, c’est un peu la réponse à beaucoup d’interactions de ce type sur mobile. Mais il fallait le coder (ou en trouver un en custom elements). Je n’ai pas trouvé une version qui répondait à tous mes besoins, donc je me suis attelé à la tâche.
Cerise sur le gâteau, j’avais réussi à en faire un composant qui réagit à la navigation, donnant ce feeling SPA. On peut donc revenir en arrière dans l’historique et voir disparaitre le tiroir du détail de l’annonce. Encore une fois, super fier de la tournure de la chose.
Globalement les contraintes supplémentaires m’avaient boosté créativement et les solutions trouvées me plaisent vraiment.
Un denier point que je peux mentionner ici. On a pu porter le CSS du site principal sur le blog : https://blog.teletravail.guru. Si l’on avait utilisé Vuetify, je pense que ça aurait été beaucoup plus difficile à faire, or en l’état ça ne m’a pris qu’une petite heure.
Bien sûr, le tout est encore perfectible. Mais c’est aussi l’apprentissage du contentement et la satisfaction d’avoir un produit qui vit sa vie et qui a déjà aidé des personnes à trouver un emploi en télétravail. C’est, pour moi, la finalité de l’expérience et même du développement : répondre à un besoin rencontré par de nombreuses personnes en leur facilitant la tâche. La partie technologique peut y aider, mais c’est rarement ce qui va différencier un produit d’un autre.
J’arrive à la fin de mon petit making-of, peut-être un peu confus, mais j’espère avoir montré que les développeurs ont ce super pouvoir de créer des outils pour tout le monde, et qu’en général se contenter est la meilleure approche pour se focaliser sur les besoins de ses utilisateurs.
