import { Notes, Appear } from "mdx-deck"; import React from "react"; import { ExamplesLayout } from "./ExamplesLayout"; import { DefinitionLayout } from "./DefinitionLayout"; import { ColumnsLayout } from "./ColumnsLayout"; import { ImageLayout } from "./ImageLayout"; import { theme } from "./theme"; export { theme } from "./theme";
<iframe style={{ width: "100vw", height: "100vh", position: "fixed", top: 0, left: 0, pointerEvents: "none" }} src="http://geraudhenrion.io/" />- 4ans graphiste web @Zygmund
- 2ans développeur / designer @Nartex
C'est vraiment la première fois que je parle devant autant de monde. Merci d'être indulgents.
Y'a-til des designers dans la salle ?
Y'a-til des développeurs dans la salle ?
Cognitive Dimensions of Notations
Une méthodologie pour l'évaluation des interfaces
Un peu putaclick je l'avoue
J'ai encore jamais appliqué ça professionnellement mais j'ai trouvé ça très instructif
Ça a beaucoup intéressé ma copine alors qu'elle n'est pas du métier
Et pour les développeurs, on constate qu'on peut faire beaucoup de parallèles avec comment concevoir un code de qualité.
Y'a-til des gens qui connaissent ?
Aussi je ne suis pas un expert du sujet, n'hésitez pas à me faire des remarques
Et surtout je vais rendre ça interactif en vous demandant de donner des exemples (et oui haha je serais pas tout seul à parler)
<ImageLayout src="./dimensions.gif" opacity={0.3}
- Évaluer l'ergonomie
- d'une interface utilisateur
- d'un language de programmation
- Avec 14 critères
- Pose des mots sur des concepts
Un peu de contexte
C'est important d'avoir un vocabulaire partagé. Par exemple la notion de téléphone est différente selon les époques. Ou celle de petit déjeuner l'est selon les cultures. Je veux m'assurer que quand je vais travailler avec quelqu'un on soit d'accord là dessus.
- Parler de reproduction à un biologiste / à ma copine
- Différence entre théorie dans le langage courant / en science
<DefinitionLayout backgroundSrc="./radar-graph.png" backgroundOpacity={0.3} title="Dimensions" translation="→ Axes d'évaluation"
- Bases pour évaluer l'existant
- Offre des Pistes d'exploration
- Maximiser un axe peut en influencer un autre
- Obligation de compromis
Beaucoup de choses qu'on fait déjà instinctivement en design / bonnes pratiques
<DefinitionLayout backgroundSrc="./brain.gif" backgroundOpacity={0.3} title="Cognitif" translation="→ En rapport avec le cerveau"
- Fortement lié à nos méchanismes cognitifs
L'idée est de développer un vocabulaire commun aux porteurs de projets, aux développeurs, aux utilisateurs et aux designers
<DefinitionLayout backgroundSrc="./Beethoven_Ninth_Symphony.png" backgroundOpacity={0.3} title="Notation" translation="→ Un système d'images, symboles, lettres et expressions servant à représenter de l'information"
- Souvent propre à la discipline
- Défini par convention
C'est vague ^^
In linguistics and semiotics, a notation is a system of graphics or symbols, characters and abbreviated expressions, used (for example) in artistic and scientific disciplines to represent technical facts and quantities by convention.[1][2] Therefore, a notation is a collection of related symbols that are each given an arbitrary meaning, created to facilitate structured communication within a domain knowledge or field of study.
Standard notations refer to general agreements in the way things are written or denoted. The term is generally used in technical and scientific areas of study like mathematics, physics, chemistry and biology, but can also be seen in areas like business, economics and music.
- Formule mathématique ou chimiques
- Partition de musique
- Interface graphique
- Brochure, manuel
- Langage de programmation
Rentrons dans le vif du sujet
Interfaces =
- Microsoft Word
- Application mobile…
D'autres exemples ?
- Viscosité
- Visibilité
- Engagement prématuré
- Relations cachées
- Expressivité des rôles
- Tendance à engendrer des erreurs
- Abstraction
- Notation secondaire
- Proximité de la correspondance
- Cohérence
- Taux de diffusion
- Opérations mentales difficiles
- Provisionabilité
- Évaluation progressive
Je vais tenter de brosser ça rapidement mais en gardant ça intelligible et surtout en donnant des exemples.
Après, j'ai trouvé une fiche méthodologie sur internet qu'on peut remplir sous la forme d'atelier si y'en a qui veulent essayer pendant la pizza ou faire des devoirs à la maison
Désolé pour les traductions un peu chelou depuis l'anglais. J'ai gardé le mot originel pour un meilleur contexte.
<DefinitionLayout backgroundSrc="./viscosity1.gif" backgroundOpacity={0.3} num={1} title="Viscosité / Fluidité" translation="Viscosity / Fluidity"
L'effort requis pour apporter une modification
Résistance au changement
- Le moins = le mieux
- La quantité de travail que va devoir fournir l'utilisateur pour accomplir son objectif.
- Mais introduit un nouveau concept (une abstraction)
Changer la couleur de tous les titres dans Word VS Styles globaux
Processus d'inscription à rallonge VS Authentification tierce
Editer en lieu et place VS Changer de page
D'autres exemples ?
- Site des impôts
<DefinitionLayout backgroundSrc="searching.gif" num={2} title="Visibilité" translation="Visibility"
Avec quelle facilité l'utilisateur va pouvoir accéder, identifier et rendre visibles les éléments dont il a besoin ?
« How readily can required parts of the notation be identified, accessed and made visible? »
Hamburger menu VS Bottom menu
D'autres exemples ?
- Menus à la navigation trop profonde VS Menus très aplatis
<DefinitionLayout num={3} title="Engagement prématuré" translation="Premature commitment" backgroundSrc="handcuff.gif"
L'utilisateur doit-il prendre des décisions avant même d'avoir toutes les informations nécessaires ?
Peut-on corriger nos décisions plus tard ?
Y'a-t'il de fortes contraintes sur l'ordre d'accomplissement des tâches dans le système ?
Ça ne devrait pas arriver.
Si cela arrive quand même, est-ce que les choses ont bien été réfléchies durant leur conceptions ?
Processus trop linéaire
Acheter un logiciel sans tester VS période d'essai gratuite
Actions irremédiables VS Bouton "annuler"
D'autres exemples ?
- Créer un compte avant de passer commande
- Popup : Inscrivez-vous à ma newsletter
- Ne pas afficher le prix d'un produit avant de l'ajouter au panier
- Ne pas afficher le prix de la livraison avant d'avoir accompli toutes les étapes
- Formulaires à rallonge
- Processus linéaire "tunnel"
<DefinitionLayout num={4} title="Relations cachées" translation="Hidden dependencies" backgroundSrc="cat-light-switch.gif" backgroundOpacity={0.4} backgroundSize="contain"
Les relations entre les éléments sont-elles visibles ou cachées ?
Toutes les relations sont-telles indiquées dans les deux sens ?
Est-ce qu'un changement à un endroit a des conséquences inattendues ?
Are dependencies between entities in the notation visible or hidden? Is every dependency indicated in both directions? Does a change in one area of the notation lead to unexpected consequences?
Si plusieurs parties d'un système dépendent l'une de l'autre, cette relation ne devrai pas être cachée
Dépendance d'une cellule dans Excel VS Impact de cette cellule sur d'autres
Dans excel on peut sélectionner une cellule et voir quelles cellules l'influencent (elle dépend de)
Tandis que dans l'autre sens, on ne sait pas quels impact elle a sur d'autres
D'autres exemples ?
<DefinitionLayout num={5} title="Évidence" translation="Roles expressiveness" backgroundSrc="tide-pod.gif"
Est-ce que c'est évident ce que fait chaque élément dans le système ?
Le rôle d'un élément doit être évident, ou du moins facilement et rapidement inferré par l'utilisateur
How obvious is the role of each component of the notation in the solution as a whole?
Le rôle d'un élément doit être évident, ou du moins facilement et rapidement inferré par l'utilisateur
L'utilisateur ne devrait pas être confus quand à l'utilisation des éléments. 2 éléments avec un rôle différent ne devraient pas être identiques.
Liens VS Titres soulignés
Texte des boutons peu explicites
D'autres exemples ?
<DefinitionLayout num={6} title="Invitation à l'erreur" translation="Error proneness" backgroundSrc="wrong-answer.gif"
En quelles proportions la notation donne-t-elle la possibilité de faire des erreurs ?
Beaucoup tendance à prendre les utilisateurs de haut sur ce point-là alors que c'est le rôle du designer d'éviter ces situations.
Il faut savoir prendre en compte les limitations humaines.
- Slips (lapsus, dérapage) -> l'intention est bonne mais il a "cliqué à côté" ou "oublié de"
- Mistake (méprise) -> l'utilisateur a mal compris les implications de son action ou a un mauvais modèle conceptuel
Trop faibles différenciations
Zones d'actions trop proches et / ou de petite taille…
D'autres exemples ?
- Incohérences (inversion de la position des boutons "valider" et "annuler")
Plusieurs éléments qui groupés ensemble peuvent alors être traités comme un seul.
What are the minimum and maximum levels of abstraction exposed by the notation? Can details be encapsulated?
Permet d'encapsuler des détails.
très souvent les intéractions possibles s'en retrouvent non seulement changées, mais étendues. (émergence => le tout est plus grand que la somme de ses parties)
Mais cache aussi des éléments, peut par exemple créer des dépendances cachées ou réduire la visibilité.
Permet de réduire d'autres axes, comme la viscosité
Renseigner l'adresse à chaque commande VS Sélectionner parmi des adresse pré-remplies
D'autres exemples ?
- Les numéros de téléphone dans contact
- Feuille de style (dans Word)
- Les symboles dans Sketch
- Les blocs dans WordPress Gutenberg
<DefinitionLayout num={8} title="Notation secondaire" translation="Secondary notation and escape from formalism" backgroundSrc="manual-annotation.png"
La notation permet-elle d'apporter des informations complémentaires sans en transformer la nature ?
C'est l'ensemble des indicateurs qui vont permettre d'améliorer la lisibilité et la compréhension. Et qui échappe au formalisme habituel (rester dans les clous, très scolaire)
On va parler de mise-en-page, de couleur, d'annotations…
Tout condenser dans un paragraphe VS Sauter à la ligne et ajouter des titres
Commentaires et annotations dans les PDF
Écrire du texte en rouge dans un Word
Nommer ses fichiers, Ajouter des icônes
D'autres exemples ?
<DefinitionLayout num={9} title="Proximité de la correspondance" translation="Closeness of mapping" backgroundSrc="metro-map.png"
Dans quelle mesure la notation correspond-elle à ce qu'elle représente ?
Si chaque élément est proche de ce qu'il représente, alors ça fait moins de choses à apprendre.
Et moins de traduction / correspondance à faire dans son esprit.
Écrire son propre Html VS Utiliser WordPress Gutenberg (WYSIWYG)
Un tracé sur la carte VS Des instructions
Un calendrier VS Un champ texte pour une date
D'autres exemples ?
<DefinitionLayout num={10} title="Cohérence" translation="Consistency" backgroundSrc="suite-logique.png"
Une fois qu'une partie de la notation est apprise, avec quelle facilité le reste peut-il être deviné ?
After part of the notation has been learned, how much of the rest can be successfully guessed?
L'utilisation de façon des faire (patterns) cohérentes permet à l'utilisateur de reconnaître les symboles familiers lors de leur navigation
Plus c'est cohérent, moins l'utilisateur n'aura a réfléchir pour inferrer les usages sans charges mentale supplémentaire.
Constance de l'apparence et de la position des boutons
D'autres exemples ?
- Position du menu
- transitions de navigation / animations
Tout ce qui va surprendre / venir perturber les habitudes = mauvais
<DefinitionLayout num={11} title="Concision / Diffusion" translation="Terseness / Diffuseness" backgroundSrc="foggy.gif" backgroundOpacity={0.4}
Faut-il beaucoup de symboles pour produire un résultat ou exprimer quelquechose ?
C'est la "verbosité" du langage de votre interface.
Plus c'est concis, mieux c'est ;) Mais forcément ça peut impliquer des impacts sur d'autres axes
Des instructions pour mot de passe verbeuses VS Un indicateur de sécurité
D'autres exemples ?
- Menu déroulant pour une date, menu déroulant pour OUI/NON VS Calendrier, checkbox… (rejoint closeness of mapping)
- Message d'erreur bref et contextuel VS Message d'erreur flou et avec excuses et excès de politesse
- Trop de photo et d'espace inutiles
On remarque que la proximité de correspondance, faire des abstractions, utiliser des notations secondaires peuvent aider à ce propos
<DefinitionLayout num={12} title="Opérations mentales difficiles" translation="Hard mental operations" backgroundSrc="hard-mental-operations2.gif"
Y'a-t-il des opérations mentales compliquées à accomplir pour l'utilisateur, qui seraient dues à la notation elle-même ?
Doit-il utiliser ses doigts, prendre des notes ?
Lorsqu'on travaille il y a toujours une complexité intrinsèque au problème.
Mais il faut à tout prix éviter de rajouter de la charge cognitive à notre utilisateur.
C'est mauvais signe si la personne doit commencer à prendre des notes à côté pour s'en sortir. Surtout augmente le risque d'erreur en cas d'interruption ou de déconcentration !
Genre faut pas que la personne ait l'impression de rsoudre un sudoku
Retenir un mot de passe
Composer un numéro de téléphone de mémoire VS Utiliser le carnet d'adresse
D'autres exemples ?
- Calculer la TVA
- La somme du panier avec livraison…
La capacité avec laquelle il est possible d'expérimenter avec le système
Avec quelle aisance peut-on tester, jouer, explorer ?
Peut-ton avoir un aperçu de l'action en cours avant même qu'elle soit terminée ?
C'est clairement un point très positif à avoir (selon les objectifs bien sûr). Permet à l'utilisateur d'explorer le domaine des solutions sans risque.
Possibilité de dupliquer, de revenir en arrière, de conserver des états antérieurs
Drag and Drop avec aperçu du résultat en temps réel
D'autres exemples ?
- Panier, wishlist
<DefinitionLayout num={14} title="Évaluation progressive" translation="Progressive evaluation" backgroundSrc="cardboard-prototype.gif"
Avec quelle aisance peut-on évaluer et obtenir des retours d'une solution incomplète ?
Peut-on s'arrêter en plein milieu et se dire "Où en suis-je ?"
How easy is it to evaluate and obtain feedback on an incomplete solution?
capacité à prototyper
avoir un "à peu près" à tout moment
Bouton "Aperçu" dans les CMS, ou "Prototype" dans Sketch
Barre de progression processus de paiement
D'autres exemples ?
- Complétion des infos du profil (Linkedin)
- Faire son plan en avance dans un éditeur de texte (titres etc.)…
- Viscosité
- Visibilité
- Engagement prématuré
- Relations cachées
- Expressivité des rôles
- Tendance à engendrer des erreurs
- Abstraction
- Notation secondaire
- Proximité de la correspondance
- Cohérence
- Taux de diffusion
- Opérations mentales difficiles
- Provisionabilité
- Évaluation progressive
J'espère que vous avez apprécié autant que moi parler de ce sujet
Je rappelle que pour ceux qui le souhaitents j'a ides fiches de méthodlogie (en anglais) pour pratiquer après.