Comment afficher plusieurs options pour la page des paramètres à l'aide d'icônes?
Question
Pour une application mobile, comment afficher plusieurs options (disons, 20 options sont disponibles) dans une page de paramètres à l'aide d'icônes?
Exemple:
Fig.1: Toutes les options dans une activité d'écran unique
Toutes les options sont présentes dans une activité d'écran (accessible en faisant défiler vers le haut/bas si elles ne peuvent pas tenir dans un écran). Les options peuvent être triées d'une certaine manière (par exemple, alphabétique, fréquence d'utilisation, catégorie, etc.).
Fig.2: Cinq options les plus fréquemment utilisées.
Certaines options sont masquées. Seules les cinq principales options, les plus fréquemment utilisées, sont visibles à partir de ce panneau principal. Pour accéder aux options de repos, les utilisateurs doivent parcourir les pages de configuration (par exemple en cliquant sur le bouton "Autres options" et en chargeant différentes activités d'écran dans lesquelles les options de repos sont présentes dans Fig.1 façon).
Fig.3: Disposition à deux niveaux.
L'utilisateur sélectionne d'abord la catégorie pertinente, puis il/elle atteint les options exploitables qui sont associées à la catégorie.
Remarque:
L'exemple de tableau de bord ci-dessus ne réside pas techniquement dans un environnement intégré à l'application. Mais, c'est le meilleur exemple que je puisse donner pour l'instant. Je veux que cette question soit strictement limitée à la page Paramètres et configurations de l'application.
Quelques pensées
Avoir plus de 4 (5 au maximum) des éléments dans un cluster est une mauvaise idée car après 4 éléments, votre esprit doit brûler une attention supplémentaire pour comprendre "ce qui se passe". Se concentrer sur l'icône est facile quand ils sont peu nombreux mais en grand nombre ils deviennent un fardeau cognitif. Avoir 20 icônes ensemble est bien trop loin d'être une expérience utilisateur décente.
La fréquence d'utilisation est l'un des aspects clés qui vous aident à décider. Avoir "Section favorite" ou "Section fréquemment utilisée" en plus de "Ensemble standard" est un fardeau d'apprentissage supplémentaire et peut-être une fonctionnalité trompeuse. Étant donné que cette section continuera de placer les icônes dès votre première utilisation, l'utilisateur cliquera sur certaines icônes et l'application les mettra en "fréquemment utilisé" car il aura une utilisation = 1 tandis que d'autres icônes auront une utilisation = 0 mais pratiquement celles préférées et les sections fréquemment utilisées peuvent ne pas être "fréquemment utilisées" à moins que l'utilisateur ne les ait utilisées à quelques reprises et qu'elles soient en fait admissibles. Soyez très réfléchi sur l'introduction de cette fonctionnalité et ses implications.
Je vous suggère de regrouper et de rassembler les options sous des titres clairs et de conserver 4 à 5 icônes sous chaque titre. Android a une expérience utilisateur décente et pourrait être une bonne ressource d'apprentissage à cet égard.
Si vous le pouvez, répertoriez ces icônes verticalement et affichez une description textuelle. Lorsque vous mettez des éléments dans une colonne, votre esprit n'utilise qu'un balayage unidimensionnel, ce qui est plus facile par rapport au balayage bidimensionnel dans lequel il doit se souvenir d'une ligne, puis d'un numéro de colonne pour se souvenir de la position d'une icône. (l'esprit utilise le positionnement comme raccourcis et la sensibilité à la position d'un élément dans un cluster fonctionne plus rapidement que la visualisation et la reconnaissance d'éléments) Si vous aviez 4 icônes, vous pourriez utiliser une grille 2,2 qui est en fait plus efficace qu'une disposition unidimensionnelle mais quand vous avez une grille 3,3 ou 4,4 ou 5,5, la charge cognitive est tripliquée ou quadruplée.
J'espère que cela vous aidera à décider et répondra à vos questions.
Je dirais que, sauf s'il est nécessaire que l'utilisateur puisse afficher l'état de toutes les options simultanément, ou si vous n'avez qu'un très petit nombre de options, la disposition à deux niveaux (Fig. 3) est préférable. Non seulement cela fournit une interface plus simple, mais cela permet une expansion, tandis que "toutes les options sur un seul écran" (Fig. 1) exigeraient que l'utilisateur défile si plus d'options étaient ajoutées.
Cela suppose que les options peuvent être regroupées en sous-ensembles de manière logique.
L'alternative "options les plus utilisées" est un compromis si le regroupement n'est pas réalisable, un inconvénient étant que les utilisateurs pourraient être confrontés à un ensemble d'icônes différent si leurs modèles d'utilisation changent au fil du temps, ce qui peut provoquer une certaine confusion.
Voici quelques directives qui peuvent être utiles.
Les paramètres sont la partie d'une application qui n'est pas destinée à une utilisation fréquente. Il sera difficile de localiser l'option nécessaire sur un seul écran. De plus, vous avez peu d'espace pour les étiquettes d'options et cela rend le processus de recherche encore plus difficile (ne vous fiez pas uniquement aux icônes).
Comme mémorisation devrait être faible (les paramètres sont utilisés moins fréquemment), vous pouvez augmenter efficacité en rendant les actions de l'utilisateur plus évidentes. Organisez les éléments en groupes significatifs et pour 20 options une mise en page à deux niveaux serait préférable.
Vous pouvez également repenser vos paramètres. Si certaines options sont utilisées fréquemment, vous pouvez les déplacer vers la partie actions de votre application. Et les valeurs par défaut intelligentes seront également bonnes.