L’avènement des terminaux mobiles a changé beaucoup de choses dans le quotidien des concepteurs d’interfaces. Si les meilleures pratiques de conception d’interfaces mobiles pour iPhone ou iPad étaient facilement appréhendables il y a encore deux ans, la situation s’est considérablement complexifiée ces derniers mois avec la multiplication des formats et des technologies d’écran. Les concepteurs d’interfaces mobiles doivent maintenant jongler avec différents types de smartphones et tablettes, mais ils doivent de plus prendre en compte des résolutions d’écran très disparates (cinema display, HD…). Bref, c’est un authentique calvaire, et nous n’avons plus réellement de repères pour nous y retrouver.

Ce n’est pas la première fois que j’aborde le sujet de la conception d’interfaces mobiles (Des mises en page adaptives aux systèmes de navigation adaptatifs) et ce sujet est régulièrement abordé par d’autres blogs spécialisés dont le très sérieux UXmatters (Designing for Users and Their Devices et Mobile Input Methods). Ils ont justement publié la semaine dernière un très bon article abordant la problématique de résolution d’écran : Common Misconceptions About Touch.

Le point de départ de l’article est que la taille “standard” définie par Apple pour les éléments d’interaction (44 pixels) n’est plus pertinente dans la mesure où  avec ces grandes disparités de résolution d’écran (le dernier smartphone Samsung a un écran full HD). Plutôt que de résonner en pixels, il est ainsi plus rigoureux de se baser sur des dimensions en mm. Nokia et Microsoft préconisent ainsi des éléments d’une largeur minimale de 7 mm, avec un espacement minimal de 2 mm. Le problème est que ces tailles minimales sont plus adaptées à une manipulation au stylet qu’avec nos gros doigts. Le principal argument avancé par l’auteur de l’article est que nous manipulons principalement nos smartphones avec nos pouces, cachant ainsi une bonne partie de l’écran (d’où un grand manque de précision).

De plus, nous n’avons pas le nez sur notre smartphone ou tablette, surtout quand nous sommes en position debout :

D’après l’auteur, ces différents facteurs combinés font que la taille minimum devrait être de 2 mm pour du texte et de 2,8 mm pour une icône. Il fait également fort justement remarqué que le mode d’usage décrit plus haut rend complexe la lecture du texte ou l’identification d’un bouton, mais qu’il perturbe également la précision. L’auteur recommande donc d’élargir la zone d’interaction autour d’un bouton ou d’un lien pour compenser un contexte d’usage problématique (reflet sur l’écran…) et un manque de précision dû à une tenue à une main.

Une solution élégante, mais qui induit un autre problème : celui des zones de recouvrement. Les boutons sont ainsi généralement regroupés en haut ou en bas d’une interface, si l’on utilise une zone d’interaction (touch target) plus large que la zone d’affichage (visual target), les éléments se font concurrence.

Certains navigateurs mobiles comme Chrome anticipent ce problème en affichant un zoom contextuel en cas de pression sur une zone de recouvrement (ici, deux liens l’un au dessus de l’autre) :

Comme vous l’aurez compris, augmenter la taille des boutons permet de faciliter le repérage, mais dans une certaine limite sinon on ne peut pas tout faire rentrer, d’autant plus si vous prévoyez d’étendre la zone d’interaction de quelques pixels. Ceci étant dit, il est tout de même primordial de privilégier le repérage et la prévention des fausses manipulation. L’auteur précise enfin qu’au-delà d’une certaine taille, un champ ou un bouton ne sont plus interprétés en tant que tels par les utilisateurs qui les confondent avec des bannières.

Au final, l’article se termine par des recommandations précises sur le formatage des éléments d’interface :

• hauteur minimum des textes et icônes respectivement de 1,4 et 2,1 mm pour un feature phone ; 2,1 et 2,8 mm pour un smartphone ; 2,8 et 3,5 pour une tablette ;
• hauteur recommandée de 8 mm pour une zone d’interaction sur un bouton (minimum 6 mm et maximum 15 mm) ;
• espacement recommandé de 10 mm entre deux éléments (minimum 8 mm).

Il ne vous reste plus qu’à sortir votre règle pour vérifier si vous respectez ces recommandations !

