Comment afficheriez-vous une clé équivalente à l'utilisateur?
On est autorisé à affecter des équivalents clés à des contrôles tels que les boutons-poussoirs dans Cocoa.
Par exemple, on pourrait affecter Cmd-E au bouton poussoir. Pourriez-vous essayer de faire savoir à l'utilisateur qu'appuyer sur Cmd-E revient à cliquer sur ce bouton? (Peut-être, via une info-bulle, dans l'étiquette du contrôle, etc.) Ou, vous attendriez-vous à ce que l'utilisateur apprenne de tels équivalents dans la documentation seule?
Windows vous permet déjà de savoir quel est l'équivalent clé en soulignant une lettre, par exemple dans la boîte de dialogue ci-dessous, appuyer sur Alt-F reviendrait à cliquer sur le bouton Rechercher:
Dans Windows 3.1, la lettre correspondante était toujours soulignée. À partir de Windows XP, je pense, les soulignements n'apparaissent plus tant que vous n'appuyez pas sur la touche Alt.
Sur le Mac, vous pouvez implémenter une approche similaire en affichant les équivalents de touche de commande lorsque l'utilisateur appuie sur la touche Option, mais AFAIK il n'y a pas de mécanisme intégré dans Mac OS pour l'implémenter automatiquement. L'activation des fonctionnalités d'accessibilité peut fournir un moyen d'afficher les équivalents clés, mais je ne les ai jamais essayés et ils ne sont pas activés par défaut.
OMI, Windows gère mieux les équivalents des touches des boutons que le Mac, mais le Mac gère mieux les équivalents des touches des éléments de menu. Lorsque vous cliquez sur un menu, puis appuyez sur la touche Option, vous verrez différents éléments de menu qui sont généralement des extensions de ceux d'origine, par exemple Fermer la fenêtre devient Fermer tout:
J'ai lu l'article AskTog auquel @DanM a lié il y a quelques années. Je l'ai trouvé idiot à l'époque et je le trouve idiot maintenant. Sa prémisse est fausse:
Demandez à tout utilisateur d'ordinateur qui dépend fortement des équivalents clés et les utilise presque inconsciemment, par opposition aux participants au test qui sont invités à appuyer sur une touche
Le test de Tog est très limité et, à mon avis, inutile. En tapant cet article, j'ai appuyé plusieurs fois sur Cmd-Shift- [et Cmd-Shift-] pour aller et venir entre les différents onglets du navigateur. Je me serais senti très handicapé si je devais aller au menu à chaque fois ou déplacer la souris pour appuyer sur un bouton. Non seulement cela me prendrait plus de temps, mais je devrais déplacer le curseur de la souris à l'endroit où j'étais dans le champ d'édition - un effet secondaire qui n'est pas mesuré par Tog.
Personnellement, je l'aime quand le menu ou l'info-bulle du bouton me montre le raccourci pour une option.
Cependant, cela dépendrait de votre public.
Les programmeurs ont tendance (généralisation générale je sais) à aimer utiliser le clavier plus que les utilisateurs de bureau "ordinaires" afin qu'ils puissent apprécier les informations. Ils sont également plus susceptibles d'expérimenter l'interface pour voir ce qu'elle peut faire.
Les utilisateurs moins techniques peuvent être submergés par les informations que vous fournissez et sont plus susceptibles (une autre généralisation) d'utiliser la souris plutôt que le clavier, de sorte que le raccourci n'est pas pertinent pour eux.
C'est généralement une convention que les raccourcis clavier soient notés près de l'élément de menu auquel ils sont affectés. C'est moins évident ou simple quand il s'agit d'autres contrôles (vous pouvez utiliser une info-bulle là-bas, mais ce n'est pas standard ou prévu, à mon avis).
Pourquoi voudriez-vous éviter cela? Économiser de l'espace?
Les utilisateurs ne lisent généralement pas et en particulier ils ne lisent pas les documentations ...
Une chose à garder à l'esprit est que les raccourcis clavier ne sont pas une fonctionnalité critique pour la plupart des utilisateurs. Des recherches montrent également que la souris est plus rapide que le clavier pour la plupart des tâches et la plupart des utilisateurs (par exemple, http://www.asktog.com/SunWorldColumns/S02KeyboardVMouse3.html ). Cela ne signifie pas que vous ne devez pas fournir de raccourcis clavier ou que vous ne devez pas fournir aux utilisateurs une méthode pour les découvrir, mais cela suggère que vous voudrez peut-être réfléchir à deux fois avant d'encombrer votre interface utilisateur avec des info-bulles de raccourcis clavier.
À titre d'exemple, GMail propose un grand nombre de raccourcis clavier, mais vous ne les découvrirez pas en survolant les boutons ou même en cliquant sur un lien bien visible. Pour autant que je sache, toutes les informations sur les raccourcis clavier peuvent être trouvées sur une page Web unique , et la seule façon d'y accéder est de cliquer sur Aide puis de rechercher des "raccourcis clavier" ".
Je ne dis pas que la stratégie de Google est celle que vous devez suivre, mais je pense qu'un bon point de départ serait de créer une page Web ou un fichier d'aide contenant tous les raccourcis clavier. Si de nombreux utilisateurs demandent des raccourcis, vous saurez qu'il est temps de faire quelque chose pour rendre plus évident leur existence, mais sinon, vous allez probablement bien.
J'aime la façon dont Office gère les raccourcis clavier - avec une infobulle ET de la documentation à l'appui. L'info-bulle n'est pas invasive - vous ne la voyez que lorsque vous survolez un moment sur la commande et elle est là quand vous en avez besoin.
Alternativement, si vous voulez une liste de raccourcis, vous pouvez aller dans l'aide et taper "raccourcis clavier". Pour les utilisateurs qui VEULENT les apprendre, cette option doit être là aussi.
Et je trouve également que lors de l'apprentissage d'une nouvelle application, les utilisateurs utiliseront la souris, en cliquant à gauche et à droite pour voir ce qui se passe et il est très probable qu'ils survolent les éléments de menu. Le fait d'avoir la fenêtre contextuelle du raccourci clavier leur montre qu'ils peuvent l'utiliser sans encombrer la conception de l'application.