L'invite, la confirmation et l'alerte de JavaScript sont considérées comme «à l'ancienne» [fermé]

Dernièrement, j'ai développé un système de gestion basé sur le Web pour un gymnase. Leur précédente application a été développée en Visual Basic. Pour la nouvelle application, tous les scripts frontaux utilisent jQuery, le serveur exécute PHP et MySQL ... vous savez, la pile basée sur el-cheapo linux typique.

Quoi qu'il en soit, je me demandais pourquoi les boîtes de dialogue d'invite, de confirmation et d'alerte de JavaScript sont si sous-utilisées de nos jours. Il existe de nombreux plugins jQuery pour les fenêtres modales et les messages d'alerte qui tentent d'imiter quelque chose que la langue propose déjà et chaque navigateur est obligé de prendre en charge correctement.

L'utilisation de solutions faites à la main ou basées sur des plugins est acceptable pour les formulaires complexes et les besoins spéciaux, mais si vous avez juste besoin de demander une valeur unique ou de confirmer la suppression d'un enregistrement, pourquoi ajouteriez-vous une telle surcharge à votre application Web? De plus, iOS et Android offrent des boîtes de dialogue de messages bien adaptées lorsque vous utilisez l'invite, la confirmation et l'alerte.

1. UX: les boîtes de message sont surtout maléfiques

Les boîtes d'alerte sont mauvaises dans tous les cas du point de vue UX. Dans les applications de bureau. Dans les applications Web sous forme d'alertes ou de messages JavaScript en ligne. Partout.

Vous pouvez lire About Face 3 par Alan Cooper¹ si vous voulez savoir pourquoi; il explique très bien comment cela interrompt le flux de travail et agace l'utilisateur, et comment presque chaque boîte d'alerte qui existe dans le logiciel actuel est profondément erronée . À la page 542, «La boîte de dialogue qui criait« Loup! »» Explique que les boîtes d'alerte sont systématiquement fermées, de sorte que leur modèle est complètement rompu. À la page 543 du livre sont énumérés trois grands principes de conception:

• Faites, ne demandez pas.
• Rendez toutes les actions réversibles.
• Fournissez des commentaires non modaux pour aider les utilisateurs à éviter les erreurs.

Ensuite, les auteurs nous expliquent comment remplacer les boîtes d'alerte par la bonne approche de conception.

Les messages d'invite sont légèrement différents. Et pourtant, ils brisent l'expérience utilisateur de votre application. Si vous souhaitez que l'utilisateur saisisse quelque chose, envisagez d'utiliser une zone de texte ou une zone de texte, en le décorant avec JavaScript en cas de besoin. Ne soyez pas paresseux, offrez une interface riche à l'ère des applications compatibles RIA et AJAX ; dans tous les cas, si JavaScript est désactivé, votre invite ne s'affichera pas.

Dans les pages Web, les boîtes d'alerte et les invites sont généralement ennuyeuses. Quelques exemples:

1. Certains forums vous permettent de créer des listes en vous demandant à l'infini les éléments de la liste. Cela signifie que lors de la création de la liste, vous ne pouvez pas utiliser la page elle-même, y compris le copier-coller. Vous avez également un seul petit champ. Et le texte long? Qu'en est-il du gras et de l'italique?

2. "Si vous continuez, la photo sera définitivement supprimée de votre profil. Êtes-vous sûr?" . Bien sûr que j'en suis sûr! Dois-je cliquer sur "Supprimer la photo de mon profil" sinon? Pourquoi votre application web suppose-t-elle que je suis si stupide? En fait, les applications Google comme GMail montrent la bonne approche. Vous pouvez supprimer, supprimer, détruire tout ce que vous voulez, et lorsque vous le faites, l'application affiche un petit lien "Annuler".

3. "Voulez-vous participer à notre plus grande enquête?" . Eh bien, en fait, j'étais là pour visiter votre site Web, mais comme vous me dérangez avec vos messages ennuyeux, je préfère aller ailleurs.

4. "Le clic droit est désactivé sur ce site Web afin de protéger les photos protégées par le droit d'auteur" . Eh bien, en fait, j'ai fait un clic droit pour changer la langue du correcteur orthographique avant d'envoyer mon commentaire. Bien sûr, je vais l'envoyer sans vérifier l'orthographe.

Conclusion: du point de vue de l'expérience utilisateur, les applications utilisent la plupart du temps des boîtes de message à tort.

Mais attendez! De nombreux sites Web de mauvaise qualité remplacent les boîtes d'alerte ennuyeuses par des messages JQuery ennuyeux avec un arrière-plan semi-transparent qui couvre toute la page. Les inconvénients subsistent donc.

Eh bien, il y a une autre raison de ne pas utiliser de boîtes de message dans les applications Web:

2. Conception: les boîtes d'alerte ont leur propre conception

Vous ne pouvez pas du tout concevoir une boîte d'alerte. Vous ne pouvez pas changer sa couleur, sa taille, sa police. Cela rend encore plus ennuyeux pour l'utilisateur: vous travailliez avec une application Web et votre flux de travail est interrompu par un message qui semble venir de nulle part et ne correspond même pas à l'aspect visuel de l'application. Sans compter que la langue des boutons correspond également à la langue du système d'exploitation / navigateur, pas celle de l'application Web.

Pour les concepteurs, les messages JavaScript sont beaucoup plus puissants que les boîtes d'alerte.

Ils sont également beaucoup plus étendus. Vous pouvez ajouter du gras et de l'italique, vous pouvez choisir vos propres boutons (qu'en est-il: "Nous nous excusons mais le mot de passe que vous avez entré n'est pas valide. [Réinitialiser mon mot de passe] [Essayez un autre] [Annuler]"?) ².

