#1742: WXGUI layer manager window doesn't show all menubar entries -------------------------+-------------------------------------------------- Reporter: marisn | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: wxGUI | Version: svn-releasebranch64 Keywords: menu | Platform: Linux Cpu: Unspecified | -------------------------+--------------------------------------------------
Comment(by cmbarton): This wish/issue has been around since the TclTk menus. The screenshot attached shows what appears to be a low resolution, small monitor, creating a small layer manager with large type. This is exacerbated by long menu entries in German. I agree with Hamish that while we definitely want GRASS to work across multiple languages, we should not make the interface worse for the majority to satisfy a minority of users. So we need to understand the true extent of this problem. So here are a few questions and comments. 1. The current menu words in English were picked because they were relatively short. Rather than direct translation to another language, can the same concepts be expressed in shorter words? It is the concepts that are important, not the actual words used in the menus. This is something those who work on the translations can best consider and answer. 2. On the smaller monitor of my MacBook Air, the absolute (i.e., in mm) size of the type is smaller because more pixels are crammed into smaller screen real estate. Is this primarily a problem on small monitors with average or lower resolutions (e.g., notebook computers)? If so, we need to think about whether this is the main GRASS user audience. While it would be nice to run GRASS on a notebook (and a number of student do so here) those platforms are not really very good for GIS work. While it is really great that GRASS works on such platforms, I'm reluctant to optimize the GUI for such platforms. The menu structure (horizontal menu bar, pull down menu item lists, sub- menus) is very traditional. However, this in and of itself tends to be best at optimizing limited screen real estate (i.e, small displays). A top level list of menu items can be horizontal, vertical, or in a rectangular matrix. All current displays are longer horizontally than they are vertically. So, especially for long words, you can get more textual information while using up less available screen space in a horizontal menu than in either of the other 2 options, because each menu entry only takes up the width of the menu word. For a vertical set of menus, each entry takes up the space of the longest word in the entire menu. Block matrices are similarly affected. One solution is to allow the user to alter the menu font size in the preferences. It could then be set for different display environments by the user. Another solution is to replace the words in the top level menu with more icons. The possible draw back is that icons may not be easily understandable to novice users (see below). But with mouse over text, they can be learned relatively easily. 3. Currently, it is relatively easy to find and access all functions in GRASS--in spite of the fact that it is a very complex program with hundreds of modules--because of the current menu design. Early in the current GUI design process, one of the devs (I don't remember which one) noted that good menu design should keep all selections within a maximum of 3 levels of nesting (top menu, pull-down, and sub-menu). This has been a very good principle to follow. One of the complaints I regularly hear about Arc is how difficult it is to find different functions, being nested in menus, leading to tool boxes, leading to dialogs and more menus. The current GUI attempts to group functions according to work flow. Functions for making and altering maps are in the menus, functions for arranging maps for viewing are in the layer manager. Functions for interacting with displayed maps are in the map display windows. I'm in favor of experimenting with new designs for ways to access different functions. But the top priorities in any GUI should be ease of access, transparency in signaling, and facilitating work flows. Users should be able to find and identify the tools they need as quickly and as easily as possible as they need them. So I remain skeptical of tool boxes and don't like the idea that users will need to access yet another interface (e.g., hierarchical module list) from the primary interface to find a needed function. As much as possible should be accessible at a glance, while minimizing the loss of total screen space--which is best used to display maps. These are just some musings. We need to be innovative but for the GUI keep in mind novice rather than expert users. -- Ticket URL: <https://trac.osgeo.org/grass/ticket/1742#comment:14> GRASS GIS <http://grass.osgeo.org> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev