Tout le monde copie tout le monde en conception d’interface utilisateur. Alors pourquoi ne pas faire la liste de ce qui a été le plus copié et, donc, est le plus visible sur les interfaces pour que ce soit encore plus copié, donc encore plus visible, donc encore plus….
Et on appellera ça un « pattern », et comme ça concerne l’interface utilisateur, un « UI pattern ».
Je suis pour parce que ça rend homogène les interfaces web par exemple, ou web mobile, ou « desktop » (bureau). Et plus d’homogénéité c’est plus d’éfficacité pour l’utilisateur qui va par exemple s’attendre à ce que la petite icône à côté du champ date ouvre un calendrier.
Mais attention, ça ne prive pas le concepteur d’interface de chercher à faire mieux que le maître, bien au contraire.
Je suis tombé sur cette bonne ressource : 40+ Helpful Resources On User Interface Design Patterns
Et en particulier sur 30 Essential Controls
Et c’est vrai que c’est pratique.
Mais je reproche 2 choses aux « UI patterns ».
D’abord, ils font étrangement leur apparition avec une technologie. Ce n’est donc pas toujours leur intérêt propre qui intéresse ceux qui les manipulent mais plutôt le fait qu’il existe et que donc il faut les utiliser. Autrement dit, le « date picker » (le petit calendrier qui s’affiche quand on clique sur une icône calendrier) est utilisé par ce qu’il est intéressant ou parce qu’il existe dans la librairie flex (ou Laszlo, ExtJS, Dojo, YUI, JQuery, Scal built on) ?
La encore, une seule solution possible, profiter de tests utilisateurs pour vérifier que les utilisateurs ont besoin d’un « date picker ». « L’auto completion » (« auto suggest ») permet à l’utilisateur de saisir les premières lettres d’une ville et de voir apparaître une liste de villes commençant par ces lettres. Parfois mes prototypes n’en sont par pourvus car statiques et les utilisateurs n’hésitent pas à me le dire : « c’est pénible de devoir tout écrire, il faudrait que je tape une lettre et une liste apparaît »… C’est l’identification claire d’un besoin.
Ensuite l’UI pattern n’offre aucune garantie en terme d’ergonomie (ou d’utilisabilité). Pour faire court, l’ergonome s’intéresse aux utilisateurs, aux tâches et… au contexte d’utilisation. Hors ce qui est la qualité de l’UI pattern, être le même partout, devient un gros défaut.
Par exemple, j’ai beaucoup étudié la sélection des dates avec le « date picker » présent sur quasiment tous les sites de tourisme. Et il ressort que ce composant est indispensable, en effet, savez-vous donner les dates de vos vacances de Noël 2010 du samedi au samedi sans regarder un calendrier ?
Mais la façon dont le composant est mis en oeuvre peut faire varier l’efficacité de l’utilisateur de 1000%. Un couple de dates (aller, retour) sélectionné en 15 secondes sur un site peut demander 2,5 minutes sur un autre (véridique).
Cela dépend de (un extrait) :
- la grosseur des « cases dates »,
- si le calendrier de sélection de la date de retour s’ouvre immédiatement après celle de l’aller
- si les jours du mois suivant/précédent sont affichés
- si les intitulés des jours sont « L » ou « Lu » ou « Lun » ou « Lundi »
- si 1, 2 ou 3 mois sont affichés
- si la date de l’aller est indiquée sur le calendrier de la date retour
- si le calendrier de la date retour est par défaut fixé sur la date aller
- si le jour par défaut est aujourd’hui
- etc…
Donc pour définir et concevoir le meilleur outil sélection de date, une goutte d’eau dans la conception de l’interface complète, utiliser le composant par défaut de la librairie de développement ou faire comme son site préféré n’est pas suffisant. Il faut faire appel aux utilisateurs, encore une fois ! Et donc faire appel à celui dont le métier est de savoir discuter avec cet utilisateur : l’ergonome.
Loading ...