Depuis que le web existe, les acteurs de la presse et autres éditeurs de magazines s’arrachent les cheveux pour reproduire une expérience de lecture enrichissante à l’écran. Problème : personne ne lit à l’écran ! Si l’on commence à y voir un peu plus clair dans la meilleure façon de porter un journal sur le web (le NYTimes est un très bon exemple), la tâche est beaucoup par contre beaucoup plus ardue pour les magazines. Certains ont déjà proposé des solutions innovantes comme MSN Glo (cf. MSN expérimente des nouveaux formats pour ses magazines en ligne), mais ça reste marginal.

Ceci étant dit, les choses sont en train de changer avec notamment la montée en puissance de HTML5 (Dopez votre narration interactive avec HTML5) et des tablettes (2013 sera l’année du tablet first). Nous avons ainsi pu voir des choses tout à fait intéressantes chez USA Today ou Quatrz avec des interfaces adaptées pour la lecture à l’écran sur ordinateur ou tablette.

Outre le problème de la mise en page, il y a surtout un gros défi à relever en ce qui concerne le positionnement du magazine en lui-même. Certains magazines “haut de gamme” proposent ainsi des interfaces incroyablement froides, censées correspondre à l’univers du luxe (ex : Vogue, Dujour ou Variety).

Vous conviendrez que ce n’est pas avec ces mises en page glaciale que l’on va révolutionner la lecture à l’écran…

Heureusement, d’autres pistes sont explorées, avec de belles innovations à la clé :

• Des sites de contenu minimalistes qui s’inscrivent dans le mouvement du slow web (Suit-up or Die, The Great Discontent, Edits Quarterly) ;

  

• Des mises en page très sophistiquées, comme chez Polygon (cf. The Rise of Barcade et Tomb Raider Review) ;

  

• Une scénarisation de la narration comme chez Google (How Search Works).

  

Ces trois exemples sont, à mon sens, les plus représentatifs des transformations en cours dans le milieu de la création de contenus en ligne. Ils ne sont pas anondins, car rappelez-vous que l’information est gratuite et abondante sur le web. À partir de ce constat, trois leviers me semblent intéressants à travailler pour se démarquer :

1. La curation du contenu pour lutter contre l’infobésité (la nouvelle version de Digg illustre bien ce retour en arrière) ;
2. Le confort de lecture avec des mises en page beaucoup plus légères, adoptées par tous les gros blogs high-tech (TNW, Mashable…) ;
3. Une narration enrichit comme le très remarqué Snow Fall (Le NY Times innove avec Snow Fall, mais illustre les limites de la narration multimédia).

Nous avons donc de belles pistes à explorer pour réenchanter les internautes et leur donner envie de lire à l’écran. Reste à trouver les leviers de monétisation pour financer ça, mais c’est une autre histoire…

Aviez-vous remarqué qu’en quelques années les carrousels avaient envahi quasiment l’ensemble des sites de média et des boutiques en ligne ? Les carrousels sont ces énormes blocs où des extraits de contenus défilent, comme un ruban horizontal. S’ils sont bien pratiques pour faire rentrer toute l’actualité et les promos, leur principal intérêt est de pouvoir “donner vie” à un site. Je ne savais qu’il y avait des sites vivants et d’autres morts. Je ne savais pas non plus que les internautes refusaient de visiter les sites statiques où “il n’y a pas de vie”. Bref, j’ai comme l’impression que la profession a adopté les carrousels sans trop se poser de question. Pourtant, ces éléments d’interface soulèvent de nombreuses questions :

• Le principe de défilement horizontal est-il simple à utiliser ?
• Les différents panneaux qui se succèdent fournissent-ils une information précise sur le contenu du site ?
• Les couleurs vives, titres racoleurs et animations ne font-ils pas trop ressembler les carrousels à des bannières ?

Bref, la question est de savoir si l’énorme place attribuée aux carrousels en page d’accueil, au détriment des autres éléments, est justifiée. Et visiblement la réponse est : Non ! Il y a en premier lieu le gros problème d’utilisabilité de ces panneaux qui défilent : le temps que les internautes lisent le message affiché et prennent la décision de cliquer, c’est un autre panneau qui s’affiche (The Unstoppable Carousel).

Ceci étant dit, les principaux points de vigilance de l’utilisabilité des carrousels ont déjà été identifiés : 5 Big Usability Mistakes Designers Make on Carousels. Si vous êtes à la recherche d’un bon exemple, le portail de la BBC semble avoir respecté tous ces points :

Le carrousel est parfaitement identifié en tant que tel (“Top News Story“), le point orange indique le nombre de panneaux ainsi que le panneau actif, des flèches permettent de basculer plus rapidement sur les autres panneaux. Le survol avec la souris permet de mieux comprendre son fonctionnement :

