[GRASS-dev] relation between GRASS modules and GUI wizards

[Moritz Lennert]

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