Vous cherchez des idées d'interfaces pour vos applications iOS, découvrez les deux sites suivant :

En espérant que cela vous aidera à améliorer l'ergonomie et l'expérience utilisateur de vos applications.

Mais que mettre dans les menus contextuels ?

06042009 Dans: Design

L'un des béta-testeurs de mon logiciel m'a posé une question intéressante: "À quand les menus contextuels ?". Ce à quoi j'ai répondu: "Jamais !".
Comment puis-je donner une réponse aussi catégorique ? Parce que cela fait un moment que j'y réfléchis.

Une demande des switchers

Les menus contextuels sont apparus sous Mac OS 8.5, alors que jusqu'alors, Apple ne les avait pas trouvés nécessaires. Il s'agissait de répondre à une demande des utilisateurs venant du monde Windows, qui ne parvenaient pas à créer un dossier ou faire du copier-coller.

Sous NeXTStep

Je souhaite revenir à ce vieux système, parce qu'il a poussé les menus contextuels très loin. D'après ce que je me suis laissé dire, un clic droit y permettait d'afficher un menu proposant toutes les opérations possibles sur l'objet cliqué, présentées en menus hiérarchiques. Et ce fonctionnement n'était pas affreux, puisqu'il était cohérent: on était sûr d'y trouver toutes les opérations possibles.

Il n'était pas non plus idéal, parce que les menus hiérarchiques ne sont jamais très pratiques: la souris a tendance à replier trop facilement le menu, et puis quand on arrive sur le bord droit de l'écran, l'article de menu doit passer à la ligne; on s'y perd un peu.

Pendant ce temps là, chez Microsoft

Sur PC, on était habitué depuis longtemps à ce que la souris comporte souvent trois boutons. Seules les applications de CAO en tiraient parti; pour le reste, comme l'IHM de Windows avait été pompée sur le Mac, Microsoft s'est longtemps demandé que faire des boutons supplémentaires, qui servaient à faire défiler le document ou à émuler le double-clic. Quand ils se décidèrent à utiliser le bouton droit pour faire apparaître un menu contextuel, ils ne voulurent pas — comme nous l'avons vu, par commodité — proposer trop de menus hiérarchiques, mais limitèrent la liste des opérations à une poignée.

Ceci amena alors une question: quelles opérations incorporer ?

Revenons au Mac

Tout développeur se retrouve donc avec la même question que Microsoft. Comme chez Apple, ils sont balèzes et que ça fait dix ans que ça existe sur Mac, ils ont dû trouver la réponse, pas vrai ? Comme à mon habitude, je m'en vais lire la bible, et la confronter aux logiciels d'Apple:

Un petit exemple sous Safari:

Copie d'écran de Safari

Et un extrait des AHIG:

Include a small subset of the most commonly used commands in the appropriate context. For example, Edit menu commands should appear in the contextual menu for highlighted text, but a Save or a Print command should not.

Un autre exemple sous Finder:

Copie d'écran de Finder

Always ensure that contextual menu items are also available as menu commands. A contextual menu is hidden by default and a user might not know it exists, so it should never be the only way to access a command. In particular, you should not use a contextual menu as the only way to access an advanced or power-user feature.

Ma démarche n'est pas de démontrer qu'Apple — qui n'est pas à une contradiction près — ne suit pas les règles qu'elle édicte; simplement que ses ingés ne savent foutrement pas quoi mettre dans ces menus.

C'est pas tout ça, mais j'ai un logiciel à coder

Je ne saisis pas bien l'intérêt d'avoir une manière supplémentaire de faire du copier-coller, dont les raccourcis-clavier sont bien connus. En tant qu'utilisateur, j'utilise les menus contextuels, mais justement pour les fonctionnalités avancées.

Et pour une application aussi simple que la mienne — il n'y a même pas de Préférences — je peux dire que les menus contextuels ne sont pas pour demain.

Renaud Pradenc
Céroce

Je parle bien de design