Le bouton Play/Stop afficher un plein milieu permet d’arrêter le défilement et les vignettes sur les flèchent servent à anticiper les prochains contenus. Ce carrousel est donc un modèle du genre, qui fonctionne parfaitement sur un site média, mais qui n’a pas forcément sa place sur une boutique en ligne.

Très largement utilisés sur la page d’accueil des boutiques en ligne, les carrousels se révèlent pourtant très encombrants et pas forcément efficaces : Don’t Use Automatic Image Sliders or Carousels, Ignore the Fad. Les différents tests réalisés sont sans appel : les carrousels sont soit ignorés, car confondus avec des bannières, soit ils monopolisent l’attention d’utilisateurs hypnotisés par le mouvement des panneaux sans réellement retenir les messages. Des observations confirmées par cette discussion entre professionnels : Are carousels effective?.

Les carrousels ne méritent donc pas la place qu’on leur accorde. Mais alors pourquoi les retrouve-t-on partout ? La réponse semble se trouver dans cet article : Carousels on ecommerce sites, are they worth bothering with?. La raison pour laquelle les carrousels sont si populaires est qu’ils permettent de faire rentrer autant de promotions que possible et d’éviter ainsi des conflits internes sur la priorité à donner à telle ou telle opération.Cette raison peut vous décevoir, mais en tout cas elle ne me surprend pas réellement. De nombreux choix de conception sont ainsi guidés par l’ego ou sont le fruit de compromis pour éviter des gue-guerres internes.

Ce qu’il faut retenir de ces différents écrits et discussions est que des blocs de promotion ou de mise en avant statiques sont bien plus efficaces qu’un carrousel. Il va donc falloir vous armer de courage pour convaincre vos collègues d’abandonner cette “norme”, au même titre que la règle des 3 clics. Pour se faire, le meilleur moyen est de vous appuyer sur des statistiques : placez un marqueur sur le carrousel suffira à démontrer un taux de clic très faible. Sinon vous pouvez également argumenter sur le fait que les gros sites de commerce en ligne comme Soap, Zalendo ou MisterGoodDeal n’utilisent plus les carrousels.

Voilà plus de 15 ans que travaille dans le milieu de l’internet, et presque autant d’années à concevoir des sites web.  S’il y a bien une leçon que j’ai retenue au cours de ces années, c’est que la conception d’une page d’accueil est un exercice très périlleux, et pourtant, c’est ce que les clients demandent à voir en premier. C’est un peu comme si vous demandiez à un l’architecte qui va construire votre maison si vous pouviez rentrer dans le salon avant même d’avoir vu les plans. Pour en avoir discuté longuement autour de moi, je sais que je ne suis pas le seul à éprouver de la frustration à ce sujet.

La frustration vient du fait que la page d’accueil d’un site est la résultante d’un long travail de conception, généralement séquentiel. Une page d’accueil ne s’invente pas, elle est fonction de ce que le site va proposer en matière de contenus et fonctionnalités. Commencer le travail de conception par la page d’accueil est à mon avis un non-sens, c’est clairement mettre la charrue avant les boeufs.

Il y a ainsi un certain nombre de tâches à réaliser en amont et des livrables à produire :

• Une liste priorisée des objectifs et des besoins ;
• Un cahier d’exigences et de contraintes ;
• Une description des utilisateurs types (personnas) ;
• Un inventaire des contenus et fonctionnalités nécessaires (comparé à ce l’existant) ;
• Un plan du site et des flux de navigation ;
• Des cas .

Cette liste n’est pas exhaustive, mais elle vous donne une bonne vision du travail préparatoire nécessaire AVANT de se lancer dans le travail de conception. Sans vouloir rentrer dans une polémique sur les méthodologies de conception / gestion de projet web, il y a selon moi trois aspects de la phase de conception :

• La conception fonctionnelle avec notamment les cas d’utilisation pour les fonctionnalités complexes ;
• La conception ergonomique portant sur le système de navigation (plan du site, parcours clients) et les interfaces (storyboards) ;
• La conception graphique qui passe par la création d’une charte.

C’est bien l’empilement de ces trois couches (la logique “métier”, l’interface et la présentation) qui compose les écrans de votre site ou application en ligne. Ces couches nécessitent un minimum de travail et font appel à des compétences et profils très différents. Par expérience, présenter une interprétation graphique de la page d’accueil de façon prématurée peut avoir des conséquences très graves pour la suite du projet, surtout sur la valeur perçue de ce travail de conception (“pourquoi payer le reste alors que l’essentiel du boulot est fait, en plus je n’aime pas les couleurs…“).

