Pourquoi les dialogues d'alerte / confirmation sont-ils mauvais pour le Web mobile?
Je travaille actuellement sur une application Web mobile avec des concepteurs externes, mais nous (les développeurs) sommes autorisés à participer. Ils veulent toujours ajouter des dialogues d'alerte et de confirmation pour des choses comme la validation de formulaire, la déconnexion, la suppression de choses, etc., ce qui soulève des drapeaux rouges UX pour moi - ils semblent juste mal sur les applications Web mobiles pour une raison quelconque et je ne peux pas identifier exactement pourquoi .
Pire encore, ils continuent de demander des choses que alert() et confirm() ne peuvent pas faire, comme utiliser "Supprimer/Annuler" ou "Oui/Non" au lieu de la valeur par défaut "OK/Annuler" ou désactivez la case à cocher "Empêcher cette page Web de créer une boîte de dialogue supplémentaire" qui apparaît sur les navigateurs modernes. La seule façon de le faire, bien sûr, est de créer des boîtes de dialogue personnalisées, ce qui soulève encore plus de drapeaux rouges.
Existe-t-il des recherches ou des articles faisant autorité sur les raisons de cette situation? Ou suis-je en train de devenir fou?
Jetez un œil à cette directive UX/Design de Google sur la confirmation et la reconnaissance:
http://www.androiddocs.com/design/patterns/confirming-acknowledging.html
Bien que la directive concerne les applications mobiles, le principe et l'organigramme mis en évidence dans la directive peuvent vous aider, vous et votre équipe, à décider quand et quand ne pas utiliser les alertes et confirmer la boîte de dialogue.
En règle générale, vous devriez considérer l'utilisation des boîtes de dialogue de confirmation en dernier recours. Ils interrompent le déroulement de la tâche pour les utilisateurs qui comprennent le système. Les dialogues sont souvent confus par les utilisateurs ou pas du tout lus. Décidez d'abord si quelque chose d'important se produira. Si tel est le cas, déterminez si la fonction d'annulation peut être développée.
Je ne pense pas que les dialogues d'alerte/confirmation soient mauvais, dans le Web mobile ou dans d'autres contextes. Lorsque l'utilisateur doit confirmer une opération importante, comme supprimer quelque chose, il sera heureux d'avoir la possibilité d'annuler cette opération. Mais lorsque vous parlez de validation de formulaire ou de déconnexion, il est étrange de demander une confirmation pour ces choses. La déconnexion est-elle permanente? Puis-je simplement me reconnecter si j'ai cliqué sur le lien par erreur?
Je n'ai donc aucune source pour répondre à votre question mais je pense que vous pouvez vous demander: qui aime confirmer le dialogue? Personne, confirmez que les dialogues ne font que vous distraire, vous ou vos utilisateurs, de faire des choses réelles. Mais lorsque vous devez demander une confirmation à l'utilisateur, c'est la solution parfaite.
Vous posez spécifiquement des questions sur mauvais pour le Web mobile, et la plupart des réponses ne semblent pas en parler (ils ont tendance à se demander si les fenêtres contextuelles sont intrinsèquement mauvais, et suggèrent principalement que le même argument s'applique au mobile ou desktop 1 ).
Pour moi, le plus gros problème avec les alertes pop-up ou les confirmations sur un mobile est quand elles (ou ne peuvent pas en raison de l'espace) montrent suffisamment le contexte à propos de ce qu'ils demandent pour permettre à l'utilisateur de répondre à la question à partir du pop-up seul.
Dans une certaine mesure, cela est vrai à la fois sur les ordinateurs de bureau et les mobiles. Cependant, le problème est considérablement amplifié sur un mobile:
Sur un bureau, si vous voyez une fenêtre pop-up qui vous demande " Êtes-vous sûr de vouloir supprimer cet élément" vous pouvez souvent soit voir facilement à quoi élément auquel il fait référence, ou peut déplacer la boîte de dialogue pour que vous puissiez.
Sur un mobile, vous ne pourrez souvent pas voir suffisamment de l'écran principal pour voir à quoi il fait référence, ni assez d'espace pour que vous puissiez déplacer la boîte de dialogue "hors du chemin".
Pour les cas simples, la solution consiste à inclure suffisamment de contexte dans la boîte de dialogue pour permettre à l'utilisateur de prendre la décision. Par exemple, notes de Google sur les confirmations lié dans une autre réponse touche indirectement à cela, mais n'attire pas vraiment l'attention dessus. Leur dialogue final inclut le titre sur le point d'être supprimé:
Cela contient suffisamment d'informations pour ne pas avoir besoin de voir l'écran sous-jacent.
Le problème survient lorsqu'il y a pas assez d'espace pour résumer l'action en cours de confirmation. Par exemple, si au lieu d'un seul livre, l'utilisateur avait sélectionné 12 livres à supprimer. Une boîte de dialogue sur un mobile ne sera probablement pas en mesure de lister tous les titres de manière lisible, donc vous devrez probablement vous contenter de " Voulez-vous vraiment supprimer les 12 titres sélectionnés". L'inclusion du nombre de titres permettra à l'utilisateur de reconnaître la gravité de l'action: s'il n'est pas sûr à 100% (ou pensait ne supprimer que deux éléments), il peut au moins annuler et revoir l'écran principal.
C'est à ce stade qu'il peut être préférable de trouver des alternatives aux confirmations contextuelles (par exemple en s'assurant que ces suppressions sont réversibles).
1
Je serais d'accord avec votre affirmation selon laquelle l'utilisation native de
alert()ouconfirm()est presque toujours mauvaise pour les raisons que vous citez: aucun contrôle sur ce que disent les boutons; aucun contrôle sur les effets de " Empêcher cette page Web ...". Cependant, je ne serais pas d'accord pour dire que les boîtes de dialogue "personnalisées" sont un "drapeau rouge" (si vous ne pouvez pas utiliser les boîtes de dialogue "intégrées", vous avez pour utiliser des boîtes de dialogue personnalisées). Cependant, tout cela est aussi vrai sur mobile que sur ordinateur.La surutilisation des alertes peut être intrusive, mais en soi ne sont pas plus intrusives sur un mobile qu'un ordinateur de bureau (si quoi que ce soit, en raison de la plus petite taille de l'écran, il est souvent plus facile de rejeter une pop mobile -up que sur un bureau).