Sam & Max » design http://sametmax.com Du code, du cul Sat, 07 Nov 2015 10:56:13 +0000 en-US hourly 1 http://wordpress.org/?v=4.1 Mobile First 25 http://sametmax.com/mobile-first/ http://sametmax.com/mobile-first/#comments Sun, 23 Mar 2014 17:59:21 +0000 http://sametmax.com/?p=9873 Ca fait un bout de temps que les amateurs des claviers virtuels sautillent en criant que le mobile va remplacer le PC.

Ce mois ci la version mobile d’un site de cul de Max vient de rapporter plus d’argent en pub que la version Desktop.

C’est arrivé.

Donc c’est parti pour une énième reconversion de vos skills.

Aiguisez vos talents de responsive designer. Developpez le site pour mobile en premier, puis étendez le aux tablettes et enfin aux écranx 1024 pouces et plus. Servez-vous un red bull, ça fera passer le goût du guronsan.

Je sais vous venez tout juste de finir d’apprendre les animations CSS3, le localStorage, les nouveaux tags HTML 5 et les websockets. Vous vous disiez que vous pouviez encore attendre un peu. Faire une petite pause quoi, merde. Peut être le temps d’essayer un autre langage pour le fun ?

Nope.

Au boulot !

Et n’oubliez pas, la prog asynchrone, le WebRTC, les nouveaux frameworks comme angularjs, bref, le real time Web, est en train de monter aussi. Et demain, sûrement, les clients ne voudront plus que ça.

Au passage, vous vous souvenez comme dans les années 2000 tout le monde se touchait sur le code xHTML valide, accessible pour les handicapés ? Tout le monde s’en tape maintenant. Il n’y a pas une app new gen qui soit blind-friendly.

Bref, comme toujours, entre bonne conscience et pédance, il n’y a qu’un pas.

]]>
http://sametmax.com/mobile-first/feed/ 25
Beau et facile à utiliser: deux choses bien différentes 21 http://sametmax.com/beau-et-facile-a-utiliser-deux-choses-bien-differentes/ http://sametmax.com/beau-et-facile-a-utiliser-deux-choses-bien-differentes/#comments Fri, 07 Dec 2012 11:24:38 +0000 http://sametmax.com/?p=3127 Je suis ergonome de formation. La première chose que j’ai apprise, c’est que mon intuition est à chier. Dit très clairement: si je design un site Web basé sur ce que je pense être utilisable, je vais me planter.

Même après des années d’expérience, mes premières idées sont très classiques, formatées, et Max me met des taquets derrière la tête régulièrement en guise de rappel.

Pour rendre une interface utilisable, il n’y a qu’un moyen fiable: le test. Pour apprendre en une journée tout ce que sais de l’ergonomie, vous pouvez en fait plus ou moins vous limiter à lire et appliquer le bouquin culte de Steve Krug.

Et c’est quelque chose que les designers ont du mal à comprendre. Ils font souvent des choses très belles, mais n’est pas Apple qui veut. Faire quelque chose de beau ET d’utilisable est très difficile.

Et si on doit choisir, il vaut mieux faire utilisable que beau.

Les états

Les états sont par exemple un vrai problème. En informatique, il n’y a pas vraiment de moyen de connaître l’état de quelque chose, et donc on crée artificiellement des repères visuels en espérant que l’utilisateur comprenne ce que l’on veut dire.

Seulement beau n’est pas forcément explicite. Est-ce que quelqu’un peut me dire ici quel bouton correspond à l’état “on” ?

Bouton on / off

On / Off, l'état le plus simple du monde

Le premier bouton, il est sur “off” parce qu’il affiche “off” ou il est sur “on”, offrant la possibilité de slider vers l’état “off” ? Les deux comportements existent dans le monde matériel.

Nous avons déjà des boutons qui reflètent très bien on / off: les checkboxes. Tout le monde sait comment ça marche, mais c’est moche, alors la plupart des designers essayent de les remplacer.

Si la designite vous démange, il faut alors sérieusement réfléchir, et ne pas proposer une solution moins efficace que ce qui existe déjà. Par exemple, une bonne implémentation du concept ci-dessus est:

