Placement des boutons d'action différent pour les modaux des écrans de base
Je suis en train de repenser un produit pour iPad et Windows et j'étudie actuellement la façon dont les boutons sont placés dans l'application.
Écran de base
Voici à quoi ressemble un "écran de base" générique. Rien de spécial, juste une navigation avec quelques actions alignées à droite, avec le contenu apparaissant en dessous. Le contenu est modifiable, donc lorsque vous y apportez une modification, vous devez l'enregistrer en cliquant sur le bouton Enregistrer. Enregistrement automatique au-delà de la portée de cela.
Modals
Lorsque vous cliquez sur l'un des liens dans la navigation, un petit modal apparaît, qui contient un formulaire de modification.
Conception actuelle
Actuellement, vous remplissez un formulaire ou le modifiez, puis vous acceptez ou annulez vos modifications en appuyant sur deux icônes en haut à droite du modal. Cela présente un certain nombre de limites immédiatement évidentes:
- Les icônes sont ambigües et doivent être accompagnées d'étiquettes pour clarifier le sens
- Une action destructrice (annuler) et une action constructive (complète) sont de style trop similaire (compte tenu du même niveau de visibilité) et placées trop près l'une de l'autre.
- Les actions apparaissent après le formulaire, de sorte que l'utilisateur remplit le formulaire de haut en bas, uniquement pour revenir en haut pour l'action.
Conception proposée
- Les icônes sont remplacées par des boutons qui spécifient clairement ce que chaque action fait avec une étiquette.
- Les boutons Annuler et Terminer sont séparés et désormais stylisés différemment, le plus important: l'action destructrice "Annuler" est stylisée uniquement en tant que lien, par opposition à "Terminer" qui est maintenant un bouton. Nous espérons que cela encouragera le remplissage du formulaire plutôt que l'annulation.
- Les actions sont maintenant au bas du formulaire.
Le problème
Il a été souligné qu'il semble étrange que pour les écrans de base, nous ayons nos actions avant le formulaire (le bouton Enregistrer qui enregistre le contenu en dessous) tandis que sur ma conception proposée pour les modaux, ils sont en bas.
Je vois son argument bien que la raison en soit simplement pour conserver de l'espace. Ce que ces images filaires ne reflètent pas, c'est la quantité de contenu que nous devons remplir dans un si petit endroit, donc aligner le bouton Enregistrer sur la navigation principale est logique. Si nous ne le faisions pas, nous devrions sacrifier notre zone de contenu à la place en incluant une nouvelle ligne pour accueillir un bouton de sauvegarde et peut-être un ou deux boutons de plus à l'avenir. Semble à peine en vaut la peine.
Ma question est la suivante: quelqu'un d'autre a-t-il rencontré ce problème et qu'en avez-vous fait? Ma proposition est-elle OK compte tenu de cette incohérence entre le placement des boutons sur l'écran de base et les modaux, ou doit-elle vraiment être corrigée?
Limites
- Les tests utilisateurs en ce moment sont malheureusement hors de portée.
- Doit fonctionner aussi bien pour le toucher que pour la souris.
Tous vos points concernant la conception actuelle sont absolument corrects, et je vous suggère fortement de vous en éloigner.
Avoir des boutons en bas d'un modal est une pratique courante, donc vos utilisateurs sont susceptibles d'être très familiers avec ce modèle, quelle que soit la cohérence avec votre écran de base. Si les utilisateurs ne sont pas très férus de technologie, il est toujours très naturel de faire suivre l'action après le contenu.
Si vous êtes vraiment préoccupé par l'immobilier d'écran, je considérerais une approche de "tâche ciblée", comme l'a démontré Atlassian: https://www.atlassian.design/server/patterns/focused-tasks/ =
Si votre ligne supérieure au-dessus du contenu a pour but une barre d'outils, je déplacerais le bouton "Enregistrer" vers la gauche. De cette façon, vous êtes cohérent avec la plupart des autres applications. Il est courant que l'importance des boutons de la barre d'outils diminue de gauche à droite (importance: par exemple en ce qui concerne la fréquence d'utilisation). Un exemple typique sont les applications bureautiques telles que Microsoft Office.
De plus, vous remarquerez que de nombreuses applications (par exemple Office) utilisent simultanément des barres d'outils de la manière décrite ci-dessus et des boîtes de dialogue modales comme dans votre conception proposée. Il s'agit d'une conception typique et de nombreux utilisateurs la connaissent. À mon avis, il n'est pas nécessaire d'appliquer ici la cohérence.