Ce matin je lisais un article fort intéressant en cela qu’il dissèque les raisons de l’échec d’un site : l’expérience utilisateur. Mais si effectivement l’auteur met en cause le choix d’une technologie, je pense qu’il est de bon aloi de revenir un peu en arrière et traiter plus en profondeur les raisons de son échec.
Avant toute chose, je tiens à préciser que le but de cet article n’est pas de critiquer gratuitement le travail d’autrui, mais d’utiliser son expérience pour appuyer mon propos. Car il n’y a aucun doute pour ma part, sur le fait que cette personne est probablement très compétente. Mais elle décrit un écueil dans lequel il est très facile de tomber, même lorsqu’on est rompu à la pratique du développement web. Par ailleurs, je tiens à souligner qu’il n’est pas évident de mettre en abîme son propre travail et de le critiquer publiquement. C’est donc avec le plus grand respect que je traiterai ici de son échec à produire un site pour ses visiteurs.
C’est parti donc, voici le site en question : http://aboutmeng.cf
Je ne m’arrêterai que brièvement dessus car l’auteur lui même détaille très bien ce qui ne va pas. Je vous encourage d’ailleurs à lire son article. Pour faire simple, l’auteur a construit son site autour d’un framework « Material Design ». Jusque là tout va bien, mais il a fait l’impasse sur l’indispensable lorsqu’on construit un site : sa pré-conception, les tests et l’optimisation.
Le choix des armes
Les framework front-end peuplent nos boîtes à outils de designer et nous avons tendance à les considérer sans faille et utilisables à tort et à travers sans jamais se poser la question de leur pertinence. « Est-ce un bon choix ? Répond-il à un besoin réel ? » ou encore « Quelles sont ses limites ? ». C’est ce qui est arrivé à l’auteur de cet article.
Ce qui m’emmène au premier point lorsqu’on développe un site : Le choix des outils. Ils doivent répondre à un besoin spécifique. Un site doit être développé pour ses utilisateurs, et pas seulement pour se faire plaisir. De fait la pertinence des choix à faire est primordiale. Avoir un site utilisable et qui permette à l’utilisateur d’accéder au contenu qui le concerne de manière simple, efficace et rapide doit être à mon avis au cœur des préoccupation du développeur. L’accessibilité, trop souvent négligée au profit du beau, a tôt fait de pénaliser le site. Les internautes sont exigeants, mais pas plus en termes d’esthétique que d’utilisabilité. Car un site aura beau être beau, s’il est inutilisable, ou tout du moins difficile à utiliser, il perd en pertinence et en crédibilité.
Choisir ses outils c’est donc faire des choix crédibles vis à vis de l’utilisabilité, mais aussi de la durabilité.
La pérennité est à considérer, car une librairie ou un framework qui est peu, pas ou mal maintenu aura un impact majeur sur le site qui l’intègre, et à fortiori sur l’expérience utilisateur (et je ne parle même pas de la sécurité).
Les tests navigateurs
Par ailleurs, et je suis extrêmement perplexe, car je pense que l’auteur est compétent, mais il a, semble-t-il, eu une confiance quasiment aveugle en l’outil utilisée au point de ne tester son design que dans un seul navigateur : Apple Safari. Je vous laisse méditer ceci 5 secondes.
Ce que j’ai appris avec le temps et l’expérience, c’est que la technologie n’est pas une fin en soit, que chacune répond à un besoin spécifique comme je l’ai déjà dit, et qu’il faut se montrer à la fois humble et aussi peut être un peu paranoïaque (d’où les tests, et multi-navigateur s’il vous plaît !). Penser qu’il suffit d’intégrer un framework sans présupposer qu’il possède des limites, c’est se tirer une balle dans le pied.
Il est donc impératif de faire des tests multi-navigateur (voire multi-architecture).
Ceci est un impondérable lorsqu’on développe un site. Au menu nous avons, Google Chrome, Apple Safari, Mozilla Firefox et le bien aimé Microsoft Internet Explorer. D’ailleurs, pour ce dernier, il existe plusieurs versions utilisées de par le monde. Il est connu que la version la plus problématique aujourd’hui reste la version 8. A celà vous pouvez aussi rajouter les navigateurs mobiles qui sont devenu autant voir plus utilisés que leurs homologues desktop. Avec l’avènement de HTML 5 et CSS 3 il est très tentant de pousser toujours plus loin nos interfaces front-end. Mais beaucoup de nouvelles balises html et attribut css ne sont tout simplement pas compatibles avec tous les navigateurs. Heureusement, des librairies existent et offrent la possibilité de rendre au maximum ces outils compatibles avec un maximum de navigateurs. Je pense notamment à Modernizr entre autres. D’autres outils permettent aussi de savoir avec quelles versions de navigateurs sont compatibles certaines propriétés. Je vous renvois à l’excellent caniuse. Mais parfois, il peut aussi être judicieux de ne pas utiliser certaines propriétés offertes par ces langages. Ceci pourrait faire l’objet d’un débat, mais je pense que ce choix appartient à chacun, car finalement, quand on connaît les usagers finaux du site, on est normalement à même d’avoir une idée des navigateurs utilisés. Et si ce n’est pas le cas, il existe de très bons outils d’analyse, comme Google Analytics qui nous renseignent assez bien sur les comportement de nos visiteurs. Maintenant, je ne blâmerai pas ceux qui souaitent pousser l’adoption de navigateurs modernes, mais je pense aussi qu’il faut respecter ceux qui n’ont pas cette possibilité. Chacun voit midi à sa porte comme on dit.
Analyser, tester, optimiser… recommencer
Alors certes, le but d’un framework est de nous simplifier le travail, mais ça ne signifie pas qu’il n’y a pas de travail. Dans un projet par exemple, on a un ou plusieurs objectifs à atteindre. En fonction de ces besoins, on choisit les outils qu’on pense pertinents. On fait le bilan des possibilités et des choses qu’il va falloir nous même créer ou adapter pour coller aux autres pièces du puzzle. On déduit qu’on va devoir développer soi-même ou adapter pour la version Responsive par exemple. On se lance, on teste, on corrige, on re-teste. Et une fois qu’on a terminé on passe à la phase d’optimisation ou « fine tuning ». C’est par exemple à ce moment là qu’on va se concentrer sur le poids des pages (ce qui implique qu’on a déjà fait un travail d’optimisation de ses images, ou encore des librairies servies et de quelle manière on les sert) et éventuellement l’optimisation côté serveur.
Il n’y a pas de magie : il faut savoir se poser les bonnes questions avant même d’avoir couché la moindre ligne de code. C’est indispensable, car ceci constitue les fondations de tout projet, et par là même sa viabilité.
Il faut éviter aussi les amalgames : il ne pas confondre UI (user interface) et UX (user experience), car comme notre exemple nous le montre, on peut avoir un design du feu de dieu, pour une expérience utilisateur en carton pâte. Et l’expérience nous prouve qu’un utilisateur pour qui l’interface n’est pas adaptée, fera un gros fuck pied de nez à notre site. Donc un beau site n’est pas à confondre avec un bon site.
De fait quand on parle de « web design », on fait souvent un amalgame entre ce qui relève du « beau » de ce qui relève de « l’utilisable ». Pourtant ces deux éléments sont les deux revers d’une même médaille : c’est ce qui fait qu’un web designer peut, à mon avis, mériter ce titre. On ne peut pas (ou très difficilement) considérer ces deux qualités individuellement, car l’une sans l’autre n’a aucune légitimité, ni aucune possibilité de promouvoir un site de manière pérenne.
Conclusion
Je terminerai en disant qu’être web designer c’est penser à la fois en termes de design (UI) et d’ergonomie (UX). C’est être capable de se poser les bonnes questions avant, ce qui permet de faire les bons choix et d’avoir le moins de mauvaise surprise après coup. Et comme je l’ai dit, faire preuve d’humilité envers la technologie, car ce n’est pas magique, mais pratique (ou pas).
