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.
