Je traiterai d'abord votre deuxième problème. Si chaque sélection d'élément de menu remplace le menu par le texte du sujet, je ne vois pas beaucoup d'avantages d'un panneau de menu à côté d'un panneau de graphique. Les utilisateurs doivent cliquer sur un lien pour revenir au menu et une fois là, je ne vois pas pourquoi ils doivent continuer à voir le graphique - ils ont cliqué sur le menu graphique parce qu'ils en ont terminé avec le graphique. L'application sera au moins aussi efficace (en termes de nombre de clics pour modifier les graphiques) avec une page d'accueil qui est seulement le menu. Cela vous donnerait plus d'espace pour le menu afin d'aider les utilisateurs à choisir un graphique (par exemple, afficher la hiérarchie entièrement développée de manière à ce que tout graphique puisse être choisi en un clic ou fournir des vignettes ou un résumé pour chaque graphique).
Un panneau de menu séparé peut être meilleur s'il reste après que l'utilisateur ait sélectionné un graphique. Cela permet à l'utilisateur de voir la relation du graphique courant avec d'autres graphiques (par exemple, ils sont tous économiques) et de sélectionner un graphique associé en un seul clic, le rendant plus efficace que de revenir d'abord au menu graphique. Cependant, un menu à temps plein signifie moins de biens immobiliers pour les autres panneaux. Pour intégrer dans une seule fenêtre le menu, le graphique et le texte du sujet (ce dernier dans le troisième panneau), il se peut que vous deviez réduire le graphique, ce qui signifie que les utilisateurs risquent de perdre les détails qui pourraient les intéresser.Alternativement, vous pouvez rendre le texte accessible avec un lien, en remplaçant le graphique par le texte, mais cela rend plus difficile l'accès au texte et nuit à l'efficacité de tout texte qui pointe vers des caractéristiques spécifiques du graphique (par ex. en 1929 ... ").
Donc, vous devez juger, le menu vaut-il les pixels qu'il en coûte? Si vous vous attendez à ce que vos utilisateurs effectuent une navigation relativement importante, en regardant brièvement chaque graphique, ne lisant généralement pas une grande partie du texte, puis en passant au graphique suivant, un menu à temps plein est préférable. Si vous vous attendez à ce que vos utilisateurs effectuent une quantité relativement importante d'étude graphique, inspectent les détails, lisent le texte et manipulent éventuellement le graphique pendant plusieurs minutes ou plus, une page d'accueil pour le menu est alors préférable. Pour être autre chose qu'un pari, vos attentes en matière de comportement de l'utilisateur doivent être basées sur la recherche de l'utilisateur: qui sont vos utilisateurs, que veulent-ils accomplir et dans quelles conditions fonctionnent-ils?
Vous pouvez fournir la capacité d'utiliser l'application dans les deux sens en ayant trois panneaux où chacun est un volet qui est redimensionnable et fermable (et zoomable, pour le graphique), permettant à l'utilisateur de configurer la fenêtre pour l'équilibre nécessaire d'étude par rapport à la navigation. Toutefois, vous avez toujours besoin d'une configuration par défaut. Vous devez donc effectuer des recherches pour déterminer comment la plupart de vos utilisateurs utiliseront l'application.
Si vous avez un panneau de menu à temps plein, un contrôle d'arbre est bon si vous vous attendez à ce que les utilisateurs naviguent généralement parmi les graphiques de la même catégorie. Le contrôle d'arbre met les graphiques associés en un seul clic mais peut pousser des graphes indépendants sous le pli, forçant les utilisateurs à les faire défiler avant de les sélectionner (si vous pouvez afficher tous les graphes sans avoir à défiler, ne pas obliger les utilisateurs à ouvrir et fermer les branches d'arbres s'ils ne le doivent pas). Un contrôle d'arborescence à temps plein peut éliminer le besoin des liens Voir aussi si le Voir aussi est presque toujours d'autres graphes dans la catégorie. Si vous souhaitez que l'utilisateur accède à un graphe arbitraire, vous pouvez implémenter la hiérarchie des menus sous la forme d'un ensemble de menus latéraux ou de menus déroulants afin de minimiser l'effort de navigation total. Si les utilisateurs connaissent le graphique exact qu'ils veulent, alors une seule liste déroulante de graphiques triés sur le nom, de préférence en appuyant sur la saisie anticipée. Si les utilisateurs sélectionnent parfois des graphiques par nom et parfois par catégorie, répertoriez les graphiques dans une table déroulante triable par nom ou par catégorie.
Pour résoudre votre premier problème, si vous disposez d'un panneau de menu à temps plein, vous n'avez pas à vous soucier des utilisateurs sachant comment y revenir. Si vous prenez l'alternative d'avoir le menu sur la page d'accueil, alors faire du logo un lien vers la maison est une convention largement comprise. Cependant, vous pouvez le sauvegarder avec un lien explicite. Je voudrais l'étiqueter avec le contenu (par exemple, "tous les graphiques") plutôt que sa mise en œuvre (par exemple, "Graph Menu", qui pourrait être interprété comme un menu pour manipuler le graphique courant)? contourné le menu, il n'y a pas de retour à quoi que ce soit). Je placerais le lien Tous les graphes près des liens Voir aussi afin que ces liens renforcent la notion de plusieurs graphes disponibles. Pour construire sur l'association avec les liens Voir aussi, vous devez donner le même aspect général au lien All Graph (couleur, souligné), bien qu'il puisse être plus grand ou plus audacieux pour attirer l'attention.
