[GRASS-dev] [GRASS GIS] #1742: WXGUI layer manager window doesn't show all menubar entries

[GRASS GIS]

#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>