Comme j’ai plus d’expérience sur la conception des interfaces, je complète mon argumentation en me concentrant sur ce point. En règle générale, la création de storyboards s’effectue dans cet ordre :

1. Lister et positionner les éléments devant être affichés dans le header et le footer ;
2. Définir un système de navigation clair, robuste et qui ne prenne pas trop de place ;
3. Concevoir les pages de second niveau (ex : page de contenu) ;
4. Concevoir les fonctionnalités complexes (ex : configurateur…) ;
5. Concevoir les pages d’orientation (ex : page de catégorie) ;
6. Concevoir la page d’accueil.

Le travail de création des storyboards est donc un processus séquentiel qui démarre par les pages de second niveau. Les pages d’orientation ou la page d’accueil ne servent qu’à orienter les visiteurs vers la bonne partie du site (sauf dans le cas bien précis des sites mono-page). Commencer la conception par la page d’accueil est selon moi une grosse perte de temps, car cela revient à travailler à l’aveugle.

De même, la conception graphique est un processus créatif qui nécessite de mener à bien une réflexion, d’explorer des pistes et surtout de se conformer aux contraintes fonctionnelles et ergonomiques. Je ne vois pas bien comment il est possible de livrer une charte graphique réaliste avant d’avoir stabilisé les spécifications fonctionnelles et le storyboard.

Bref, tout ça pour dire que même après 15 ans, je suis toujours surpris que l’on me demande “juste” de voir à quoi ressemble la page d’accueil avant de lancer un projet de création ou de refonte d’un site web. C’est comme si vous demandiez à un chef de vous faire goûter avant qu’il n’ait commencé à préparer son plat.

Ceci étant dit, rien n’empêche de montrer des intentions graphiques au commanditaire du projet. Le but de l’opération sera de satisfaire sa curiosité (et/ou son impatiente) avec des illustrations, mais qui ne garantissent en rien une conformité avec le résultat final. Par expérience, je suis très réticent sur ce genre de pratique, car 9 fois sur 10 ça se termine par un “je préférais ce que vous m’aviez montré au début“.

Mais peut-être suis-je devenu grincheux avec l’âge… N’hésitez pas à donner votre opinion et à décrire votre façon de travailler dans les commentaires.

Saviez-vous qu’en moyenne la dyslexie touche 10% de la population ? Si ce handicap ne touche que 5% de la population en France (7% pour les enfants scolarisés), il est responsable de  problèmes d’assimilation des textes et de retard dans l’apprentissage. Sans trop rentrer dans les détails, les personnes atteintes de dyslexie ont tendance à inverser les lettres (comme illustré plus bas) et donc à changer la signification des mots.

Souffrant moi-même de légère dyslexie depuis mon enfance (je ne crois pas que ça se soigne d’ailleurs), je suis particulièrement sensible à ce sujet. Non pas que je souffre d’un gros handicap, mais j’ai tout de même conscience de faire beaucoup de fautes d’orthographe dans mes écrits, maintenant vous en connaissez la cause.

Pour pallier à ce problème d’inversion, un graphiste néerlandais souffrant de dyslexie, Christian Boer, a conçu une police de caractères permettant de mieux identifier les lettres : Une police d’écriture pour les dyslexiques. L’essentiel de son travail concerne les barres et les queues des lettres. Par exemple, la barre du “h” a été allongée pour ne pas le confondre avec un “n”. De même, l’ouverture du “c” a été agrandie pour le différencier du “e”.

Le principe est donc d’augmenter l’épaisseur des lettres à leur base pour leur donner plus de “poids” et éviter que le cerveau ne les retourne. Cette police de caractères a été testée à l’université de Twente aux Pays-Bas auprès d’une vingtaine d’étudiants pendant un an et demi. Le bénéfice constaté de cette police a suffi à convaincre l’auteur de commercialiser sa police. Elle est disponible en France au travers de la société Auxilidys.

Fort de ce succès, d’autres personnes ont décidé de créer leur propre police sur le même principe, notamment Abelardo Gonzalez : Open Dyslexic : une police de caractères pour aider les dyslexiques. Le principe de sa police est le même que précédemment, sauf que celle-ci est distribuée en licence Creative Commons BY, donc librement utilisable et distribuable à condition de citer l’auteur (la même licence que j’utilise pour mes articles).