Slide on / off avec effet lumineux

Un tout petit détail...

L’auteur a ici ajouté un simple effet grisé sur le “off” (qui a la connotation de “désactivé”) et un effet de lumière sur le “on” (qui à la connotation de “en fonctionnement”). On sait clairement que le premier est l’état “off”, et que si on clique dessus, on va obtenir le second état: “on”.

Mais les états ne sont pas toujours aussi simples que on / off, et surtout, ils se cachent parfois dans des situations naturelles. 37signals ont largement défendu l’idée de parer à ce que l’utilisateur va vouloir faire, plutôt que d’attendre qu’il le fasse. Et cela passe par la prédictibilité, et la compréhension du contexte, donc par l’affichage d’états et d’intentions.

Un exemple simple: l’état vide. Vous n’imaginez pas combien il est courant de ne pas travailler l’état de départ, ou vide, d’une UI. Pourtant, c’est primordial car c’est le premier contact de l’utilisateur avec votre logiciel, et surtout, par principe, vide signifie qu’il n’y a aucun indice sur ce qu’il faut faire par défaut.

Prenez l’explorateur de fichiers par défaut d’Ubuntu, Nautilus. Il est globalement très bon. En revanche, sur les gros dossiers, ou sur les dossiers contenant beaucoup de thumbnails, il y a un instant plus ou moins long durant lequel on ne sait pas si il charge, ou si le dossier est vide.

Capture d'écran de Nautilus dans un dossier vide

Il n'y a rien dans ce dossier

Une fois qu’on a décidé que l’état “n’affiche rien” était bien non un temps de chargement, mais le fait qu’il n’y a rien à afficher, le cerveau fait la déduction, “le dossier est vide”.

Prenez par contre Marlin, l’explorateur d’Elementary OS, et donc bien moins intégré à Unity, dans lequel il ressort plus laid que Nautilus. Mais il vous montre instantanément de quoi il est question.

Capture d'écran de Marlin dans un dossier vide

Marlin est un projet très prometteur

Ceci vous parait un détail. En fait, certains geeks trouvent même énervant tous ces trucs qui “ne servent à rien” pour “les gens qui ne veulent pas réfléchir” car “c’est quand même pas compliqué de voir que le dossier est vide”.

Oui, sauf que comme je vous en parlais précédemment, il existe une telle chose que la charge cérébrale, et que tout ce qui y participe se cumule.

Faire un beau design allège la charge cérébrale, mais faire un design utilisable la soulage sans commune mesure. Qui dit moins de charge, dit une utilisation fluide, sans peur (car oui, la peur de cliquer est un facteur étonnamment important dans le schéma de décision des utilisateurs lambdas), et donc des users qui aimeront votre app.

Le but est d’obtenir le même résultat que le crayon: quand vous écrivez, vous pensez à ce que vous écrivez, pas au crayon. Bien sûr que réfléchir un tout petit peu n’est pas la mer à boire, mais c’est autant de neurones que vous consacrez à votre outil plutôt qu’à votre travail.

Mais faire un design, plus que beau, utilisable, c’est aussi proposer à l’utilisateur ce qu’il peut faire. Mettre en avant les solutions les plus importantes. Les menus ajoutent à la charge cérébrale, ce sont des accès secondaires.

UsabilityFriction a posté une bonne illustration de la démarche. Ils sont partis d’un truc vide et pas top:

Mockup d'un porte folio

Vous n'avez pas de photo. Merci. Au revoir.

Et ils ont ajouté:

  • Des raccourcis vers les actions de certains menus pour ajouter des photos.
  • Un album photo d’exemple facilement supprimable pour que l’utilisateur puisse déjà se balader.
  • Une vidéo de démo qui disparait dès qu’on ajoute un élément.
  • Une courte et simple explication en forme d’invitation à l’action.
Mockup d'un porte folio amélioré

Vous n'avez pas de photos. Mais vous pouvez faire tout ça !

