Les fonctions d'édition en bloc doivent-elles être masquées jusqu'à ce qu'une ligne du tableau soit sélectionnée, ou existe-t-il une meilleure solution?
Par exemple, MailChimp affiche les listes d'abonnés dans une table/grille de données. Notez que même si l'utilisateur peut sélectionner une ou plusieurs lignes à l'aide de la case à cocher à gauche de chaque ligne, il ne sait pas quelles actions peuvent être disponibles une fois la ligne sélectionnée. Aucune n'est visible:
Ensuite, il sélectionne une ligne. Notez que le bouton Supprimer est désormais visible.
Je comprends pourquoi ce modèle a été utilisé. Le concepteur estime que la suppression d'une ligne est une tâche moins courante et n'a pas besoin d'être visible à tout moment. Il est également vrai que si le bouton Supprimer était visible alors qu'aucune ligne n'était sélectionnée, cliquer dessus ne donnerait aucun résultat fonctionnel. (Le concepteur devrait présenter le bouton de manière clairement désactivée, ou proposer un message d'erreur, etc.)
Bien que je comprenne, cela ne signifie pas que je suis parfaitement satisfait.
Objections
- Manque de découvrabilité. Cela me met mal à l'aise que des catégories entières d'interactions volent sur et hors de l'écran. L'utilisateur ne voit pas quelles actions il peut effectuer sur une ligne tant qu'il n'en a pas sélectionné une. En fonction de sa familiarité avec les modèles d'interface courants, il peut même ne pas prévoir qu'une fonction cachée se révélera, et donc il pourrait se sentir peu incité à sélectionner une ligne.
- Mauvaise utilisation de la proximité. Le bouton d'action peut être très éloigné de la case à cocher, de sorte que l'utilisateur défile jusqu'en bas de la page pour sélectionner quelque chose, puis défile jusqu'à la haut de la page pour effectuer l'action.
- Mauvaise rétroaction. Peut-être que l'utilisateur a fait défiler vers le bas de la page pour faire sa sélection, et le bouton Supprimer a été éclipsé. Dans ce cas, selon la connaissance de l'utilisateur, il pourrait ne pas comprendre que quelque chose s'est produit en raison du manque de rétroaction apparente.
Les deux derniers pourraient potentiellement être atténués avec une barre d'action "collante". La proximité serait toujours un problème, mais moins.
Conclusion
Je comprends pourquoi MailChimp a utilisé la divulgation progressive comme ils l'ont fait, et j'utilise moi-même le même modèle. Cela semble encore mal à certains égards, et j'espère une meilleure solution.
Vous demandez quand vous pouvez masquer certains contrôles.
Je suis tombé sur une réponse utile à cette question qui se trouve dans le livre, Conception des deux côtés de l'écran , par Ellen Isaacs et Alen Walendowski.
Ce livre traite de la fréquence et des points communs en tant que moyen d'évaluer si une fonctionnalité doit être créée, et également de la place de la fonctionnalité dans l'interface utilisateur. L'hypothèse est que, comme un programme possède de nombreuses fonctionnalités, et qu'elles ne peuvent pas toutes être dans l'interface utilisateur principale, car en tant que concepteurs UX, nous ne voulons ni surcharger l'interface utilisateur ni submerger les utilisateurs.
Cette grille est une simplification grossière de leur idée de l'endroit où présenter les contrôles d'une fonctionnalité dans l'interface utilisateur.
Utilisez la grille pour examiner le traitement possible pour une combinaison particulière de fréquence et de similitude. Pour une nouvelle fonctionnalité, vous estimez les montants; pour une fonctionnalité existante, vous mesurez le comportement de l'utilisateur. Dans cette grille, Fréquent signifie presque chaque fois qu'ils utilisent le logiciel. Comme avec n'importe quelle directive, une autre directive peut avoir la priorité sur celle-ci, vous pouvez donc choisir de ne pas suivre cela.
Clause de non-responsabilité . Je veux répéter: la grille ci-dessus est une simplification excessive incomplète. Il y a beaucoup plus d'options et de nuances que la grille ci-dessus omet. De plus, bien que le concept de base provienne d'Isaacs & Walendowski, ce ne sont pas leurs mots, donc toutes les erreurs d'interprétation sont les miennes. :)
Voir cette idée à l'œuvre à grande échelle
Si la fréquence commune vous intéresse, je vous recommande de regarder Jensen Harris raconter l'histoire du ruban en vidéo (ou diapositives + audio uniquement), dans lequel il décrit comment Microsoft a collecté et analysé les données qui ont informé le regroupement des contrôles sur le ruban Office 2007. Même si vous n'aimez pas le ruban, la vidéo donne un aperçu fascinant de la méthode.
La modification en bloc est un outil électrique.
L'abordabilité, bien que la découverte puisse être un terme plus pertinent ici, n'est pas un gros problème car ce n'est pas le seul moyen de supprimer ou de modifier des éléments. Vous pouvez toujours explorer un élément spécifique pour le gérer. Donc, même si vous devez "l'apprendre" la première fois. Une fois que vous l'avez, ce n'est pas grave.
Rappelez-vous également qu'une interface qui permet une édition en bloc suppose que vous avez affaire à un système qui reçoit une utilisation suffisante et contient une certaine complexité dans l'ensemble de données. Sinon, pourquoi auriez-vous besoin d'une fonction de modification groupée? L'interface est désormais un outil qui, dans la plupart des cas, est utilisé régulièrement. La découvrabilité importe moins que l'efficacité.
Ce qui va à votre prochain point: enfreindre les règles de proximité.
Si le système vous fait défiler vers le haut ou le bas de la page pour effectuer des actions en masse et qu'il y a une grande quantité de données sur une page, c'est une mauvaise utilisation comme vous l'avez mentionné. Une barre d'action "collante" comme la modification en masse de Gmail est ce à quoi je suis habitué quand il s'agit de longs tableaux à défilement.
Oui, les actions groupées peuvent ne pas se trouver juste à côté des lignes sélectionnées. Cependant, les actions apparaissent toujours dans un emplacement cohérent et attendu. Et franchement, la modification en bloc est une action suffisamment spécialisée où demander à l'utilisateur de faire une action délibérée pour amener sa souris dans la barre d'action n'est pas une mauvaise idée. Les modifications groupées peuvent affecter un grand nombre d'enregistrements. L'utilisateur doit être sûr avant d'effectuer l'action.
Quant à savoir si les actions de modification en bloc doivent être masquées jusqu'à ce que les lignes soient sélectionnées ou non, cela se résume au nombre d'actions disponibles. Si vous en avez beaucoup, il est logique de les montrer contextuellement pour éviter d'encombrer l'interface, sinon vous ne le faites pas.