Le résultat est assez étrange, mais souvenez-vous que cette police a avant tout des vertus thérapeutiques plutôt qu’esthétiques, vous pouvez la tester sur DyslexicFonts.com, avec en prime une astuce avec la souris pour vous aider à ne pas vous tromper dans la ligne que vous lisez.

Nous sommes tous d’accord pour dire que c’est une très bonne chose, mais d’un intérêt limité, car personne ne lit à l’écran. Certes, mais si nous scannons les pages web, il nous arrive néanmoins de prendre le temps de lire un article en entier. Et c’est là où cette police peut se révéler très utile, notamment en étant couplée à des services de “nettoyage” des pages web comme Instapaper, Pocket ou Clearly. L’idée n’est donc pas d’imposer cette police sur toutes les pages web, mais uniquement dans un contexte de lecture intensive, sur votre ordinateur, smartphone ou tablette.

Encore plus intéressant, cette police peut également être utilisée sur les liseuses numériques. La Kobo est ainsi livrée avec une police nommée “Open Dyslexia”, mais je ne serais pas vous dire s’il s’agit de la même. Saluons donc le travail de ces personnes qui ont trouvé une solution pragmatique pour diminuer les effets de la dyslexie.

Croyez-le ou non, mais ça fait presque deux ans que je n’ai pas abordé le sujet des outils de prototypage rapide. À ma décharge, je pense ne pas me tromper en disant que la situation que j’avais décrite à l’époque n’a pas beaucoup changé (Wireframes : 4 styles pour 4 types d’outils). Pourtant, l’offre s’est considérablement élargie, comme en témoigne cette analyse comparative très complète : The Ultimate Wireframing Tools Guide.

Il y a plus d’une trentaine d’outils dans ce tableau, et pourtant il n’est pas complet ! J’ai ainsi repéré dernièrement 4 outils particulièrement intéressants que nous pouvons classer dans deux catégories : les ateliers de prototypage en ligne et les applications de dynamisation.

Pour celles et ceux qui veulent concevoir leurs interfaces à l’écran en misant sur la collaboration et le partage, je recommande ainsi ces deux outils :

• Wireframe.cc, une application en ligne minimaliste pour créer des interfaces en quelques secondes (littéralement) :

  

• FluidUI, une application en ligne beaucoup plus sophistiquée qui existe aussi sous forme d’extension pour Chrome. Je vous recommande vivement de tester l’éditeur en lignepour bien juger la puissance de l’outil.

  

Pour celles et ceux qui sont attachés au papier, je recommande les applications suivantes qui permettent de créer des prototypes avec des photos :

• Pop, une application mobile minimaliste, mais parfaitement opérante ;

  

• Solidify, une application équivalente, mais bien plus sophistiquée (qui propose notamment un environnement complet de collaboration).

  

Ces quatre solutions illustrent bien selon moi l’état du marché : des approches novatrices à la fois minimalistes et très sophistiquées. Ceci étant dit, je n’ai toujours pas trouvé l’outil répondant à mes exigences : pouvoir créer une maquette fonctionnelle tout à la souris, la partager en ligne avec des collègues et avoir la possibilité de générer un squelette HTML (pour commencer le travail d’intégration) et l’exporter vers un logiciel de création graphique (pour bien respecter les proportions).

Pour le moment je reste fidèle à mes outils papier et à Balsamiq (qui vient enfin d’introduire les skins), mais ils ne répondent pas non plus à la problématique décrite ci-dessus. Ceci étant dit, je ne désespère pas de trouver la perle rare un jour…

Voilà un petit moment que je parle de conception d’interfaces mobiles. S’il existe largement assez de documentation sur l’utilisabilité des smartphones (Pour bien démarrer dans la conception d’interfaces mobiles), le cas des tablettes commence à devenir problématique. Si Apple a révolutionné le monde de la mobilité avec l’iPhone et son interface tactile, force est de constater qu’ils se sont contentés du minimum avec la sortie de l’iPad (puisque c’est le même système d’exploitation). Du côté de Google, c’est le même son de cloche avec un Android proposé pour smartphones et tablettes. Le problème est que les smartphones sont maintenant de plus en plus grands (>4,5 pouces) et des tablettes de plus en plus petites (7 pouces pour le Nexus et le Kindle Fire). Il en résulte des interfaces pas forcément adaptées à la taille de l’écran. Jusqu’à présent ceci était géré par l’intermédiaire de versions HD des applications (généralement vendues plus cher, allez savoir pourquoi…), mais cette rustine a des limites.

