Reading Common web app usability gotchas? Je me suis senti coupable quand j'ai lu qu'en utilisant un target = "_blank"
est un mauvaise chose .
J'ai développé une petite application Web qui formate les questions Stack Exchange dans une vue imprimable et je pense qu'il y a quelque chose de cassé dans l'interface à propos de target = "_blank"
expérience de navigation.
Laisse-moi expliquer:
Je pense qu'il n'y a rien de mal à cela (bien que toute rétroaction soit appréciée).
target = "_blank"
)Pourquoi j'ai fait ça?
Première raison:
La fonction "imprimer" de Gmail fonctionne comme ceci (ouverture d'une nouvelle page)
Deuxième raison:
Parce que je voulais donner la possibilité d'imprimer un tas de questions en même temps.
Avec une séquence comme print - back to the "questions page" - print - back to the "questions page" - print etc. etc.
l'utilisateur pourrait imprimer ses questions en parallèle (le processus d'impression n'est pas très rapide sur les grosses questions comme celle-ci ).
Je pense qu'il y a quelque chose de cassé parce que:
1. L'expérience du premier cas est différente de la seconde
2. Une fois que de nouvelles fenêtres "imprimables" sont ouvertes, les gens ont la même icône "retour à la maison" dans le coin supérieur gauche et je pense que cela pourrait prêter à confusion.[fixé]
Toute suggestion?
Je ne suis pas d'accord avec l'idée que target="_blank"
est toujours mauvais. Dans certains cas, en particulier dans les applications Web, cela peut être très utile, comme dans la situation que vous décrivez ci-dessus. (Et j'ai également rencontré une race de concepteurs de sites Web qui le détestent simplement parce que la dernière spécification du W3C dit que c'est illégal ...)
La raison pour laquelle les concepteurs d'interface utilisateur ne l'aiment pas est parce qu'elle enlève le contrôle à l'utilisateur, ce qui est ennuyeux - sur les sites Web. C'est parce que vous contrôlez votre expérience de navigation, et lorsque vous êtes navigation, par exemple. en lisant un article, vous ne voulez pas que des sites Web ouvrent de nouveaux onglets ou de nouvelles fenêtres chaque fois que vous cliquez sur un lien. Vous déciderez cela par vous-même.
Mais lorsque vous utilisez une application Web, en particulier ces jours-ci, les applications Web devenant de plus en plus compliquées (Gmail en est un bon exemple), l'utilisateur est dans un état d'esprit différent et souhaite une commodité centrée sur l'utilisation de l'application Web. Je ne dis pas target="_blank"
est une solution parfaite, mais ce n'est certainement pas aussi terrible qu'il est fait pour sonner dans la question "gotchas".
Comme d'habitude, il s'agit de comprendre ce que vos utilisateurs en pensent. En tant que concepteur, vous devez prendre des décisions basées sur ce que vous jugez le mieux pour votre base d'utilisateurs, et essayez de ne pas trop dépendre de "règles" universelles qui semblent s'appliquer à tout, toujours. Les conventions et les modèles sont excellents, mais il est important que vous gardiez un esprit ouvert et que vous fassiez preuve de bon sens le cas échéant. :)
Ce n'est pas directement lié à votre question, mais voilà ... Une chose qui m'a toujours dérangé avec les boutons "Imprimer" est que vous ne savez jamais si cliquer dessus s'imprimera réellement ou s'il vous montrera une mise en page imprimable . Je n'ai vu qu'un ou deux sites Web qui ont étiqueté leur bouton "Afficher la page imprimable" (ou quelque chose comme ça).
Je ne suis pas d'accord avec la nécessité d'avoir un bouton convivial pour imprimer une page différente du tout. En utilisant CSS, vous pouvez masquer toutes les choses que vous ne souhaitez pas imprimer et apporter les modifications souhaitées. Par conséquent, presque toutes les pages peuvent être imprimables par défaut. La seule véritable exception concerne les listes paginées où vous souhaitez imprimer la liste complète.
http://www.w3.org/TR/CSS21/media.html
Je pense que même lorsque vous utilisez css pour rendre les pages imprimables, vous devriez toujours avoir un bouton Imprimer sur la page, mais tout ce qu'il doit faire est d'appeler directement la fonctionnalité d'impression du navigateur. Le fait est que la plupart des utilisateurs ne sont pas habitués à ce que la fonctionnalité d'impression du navigateur fonctionne très bien et qu'un bouton Imprimer sur la page offre une sortie plus propre.
Je pense que les utilisateurs devraient avoir un aperçu de ce qui sortira réellement de leur imprimante. Cela pourrait être moins nécessaire dans le cas d'un bouton "Imprimer cet article" et la page transformée dans ce cas pourrait également être directement transférée vers l'imprimante si possible.
À propos de l'ouverture d'une nouvelle fenêtre Je pense qu'une fenêtre modale (a la safari reader) est toujours le meilleur choix, car elle concentre l'attention de l'utilisateur sur la fenêtre elle-même et est très facile de voir comment la fermer, et cela en la fermant l'utilisateur reviendra à l'état précédent de l'application (la page grisée en arrière-plan), même si les données sont mises à jour en temps réel, il serait clair, étant donné qu'elles sont affichées quelque part dans l'interface utilisateur, quelle est la mise à jour de la page en cours d'impression.
Quoi qu'il en soit, il n'est pas facile de trouver des solutions optimales pour ce type de problème particulier.
Je ne peux pas être plus d'accord avec Rahul, en particulier sur le dernier paragraphe. Dan Saffer dans son livre "Designing for Interaction" appelle ce Genius Design où les concepteurs utilisent leur meilleur jugement quant à ce que veulent les utilisateurs, puis conçoivent en fonction de ce jugement.
L'imprimante ne l'est jamais. Je ne sais pas pourquoi il doit en être ainsi.
Ce que vous pouvez faire est de rendre la page sur le serveur avec wkhtmltopdf (en utilisant vos propres feuilles de style, polices préférées et images SVG comme requis pour les logos haute résolution), puis servez-le avec la boîte de dialogue d'impression - pas d'aperçu absurde, juste PDF directement sur l'imprimante, pas de _blanc ou quoi que ce soit du genre. De cette façon, vous pouvez contrôler la mise en page et la mettre aux normes du "catalogue", et éviter à votre utilisateur l'étape supplémentaire de devoir imprimer bouton.
Laissez votre bouton d'impression "faire ce qu'il dit sur l'étain".
Purement mon opinion ne s'appuie sur aucune recherche spécifique:
"Print Friendly" est préférable à "Print" pour un certain nombre de raisons:
En tant que tel, je préfère avoir à la fois un fichier CSS d'impression approprié ainsi qu'un lien "convivial".
Quant à savoir s'il devrait s'ouvrir dans une nouvelle fenêtre ou non… c'est difficile. De nouvelles fenêtres introduisent toujours des problèmes de convivialité et d'accessibilité. Je pencherais pour le charger dans la même page avec une sorte de lien évident de "retour à la version Web".
Suis-je incompris ou faites-vous faire des va-et-vient à vos utilisateurs chaque fois qu'ils souhaitent ajouter une question à une seule commande d'impression? Si oui, vous devriez vraiment penser à une meilleure façon d'accomplir cela. Quelque chose comme un bouton "Ajouter à la liste d'impression" qui stocke une liste des identifiants de questions et formate tout pour l'utilisateur final lorsqu'il clique sur "Imprimer ma liste de questions". Faire des allers-retours entre les écrans comme ça serait très frustrant pour moi.
Désolé si j'ai mal compris ce que vous dites là-bas.