La conception maître / détail est-elle la meilleure approche pour notre application?
Nous avons une grande application financière qui se compose actuellement de pages de liste/affichage/édition. Nous avons reçu des commentaires de nos utilisateurs disant qu'il leur fallait trop de clics pour parcourir/afficher/modifier les enregistrements. Ils veulent avoir un moyen de parcourir une page de liste, être en mesure de sélectionner un enregistrement, le visualiser, puis être en mesure de sélectionner un autre enregistrement, donc en gros, ils veulent que la liste soit visible pendant qu'ils consultent également un seul enregistrement .
Ma pensée initiale était d'avoir une conception maître/détail où cela résoudrait ce problème. Les deux conceptions les plus courantes que j'ai trouvées sont la conception à deux volets, puis l'approche descendante (comme un client de messagerie).
Notre application est gourmande en données, donc nos pages de liste peuvent contenir beaucoup de colonnes nécessaires, donc au début, je pensais que la meilleure façon serait de créer une conception où la liste se trouve en haut et lorsque vous sélectionnez un enregistrement, un volet s'ouvre à la bas avec l'enregistrement que vous avez sélectionné, vous donnant la possibilité de le modifier.
Donc je suppose que ma question est, l'approche descendante est-elle la meilleure solution à notre problème? L'un de nos concurrents utilise la conception du volet gauche/droite, et ils ont simplement une barre de défilement horizontale sur le volet gauche afin que le tableau de liste puisse avoir autant de colonnes que nécessaire et ne pas entrer en conflit avec le volet droit.
L'approche descendante semble fonctionner pour les clients de messagerie (même s'ils ont également gauche/droite) mais je ne sais pas si cela fonctionne bien avec une application Web où le volet inférieur ne sera pas simplement du texte, mais aussi un formulaire avec des modaux possibles popups et autres.
Dans l'attente de vos réponses.
Il existe plusieurs façons d'aborder votre problème. Mais tout d'abord, je vais donner des conseils qui ne peuvent pas être donnés assez souvent:
Débarrassez-vous d'abord du fouillis. Surtout dans un environnement "intensif en données".
La règle générale est la suivante: si vous avez plus de 7 colonnes environ, vous vous trompez. Regardez chaque colonne, découvrez si vous en avez réellement besoin et trouvez d'autres moyens de transmettre les mêmes informations. Une application qui ressemble essentiellement à "Excel dans un navigateur" est une mauvaise application.
Cela dit, voici comment aborder votre tâche dans un environnement de navigateur:
- Interfaces maître/détail "en forme de trame", disposées horizontalement ou verticalement. L'inconvénient de cela est beaucoup d'encombrement à l'écran car l'utilisateur ne se concentrera que sur une moitié à tout moment, mais les deux resteront visibles. Vous souhaiterez peut-être masquer automatiquement le volet de détails lorsque la liste est mise au point/aucun élément n'est sélectionné. Voir cet avis qui permet une comparaison visuelle d'une application de messagerie divisée horizontalement avec une application verticale. Et s'il vous plaît, n'utilisez pas réellement de cadres, car ils sont mauvais .
- Info-bulles , affichant plus d'informations lorsque vous survolez quelque chose. Cela convient aux informations plus petites que vous décidez de masquer initialement. Passer la souris sur un ensemble d'étoiles pour savoir si quelque chose est noté 4,7 sur 5 est souvent une bonne interface utilisateur car la plupart des utilisateurs s'en moquent et les étoiles sont plus faciles à saisir que les nombres. Veuillez noter qu'avec l'avènement des appareils tactiles, "survoler" quelque chose n'est pas toujours possible - vous pouvez avoir besoin de moyens supplémentaires pour récupérer ces informations (par exemple en cliquant dessus).
- Nouveaux onglets/nouvelles fenêtres En bref: ne le faites pas. Nous ne sommes plus en 2000 - lancer une nouvelle fenêtre dans le visage des utilisateurs est invasif, et de nouveaux onglets interrompent le flux d'une application.
- Boîtes de dialogue pop-up/modales (JavaScript/Ajax) Les pop-ups sont de nos jours beaucoup moins effrayants que leurs homologues pré-web-2.0. Bien qu'ils fonctionnent de manière similaire, faire de même en JavaScript permet à l'utilisateur de rester sur la même page, de regarder de nombreux détails (éventuellement même avec sa propre barre de défilement) et de revenir à la liste. Les fenêtres contextuelles sont beaucoup utilisées pour images mais fonctionnent également pour formulaires et texte . Veuillez noter que l'empilement de popups (invoquer un autre popup depuis un popup) est généralement une mauvaise idée.
- Divulgation progressive C'est quelque chose que très peu de concepteurs d'interface utilisateur regardent vraiment, mais de manière injustifiée. Des exemples plus anciens de boutons ce concept sont vues arborescentes et "plus" qui vous permettent de rester dans le même contexte mais révèlent plus d'informations. Les variantes plus récentes comportent souvent un "curseur" pour montrer que plus d'informations sont disponibles, mais d'autres variantes de la même idée existent également (même si elle se concentre principalement sur l'interface utilisateur du bureau, this est un bon point de départ pour Dans votre application, il peut être possible de "développer" un élément de sa vue de liste minimale à une vue détaillée en taille réelle sans le déplacer de sa position actuelle. Cela peut même permettre à l'utilisateur de comparer les détails de plusieurs éléments si qui tient en fait sur l'écran.
Je pense que ce qui précède couvre les principales options qui s'offrent à vous. Je crains cependant qu'il n'y ait pas de "meilleure" approche universelle, vous devrez peser le pour et le contre par rapport à votre application.