J’ai déjà abordé le sujet de la conception multi-écran en 2010 et 2011, mais le débat risque de prendre une autre tournure avec l’arrivée de l’iPad Mini. S’il n’est pour le moment pas du tout prévu de scinder iOS en fonction du support (l’interface reste parfaitement homogène sur iPhone ou iPad), des différences commencent à émerger sur Android où les équipes de Google ont la bonne idée d’encourager les développeurs à concevoir des interfaces spécifiques pour tablettes : Google Wants Developers To Build Better Tablet Apps.

Ils viennent ainsi de publier une liste des points à surveiller pour exploiter les points forts des tablettes : Tablet App Quality Checklist. Plusieurs points de vigilance sont ainsi passés en revue avant de lancer une application dédiée aux tablettes :

• Tester la conformité de l’application avec les Core App Quality Guidelines (une sorte de charte de qualité) ;
• Optimiser la mise en page pour éviter l’étirement disgracieux de l’interface ;

  

• Retravailler l’agencement des blocs pour bien exploiter la surface d’affichage ;

  

• Utilisation d’icônes, de polices de caractères et de widgets adaptés aux grands écrans des tablettes ;
• Ne pas rendre obligatoire l’utilisation de matériel non disponible sur certaines tablettes (ex : puce GPS ou APN dorsal) ;
• Déclarer la compatibilité de l’application avec tel ou tel format (ex : 7″, 9″, 11″…).

Toutes ces recommandations sont assorties de belles études de cas de Mint, Instapaper et TinyCo : Developer Stories, The Opportunity of Android Tablets.

Je ne peux qu’approuver cette démarche : les tablettes proposent en effet une surface d’affichage, des modalités d’interaction et des capacités matérielles bien différentes des smartphones. Pire : il existe des différences importantes au sein même du créneau des tablettes avec des produits haut de gamme comme l’iPad 3 et des tablettes chinoises à 100$.

La question que cette initiative soulève est maintenant la suivante : puisqu’ils sont si prompts à donner des conseils aux autres, pourquoi ne montrent-ils pas l’exemple ? La place de marché Google Play n’est ainsi pas très explicite quant à la destination des applications. Autant sur l’App Store il y a un distinguo entre iPhone et iPad, autant sur Google Play ils pourraient appliquer un filtre en fonction de la machine associée à l’utilisateur. Certes, il y a bien une mention “cette application est compatible avec votre xxx”, mais c’est un peu léger.

Attendons de voir ce qu’Apple va annoncer ce soir, notamment une nouvelle version majeure d’iTunes, mais selon moi il est indispensable d’envisager une scission plus marquée au niveau du système d’exploitation : un même Os, mais des interfaces et applications adaptées aux machines : 4″, 5″, 7″, 9″…

En ce moment, je lis énormément de choses sur la “révolution du HTML5″ et la façon dont le HTML4 est supplanté par cette nouvelle itération pensée pour les applications en ligne. Je ne sais pas trop d’où sort cet adage que l’HTML5 est LE langage des applications en ligne, toujours est-il que je ressens comme une ambigüité persistante à ce niveau.

Pour schématiser, un site est un ensemble de pages qui forme un tout cohérent (comme un magazine). Une application est un outil offrant de fonctionnalités. Selon cette définition, dire que HTML5 est le langage des applications en ligne et qu’à l’avenir tout sera application est un non-sens.  Je vois plutôt HTML comme un langage versatile permettant de faire tout un tas de choses, plutôt que de réduire ça à la notion d’application. Pour mémoire, le W3C a essayé pendant des années d’imposer XHTML2 et de faire accepter l’idée que toutes les pages sont des applications, nous savons tous comment cela s’est terminé. Pour être certain qu’il n’y ai pas d’ambigüité, je précise que HTML5 n’est pas remplaçant de XHTML2.

Mais revenons à nos moutons : les applications en ligne sont donc des outils offrant des fonctionnalités aux internautes. Dans la cadre d’une application de gestion de projet ou d’édition de document, tout est limpide. Mais si cette fameuse fonctionnalité est d’afficher du contenu, tout se complique. Pourquoi donc un éditeur de sites voudrait utiliser une application pour afficher du contenu ? Tout simplement pour améliorer l’expérience utilisateur. Deux des sites les plus populaires au monde sont ainsi des applications en ligne permettant d’accéder à des contenus : Facebook et Twitter.