La plupart des gens confondent stylisme et design. Autrefois en français, on distinguait le dessin du dessein; l'homophonie a fait préférer le terme design à dessein, mais l'idée reste: le design, c'est la conception fonctionnelle, comment "marche" l'objet. Le stylisme, lui, n'est lié qu'à l'apparence d'un objet (et non pas son esthétique, il n'y a pas de notion de beau ici, juste celle de différenciation).

Les Mac sont des machines fortement designées. Il m'a toujours été difficile d'expliquer pourquoi j'avais fait le choix du Mac à des personnes qui ne connaissent que le PC. Elles ne comprennent pas pourquoi elles devraient payer plus cher pour un ordinateur, "seulement parce qu'il est plus beau". Certainement, si vous me lisez, vous utilisez un Mac, et vous savez pourquoi: vous avez acheté plus que du matériel, vous avez acheté une expérience. Vous aimez le Mac parce qu'il a été "pensé".

En tant que programmeur sur Mac, je suis aussi un utilisateur, et je m'arrange pour reproduire ce qui me plaît et bannir ce qui m'agace au quotidien. L'essentiel du travail de design se faisant sur l'interface utilisateur, les Apple Human Interface Guidelines restent un livre de chevet. Mais ce sont tout autant les années d'utilisation du Mac qui m'ont formé à sa culture: minimalisme, prévisibilité, cohérence.

J'ai eu l'occasion de parler avec un programmeur qui a un poste important chez un grand éditeur de logiciels d'apprentissage des langues. Nous parlions d'Eclipse, et je lui exprimais mon dégoût pour son interface. Il me répondit: " l'interface utilisateur, c'est avant tout une question de goût". Je ne peux pas être plus profondément en désaccord ! Il y a certes des habitudes, personnelles ou liées à l'utilisation d'une plateforme particulière, certes tout le monde ne pense pas pareil, ni n'a les mêmes aptitudes mentales, mais je suis convaincu que les trois piliers que j'ai cité plus haut (je les cite à nouveau: minimalisme, prévisibilité, cohérence) sont des principes qui peuvent s'appliquer à tous les cerveaux.

Votre rôle de designer: prendre des décisions

Voici un exemple. Un développeur a proposé que nous faisions des remarques sur son nouveau logiciel. Beaucoup de mes remarques portaient sur les Préférences, mais particulièrement sur une case à cocher. Cette case servait à activer la génération de l'aperçu QuickLook. Si, si, vous savez, QuickLook, le truc introduit par Apple avec Mac OS 10.5 et qui permet d'afficher l'aperçu des documents.

"C'est utile alors. Pourquoi tu ne le laisses pas activé tout le temps ?" lui demandais-je.

Parce que la génération de l'aperçu prend du temps. Mais si la génération n'est pas faite, le Finder met plus de temps à afficher l'aperçu", me répondit-il. Et un peu agacé par mes propos, il a laissé sa case à cocher.

Voyez-vous le travers ici ? Ce développeur n'a pas voulu faire de choix. Il laisse l'utilisateur le faire à sa place. Mettons-nous dans la peau de l'utilisateur: je me retrouve avec une case "Générer l'aperçu QuickLook", je la coche ou pas ? À mon avis, 9 personnes sur 10 préférerons ne pas y toucher. Dans celles qui restent, certaines iront voir la doc et ne seront pas plus avancées. Elles laisseront la valeur par défaut. Il reste peut être alors une infime portion d'utilisateurs qui vont tester ce qui leur convient le mieux. Le pire, c'est que le développeur devra quand même décider si la case doit être cochée par défaut ! Les conséquences sont les suivantes:

  1. vous avez troublé vos utilisateurs
  2. vous avez peut-être codé une fonction inutile
  3. vous avez dû documenter le rôle de cette case
  4. vous avez compliqué votre source (ce qui gâte son évolution et peut éventuellement produire des bogues)

Quelle était la bonne décision alors, puisque je sais tout ? Je dirais: Imposer la meilleure option à l'utilisateur. Si la génération de l'aperçu prend moins d'une seconde, alors c'est négligeable pour l'utilisateur. Mais mon vrai choix, en vrai, aurait été de ne tout simplement pas coder cette fonctionnalité. Je n'utilise jamais l'affichage Coverflow, et très rarement QuickLook. Et j'imagine qu'il en est de même pour tout le monde, sauf Steve Jobs, pour épater la galerie lors de ses conférences. D'ailleurs, je parie que Coverflow aura disparu dans Mac OS 10.8. Et même si j'ai tort, il y avait plein d'autres choses plus importantes à coder avant.

Pour finir, ne jetons pas la pierre à ce développeur — qui a pensé avant tout à ses utilisateurs — mais balayons déjà devant notre porte: Toi, lecteur, quels choix t'es-tu refusé à faire ?

Dans la suite du billet Un exemple de gestion des préférences, voici les différentes étapes de l'amélioration des préférences du logiciel CPU History de Christopher Bowns :


Sponsors