Alternative au modèle de menu de tableau de bord / page de portail?
En ce moment, la page d'ouverture de notre application est un tas de boutons vaguement regroupés en catégories qui pointent vers des zones assorties de l'application. Certains de ces liens vous amènent à des pages d'application plus approfondies (menus de paramètres, tableaux de données, etc.) tandis que d'autres vous amènent à des pages de tableau de bord imbriquées.
Je souhaite éviter ce design autant que possible car:
- Il ralentit la navigation vers des pages plus profondes avec des fonctionnalités réelles
- Les pages elles-mêmes sont très clairsemées, n'étant rien de plus que des liens, ce qui les fait se sentir plus comme des espaces réservés que des destinations réelles
- C'est généralement juste un motif de conception laid
Je suis donc à la recherche de modèles alternatifs à essayer ici au lieu de listes de grilles d'icônes. Une idée que j'ai lancée a été de transformer ces pages en pages de résumé qui, au lieu de liens de bouton, contiennent des informations de résumé sur la page vers laquelle ils sont liés. Une autre alternative que j'ai envisagée consiste simplement à utiliser un menu déroulant de style Windows, mais comme il s'agit d'une application Web réactive, ce type de navigation sera difficile à mettre en œuvre correctement compte tenu de l'échelle de la hiérarchie de navigation.
EDIT: Ci-dessous est une maquette rapide qui est essentiellement à quoi ressemble le système actuel. Les images d'espace réservé sont destinées à être des icônes semi-pertinentes au contenu de la section et appuyer sur ces icônes ou sur le texte du lien vous amènera à la page.
Des idées?
Idéalement, vous pourriez me fournir exactement ce dont j'ai besoin sans aucune contribution. Bien sûr, cela est impossible à faire avec différents types d'utilisateurs qui veulent tous des choses différentes. La réalité est certaines entreprises ont juste beaucoup de contenu auquel il faut accéder à différents moments par différentes personnes, alors voici quelques éléments à garder à l'esprit lorsque vous remodelez les pages de votre portail ...
1. Moins c'est plus
Le paradoxe du choix est une chose amusante. Il est possible de donner à quelqu'un autant d'options qu'il n'en a plus. C'est pourquoi la première chose que j'essaie de faire lors d'une refonte comme celle-ci est de justifier chaque lien. Assurez-vous qu'il a absolument un but d'exister et que son but facilitera sans aucun doute la vie de quelqu'un.
2. Essayez de recommander au lieu de montrer des choix égaux
Les utilisateurs préfèrent souvent les recommandations, car cela nécessite moins de réflexion, donc si certaines choses sont meilleures que d'autres, allez-y et faites-les ressortir.
source: goodui.org
3. Regroupez les articles en petits morceaux
Il semble que vous ayez déjà divisé les liens de navigation en catégories, ce qui les rend plus faciles à digérer, ce qui est bien. Assurez-vous de montrer les groupes les plus importants en haut.
source: Khan Academy
4. Divulgation progressive
Lorsque les éléments ne sont pas vraiment accessibles, vous pouvez réduire la charge cognitive de vos utilisateurs en les masquant jusqu'à ce qu'ils demandent à en voir plus. Parfois, il n'est pas possible de classer un groupe ou un élément au-dessus d'un autre, mais lorsque vous pouvez le faire sans deviner, envisagez de n'afficher que les groupes les plus importants ainsi que les éléments les plus importants de chaque groupe.
5. Testez tôt et testez souvent
Obtenez les commentaires d'un ensemble de base de vos utilisateurs dès que possible pour vous assurer que vos efforts de refonte leur faciliteront vraiment la vie. Ne vous attachez pas trop à une seule interaction et laissez le processus être itératif. Les meilleurs modèles survivront.
J'espère que vous trouverez certains de ces conseils utiles et bonne chance dans votre refonte de navigation.
Les deux alternatives que vous avez mentionnées:
- Pages récapitulatives
- Liste déroulante de style Windows
Une alternative que j'ai trouvée est presque une combinaison de ces deux. Au lieu d'un tableau de bord basé sur des icônes, j'ai créé un tableau de bord fenêtré:
Chaque fenêtre peut répertorier les différents sites sous forme de liens ou de boutons, avec des liens hiérarchiques affichés sous forme d'éléments imbriqués:
La capture d'écran ci-dessus montre également les capacités réactives, vous redimensionnez simplement les fenêtres individuelles en fonction de la résolution donnée. Si deux fenêtres sont affichées côte à côte dans un navigateur paysage, elles peuvent être affichées de haut en bas sur un navigateur mobile plus petit.
Chaque fenêtre peut également être réduite, permettant aux utilisateurs de personnaliser ce qu'ils voient:
Juste quelques idées basées sur des tableaux de bord que j'ai utilisées qui fonctionnent bien.
J'ai également été confronté à ce défi récemment. Il y a un désir d'avoir une page de portail "cool" avec beaucoup d'icônes vaguement pertinentes menant à des zones fonctionnelles spécifiques de l'application.
Le problème, c'est que le tout se sent forcé. Et si votre suite d'applications (ou un ensemble de vues et d'activités) devient très profonde, le portail a tendance à être trop peu profond ou trop encombré.
Peut-être que vous n'avez pas du tout besoin d'un portail?
Et si tout ce dont vous avez vraiment besoin est une meilleure architecture de l'information et une meilleure solution de navigation dans les vues réelles de votre application? Il y a de fortes chances que vous ayez quelques régions principales:
- Principaux domaines fonctionnels. Ce sont les compartiments généralisés pour les types d'activités.
- Vues dans ces domaines fonctionnels. C'est là que démarre une activité.
- Pages détaillées/détaillées Ce sont les éléments de support d'une activité.
(Veuillez accepter mes excuses pour la googleness suivante - c'est la première chose qui m'est venue à l'esprit et je ne peux pas encore partager mon travail)
Les grands domaines
Ce sont comme des applications (ou sous-applications) distinctes qui interagissent les unes avec les autres. Vous pouvez basculer entre eux comme vous basculez entre les applications Google, soit en réponse à une étape d'une activité ou explicitement via un menu d'application. Le menu de l'application me semble être une réponse plus moderne au portail: ce n'est pas une page entière et il peut rester avec vous tout au long des applications.
Vues secondaires
C'est là que vous plongez dans des activités spécifiques (ou des tâches, des emplois, etc.), des vues dans l'application actuelle. Les onglets semblent être un bon choix pour cela et ils pourraient fonctionner sur ordinateur de bureau et mobile.
Pages de détails
C'est là que l'utilisateur commence à creuser pour apprendre et faire avancer les choses. Dans un contexte mobile, le titre de la page peut changer et la sauvegarde vous mènerait dans l'autre sens. Ils conviennent également parfaitement aux menus de navigation secondaires/latéraux.
Préférence utilisateur
À tout moment à partir du deuxième niveau, l'utilisateur peut vouloir accéder rapidement à une vue. Il peut même vouloir cette vue avec son propre ensemble de paramètres appliqués (comme les filtres). C'est là que vous pouvez fournir une sorte de portail personnalisé, comme le menu de l'application mais pour les "favoris" de l'utilisateur. Le menu FAB vient à l'esprit, mais imaginez-le avec une icône d'étoile ou de signet.
YMMV
C'est là où je vais. Quand je travaille à travers mes histoires d'emploi , cela semble être la meilleure expérience. Je ne testerai pas l'un contre l'autre pendant quelques mois, mais les premiers commentaires de la guérilla me disent que c'est la bonne voie.
Même si je n'ai aucune idée du contenu que vous souhaitez afficher, vous pouvez essayer Google Material's cards , en ajoutant votre titre en tant que carte , puis des actions supplémentaires si nécessaire, et une liste de contenu pour cette carte particulière.
Étant donné que les cartes permettent un contenu hétérogène, cela pourrait être très adapté à vos besoins spécifiques, sans parler de ce sont des éléments très agréables pour "habiller" une version de bureau. Voir l'image ci-dessous:
Comme vous pouvez le voir, vous pouvez utiliser une grande variété de contenus à l'intérieur d'une carte. Et bien que les spécifications techniques indiquent que vous ne devez utiliser qu'un seul lien, vous pouvez sortir de la logique de la carte et ajouter autant de liens que vous le souhaitez, voire des liens avec un texte explicatif et des icônes, comme une liste à l'intérieur d'une carte . Vous n'êtes pas censé le faire, mais rien de mal ne se produira si vous le faites!
Et pendant que nous sommes dans le domaine Material Design lists , vous pouvez simplement jeter un œil à ces fonctionnalités pour obtenir plus d'idées. Par exemple, jetez un œil aux images ci-dessous:
Ici, vous pouvez voir un bel affichage des listes et un comportement d'informations étendu. Il a l'air bien sur mobile, mais bien sûr, il aura l'air stupide sur le bureau, vous pouvez donc adapter la liste à une carte ou liste de grille ou autre afin de profiter de l'espace disponible.
Quoi qu'il en soit, cela dépendra de votre contenu et de la référence visuelle que vous souhaitez fournir aux utilisateurs. Puisque vous mentionnez des images et des icônes, c'est un peu difficile à dire, mais j'espère que ces idées vous seront utiles