[GRASS-dev] GUI wizards reducing functionality [was: Re: Missing subgroup functionality in GRASS 7 wxGUI's i.group?]

[Hamish]

Moritz wrote:

> I do think that we should have a more general debate about how to handle 
> these issues. Personally, I'm very strongly opposed to this tendency of 
> "dumbing-down" the GUI menus. I have nothing against wizards, but I 
> think they should be an additional feature, not a replacing features.

Hi,

I don't think it needs a big debate, just a bit of finesse in the execution.
For example I think the Cartographic Composer tool does a nice job of hiding
the ps.map module GUI dialog behind a conceptual "Advanced" button using
its menu placement. New users would probably ignore the menu item not
knowing what it did; seasoned users would recognize what it was and use it
as needed, but for them too it wouldn't be cluttering up for normal use.

An example I keep coming back to is wrapper-subset scripts for d.vect (*see g6
addons d.stations, d.varea, and ~d.mark), since the main GUI controls begin
to resemble the complication of a Boeing 747 cockpit. Simplification in and
of itself is not always a bad thing.

wrt the steepness of the learning curve, I don't think you should have to know
the name of a module to launch its GUI (ie from the command line) instead of a
wizard, but the wizard should gently teach you the name of the module. For
me this was the self-assembling command lines at the bottom of the grass5
tcltkgrass module GUIs.

wrt r.import and r.export as fancy g.GUI wizards and r.{in|out}.gdal as
advanced full module dialog GUIs, the idea sounds nice to me.


regards,
Hamish