En fait, tout a commencé avec Gmail qui a été le premier site avec une très large audience à utiliser Ajax pour faire des rafraichissements silencieux des pages. Cette technologie n’est plus toute jeune (elle existait déjà au siècle dernier), mais très peu de sites l’utilisent dans le cadre de contenus textuels. Cette réflexion est initialement venue d’une discussion très intéressante que j’ai eue avec Alexandre Malsch, le fondateur de Melty.fr. Pour celles et ceux qui ne connaissent pas, il s’agit d’un des portails les plus populaires auprès des jeunes.

Si vous visiter Melty.fr, vous aurez une expérience de visite assez similaire à n’importe quel portail, pourtant  lorsque que vous arriverez sur le site pour la première fois, c’est le moteur d’affichage qui sera téléchargé en premier, car c’est lui qui gère l’affichage des contenus ainsi que les interactions. Ce moteur, développé en javascript, se positionne ainsi entre le navigateur et l’utilisateur et va intercepter les clics et défilements de la souris pour les interpréter à sa façon et proposer une navigation avec des rafraichissements silencieux qui évitent de recharger à chaque clic des éléments qui ne changent pas.

Les bénéfices de ce moteur d’affichage sont les suivants :

• des temps de chargement plus courts ;
• plus de faciliter dans les fonctions de partage ;
• un meilleur contrôle de l’expérience de lecture ;
• une analyse beaucoup plus fine des parcours et interactions des utilisateurs.

Dans l’absolu, maintenant qu’ils disposent d’une application de lecture pour les ordinateurs, ils peuvent proposer une expérience de lecture très cohérente sur les autres terminaux en proposant des moteurs optimisés pour les tablettes, les smartphones, les TV connectées… Une hypothèse tout à fait intéressante au vu du phénomène de fragmentation des terminaux mobiles, et surtout une réponse tout à fait viable aux problèmes de connexion et de stockage des contenus hors-ligne.

Les premiers utilisateurs de PDAs seraient alors tentés de me faire remarquer que ce n’est ni plus ni moins qu’une reformulation des lecteurs de news du siècle dernier comme AvantGo. Certes, il y a un peu de ça, mais je préfère plutôt saluer la volonté des équipes de Melty de proposer une expérience de lecture maitrisée de bout en bout sans avoir à se reposer sur des applications comme Instapaper ou Pocket.

Je vous rassure : moi aussi j’ai été très perturbé à l’idée d’utiliser un moteur d’affichage pour remplacer celui du navigateur, car c’est toute ça raison d’être ! Toujours est-il que ce site apporte des solutions là où d’autres sont dans une impasse (expérience de lecture maitrisée quel que soit le terminal, gestion des contenus hors ligne, analyse détaillée…). Je serais bien incapable de vous dire si au final cette solution est mieux que de se reposer sur le moteur de rendu natif des navigateurs, car “mieux” est une notion subjective. La discussion reste donc entièrement ouverte…

Concevoir un site web n’est pas une tâche facile, c’est un chantier complexe qui mobilise de nombreuses ressources dans des domaines d’expertise très variés. Traditionnellement associée à l’utilisabilité, l’expérience utilisateur a toujours été considérée comme une notion vague, du genre : “Il faut améliorer l’expérience utilisateur“. Soit, mais à partir de quand l’expérience est-elle bonne ? Quels sont les leviers permettant de l’améliorer ? Autant de questions que la communauté se posait déjà au siècle dernier (littéralement). Pourtant, nous arrivons à décrire de façon précise la différence entre utilisabilité et expérience utilisateur.

Toujours est-il que la responsabilité de l’expérience utilisateur n’est toujours pas clairement définie. N’était pas clairement définie, car la Usability Professionals Association prend les choses en main et change de nom : Hello UXPA, Bye bye UPA. L’UPA a donc été rebaptisée en UXPA, pour User Experience Professionals Association. Le but de la manoeuvre est de redéfinir les contours de l’association et plus généralement d’élargir le périmètre d’intervention de ses membres.

Ne vous y trompez pas, il n’est pas ici question de l’association des diplômés en ergonomie (une discipline scientifique enseignée dans les universités françaises), mais de l’association internationale des professionnels de l’expérience utilisateur. Ce changement de nom reflète bien l’évolution des missions et des responsabilités qui sont confiées aux concepteurs (dans le sens large du terme) : Why Change Name to UXPA?.

