Pourquoi les boîtes de dialogue "sur la page" de type Gmail ne sont-elles pas des solutions d'interface utilisateur plus populaires?
Il y a quelques mois, Gmail nous a donné le choix de passer à une nouvelle interface utilisateur, avec de nombreuses nouvelles fonctionnalités (...) dont une fenêtre "on-page-docked". Personnellement, je trouve cette partie de l'interface utilisateur très utile car elle permet aux utilisateurs d'interagir avec le reste de la page et ne me semble pas aussi envahissante qu'un modal classique.
Pourquoi ce type d'interface n'est-il pas plus populaire dans les applications Web?
Nous avons effectué des tests utilisateurs internes sur notre application et les résultats ont montré que 90% des utilisateurs trouvaient l'interface de fenêtre "sur la page ancrée" pour:
- être plus rapide à traiter (charge cognitive plus faible) et plus rapide à utiliser
- créer moins d'interruptions visuelles
Je ne peux pas commenter les résultats de vos tests utilisateur car je ne connais pas vos paramètres et votre scénario.
Mais parlons de la nouvelle méthode de saisie des e-mails de gmail. L'avantage des applications de courrier électronique de bureau sur celles basées sur le Web était, tandis que en composant le courrier électronique (dans une fenêtre séparée), vous pouviez parcourir librement les anciens courriels et rechercher le contenu que vous souhaitiez peut-être consulter. (C'était possible dans la messagerie Web en utilisant différentes fenêtres, mais n'était pas très propre). Avec la nouvelle méthode de courrier électronique ancré, vous pouvez continuer à taper votre message et parcourir également d'autres contenus.
En outre, c'est assez similaire à ce que fait Facebook. Si vous regardez le libellé, il est écrit "Message" et non par e-mail. Lentement et progressivement, le courrier électronique est fusionné avec le chat. Le mécanisme de stockage est le même pour le chat et le courrier. Sur facebook, un message et un mail, c'est la même chose. Lorsque vous utilisez le chat ou le client de messagerie pour contacter la personne, ils se retrouvent dans la boîte de réception des messages.
Pour répondre à la question de savoir pourquoi ce n'est pas une solution d'interface utilisateur populaire, vous devez vous demander, dans quels scénarios est-ce une bonne solution? La réponse est quelque chose comme le multitâche: se concentrer sur une tâche tout en gérant les autres dans la même vue. Selon vous, combien de services ont besoin d'une telle fonctionnalité? De nombreux services utilisent déjà des fenêtres contextuelles pour obtenir des résultats similaires.
Si utilisé à bon escient, cela équivaudra à beaucoup de frais généraux cognitifs pour l'utilisateur. Sur une application rationalisée, cela a du sens (comme gmail).
Les dialogues sont ( pas modaux , donc on peut composer plusieurs mails en parallèle en cliquant sur Compose encore. Tous les mails composés en parallèle sont enregistrés automatiquement dans les brouillons, ils sont non arrimables et minimisable dans la fenêtre, donc on peut toujours parcourir et répondre aux e-mails entrants dans la vue "conversation" également de style GMail .
Comme vous le voyez, ces boîtes de dialogue sont assez puissantes. La raison pour laquelle ils n'apparaissent pas dans d'autres applications pourrait être que le fait de travailler sensible aux interruptions sur tâches parallèles dans une application est souvent un scénario pour les utilisateurs expérimentés rarement nécessaire. D'un autre côté, je ne connais aucun site ou application ayant cette forme de dialogue avant Gmail. Si je me souviens bien, GMail les a reçues vers octobre/novembre 2012, il y a à peine six mois. Peut-être que Google vient d'inventer ces dialogues et que l'idée ne s'est pas encore propagée à d'autres applications.
Répondant à votre question " Pourquoi cela n'est-il pas utilisé plus largement? ", je pense que cela n'a pas seulement à voir avec Google étant le premier à le faire et faites-le bien, mais aussi avec technologie.
Nous avons des applications Web qui utilisent toujours des tableaux pour les données non tabulaires, des applications qui n'ont pas changé depuis des années. Une boîte de dialogue comme celle-ci nécessite au moins du Javascript. La reconception d'une application Web est un problème suffisamment complexe, je suppose que l'ajout de fonctionnalités `` modernes '' (avec beaucoup de '') peut ne pas être considéré comme une priorité absolue pour certaines entreprises. C'est une zone de confort qui existe peut-être depuis trop longtemps.
Un autre aspect qui n'a pas été abordé est le fait que de nombreux concepteurs abordent désormais les choses "en priorité sur le mobile" et sont beaucoup plus sensibles à la conception réactive. Le client de messagerie de Gmail est décidément un produit de bureau: il repose sur de grandes fenêtres et pour résoudre bon nombre des défis de l'interface utilisateur répertoriés par d'autres répondeurs, ils ont besoin de cet espace pour garantir que les utilisateurs peuvent accomplir d'autres tâches en même temps. Mais la conception pour un petit écran implique des tâches à foyer unique: basculer constamment entre deux contextes n'est pas du tout optimal pour l'attention de l'utilisateur. Les concepteurs qui sont influencés par la conception mobile réfléchissent donc davantage aux interactions à objectif unique et ne bénéficient donc pas de l'interface utilisateur et du défi technique de la construction de ces boîtes de dialogue de même fenêtre.
Il y a une grande limite aux dialogues sur la page: ils vont toujours couvrir une partie de la page.
Contrairement à deux fenêtres réelles, votre dialogue ne peut pas être déplacé en dehors du chrome du navigateur. Vous ne pouvez pas les déplacer côte à côte (comme la fonction d'accrochage dans Windows), par exemple. Cela couvrira toujours quelque chose, quelque part. On peut dire que cela peut être plus ennuyeux que d'ouvrir le dialogue dans son propre onglet ou fenêtre - Gmail n'est pas mobile (sauf en minimisant), tout ce qui se trouve en dessous ne peut pas être lu sans essayer de redimensionner et de faire défiler votre navigateur pour voir le contenu caché . L'utiliser pour écrire un e-mail tout en en référençant un autre ne fonctionne que si vous n'êtes pas intéressé par la moitié droite des derniers paragraphes, ou si vous vous contentez de le réduire/le restaurer à plusieurs reprises.
Vos raccourcis et outils de bureau standard ne s'appliquent pas non plus - vous ne pouvez pas alt-tab la boîte de message dans le "fond". Cliquer et faire glisser l'en-tête ne le déplace pas, il minimise simplement. Le fait de devoir ramasser la souris lorsque vous vous concentrez sur une tâche de frappe est toujours maladroit et interruptif - je suis sûr que Google a probablement ajouté des raccourcis clavier pour minimiser/fermer la fenêtre de composition, mais comme ce ne sont pas ceux que vous utilisez Pour cela, cela signifierait trouver les documents d'aide et les rechercher. Que la plupart des utilisateurs (et moi) ne seront pas gênés de rechercher.
En fin de compte, l'approche standard (nouvel onglet/nouvelle fenêtre de navigateur) est beaucoup plus facile à mettre en œuvre et plus familière aux utilisateurs finaux.