Les liens de la semaine #6

  • Blackberry va sortir un gros téléphone avec un écran carré. C’est un choix audacieux (suicidaire ?) puisqu’il va à rebours des idées reçues sur l’ergonomie physique des smartphones. Je l’imagine assez confortable à utiliser si l’on accepte d’y mettre les deux mains. Il est suffisamment large pour être vraiment en pris en main (comme un gros smartphone type Galaxy Note en mode paysage), avec un écran suffisamment haut pour que le contenu ne soit pas bouffé par le clavier et l’interface.

  • Un axe de réflexion intéressant pour des appareils vestimentaires vraiment utiles : « wearable devices [should] leverage their physicality, their presence in my immediate environment, to add to my interactions as they happen, rather than record aspects of the world for later. » Cela permettrait aussi de les rendre plus sociaux.

  • Pourquoi y a-t-il si peu de jeux vidéo violents ? : une satire très juste moquant une excuse fréquemment employée pour expliquer la prépondérance de jeux violents, selon laquelle les interactions sociales seraient plus difficiles à modéliser et à traduire en jeu. Je trouve l’article salutaire, parce que c’est une idée intuitive et répandue, y compris chez ceux appelant de leurs vœux plus de jeux non-violents.

  • Partager : l’icône qui ne met personne d’accord : un article sur le manque de convention stable autour de ce symbole, avec quelques nouvelles propositions. J’aurais aimé que l’article aille plus loin et questionne la sémantique de ces icônes. Y a-t-il une réelle unité dans les fonctions sous-jacentes, par exemple entre « transmettre par email », « poster une photo sur Twitter », « rendre accessible un document sur Google Drive » ?

  • Des livres électroniques gratuits : Mobile Design Patterns, The Guide to Wireframing, Mobile Book of Trends, Web Design Book of Trends, The User Experience Guide Book For Product Managers et UX Design for Startups.

Le guide relativement exhaustif et raisonnablement ultime des outils de prototypage

J’ai commencé un guide des différents logiciels de prototypage, sous forme de matrice de fonctionnalités. Elle est sur Wikipedia et toutes suggestions et contributions sont les bienvenues.

Pour y voir plus clair, il y a trois sections : généraliste, wireframing (zoning) et animation (souvent des outils dédiés au mobile). Je pensais au départ faire un guide plus large, afin d’inclure des outils pouvant être pratiques pour du prototypage mais dont ce n’est pas le but premier : frameworks CSS, logiciels de design UI (Fireworks, Sketch), IDE web avec des fonctions de templating et de préprocesseur, aides au prototypage papier, etc. Finalement l’article est limité aux logiciels dédiés, ce qui fait tout de même quarante-six items. Cela permet d’éviter le coté fourre-tout et de permettre la comparaison de fonctionnalités à terme à terme. Une liste brute des outils exclus se trouve dans la page de discussion.

Évidemment, ce choix et les catégories retenues sont discutables, tout comme la manière dont j’ai tenté de normaliser les atouts de chaque logiciel en les faisant rentrer dans des cases. Certains services ont certes des concepts propres et sont remplis de petites astuces qui peuvent les démarquer, mais ils sont pourtant globalement assez homogènes. Si vous avez des idées de meilleur découpage ou s’il y a des points obscurs, n’hésitez pas.

Nota bene : les tableaux sont scrollables horizontalement. Ce n’est pas idéal mais c’est la présentation que j’ai trouvé la plus optimale.

À faire :

  • Remplir la section Wireframing.
  • Trouver un découpage pour la section Animations.
  • Je compte faire quelques posts pour mettre en valeur des logiciels méconnus ou des fonctionnalités que j’ai trouvé cool.
  • J’envisage de faire un flowchart qui servirait de vrai guide pour choisir le logiciel le plus adapté à ses besoins. Un arbre de décision moins rude que les tableaux actuels. À voir.

Voir d'autres travaux

Le responsive design ailleurs que sur le web

Les applications natives mobiles, sur Android (et Apple depuis peu) ont accès à des fonctions responsive, mais sur desktop la pratique est moins fréquente. Non seulement les interfaces ont rarement des agencements différents selon la taille de la fenêtre, mais en plus elles ne sont pas toujours fluides, c’est-à-dire que tailles et marges des éléments ne sont pas redimensionnées. Certains logiciels bloquent également la largeur minimale de la fenêtre, parfois drastiquement. C’est dommage, car ce serait l’occasion de mieux prendre en compte les petits écrans (cf. par exemple les distributions de Linux visant spécifiquement les notetbooks) et toutes les manières d’utiliser un OS fenêtré.

