[GRASS-PSC] relation between GRASS modules and GUI wizards
Moritz Lennert
mlennert at club.worldonline.be
Thu Dec 3 00:25:02 PST 2015
Dear all,
In light of the debate linked to #2402 [1] on the relation between the
r.in.gdal/v.in.ogr modules and the GUI import wizards, I would like to
raise this as a fundamental question (and decision) for GRASS.
In my eyes (and I don't think anyone has ever questioned this) one of
GRASS' major strengths is its modular structure, with GRASS modules as
basic building blocks that allow to elaborate complex workflows and
applications. At the same time, this modular structure can be
intimidating for new users, especially those coming from a GUI environment.
The automatically generated GUIs for each module are already a big step
towards taking away the fear of using command line.
The wxGUI goes even further and provides a beautiful entry point to
GRASS modules, adding several, extremely useful, specific GUI elements.
In order to respect the modular GRASS philosophy, most of these exist as
standalone gui modules (g.gui.*).
However, in my eyes, the GUI and its tools should be a way to ease
people in towards the core of GRASS, i.e. its modules, and not a way to
hide this core. In the case of the import (and export) wizards this is
the unfortunate effect that we have now: new users are held afar from
the actual modules, with no easy transition. You either are a power
user, and you learn about obscure --ui tricks to see the GUI of the
module, or you are not and then you are not even really supposed to know
about the modules (and their logic) underlying the wizards.
I find that an unfortunate development.
Yes, some people might sometimes get confused, and some people sometimes
might be intimidated by some 'advanced' feature, but not all. I teach
with GRASS every day and I have seen so many different responses that I
would never categorize new users into one clearly defined group, and so
I do not think that we should make fundamental interface choices with
only one specific group of users in mind.
To make a long discussion short:
I propose that we decide once and for all that calling a module by name,
be it in the terminal window, or in the GUI console or via the menu,
launches the actual module GUI. If we want to propose specific wizards
to ease the use of these modules, these should be called as such, and
not via the module name. _That_ causes confusion for many people in my
experience. And wizards should not be complete replacements of the GUI
modules, but offer specific simplifications or added value (such as the
looping through import calls when importing a directory of files). And
IMHO, wizards should always offer a path to the original modules behind
them, in the form of buttons, or at least information.
In the concrete case of the import modules this would mean having the
entries such as the following in the File menu (example given for raster
only):
- Import wizard for raster maps (with a button to launch the module GUI)
- Import common formats (r.in.gdal)
- Import common formats with reprojection (r.in.import)
Any thoughts ?
Moritz
[1] https://trac.osgeo.org/grass/ticket/2042
More information about the grass-psc
mailing list