用户界面建议/导航创意（提供模型图像）
我想显示许多图表，每个图表都有相应的文本。
由于左侧区域的大小是您唯一的限制，我很乐意提供有关如何使界面直观且刺激的建议（如果有任何矛盾？）。
在此模型中，基本上有 2 种模式：
1) 显示图形树菜单（图 1）。用户单击标题并加载相应文本的图表。
2) 选择特定图表（图 2）。用户可以导航到相关图表或返回图表菜单。
一个问题是用户绕过模式 1 进入特定图表：
界面应该如何设计才能方便这些用户找到树形菜单？
...是否应该有一个树形菜单和 2 个独立的“面板”？
请建议其他可以在这种情况下工作的 UI 组件/布局。
替代文本 http://www.lapidus.se/external/mockup1.jpg
< a href="http://www.lapidus.se/external/mockup2.jpg" rel="nofollow noreferrer">替代文本 http://www.lapidus.se/external/mockup2.jpg
I have a number of graphs I'd like to display, each one with a corresponding text.
With the size of the area to the left as your only constraint, I'd appreciate suggestions on how to make the interface intuitive and stimulating (if there's any contradiction?).
In this mockup, there are basically 2 modes:
1) A graph tree menu is shown (image 1). The user clicks a title and the graph with corresponding text loads.
2) A specific graph is selected (image 2). The user can either navigate to related graphs or go back to graph menu.
One concern is users that come to a specific graph bypassing mode 1:
How should the interface be designed to facilitate for these users to find the tree menu?
... and should there at all be a tree menu and 2 separated "panels"?
Please suggest other UI components / layouts that could work in this context.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为您不应该将同一页面区域用于导航和上下文信息。
恕我直言，您有多种选择：
1）将图形选择控件放在可隐藏层中（模式弹出窗口，或者 - 更好 - 标题下可访问的垂直滑动层：查看此处的“控制面板”http://www.tomstardust.com/），将图形信息保留在 Image2 中的位置。
2) 将图形信息层放在图形下方，以扩大可视区域。
在每种情况下，我的建议都是让主导航树始终可访问。
I think you should not use the same page area for navigation and contextual informations.
IMHO You have several choices:
1) Put the graph selection controls in a hideable layer (a modal popup, or - better - a vertical sliding layer accessible under the header: look at the "control panel" here http://www.tomstardust.com/), leaving the graph informations where they are in Image2.
2) Put the graph informations layer under the graph, so to expand the viewable area.
In every case my advice is to have the primary navigation tree always accessible.
我先解决你的第二个问题。如果每个菜单项选择都用主题文本替换菜单，那么我看不出图形面板旁边的菜单面板有多大好处。用户必须单击链接才能返回菜单，一旦到达菜单，我看不出他们需要继续查看图表的充分理由 - 他们单击“图表菜单”是因为他们已经完成了图表。该应用程序至少与仅包含菜单的主页一样高效（就更改图表的点击次数而言）。这将为菜单提供更多空间，以帮助用户选择图形（例如，显示完全展开的层次结构，以便单击即可选择任何图形，或者为每个图形提供缩略图或摘要文本）。
如果在用户选择图形后保留单独的菜单面板可能会更好。这允许用户查看当前图表与其他一些图表的关系（例如，它们都是经济的），并通过单击选择相关图表，这比必须首先导航回图表菜单更有效。然而，全时菜单意味着其他面板的空间更少。为了在一个窗口中容纳菜单、图表和主题文本（后者在其自己的第三个面板中），您可能必须缩小图表，这意味着用户可能会丢失他们可能感兴趣的详细信息。或者，您可以可以通过链接来访问文本，用文本替换图表，但这使得获取文本变得更加困难，并破坏了指向图表中特定特征的任何文本的有效性（例如，“请注意 1929 年...... ”）。
所以你必须判断，菜单值得它花费的像素吗？如果您希望用户进行相对大量的导航，简要查看每个图表，通常不会阅读太多文本，然后转到下一个图表，那么全时菜单会更好。如果您希望用户进行相对大量的图形研究、检查细节、阅读文本，并可能操作图形几分钟或更长时间，那么菜单的主页会更好。除了赌博之外，您对用户行为的期望应该基于用户研究：您的用户是谁，他们想要完成什么，以及他们在什么条件下工作。
您可以通过三个面板提供以两种方式使用该应用程序的能力，其中每个面板都是可调整大小和可关闭（对于图表而言可缩放）的窗格，允许用户配置窗口以实现学习与学习之间所需的平衡-导航。但是，您仍然需要默认配置，因此您仍然需要进行研究以确定大多数用户将如何使用该应用程序。
如果您有一个全时菜单面板，并且您希望用户通常在同一类别的图形之间导航，那么树形控件是很好的选择。树形控件只需单击一下即可将相关图形放在折叠处，但可以将不相关的图形推到折叠下方，迫使用户在选择它们之前滚动（如果您可以在不滚动的情况下显示所有图形，则永久展开层次结构并显示所有图形 -如果不需要，不要让用户打开和关闭树枝）。如果“另请参阅”几乎总是类别中的其他图形，则全时树控件可能会消除对“另请参阅”链接的需要。
如果您希望用户跳转到任意图形，那么您可能希望将菜单层次结构实现为一组侧边栏或下拉菜单，以便最大限度地减少总导航工作。如果用户知道他们想要的确切图表，则可以有一个按名称排序的可滚动图表列表，最好支持提前输入。如果用户有时按名称选择图表，有时按类别选择图表，请将图表列在可按名称或类别排序的可滚动表中。
为了解决您的第一个问题，如果您有一个全职菜单面板，那么您不必担心用户知道如何导航回它。如果您选择将菜单放在主页上，那么将徽标作为主页的链接是一种广泛理解的惯例。但是，您可能希望使用显式链接来备份它。我会用内容（例如，“所有图形”）来标记它，而不是它的实现（例如，“图形菜单”，它可以解释为用于操作当前图形的菜单）（“返回图形菜单”？如果它们绕过菜单，就没有返回任何内容）。我会将“所有图表”链接放在“另请参阅”链接附近，以便这些链接强化多个图表可用的概念。为了建立与“另请参阅”链接的关联，您应该为“所有图表”链接提供相同的总体外观（颜色、下划线），尽管它可以更大或更粗以引起注意。
I’ll address your second issue first. If each menu item selection replaces the menu with the topic text, I don’t see much benefit of a menu panel beside a graph panel. Users have to click a link to get back to the menu and once there, I don’t see a good reason they need to continue seeing the graph –they clicked Graph Menu because they’re finished with the graph. The app will be at least as efficient (in terms of number of clicks to change graphs) with a Home page that is only the menu. That would give you more real estate for the menu to help users choose a graph (e.g., show the hierarchy fully expanded so any graph can be chosen with one click, or provide thumbnails or summary text for each graph).
A separate menu panel may be better if it remains after the user selects a graph. This allows the user to see the relation of the current graph to some other graphs (e.g., they’re all economic) and to select a related graph with one click, making it more efficient than having to first navigate back to the graph menu. However, a full-time menu means less real estate for other panels. To accommodate in one window the menu, graph, and topic text (the latter in third panel of its own), you may have to make the graph smaller, which means to users may lose details that they might be interested in. Alternatively, you may make the text accessible with a link, replacing the graph with the text, but that makes it harder to get to the text and undermines the effectiveness of any text that points to specific features in the graph (e.g., “Note how in 1929…”).
So you have to judge, is the menu worth the pixels it costs? If you expect your users to do relatively large amount of navigating, looking briefly at each graph, generally not reading much of the text, then moving to the next graph, then a full-time menu is better. If you expect your users to do a relatively large amount of graph study, inspecting details, reading the text, and possibly manipulating the graph for many minutes or more, then a home page for the menu is better. To be anything other than gamble, your expectations of user behavior should be based on user research: who your users are, what do they want to accomplish, and under what conditions do they work.
You can provide the capacity to use the app in both ways by having three panels where each is a pane that is resizeable and closeable (and zoomable, for the graph), allowing the user to configure the window for the needed balance of study-versus-navigation. However, you still need a default configuration, so you still have to do the research to determine how most of your users will use the app.
If you have a full-time menu panel, a tree control is good if you expect users to typically navigate among graphs in the same category. The tree control puts related graphs only one click away but can push unrelated graphs below the fold, forcing users to scroll before selecting them (if you can show all the graphs without resorting to scrolling, then permanently expand your hierarchy and show all the graphs –don’t make users open and close tree branches if they don’t have to). A full-time tree control may eliminate the need for the See Also links if the See Also is almost always other graphs in the category.
If you expect the user to jump to any arbitrary graph then you may want to implement the menu hierarchy as a set of side bar or pulldown menus so the total navigation effort is minimized. If users know the exact graph they want, then have a single scrollable list of graphs sorted on name, preferably supporting type-ahead. If users sometimes select graphs by name and sometimes by category, list the graphs in a scrollable table sortable by either name or category.
To address your first issue, if you have a full-time menu panel, then you don’t have to worry about users knowing how to navigate back to it. If you take the alternative of having the menu on the Home page, then making the logo a link to the home is a widely understood convention. However, you may want to back it up with an explicit link. I would label it with the content (e.g., “All Graphs”) rather that its implementation (e.g., “Graph Menu,” which could be interpreted as a menu for manipulating the current graph) (“Back to Graph Menu”? If they bypassed the menu, there is no back to anything). I would place the All Graphs link near the See Also links so that these links reinforce the notion of multiple graphs being available. To build on the association with the See Also links, you should give the All Graph link same general appearance (color, underline), although it could be larger or bolder to draw attention.