Il y a évidemment des contre-exemples : en mode album, iTunes ajuste le nombre de colonnes et la taille des jaquettes. Depuis des années, Microsoft adapte intelligemment son fameux « ribbon », avec un grand nombre de points de rupture au fur et à mesure qu’on réduit la fenêtre.

Capture piquée à UX Candy

Le ruban d’Office. Capture piquée à UX Candy

Dans mon expérience, ce n’est pourtant pas fréquent. Il y a évidemment de bonnes raisons pour ces limitations. D’une, dans la plupart des cas on a affaire à un viewport dont le contenu est par définition fixe (exemple : une page Word). On peut alors seulement jouer sur l’UI (comme dans l’exemple d’Office). De deux, on retombe sur le grand problème du « device-agnostic responsive design » (concevoir pour une largeur donnée, sans préjuger de l’appareil utilisé) : il est difficile de prédire les préférences des gens. Si je redimensionne la fenêtre, serais-je content d’avoir un agencement adapté et sans scroll horizontal, ou au contraire énervé qu’on m’impose quelque chose ? Suivant les cas et les raisons du redimensionnement, la réponse varie.

La solution la plus utilisée dans les logiciels de productivité un peu complexes, c’est de laisser l’utilisateur personnaliser les différentes palettes, barres et panneaux d’interface comme il l’entend. Par exemple, Photoshop permet de créer différents « espaces de travail », c’est-à-dire différents agencements que l’utilisateur pourra activer comme il lui sied.

Jusqu’ici j’ai surtout parlé du cas assez restreint où l’utilisateur redimensionne sa fenêtre. Le problème du responsive se pose de manière peut-être plus aiguë si l’on veut créer des services dans l’écosystème Windows. Microsoft promet une plateforme unifiée où le développement à travers les OS sera unique, ou en tout cas facilité. Que Microsoft tienne sa promesse et que ce soit une bonne idée ou non, il reste que Windows, (feu ?) Windows RT et Windows Phone sont de plus en plus bâtis sur les mêmes fondations, aussi bien dans le design que dans la technique. Cela pose la question de la convergence des différentes applications : à quel point doivent-elles être semblables, faut-il un processus de conception unique, etc.

Le Principe de robustesse

Dans le domaine des protocoles de communication, le Principe de robustesse veut qu’un nœud d’un réseau (par exemple un serveur sur Internet) soit tolérant quand il décide d’accepter ou non un message plus ou moins bien formé, et qu’il soit plus rigoureux sur la qualité des messages qu’il envoie. Le principe voit son origine dans les débats autour de l’importance qu’il faut donner à une norme de communication : la stratégie optimale pour la robustesse du réseau, ce serait de suivre la norme de près en output mais beaucoup moins en input.

Par la suite (RFC 1122, § 1.2.2), il été a interprété de manière plus large comme un principe de prévoyance :

Software should be written to deal with every conceivable error.

C’est-à-dire : rendez votre programme robuste en le concevant de telle sorte à qu’il fonctionne avec les plus inputs les plus variés.

La rhétorique dispose d’un couple de règles très similaire : les principes d’honnêteté intellectuelle et de charité. Le premier revient à dire qu’il faut faciliter le travail de compréhension de l’interlocuteur, le second qu’il faut interpréter ses propos de la manière la plus avantageuse possible. (Note : c’est une vision à minima. L’honnêteté intellectuelle ne se limite pas à un souci de clarté. De manière plus drastique, ces principes rappellent qu’il faut veiller à avoir un langage et des valeurs de discussion communs.)

Il y a un troisième domaine où ce principe peut s’appliquer : les IHM. La manipulation d’un programme peut être vue comme un dialogue : l’utilisateur demande quelque chose et le système répond qu’il a bien effectué (ou non) la tâche, tout ceci via le language de l’interface. La métaphore a notamment été développée par Hutchins dès 1987 (article en lien ici – PDF pourrave mais réflexion passionnante), qui en note aussi les limites : elle suppose qu’il y a une médiation de type symbolique entre l’homme et la machine, avec toute la complexité et l’ambiguïté que cela implique.

