Design web & mobile

TFA | Robin Devouge

Construire un site, c’est comme écrire un article : on ne sait jamais par où commencer. Même si le site en question est le mien et me concerne, ça n’a pas rendu la tâche plus facile.

Reprendre depuis le début

J’avais déjà fait un TFA plutôt réussi l’année dernière, axé sur mon daltonisme. Mais une remarque qu’on m’avait faite à ce propos lors de la présentation m’est restée en tête jusqu’à aujourd’hui : j’y donnais un peu trop d’importance. Pourquoi ne pas le rendre plus anecdotique ?

Du coup, après réflexion, j’ai décidé de ne pas en parler ; mon daltonisme me rend plus sensible à l’accessibilité et les observateurs avertis le remarqueront sans que j’aie besoin de le dire.

Commencer à écrire

J’ai ensuite attrapé une feuille et un crayon et je me suis mis à lister mon contenu : ce que je voulais montrer à mes potentiels maîtres de stage. C’était la partie facile. Construire des phrases qui vont droit au but à partir de mots-clés est la partie la plus complexe.

Je suis finalement sorti de la bataille avec deux petits paragraphes, courts et efficaces, juste comme il fallait, et quelques phrases pour les autres parties.

Quelques gribouillis

Une fois mon contenu écrit, reste à le mettre en forme. Toujours armé de feuilles et d’un crayon, cette fois accompagnés d’une bonne gomme, je dessine quelques wireframes rapides. Cette étape n’a pas été trop difficile étant donné qu’il n’y a pas une quantité exceptionnelle de contenu, mais je voulais faire mieux que l’année passée, en respectant les principes du content first.

Mettre de l’ordre

Vient la phase recherche de typos sympas, de proportions qui claquent et d’une grille qui va bien.

N’ayant pas réinvesti dans une licence Typekit, j’ai du me contenter de ce qu’offrait Google Fonts, et j’y ai choisi la Ubuntu pour les titres et la Lato pour le reste, choix justifié par une hauteur de x très similaire et le contraste intéressant entre la finesse de la Lato et les graisses de la Ubuntu.

La grille en revanche s’est construite par ajustements successifs guidés par la hauteur de ligne, la taille de base et le nombre de colonnes nécessaires, le tout s’ajustant aux différents breakpoints pour que la page soit responsive.

De l’inspiration

Avoir des wireframes est une chose, mais je ne suis pas vraiment à l’aise avec le côté purement graphique du design. J’ai donc fait un petit tour sur Pinterest pour chercher quelques idées parmi celles que j’avais collectées au cours des derniers mois.

Une fois décidé, j’ai ouvert Sketch (que je préfère à Photoshop pour sa simplicité) et commencé à créer mes visuels. C’est pendant cette phase que je me rends compte que mon choix de recommencer ma deuxième année a été utile : j’ai enfin trouvé une méthode qui me permet d’avancer. Je supprime toute source de distraction pendant au moins deux heures et je me lance sans me poser de question. Ce n’est qu’une fois mon idée poussée jusqu’au bout que je prends le temps de m’arrêter et l’analyser.

Une petite mise au point

Après quelques essais ratés j’ai obtenu un résultat convaincant, assez proche de ce que j’ai au final, et je suis allé voir Arnaud pour un peu de feedback. Après un moment de réflexion et quelques commentaires constructifs qui m’ont servi à améliorer le visuel, il a attrapé un post-it sur lequel étaient écrits trois mots :

Show, don’t tell

Oui, encore une fois, pourquoi écrire ce que je savais faire alors que je le montrais juste après ? Pourquoi faire perdre du temps à mes utilisateurs quand ils peuvent se rendre compte par eux-même de ce que je suis capable de faire ? J’ai suivi son conseil, enlevé la partie texte et corrigé les autres erreurs et coquilles.

Intégratiooooooon

J’arrive enfin à la partie que je préfère : le code. Ici pas besoin de tourner en rond, je sais ce que j’ai à faire. D’abord le HTML, auquel j’ajoute les classes qui me serviront plus tard, ensuite le CSS qui m’a pris un peu plus de temps au début à cause de SASS qui m’a fait gagner pas mal de temps par la suite avec la réutilisation de styles. Et en dernier les quelques lignes de JavaScript qui fluidifient juste un peu l’expérience.

Du mouvement

J’aime beaucoup l’animation, bien utilisée elle peut rendre les interactions plus naturelles et efficaces. C’est une part importante de ce que je veux montrer, en particulier ma maîtrise des animations CSS, c’est pourquoi je ne voulais pas utiliser de gifs/vidéos ou encore du JS.animationRD

Un autre point en faveur du CSS est qu’il est très bien supporté et fluide, même sur smartphone et tablette, ce qui me permet d’éviter de mettre en place une série de fallbacks pour tous ces cas de figure.

Rien n’est parfait

Malheureusement, on ne peut pas réussir à tous les coups. La version finale que j’ai présentée en juin avait un énorme défaut d’ergonomie. Je voulais en montrer trop, et au final je laissais mon utilisateur livré à lui même devant une liste de noms de projets qui n’avaient pas beaucoup de sens sans explication.

Le problème a été résolu en limitant le nombre de projets à montrer et en ajoutant une page intermédiaire qui donne plus d’informations sur le projet en lui-même, sans être pour autant un case study afin d’aller à l’essentiel.

Mais pour surmonter ces défauts, il aura fallu qu’on m’ouvre les yeux. Savoir accepter la critique (tant qu’elle est constructive) est important pour progresser. La clé c’est de rester détaché émotionnellement de son travail, même lorsqu’il est personnel.

La fin d’un projet…

Mais le début du reste ! L’année prochaine risque fort d’être bien remplie et j’ai encore énormément de choses à apprendre. Je suis vraiment impatient de voir ce que me réservent les stages, les défis que j’aurai à relever et découvrir le monde professionnel…

Si ce n’est pas déjà fait, allez faire un tour du côté de mes projets. Sinon suivez-moi sur Twitter pour être au courant de mes réalisations futures.

     Projet au hasard