octobre
2007
Un article de christopheJ
Je ne sais pas si vous connaissez le blog de Kathy Sierra. Elle est à l’origine de la série de livre « Tête premiere » avec son style si particulier. Elle tenait aussi un blog dans le même style que les livres, mais malheureusement suspendu : creating Passionate User. Je vous recommande fortement la lecture de ces anciens billets.
Je relisais un de ses posts sur les différents types d’applications et j’ai du coup repensé à un truc qui me frustre sur les interfaces d’applications : les boutons.
Il y a trois catégories d’interfaces:
- celles qui n’affichent que les boutons utiles ou fonctionnels
- celles qui affichent une partie des boutons grisés
- celles qui affichent tous les boutons en permanence
La première catégorie est pratique on ne voit que ce que l’on peut faire, on ne se pose pas de question. Par contre dès que l’on veut faire des choses qui ne sont pas en accès direct, on peut chercher longtemps où et comment faire apparaitre les boutons. Il faut que les cinématiques soient bien pensées et intuitives. Généralement ces applications ne sont pas trop complexes.
La seconde catégorie, avec ses boutons grisés, vous fait voir tous ce que vous pourriez faire si vous aviez le droit ou aviez fait la bonne séquence d’actions. Par rapport à la première catégorie, comme on voit déjà les boutons, il ne reste plus qu’à trouver comment les activer. C’est un peu plus user-friendly que la précédente catégorie. Par contre quand on cherche depuis un moment comment rendre actif ces « satanés » boutons, cela devient frustrant et on a un peu l’impression que l’application nous dit
T’as vu un peu tout ce que tu pourrais faire si tu avais le droit…
La dernière catégorie est sans doute la pire. Vous avez tous les boutons actifs mais une fois sur deux quand vous cliquez dessus, au bout de quelques secondes, un message d’erreur vous annonce qu’il n’est pas possible de faire cela.
C’est l’application qui vous dit
Bien tenté mais tu n’as pas le droit !
Avec un peu de chance, le message est suffisamment clair pour comprendre ce qui n’allait pas, mais ce n’est pas toujours le cas….
Dans les trois types d’interface, je finis généralement par une phase d’exploration à tâtons qui une fois sur deux se solde par un echec ou mon incapacité à me souvenir de tous les endroits où j’ai cliqué/coché pour faire apparaitre/activer/fonctionner le fameux bouton.
Il y a des jours où l’on a l’impression que des développeurs sadiques préparent ces interfaces avec des rires de savants fous qui résonnent dans les bureaux…
Je sais, on va me dire que je devrais prendre plus de temps pour consulter l’aide ou lire les manuels au lieu de cliquer bêtement, mais avez-vous déjà vu un homme perdu en voiture demander son chemin….
Et vous quelle est le type d’interface qui vous fâche le plus?
Je pense que la conception d’interface graphique est une chose qu’on ne devrait pas laisser aux développeurs…
Plus sérieusement je pense vraiment que c’est un « exercice » très complexe, car il faut savoir proposer entre une interface claire sans la brider.
a++
Je serais également adepte de la seconde mais avec un mélange de la première :
Si on n’a pas les droits le bouton n’apparait pas. Mais il est grisé si on à les droits et pas la bonne séquence..
Personnellement, je suis plutôt adepte de la seconde.
Soit le libellé est assez explicite pour savoir ce qu’il faut faire,
Soit il y’a un petit message dans un coin (cf. Eclipse si une saisie est invalide dans la boîte de dialogue),
Enfin avec le libellé du bouton et une recherche rapide dans une aide quelconque (ex: manuel ou touche F1), on devrait pouvoir trouver les conditions de (dés)activation.
Concernant la première, il est bien évident que l’on se demandera plutôt si l’application en est capable plutôt que de chercher à activer une option cachée.
Le troisième est un peu frustrante et montre surtout une application mal conçu. Néanmoins, elle reste pratique car elle permet facilement au concepteur de notifier l’utilisateur sur la raison de l’échec et de lui donner assez d’information pour trouver l’origine du problème (soit directement dans le message, soit en allant cherchre dans la documentation).