Pourtant, cette métaphore de la conversion s’applique encore à bien des cas, par exemple la complétion d’un formulaire : j’entre une date et le programme me répond si elle a bien été comprise. Une bonne interface est tolérante dans les formats possibles qu’elle admet en entrée et rigoureuse (cohérente) à chaque fois qu’elle doit afficher une date en sortie.

Le principe de robustesse sur Wikipedia

Plaidoyer pour l’URL

Résumé : il faut se battre pour l’URL mais il faut aussi améliorer la barre d’adresse et en faire une vraie barre de navigation et d’action.

Google expérimente en ce moment une nouvelle fonctionnalité pour Chrome : faire disparaitre l’URL de la barre d’adresse. Il ne subsisterait que le nom de domaine dans un cadre, afin de mieux le mettre en avant et lutter contre le phishing (source). Cela permettrait de mieux distinguer amazon.com de amazon.siteChelou.com. Pour voir l’URL et l’éditer, il faudrait cliquer sur le nom de domaine.

Animation empruntée à Usability Post

Beaucoup se sont élevés contre cette idée (notamment), l’URL étant le concept fondateur du web. Grâce à elle, un document est accessible universellement et sans ambiguïté. À cela, on peut répondre que bien des appareils fonctionnent parce que leur technologie est invisible pour l’utilisateur. Après tout, on ne lui révèle pas l’adresse IP d’un site ou le header d’une requête HTTP, alors que ce sont des protocoles fondamentaux et porteurs d’information. De plus, les URL sont souvent une suite de caractères incompréhensibles et inutilisables.

Mon avis : cela reste une mauvaise idée et une réponse très disproportionnée au problème du phishing. Rien n’empêche une URL de suivre une syntaxe claire, il y a même de bonnes raisons techniques pour cela. De plus, elle peut comporter des informations directement pertinentes pour l’utilisateur. Considérez une URL de ce genre :

boutique.com/fr/vêtements/homme/pantalons?items-par-page=30?classement=prix

Elle permet de situer la page dans l’arborescence du site et de signaler comment elle est paramétrée. C’est un excellent repère de navigation, toujours présent et toujours au même endroit.

On pourrait aller plus loin et imaginer que chaque niveau de l’URL soit manipulable, comme cela se fait dans l’explorateur de fichiers de Windows ou dans certains éditeurs de code. Par exemple, dans Coda, cliquer sur un dossier du chemin ouvre un menu permettant d’accéder aux autres dossiers de même niveau. Cliquer sur le fichier ouvert permet également d’accéder aux différentes fonctions que celui-ci inclut, ce qui facilite la navigation dans le corps du document. Dans une page web, par exemple, on pourrait imaginer que changer de langue se fasse depuis l’URL, par un menu dédié, au lieu de chercher désespérément le lien dans la page (cela m’arrive souvent dans des bases documentaires).

interactive path for Coda 2

Plus généralement, je trouve toujours dommage qu’on essaye de cacher un système puissant, sous prétexte qu’il est complexe et mal utilisé. Il faudrait plutôt domestiquer cette complexité et la rendre plus accessible aux utilisateurs. La barre d’adresse d’un navigateur est aujourd’hui un des rares endroits où l’on est confronté au concept d’interface en ligne de commande. C’est aussi une interface vers énormément de choses : historique, favoris, recherche, etc. Organiser et retrouver du contenu, opérer un service… Il y a là un gros potentiel et une bonne occasion de faire progresser les interfaces en ligne de commande et d’y habituer les gens.

Je précise que mon propos n’est pas une position de principe ou un un appel à sauver le web. Un protocole ne devrait avoir aucune importance, sauf s’il peut avoir du sens pour l’utilisateur, comme ici. Je dis bien « peut » : en l’état, la plupart des gens se fichent des URL et vu la gueule de bien d’entre elles, on les comprend. Il y a là un pari : c’est seulement en explorant leur potentiel qu’on fera comprendra leur intérêt au plus grand nombre.

C’était l’idéal d’un projet de Mozilla, Ubiquity. Le concept de départ, très ambitieux, était de s’abstraire des pages et de proposer une interface en language naturel qui permette d’exécuter des actions de haut niveau et de les lier entre elles. Concrètement, on pourrait entrer « réserver un vol vers Sidney pour moi et Machin, envoyer l’itinéraire à Machin et ajouter la date à mon calendrier ». La réalité était plus modeste mais tout de même bien cool. Pour en savoir plus, voir ici et ici.