3. JavaScript: le flux d'application s'arrête

Lors de l'affichage d'une boîte d'alerte, JavaScript cesse de s'exécuter jusqu'à ce que l'utilisateur clique. Sur un site Web, cela pourrait être correct. Avec une application web, cela devient souvent un problème.

4. Sandbox: ne forcez pas l'utilisateur à redémarrer son ordinateur

Rappelez-vous les sites Web de merde qui vous montrent un nombre infini de boîtes de message ? Le seul moyen pour les utilisateurs sans connaissances techniques suffisantes de pouvoir continuer à travailler était en fait de redémarrer leur ordinateur. Cela nous amène à un problème: les boîtes d'alerte sont hors de portée du site Web ou de l'application Web. Vous n'êtes pas autorisé à empêcher l'utilisateur d'accéder à d'autres onglets du navigateur³.

Le même problème a forcé les navigateurs à le résoudre de différentes manières. Firefox, par exemple, permet d'accéder à d'autres onglets lors de l'affichage d'une alerte sur votre onglet. Chrome, d'autre part, vous permet de vérifier que vous ne souhaitez plus obtenir de boîtes d'alerte à partir d'une page, mais bloque toujours l'accès aux autres onglets.

Bien que l'approche de Firefox soit parfaitement valide, celle de Chrome peut être critiquée (car elle bloque toujours tous les onglets) et pose un problème: que se passe-t-il si l'utilisateur était gravement ennuyé par plusieurs boîtes de message émises par votre application et vérifié le cas, puis, vous essayé de montrer quelque chose de vraiment important? Bon, l'utilisateur ne le verra jamais.

Le fait reste le même, la plupart des utilisateurs seront ennuyés par les boîtes d'alerte, ils ne sont donc pas très conviviaux et peuvent bloquer sévèrement un utilisateur n'ayant pas suffisamment de connaissances techniques. En ligne, les messages JavaScript peuvent bloquer la page, mais pas le navigateur lui-même. Étant donné que le modèle d'application Web est une sorte de sandboxing, où vous ne pouvez pas par exemple accéder au clavier de l'utilisateur ou redémarrer l'ordinateur ou lire des fichiers depuis le disque dur ou passer en plein écran ou utiliser deux moniteurs, les boîtes d'alerte avec leur effet de blocage se brisent gravement. modèle de bac à sable .

Enfin et surtout, que se passe-t-il si l'utilisateur était sur un autre onglet lorsque votre application a décidé d'afficher la boîte d'alerte? Et si l'utilisateur faisait quelque chose d'important et ne veut pas interagir avec votre application pour le moment?

^{¹ À propos de Face 3, The Essentials of Interaction Design , Alan Cooper, Robert Reimann et David Cronin, ISBN 978-0-470-08411-3; Chapitre 25: Erreurs, alertes et confirmations.}

^{² Ceci n'est qu'un exemple. S'il vous plaît, ne le faites pas dans vos applications Web, car c'est vraiment un mauvais choix de conception.}

^{³ Si vous voulez une comparaison avec le monde des applications de bureau, un message JavaScript en ligne est comme une boîte de message d'une application de bureau. Une boîte d'alerte dans un navigateur, d'autre part, est comme une fenêtre apparaissant de nulle part, définie comme la plus haute, sur un fond opaque en plein écran qui vous empêche d'accéder à toute autre application de bureau. Toute application qui décidera de le faire une fois sur mon ordinateur sera supprimée immédiatement et pour toujours.}

Conclusion: les boîtes de dialogue d'invite, de confirmation et d'alerte par défaut correspondent au style de votre navigateur et non au style de votre site. La plupart des utilisateurs de l'interface utilisateur souhaitent que toutes les boîtes de dialogue correspondent à l'interface utilisateur de leur site. Ils utilisent des fenêtres modales pour présenter des messages et collecter des données en utilisant les mêmes polices et couleurs que l'interface utilisateur du site, pas le gris et le bleu par défaut de MSIE ou FF.

Vous ajoutez des frais généraux uniquement si vous n'avez pas besoin des boîtes de dialogue sophistiquées ailleurs, ce que vous faites probablement. À ce stade, cela ne fait pas beaucoup de différence que la fonctionnalité soit incluse dans le navigateur ou dans le cadre que vous utilisez, et vous pouvez aussi garder toutes vos fenêtres contextuelles cohérentes.

Bien que vous puissiez faire beaucoup avec javascript et sans framework, je me souviens de ce que c'était que de développer en javascript avant que les frameworks ne soient disponibles, et je ne voudrais pas y revenir.

Parce que les navigateurs ne les gèrent pas très bien . Comme vous l'avez peut-être remarqué, ce sont généralement des boîtes de dialogue modales et non seulement empêchent les utilisateurs de déplacer et de redimensionner leurs navigateurs, mais également d'empêcher l'accès à d'autres onglets, ce qui est très ennuyeux.

Pour les boîtes de dialogue comme confirmer et modifier, je pense toujours que le navigateur devrait appliquer le comportement, et pour le dernier navigateur Firefox, vous pouvez voir qu'ils ont résolu le problème que j'ai mentionné ci-dessus. Ils utilisent dans les alertes de page qui sont étendues à la page actuelle.

Par conséquent, je vous suggère de remplacer le comportement d'alerte afin que tous les navigateurs puissent gérer (au moins les alertes) plus élégamment.

Quelques raisons résumées:

• Il s'agit de l'API standard et les développeurs peuvent comprendre ce que vous essayez de faire.
• Il est plus convivial et plus esthétique.
• Prise en charge de la plate-forme, les sites mobiles peuvent avoir besoin de l'API native.