Ici il n’y a pas d’enjeu esthétique car c’est un mockup. Et c’est tout l’interêt du mockup pourri, fait avec balsamiq ou même au feutre Veleda sur brouillon: on se soucie de l’utilisabilité, pas du look. Le premier est la priorité car un bon designer rendra votre site qui est déjà facile à utiliser beau, alors que rendre un site déjà designé facile à utiliser demande beaucoup plus de travail additionnel.

Un bon dessin vaut mieux qu’un long discours, sauf si on dessine mal

Utiliser des icônes, c’est bien, non ?

En théorie, les formes et couleurs sont plus faciles et rapides à identifier que des mots. Et on évite les problèmes de traduction.

Mais, le hic, c’est que la signification d’une icône, contrairement à un mot, n’est pas garantie:

  • Il existe des centaines de milliers de mots. On est loin d’avoir autant d’icônes.
  • Les concepts abstraits sont très durs à icônifier. Essayez de trouver un symbole pour “niveau de difficulté” pour voir…
  • Selon le contexte (culturel, expérience, environnement…), un symbole peut avoir des sens différents. Ainsi, le blanc est la couleur du mariage pour nous, mais du deuil dans certains pays musulmans. Le rouge est la couleur du mariage en Chine…
  • Les icônes se périment plus vite que les mots. On a en encore beaucoup de logiciels qui symbolisent “sauvegarder” par une icône en forme de disquette. Combien d’utilisateurs actuels savent à quoi sert une disquette ? Ou même ce que c’est ?

Et si on choisit les icônes, on est obligé d’en mettre de manière cohérente, donc quand on rajoute un nouveau bouton, c’est une nouvelle icône à rajouter: il faut en trouver une correspondante, et au sens, et au design.

Un exemple: j’aime le nouveau design de Gmail. Mais le tout icône n’est pas forcément une réussite. Dans l’ancienne version, trouver comment marquer un mail en tant que spam était évident:

Capture d'écran de l'ancien menu mail de Gmail

Le mot spam est très facile à reconnaître: court et à faible ambiguïté

Le nouveau design est plus beau, mais par contre, pour mettre son mail en spam…

Capture d'écran du nouveau menu mail de Gmail

Difficile de faire le lien entre un hexagone avec un point d'exclamation et "spam"

L’objectif n’est pas de pinailler sur les qualités de x ou z, mais d’illustrer. Stackoverflow est un modèle d’utilisabilité, mais le site comporte pourtant très peu d’icônes. Mnmlist prouve qu’on peut être jusqu’au boutiste pour aller à l’essentiel. Drudge report prouve que… heu… Je vous laisse lire.

Encore une fois, ne laissez pas la fièvre graphique prendre la priorité sur l’utilisabilité. Un beau design est important. Un design utilisable est primordial. Il n’existe pas de solution clé en main telle que “utilisons des icônes” qui pallie le travail de réflexion ergonomique dont votre projet à besoin.

Tous les types de designs ont leur place: avec et sans icônes, avec des images, sans, avec du texte, sans, avec des jeux de couleur, sans. La recette à elle seule ne peut pas rendre un plat délicieux, il faut de bons cuisiniers, de bons ingrédients et du travail.

(et la métaphore de la bouffe est particulièrement adaptée, car quel que soit l’acharnement que vous mettez à votre popotte, y aura toujours un connard pour trouver ça dégueulasse)

Un dernier exemple de “ça dépend”. Gedit (Gnome) VS Scratch (Elementary OS), deux éditeurs de texte, deux approches pour “l’état de départ”, aucune n’est meilleure que l’autre, et elles ne satisferont pas le même public.

Capture d'écran de Gedit sur un fichier vide

Je préfère l'approche de Gedit: on commence cash à éditer, c'est plus efficace

 

Capture d'écran de Scratch sur un fichier vide

Un non dev sera parfois plus à l'aise avec une indication claire de ce qui va se passer

Tout comme on oriente son design en fonction de son public (hacker news peut se permettre l’aspect WEB 1.0, pas Facebook), l’ergonomie doit viser aussi le type d’utilisateur auquel vous souhaitez plaire. Car il n’y a aucune chance que vous plaisiez à tout le monde.

]]>
http://sametmax.com/beau-et-facile-a-utiliser-deux-choses-bien-differentes/feed/ 21