Quand une interface utilisateur modale est-elle acceptable?

Question

De manière générale, les interfaces modales aspirent les gros rochers. D'autre part, je ne vois pas de meilleur moyen de gérer Fichier ouvert ... ou Imprimer ... , et je pense que c'est parce que

• ce sont des actions occasionnelles, peu fréquentes et importantes, et
• ils sont de nature atomique; soit vous finissez de spécifier toutes vos options d’impression et vous y passez, soit vous annulez la totalité du spectacle.

Élaborons un petit guide de style. Suggérez des cas d'utilisation dans lesquels une boîte de dialogue est la présentation préférée et pourquoi. Le dialogue peut-il être non modal? Si c'est le cas, comment marquez-vous les limites des transactions, puisque Annuler cesse d'avoir une signification claire. Utilisez-vous un bouton Appliquer, par exemple?

Answer 1

IMO, les interfaces modales ne doivent être utilisées que lorsque vous POUVEZ gérer ce que le dialogue fait ou demande avant que l'application ne puisse continuer. À tout autre moment, si vous utilisez une boîte de dialogue, celle-ci doit être non modale.

Answer 2

Lorsque vous faites des fenêtres non modales, vous pouvez vous assurer qu'elles sont uniques: vous ne voulez pas vraiment deux boîtes à outils identiques (dans un programme graphique par exemple) ou deux boîtes de dialogue de préférences identiques (je l'ai vu dans un produit), ce qui peut être déroutant au mieux.

D'un autre côté, j'apprécie qu'une boîte de dialogue Rechercher / Remplacer ne soit pas modale: je peux revenir au document et annuler la dernière modification, passer à un autre point, etc. sans perdre les paramètres actuels.

D'une manière ou d'une autre, les boîtes de dialogue modales indiquent à l'utilisateur d'arrêter tout le reste et de terminer ce que vous faites, ce qui a ses utilisations, comme indiqué dans Réponse de Stephen Wrighton .

Answer 3

Selon mon expérience, très peu de choses devraient être modales dans une interface utilisateur. Eclipse est l’un des meilleurs exemples, et probablement très familier des utilisateurs du site. Bien qu'il y ait des dialogues modaux, et je ne parle que de l'EDI principal, ils appartiennent en grande partie à trois catégories: opérations sur les fichiers, dialogues de préférences et dialogues de paramètres.

Les dialogues de préférence, bien que modaux par tradition, ne sont pas nécessairement modaux. Tout ce que vous avez à faire est de regarder le modèle de préférences Mac OS, dans lequel les modifications de configuration ont lieu immédiatement, avec un comportement modal introduit uniquement dans les cas où les modifications pourraient perturber le travail en cours.

En bref, voici ce que je dirais comme un bon résumé de ce qui devrait être modal. Les exceptions à cet ensemble devraient être bien justifiées par l'usage.

• Boîtes de dialogue de saisie de paramètres (exemple: assistants de refactorisation. anti-exemple: boîtes de dialogue de recherche)
• Opérations sur les fichiers
• Confirmation d'une action ayant un effet perturbateur immédiat

Answer 4

Qu'en est-il d'une fenêtre de connexion utilisateur, vous ne pouvez pas (ou ne devriez pas) utiliser le reste d'une application tant que vous n'êtes pas connecté, en supposant qu'une sécurité est nécessaire.

Answer 5

Je pense que la distinction est la suivante: si un utilisateur peut faire quoi que ce soit dans l'application alors que la boîte de dialogue est affichée, elle ne devrait pas être modale. Cela inclut les actions copier / coller. Personnellement, je préférerais que les dialogues Fichier / Ouvrir et Imprimer ne soient pas non plus modaux. Je pense que les dialogues modaux sont un signe de conception faible, un mal nécessaire pour sortir rapidement le code.