Bref, il y a tant de choses à faire autour de la barre d’adresse.

Difficultés de navigation entre sites web et applications mobiles

Dans un article récent, John Gruber nous invite à aller au-delà de la dichotomie entre app native et web app et à repenser ce que nous entendons par « web mobile » :

Lancer Tweetbot sur mon iPhone, appuyer sur un lien qui ouvre une page web en restant dans l’app et, depuis cette page, ouvrir une vidéo dans l’application Youtube – tout ceci fait très « web » pour moi.

Ce qui m’intéresse ici, ce sont les problèmes de navigation que cela pose. Sur un téléphone Android standard et sans surcouche, supposez que je fais une recherche sur Internet à propos d’un article que j’ai lu, que j’ouvre un lien vers Wikipedia, puis une image. Un parcours tout à fait banal, à ceci près que la recherche s’est faite dans l’application Google Search, que les liens Wikipedia envoient automatiquement vers l’application dédiée et que l’article était ouvert depuis un lecteur de RSS. Tout ceci est du contenu web mais se retrouve éclaté entre de nombreuses applications. Parmi tous ces rôles traditionnellement assumés par le navigateur, il s’est seulement chargé d’ouvrir l’image. Ergonomiquement, le résultat est assez fâcheux.

  • Quand je veux revenir en arrière, il faut que je me souvienne où est l’article : l’avais-je ouvert depuis un site web ou depuis une de ces nombreuses applications ouvrant le contenu d’un lien dans une webview ?
  • Il faudrait évoquer également la question du passage d’une application à une autre. Par exemple une app peut ouvrir une carte d’elle-même ou renvoyer vers Google Maps. Facebook a d’ailleurs récemment proposé un protocole les renvois entre applications.
  • La plupart des applications ne sont pas des clones du site mobile équivalent, ce qui perturbe les attentes de l’utilisateur. Par exemple Google Search ne permet pas d’utiliser le mode de shopping ou de partage une recherche.

Comparez ça à la simplicité de certaines cartes mentales suggérées à l’utilisateur : « tout est dans le navigateur », « tout est sur le bureau », « toutes vos photos seront automatiquement synchronisés au même endroit », etc. Tant qu’elles ne s’écartent pas trop de la réalité, ces suggestion représentent un guide puissant.

« The Oculus Rift is the first visual medium that doesn’t have a frame around it »

En avril 2012, Palmer Luckey, 19 ans à l’époque, postait sur un forum de passionnés pour annoncer qu’il faisait de grands progrès sur un casque de réalité virtuelle, Oculus Rift, et qu’il espérait bientôt le lancer sur Kickstarter. Un mois après, Carmack se faisait prêter un casque, y adaptait Doom 3 et en faisait la démo auprès de journalistes. Une entreprise est créée peu après et des vétérans de l’industrie la rejoignent pour lui donner une portée grand public. Deux ans après, Oculus VR est rachetée par Facebook et embauche John Carmack et Michael Abrash. Sacré parcours.

Voici deux liens qui peuvent aider à s’y retrouver :

D’abord, un récit du Time qui décrit très bien l’expérience du casque :

I turned my head experimentally, and the view changed, with no discernible lag, just as it would have in reality. […] That’s when my brain admitted defeat. It surrendered to the illusion that it was in another world. It wasn’t going to find an edge. There were no edges. The Oculus Rift is the first visual medium that doesn’t have a frame around it.

Il évoque également les dilemmes des dirigeants autour de l’identité de la compagnie :

…they might not be as clear as they thought they were on what virtual reality is actually for. It began as a gaming technology, but it turned out first-person shooters weren’t the killer app they expected. “Pretty quickly we realized, ‘O.K., maybe running down hallways at 40 m.p.h. isn’t exactly the most comfortable thing to do in VR when you’re sitting in a chair’” […] So they started thinking more broadly about what exactly it was they were building.

Ensuite, des slides détaillés d’Abrash sur les défis techniques et cognitifs de la réalité virtuelle :

All of the followings are needed :

  • A wide field of view
  • Adequate resolution
  • Low pixel persistence
  • A high enough refresh rate
  • Global display
  • Optics
  • Optical calibration
  • Rock-solid tracking
  • Low latency

Pour aller plus loin, son blog est recommandable.