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