Cette annonce tombe à pic, car cela fait un petit bout de temps que je souhaitais m’exprimer sur l’importance de l’expérience utilisateur et de la façon dont elle peut être améliorée et formalisée. Il existe ainsi des méthodes et modèles pour auditer et représenter l’expérience utilisateur d’un service ou d’une marque : The Anatomy of an Experience Map. Le but de la manoeuvre est de modéliser de façon précise les différentes interactions entre un client et une marque au travers des différents stades qu’il va traverser avant, pendant et après sont achat.

Cette cartographie permet d’avoir une vision d’ensemble de l’expérience des utilisateurs et d’identifier des points d’achoppement, des recoupements, des zones d’amélioration… Cette cartographie peut avoir différents noms : Experience Map, UX Map, Customer Journey Map, UX Journey Map… mais nous parlons bien toujours du même livrable, qui concerne un produit, une marque ou un secteur.

Se lancer directement dans la refonte ergonomique d’un site est une tactique intéressante à court terme, surtout pour identifier et implémenter des quick wins. Mais si vous souhaitez voir les choses en grand, il faut initier une réflexion plus globale qui prend en compte l’ADN de la marque dans un contexte d’achat élargi. Cette vision holistique va vous permettre de prendre du recul et d’améliorer l’expérience d’achat et de possession, pas uniquement les interfaces (boutique, site web, application mobile…).

La conception de l’expérience utilisateur intervient donc à un niveau stratégique, alors que l’interface d’un site et/ou son amélioration ergonomique intervient à un niveau tactique, voir opérationnel : Méthodologie du design d’expérience… on récapitule et on comprend tout. Cela ne veut pas dire que l’une est meilleure que l’autre, simplement que de nombreux choix de conception pourraient être facilités / harmonisés avec un travail rigoureux de modélisation de l’expérience utilisateur.

Tout ceci peut vous paraître un peu vaporeux, mais je peux vous assurer que, pour l’avoir testé chez mes clients, la Customer Journey Map est un outil de travail très puissant. Charge à vous de trouver la méthode et le format avec lequel vous vous sentez le plus à l’aise.

Souvenez-vous, il y  quelques années je me réjouissais de la simplification de la procédure d’identification avec Open ID : La création de compte simplifiée avec OpenID. Depuis, les choses ont bien changé avec l’avènement des réseaux sociaux et leurs mécanismes de social login. Je veux bien croire que le fait de s’appuyer sur les profils des internautes permet de gagner du temps et d’augmenter le taux de conversion, mais de là à ne proposer que cette option comme Klout, c’est extrêmement gênant.

Ce type de mécanisme d’identification fonctionne bien pour ceux qui ont un compte Facebook ou un profil Twitter, mais pour ceux qui en ont plusieurs, cela  engendre des conflits insolubles (j’ai dû avoir recours au support technique pour me dépatouiller de ce bazar). Il n’est pourtant pas très compliqué de proposer deux systèmes d’identification : délégué (avec Facebook ou Twitter) et internalisé. C’est ce que proposent des services comme Spotify ou Storenvy, et ça fonctionne très bien. De plus, ce double système permet de rendre l’éditeur du service moins dépendant des réseaux sociaux qui fournissent le profil (Astuce : Utiliser Facebook Connect pour de la pré-inscription).

Sinon dans le même genre il y a aussi Asana qui restreint le choix à Google Account et le met en première position :

On trouve aussi la même chose chez Pinterest avec un formulaire minimaliste, mais soigné :

Vous remarquerez que dans les deux cas, une fine ligne de séparation permet de faire comprendre que le bouton “Login” n’est à utiliser que si l’on rentre un nom d’utilisateur et un mot de passe.

De tous les écrans d’identification que j’ai pu croiser, je pense que la palme revient à 500px avec un formulaire très bien proportionné, explicite (“No account yet?“, “Can’t access your account?“) et surtout qui lève toute ambiguïté concernant l’utilisation de l’une ou l’autre technique (“or login using your username or email“) :

Une authentique référence en matière de simplicité, de guidage et de pédagogie. Dans un registre plus formel, nous avons aussi le formulaire de Forbes, propulsé par le widget de social login de Gigya :

Ce formulaire est d’une efficacité redoutable, propose une panoplie complète de mode d’identification, mais véhicule une sensation glaciale (froid et rigide). Bref, comme vous avez pu le voir au travers de ces différents exemples, il y a des choses à faire et des choses à éviter. Notez que je ne me suis concentré que sur les intitulés et la mise en page, mais il existe d’autres leviers d’améliorations : Innovative Techniques To Simplify Sign-Ups and Log-Ins.

Comme toujours, si vous avez de bons exemples, merci de les mentionner dans les commentaires.