Utiliser WPF pour le meilleur et pour le pire

Par David Platt, de Rolling Thunder Computing.

Principes d'une bonne interface

1. Tu connaitras l'utilisateur car il n'est pas toi. Est-ce que l'utilisateur veut des transitions?

Premier corrolaire: l'utilisateur se fiche de ton programme, et même de toi. C'est à toi de te soucier de lui, pas l'inverse.

2. Si ton application ne fournit pas de sexe ou son équivalent, ton utilisateur ne veut pas l'utiliser et n'a même pas envie d'être devant l'ordinateur.

3. Même si l'utilisateur est devant l'ordinateur, il veut se soucier de ton programme aussi peu que possible.

L'utilisateur ne veut pas utiliser ton programme et ne veut pas savoir qu'il l'a utilisé.

Et WPF dans tout ça?

L'utilisateur est un fainéant. Il en fera le moins possible quelle que soient les circonstances. Ce qui est facile à faire sera donc fait souvent, donc un bon design consiste à rendre faciles les choses qui doivent être faites souvent et sont bien.

WPF a rendu plein d'artefacts d'expérience utilisateur faciles à utiliser, et du coup ils sont aussi utilisés quand ils ne devraient pas, simplement parce qu'ils sont faciles à utiliser.

L'utilisateur ne fait pas très attention. Plus on lui prend de son attention à un endroit, moins on en aura à d'autres.

Les gradients

Il est facile de faire des gradients de couleurs, donc on les utilise beaucoup trop souvent. Le gradient permet de communiquer une quantité énorme d'information au cerveau de l'utilisateur. Rien ne sert de l'utiliser sur un bouton, mais c'est très utile pour indiquer des valeurs sur une cartographie.

Il s'agit de communiquer à l'utilisateur ce qu'il veut savoir d'une manière qui est la plus immédiate possible pour lui.

Le mouvement

Il attire invariablement l'attention de l'utilisateur. Car nous sommes faits pour détecter le mouvement. WPF rend le mouvement facile à faire, pour le bien et (souvent) pour le mal.

Il faut l'utiliser pour représenter un mouvement du monde réel. Mais attention: ça peut être saccadé, d'autant plus que la machine de l'utilisateur moyen est généralement plus lente que celle d'un développeur. Exemple: un ventilateur qui tourne dans un programme de contrôle d'un circuit de refroidissement.

Autre exemple utile: un contrôle qui grossit quand la souris arrive dessus pour le montrer et aider à le sélectionner.

Danger: l'utilisateur peut se fatiguer de l'effet de zoom. Exemple: Google Earth, qui zoome out et in à chaque changement d'adresse.

Le XAML

Il permet d'avoir un ergonome dans l'équipe, qui s'occupera de faire une interface centrée sur l'utilisateur. Mais il permet aussi d'avoir un designer qui ne pense qu'à faire quelque chose de joli, pas à l'utilisateur.

C'est la même chose pour les objets de la vie réelle. Si un objet n'est pas d'utilisation intuitive, c'est qu'il a été mal pensé. Si vous pouvez l'utiliser sans même y penser, c'est qu'un ergonome y a réfléchi.

Le relookage des contrôles ne sert que quand il aide l'utilisateur. Exemple: le treeview dans Family.Show est bien; les boutons ne le sont pas.

Les règles

1. assure-toi que l'application fonctionne correctement (même si elle est jolie, ça n'excuse pas un mauvais fonctionnement);
2. prends l'aide d'un vrai pro de l'expérience utilisateur (un designer ignore autant les principes de l'UX qu'un développeur);
3. fais attention à ce qui est "cool": l'utilisateur ne veut pas du cool, il veut du travail terminé - exemple: Clippy;
4. prends soin de ne pas être remarqué;
5. demande-toi en quoi chaque amélioration rendra ton utilisateur plus heureux.