Nous sommes bientôt arrivés à la moitié de notre TFE, et nous rapprochons dramatiquement vite de la fin de l’année. Après les premiers retours des utilisateur·trices durant les présentations MVP, nous pouvons à présent avancer à notre rythme.
Chapitre I — Changements finaux
Juste avant le début de la rédaction de ce Case Study, tous·te·s les étudiant·e·s eurent l’opportunité de faire tester leur prototype, soit-il développé ou sous forme de maquette, par un·e autre étudiant·e de l’option qui devrait alors le présenter, dans l’espoir d’en éliminer les différents problèmes et autres incohérences au sein de nos projets respectifs. Chacun·e pu avoir un peu de recul sur son propre projet et pouvait à présent continuer à travailler dessus de la manière dont iel le souhaitait. Pour ma part, je devais modifier quelques éléments çà et là afin de conclure la partie prototypage et réflexion sur le contenu.
Parmi les différentes remarques que j’obtins de la part de mon testeur, Trystan Lothaire, j’avais notamment beaucoup de contenu rébarbatif, et d’incohérences au niveau du placement de mes boutons sur l’outil lui-même ; le reste, notamment d’un point de vue visuel, semblait lui avoir plus.
Je vais alors prêter mon attention aux différentes zones dites “négatives” afin de les améliorer d’une façon ou d’une autre et de rendre mon projet en général plus épuré, propre et pratique d’accès. Je commencerai en modifiant mon contenu en ajoutant différents éléments visuels comme des tableaux, censés brisés le rythme de lecture et de mettre l’accent sur le changement effectué entre la version inclusive et la version qui ne l’est pas, et je repositionnerai mes différents boutons afin qu’ils occupent plus ou moins tous la même zone sur l’écran pour éviter à l’utilisateur·trice de faire de grands mouvements d’yeux qui peut s’avérer fatiguant psychologiquement sur le long terme (j’en profiterai pour modifier mes animations pour qu’ils n’apparaissent qu’au moment le plus opportun).
Toutes ces petites modifications qui peuvent paraître assez futile avec du recul, jouent un assez grand rôle pour moi : l’écriture inclusive étant déjà un sujet assez sensible auprès des personnes qui en réfutent l’existence ou qui ne souhaitent tout simplement pas l’utiliser, je voulais vraiment qu’ils comprennent vraiment le but de cet outil et qu’ils puissent s’en servir s’ils le souhaitaient sans s’en lasser, ni s’en fatiguer, et c’est grâce à ces petits changements que leur expérience sera un tant soit peu plus agréable, et pour cela je ne peux qu’en remercier Trystan pour m’avoir aidé à y parvenir, grâce à son analyse de mon projet.
Je terminerai la partie prototypage une bonne fois pour tout en réalisant une dernière petite maquette, pour mobile plus large, afin de vraiment ne plus me poser de questions inutiles lors de la réalisation du projet dans le code.
Chapitre II — Une base solide
Je voulais à présent m’attaquer au développement front-end, afin de pouvoir rapidement mettre tout ça de côté et de pouvoir consacrer le temps me restant ensuite au peaufinage des algorithmes de l’outil et à sa présentation en dehors de la page d’accueil (comme une animation vidéo, par exemple). D’entrée, je me tâtais à partir sur des bases que j’avais acquises, en utilisant Laravel-Mix qui était une base que nous utilisions depuis l’année dernière et qui était très simple d’utilisation et pourrait convenir parfaitement à ce projet ; ou bien de poursuivre ma découverte de Vue, que j’avais entamée durant mon stage et que je voulais approfondir davantage, ce qui pourrait représenter un autre défi à surmonter durant toute cette partie du TFE.
C’est finalement pour la deuxième option que j’opterai, et grâce aux techniques découvertes il y a quelques mois de cela durant mon stage, je parviendrai à créer une base solide sur laquelle il ne restait plus qu’à rajouter le contenu et à le mettre en page (c’est, du moins, ce qu’il me semblait).
Travailler avec Vue peut s’avérer complexe lorsque l’on apprend seulement à le découvrir, car il fonctionne d’une façon relativement différente de la manière dont on utiliserait du pur Javascript : cela nécessite une déconstruction de mon site original (qui me permit en premier lieu de traduire ma base de données) pour le construire différemment, similairement à un kit Lego multi-fonction que l’on peut assembler de façons différentes.
Petit à petit, je donnerai alors naissance à ce nouveau site, en commençant par la page d’accueil, mais ce ne fut pas sans repos : le site étant bien plus poussé visuellement et techniquement que tout ce que j’ai pu produire auparavant, tout son développement me permit de découvrir de nouvelles fonctionnalités de langage que je comprenais, mais aussi d’expérimenter de nouvelles méthodes avec mon code que je n’aurai pas osé utiliser auparavant, de peur à ce que cela n’amène davantage de problèmes que de solutions. Tantôt simples, tantôt élaborées, ces techniques étaient plus audacieuses que ce que j’avais l’habitude de proposer (surtout autour de la méthode BEM, qui jusque-là était encore floue sur les bords dans mon esprit), mais je voulais prendre ce risque, quitte à devoir corriger par la suite, car cela représentait une bonne méthode pour sortir des sentiers battus et de découvrir d’autres petites choses par-ci par-là durant l’intégration et avoir un code plus propre qu’il n’aurait pu l’être si j’étais resté dans ma zone de confort.
Comme je m’y attendais, certains problèmes vinrent cribler mon code, mais rien qui ne soit extrêmement important à un point de m’empêcher de travailler : des petits bugs visuels par-ci par là, quelques incompréhensions avec le framework employé, voire certains aspects que je n’avais jamais réellement réalisés auparavant et pour lesquels je n’avais aucune technique bien concrète (notamment au niveau du grain à l’écran), mais j’avais confiance en ma détermination et savait que je les résoudrai les uns après les autres, d’une façon ou d’une autre.
C’est lors de ma deuxième déconstruction, où je détruisis ce que j’avais développé pour le remplacer avec une nouvelle version plus efficace et plus simple, que je rentrerai dans le cœur du framework et que je l’utiliserai à son plein escient, comme je le souhaitais. Tout mon contenu était désormais sous forme de composants, que j’habillais visuellement indépendamment du flux principal dans lequel je venais les glisser par la suite. Cela rendait le code bien plus lisible, me permettant de décupler ma productivité et de réaliser bien plus en 2/3 jours que ce que j’avais réalisé en une semaine tout en nettoyant mon code et en l’optimisant davantage.
Ma manière de développer avait changé, elle aussi, depuis la remise à zéro de mon code : au lieu de réaliser l’entièreté du site d’une traite pour chaque taille individuelle d’écran prédéterminée, la division du contenu en composants me guidait à travailler le site morceau par morceau sur toutes les dimensions directement. Je trouve que cette approche est bien plus efficace, bien moins chronophage et laisse beaucoup moins de chance aux bugs puisqu’il est plus facile de vérifier et de relire son code s’il est fragmenté en plusieurs morceaux.
Pour la première fois depuis le début de mon apprentissage en code, j’étais satisfait du résultat “final” du site, car il ressemblait exactement à ce que j’avais préalablement dessiné dans Figma, ce que je n’avais parfaitement réussi à faire durant les ateliers / cours précédents, souvent à cause de problèmes techniques ou de manque d’expérience. J’aurai même découvert comment réaliser du grain de film, effet que je voulais mettre en place depuis très longtemps déjà.
J’étais loin d’avoir terminé l’intégration totale du site, mais j’avais déjà bien avancé, bien plus rapidement que ce que j’avais estimé. À l’heure d’écriture, j’avais presque fini la page d’accueil dans son entièreté, et je devais seulement commencer la page “outil”. Grâce à mes maquettes, à mon framework et aux différentes feuilles de style que j’avais déjà établi·e·s, j’estimais que j’allais prendre beaucoup moins de temps encore que pour la page principale et que le front-end du site serait rapidement opérationnel.
Chapitre III — Supprimer les intermédiaires
Plus le temps passait, plus ma gigantesque base de données se transformait en un véritable fardeau, dangereux et lourd, qui pouvait à tout moment se retourner contre moi : il était encombrant, peu optimisé, probablement redondant et dépassé, mais surtout non-vérifié, ce qui pouvait poser de gros problèmes lorsque le projet tourne entièrement autour de cette base de données. En conséquence, j’estimais d’autres alternatives plus simples, propres et plus efficaces d’analyser les textes, et une solution, potentiellement plus efficace, se présenta à moi : au lieu de tester une base de données composées de mots, pourquoi ne pas plutôt en tester une remplie de suffixes de ces mêmes mots ?
Le principe serait, en théorie, exactement le même, mais cela pourrait couvrir cette fois-ci l’intégralité de la langue française sans devoir vérifier la présence de 20.000 mots dans chaque phrase du texte proposé. C’était déjà dans cette idée-là que j’avais, justement, converti la gargantuesque base de données actuelle, je n’aurai qu’à récupérer ce morceau de code, le convertir et l’adapter pour obtenir les résultats souhaités pour réaliser mon outil, dans les grandes lignes. Bien sûr, la langue française étant aussi compliquée, il faudrait une petite liste complémentaire d’exceptions aux règles grammaticales, qu’il faudrait que le code analyse d’abord avant de procéder au changement final.
Cette piste n’est, à l’heure d’écriture, qu’une hypothèse, mais je pense qu’il s’agit de l’approche la plus optimisée, la plus efficace et la plus simple à ma disposition.
Chapitre IV — Fin du troisième acte.
Après avoir passé plus d’un mois sur ce projet de fin d’étude, nous voici plongé·e·s en plein dans les coulisses de celui-ci, à développer ce que 90% des utilisateur·trice·s ne verront probablement jamais, dans l’espoir que leur expérience soit la meilleure et la plus enrichissante.
Avant d’obtenir un résultat si idyllique, ceci-dit, il reste pas mal de chemin à parcourir et beaucoup de choses à mettre en place, mais je suis persuadé qu’en maintenant ce rythme et cette détermination, j’y parviendrai sans soucis.
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 [Vous êtes ici]
- Travail de fin d’année — Case Study n°4
- Travail de fin d’année — Case Study n°5
