cacher vs désactiver et redistribuer l'espace vide
J'ai une boîte de dialogue de formulaire UI complexe avec environ 12 onglets et je veux décider ce qui est le mieux:
- activer/désactiver les champs (grisés) - convention classique
- cacher/afficher si pas nécessaire - pourrait être déroutant + sauter l'interface graphique
- cacher mais montrer ensuite l'espace "vide" avec un indice, qu'il y a quelque chose de caché - comme
2.mais pas d'interface graphique sautante et plus évident
Vous pouvez voir un exemple dans ce violon . 1. est l'option B, 2. est l'option C et 3. est l'option A dans cet exemple.
Quelle serait la meilleure pratique ici?
(J'ai lu beaucoup de discussions similaires sur ce sujet mais ma question est quelque peu différente/plus de nature pratique).
EDIT: Eh bien, si la réponse n'est pas facile, peut-être des opinions sur ce que vous voyez comme plus convivial/intuitif/plus facile?
EDIT2: La question la plus similaire avec quelques bonnes réponses était masquer ou désactiver les options de formulaire et ne pas masquer ou désactiver les éléments de men
DERNIÈRE MODIFICATION: Réponse disponible mais explication sur le [~ # ~] pourquoi [~ # ~] peut être lu ici: Modèles de conception Android -> Paramètres -> Dépendance (accédez à Dependency).
Je n'ai malheureusement pas entendu parler d'une règle d'or; ce serait formidable si quelqu'un connaissait une étude. Quelques réflexions et mes expériences:
- L'utilisateur est-il intéressé à accéder simplement au champ "enfant" sans passer par un champ parent qui l'active/l'affiche? Si oui, masquer le champ peut rendre plus difficile pour l'utilisateur de savoir que l'option est disponible, et l'utilisateur ne peut pas non plus rechercher l'option en faisant CTRL + F (en supposant qu'il s'agit d'une application de navigateur). Si l'écran possède de nombreuses options, la recherche pourrait être très utile.
- S'il existe de nombreuses options sur le même écran, elles pourraient peut-être être regroupées davantage pour minimiser l'encombrement. Par exemple, vous pouvez afficher des accordéons avec des noms de groupe qui révèlent des champs associés.
- Lorsque les champs sont désactivés, il n'est pas toujours évident de savoir ce qui les active, vous devez donc faire attention à ce que les champs soient liés visuellement. L'indentation est parfois utilisée pour montrer la relation, mais l'écran peut sembler assez désorganisé lorsque le nombre de champs est grand et il est également plus difficile de numériser le texte à gauche car les champs ne s'aligneront pas. Le fait d'avoir des champs à l'état désactivé nécessite un clic supplémentaire pour les activer afin qu'ils puissent peut-être être activés par défaut et si l'utilisateur le modifie/le vérifie, le parent est également activé automatiquement. Par exemple, si vous avez l'option "Envoyer un cadeau" avec les enfants "Fleurs", "Carte", cliquer sur "Carte" active "Envoyer un cadeau".
- Considérez quelles sont les principales tâches que l'utilisateur essaie d'accomplir et exposez les champs associés. Les autres champs pourraient potentiellement être placés sous les options "Avancées".
J'ai toujours suivi les règles suivantes pour prendre cette décision:
Si une action sur l'écran/la page/la fenêtre actuelle modifie la disponibilité du champ, elle doit être désactivée/activée à mesure que les valeurs/entrées changent.
Si aucune action sur l'écran/la page/la fenêtre actuelle ne rend le champ disponible, le champ doit être masqué.
Si les informations du champ sont utiles à l'utilisateur, bien qu'elles ne soient pas modifiables, il doit s'agir d'un "champ d'affichage".
Vous avez raison de dire que le "saut de l'interface graphique" comme votre troisième exemple est choquant et déconcertant pour l'utilisateur. Si les choses doivent bouger, utilisez des animations pour transmettre clairement l'activité à l'utilisateur.
Faites de votre mieux pour repenser le regroupement afin de passer de 12 onglets à un nombre plus petit, si possible.
Cela fait-il partie d'un processus par étapes? (comme la configuration, la création d'un profil, etc.) Si c'est le cas, je pense que 3 est le nombre magique en termes de nombre total d'étapes. Pour réduire à 3, demandez-vous "ai-je vraiment besoin de ces données? ou 'ai-je vraiment besoin de ces données maintenant (puis-je les demander à un moment plus approprié lorsque l'utilisateur comprend pourquoi je les demande?').
Si cela ne fait pas partie d'un processus par étapes, essayez de regrouper les onglets en fonction des actions que l'utilisateur comprend, comme (planifier, appeler, supprimer, etc.). Ensuite, dans chaque section, montrez UNIQUEMENT les options dont vous aurez besoin la plupart du temps (comme 1 à 4 choses) et ayez un bouton appelé `` avancé '', puis fourrez tout et l'évier de cuisine derrière ce bouton.
En général, la simplicité est reine. 14 n'est pas simple à regarder, chaque onglet ayant un bazillion d'options à l'intérieur de chaque onglet n'est pas simple à regarder non plus. Depuis le début, continuez à supprimer les options jusqu'à ce que votre application ne puisse pas fonctionner 90% du temps, puis présentez les options HAUTEMENT UTILISÉES restantes avec autant d'espace mort que possible, et la majorité des options restantes derrière un bouton avancé