Nous nous retrouvons enfin, après plusieurs mois de travail acharné, face à la conclusion d’un projet qui me tient tant à cœur : après tout ce temps voué à l’apprentissage, l’expérimentation et la découverte, qu’aurais-je véritablement appris ? Quels sont les leçons que je tire de cette aventure ?
Bienvenue dans la dernière étude de cas de mon travail de fin d’année.
Chapitre I— Les derniers détails
Maintenant que j’avais réalisé la plus grosse partie de mon projet (cela comprend la page de présentation ainsi que la page d’accueil), il ne me restait plus qu’à corriger les derniers petits détails afin de rendre l’expérience aussi pratique et intuitive que possible. Cela consisterai principalement en de simples petites modifications de code par-ci par là, mais qui aurait suffisamment d’importance que pour améliorer mon outil d’une façon globale. Je supprimerai le maximum d’erreurs et de bugs auxquels j’avais fait face depuis le début du développement et continuerai d’ajouter davantage de mots à ma base de données, comme notamment des déterminants et des noms de métiers.
Parmi les différents bugs que j’eus corrigés, certains d’entre eux furent assez inattendus et provinrent de la même source : la nouvelle version de l’éditeur de texte. Étant donné que j’avais besoin d’afficher du contenu HTML au sein de mon texte (les balises <span> dont je parlais dans le rapport précédent), je n’avais d’autre choix, il y a de cela quelques semaines déjà, de complètement changer la manière dont l’utilisateur·trice interagissait avec le texte et comment je le récupérai : là où auparavant j’utilisais une balise <textarea>, permettant à l’utilisateur·trice d’introduire du texte simple comme je le souhaitais, je devais à présent utiliser un attribut contentEditable sur la balise qui servirai d’éditeur de texte.
La particularité de cet attribut est qu’il permet d’y insérer du contenu textuel, ainsi que du contenu HTML (c’est d’ailleurs de cette façon que la balise auquel l’attribut se rapporte gère le contenu textuel), ce qui me permet d’y insérer les <span> dont j’avais besoin, mais aussi tout un tas d’autre contenu utilisateur·trice qui n’a rien à faire ici, comme des images, du texte avec un autre style que celui que je propose, et j’en passe.
Les problèmes ne s’arrêtaient malheureusement pas là : c’était aussi tout le système de séparation du texte qui se voyait tomber à l’eau, vu qu’il était à présent sectionné en balises HTML et non plus en retours à la ligne.
Je passerai alors quelques jours à attaquer chaque problème l’un après l’autre, à réécrire presque entièrement la partie logique, afin de m’assurer que tout fonctionne comme je le souhaitais. J’en profiterai également pour nettoyer ledit code, et me débarrasser du bouton « retour en arrière », qui permettait d’annuler la suppression d’une modification locale : étant donné qu’il suffisait de repasser le texte dans le convertisseur pour reconvertir le mot, il n’était plus nécessaire de construire un bouton reproduisant le même effet.
Chapitre II — Les corrections
Après m’être assuré que le code était complet et qu’il comprenait toutes les fonctionnalités que j’avais envisagées (à l’exception du bouton mentionné plus haut), je décidai de tester et de faire tester mon outil, afin de découvrir des bugs auxquels je n’avais pas pensé auparavant.
Cela me permettra non seulement de m’assurer que l’outil que je proposais était bien opérationnel en situation d’utilisation « réelle », mais aussi de rajouter une petite liste de mots additionnels qui ne figuraient pas encore sur la titanesque base de données que je possédais déjà — base de données que j’avais d’ailleurs largement optimisée depuis le rapport dernier, arrivant maintenant à un poids « record » de 2 Méga octets pour 20 000 entrées uniques, ce qui est étonnamment peu selon moi (certaines images sont parfois plus lourdes que ça).
Je modifierai à nouveau quelques éléments visuels ainsi que quelques petites parties du code(comme recommandé par mes professeur·e·s ) par-ci par là, notamment au niveau des interactions avec les boutons adjacents à la boîte de texte. Ils se comportaient maintenant comme prévu : invisibles quand inutiles, opaques quand utilisables et semi-transparents lors du chargement du texte. Les balises <span> ont changé, elles aussi, pour paraître moins intrusives sans rompre le rythme de lecture tout en restant visuellement attractives à l’aide de la petite croix signifiant l’annulation de la modification (sur mobile, j’ai préféré opter pour une version plus visuelle de ces boutons afin de conserver cet aspect « facilement interactif avec un doigt »).
Après avoir vérifié à nouveau mon code et effectués mes dernières modifications, je pense que le projet est prêt à être conclu, présenté et utilisé.
Chapitre III — Les leçons tirées
Maintenant que le TFE touche à sa fin, je pense être capable de faire un compte rendu de tout ce que j’ai appris depuis le début du projet depuis son commencent.
Tout d’abord, j’aurai remis à épreuve ma capacité à créer des interfaces originales et intéressantes tout en restant accessible et aisément lisibles. Mes premières esquisses étaient, contrairement à ce qu’est devenu le projet par la suite, très simples et colorées, suivant la tradition du web moderne ; mais je prendrais un virage serré et proposerais une approche graphique plus personnelle, que je voulais mettre en place depuis si longtemps maintenant.
Ce qui est le plus impressionnant pour moi est la capacité que j’ai eu à réaliser en code exactement la vision du projet que j’avais envisagé, dans les moindres détails, alors que mes interfaces comprenaient des éléments que je n’avais jusque-là jamais réalisés auparavant, comme notamment le filtre granuleux animé se trouvant sur l’écran.
À propos du code justement, j’aurai appris à (ré)utiliser Vue 3, avec la majorité de ses fonctionnalités : les valeurs réactives, les valeurs calculées (computed), la Composition API, Vue CLI et j’en passe. Ce projet m’aura vraiment permit de comprendre plus précisément l’intérêt, les capacités et l’utilisation de Vue 3, tout en me permettant de m’y habituer. Bien sûr, partir de presque zéro et devoir tout réapprendre fut, au début, difficile et complexe, mais petit à petit, le code devenait plus compréhensible, les mots commençaient à porter du sens, et je comprenais ce que je pouvais et ne pouvais pas faire pour, in fine, construire un site entier en utilisant ce framework.
En outre, j’aurai découvert plus en profondeur le fonctionnement un peu plus complexe de Javascript, et j’entends par là l’utilisation de méthodes asynchrones afin d’empêcher à la partie logique d’empiéter sur la partie visuelle, permettant ainsi d’assurer une expérience douce et fluide pour les utilisateur·trice·s potentiel·le·s.
Enfin, ce projet m’aura appris à quel point le contexte était important et comment contextualiser un élément, en l’occurrence mon outil, pouvait avoir plus d’impact que ce dernier sur le long-terme. Cela permet non seulement que le monde puisse comprendre l’intérêt de cet outil, cela soit-il d’un point de vue sociétal ou psychologique, mais aussi de partager le plus précisément le point que l’on veut démontrer, dans l’espoir que l’idée germe au sein de la société et se démocratise petit à petit (dans ce cas-ci, l’utilisation de l’écriture inclusive).
Chapitre IV — Le rideau se ferme
Voici une nouvelle histoire qui se termine. Je n’ai plus énormément de choses à raconter, mis à part la fierté et le contentement qui m’habitent suite aux nombreuses découvertes, expérimentations et réalisations que j’aurai pu appliquer et mettre en œuvre durant le cours de ce projet. J’aimerai également exprimer ma gratitude et remercier toutes les personnes m’ayant aidé à réaliser ce dernier, sans qui je ne serai jamais arrivé jusqu’ici.
À bientôt pour de nouvelles aventures !
Les différents liens :
- Travail de fin d’année — Compte rendu du pitch
- Travail de fin d’année — Case Study n°1
- Travail de fin d’année — Case Study n°2
- Travail de fin d’année — Case Study n°3
- Travail de fin d’année — Case Study n°4
- Travail de fin d’année — Case Study n°5 [Vous êtes ici]
