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
_______________________________________________
grass-psc mailing list
grass-psc@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-psc

Reply via email to