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