[GRASS5] Re: Developing a New Grass UI

[Michael Barton]

David,

I'm copying this to the developer's list because your comments are well
thought out and (I suspect) express well the outlook of an important segment
of the GRASS user community, particularly developers and those who use GRASS
on a daily basis.

I agree wholeheartedly that it remains important to maintain the CLI for GIS
operations in GRASS for many of the reasons you point out, including
automation and scripting that solve problems not considered during GUI
development. This flexibility gives GRASS additional functionality.

However, I think operations now carried out through commands like d.mon
select=X0 and d.zoom map=[name] can be handled much better via an
interactive GUI. I feel the same is true for commands like d.rast and
d.vect. Building display control into the GUI makes it more flexible than if
it must issue a set of commands whenever you want to do something as
apparently "simple" as see a map or select a window. That is, a program the
includes graphic displays is easier to work with--by al--if the complexities
of such display operations operate largely behind the scenes. There are also
programming advantages to controlling the display directly from the GUI
rather than via an intermediary set of commands. IMHO, NVIZ is much more
flexible and functional than trying to use a GUI to run the GRASS 5.x d.3d
command. Graphics and CAD programs may retain a CLI to process images and
drawings, but by and large display control is through on-screen manipulation
of some kind--for good reason.

Where we make the distinction between direct GUI control and commands that
can be called directly through the CLI (and optionally through a menu) is an
important issue to discuss. For myself, I'd make the cut between
manipulating files/processing spatial and attribute data/analyzing
data/spatial operations/etc and visualization/display control/digitizing.
The first group would be CLI with optional access via menus (as we have
now). The second group would be integrated into the GUI (like in NVIZ or
QGIS). Attribute data management would be a hybrid: accessible via CLI SQL
and GRASS data management modules and via a more interactive
spreadsheet-like interface distinct from the display GUI. But that is my
opinion given my experience using GRASS, GIS in general, other programs, and
many years on a Mac. While I can appreciate the power of R, I'd much rather
use JMP in my own research. Others may well see it differently. This is the
reason for asking for input.

Thanks very much for your insightful comments. This kind of response if very
helpful.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: David Finlayson <dfinlays at u.washington.edu>
> Reply-To: <dfinlays at u.washington.edu>
> Date: Sun, 06 Nov 2005 19:08:22 -0800
> To: <michael.barton at asu.edu>
> Subject: Developing a New Grass UI
> 
> Michael -
> 
> I noticed a thread at gmane.comp.gis.grass.devel (I am not a list
> member) about a road map for a new GRASS UI and thought that I would
> chime in (this is long).
> 
> Right now the GUI is an afterthought in GRASS and new users face a
> steep learning curve to get anything at all done. So clearly something
> must be done to make using GRASS easier for average and casual users.
> But, as you are developing a vision for the next-generation GRASS, I
> would urge you to consider a model more like Matlab, Mathematica or R
> (etc.) rather than ESRI's ArcGIS. In all of the former programs there
> is a nice GUI wrapping a CLI interface. Things like interactive plots,
> menus, etc are available to ease users into the program, but the key
> interface is not a GUI, it is an "enhanced" command line.
> 
> The advantage of this format is that new users get the hand-holding
> they need, it is easy to make visual changes to plots, etc.,
> infrequently used features are wrapped in wizards etc., but crucially,
> there is no fundamental difference between casual use and advanced
> use. Full automation is available from the CLI or from a script and
> they use EXACTLY THE SAME COMMANDS...nothing new to learn.
> 
> Compare the matlab model with ArcGIS. ArcGIS was designed to be a
> GUI-first system after the huge success of ArcView. After more than 7
> years on the market ESRI is still distributing ArcInfo. Why? In part,
> I think, because it is orders of magnitude more difficult to automate
> the new interface and advanced users refused to use ArcObjects (VB or
> C++) to do it. ESRI relented in the latest version (9.X) and has
> bolted on a Python interface and a GUI model builder that go part-way
> to restoring the automation capabilities lost, but I assure you that
> ArcInfo will continue to be popular until the CLI in ArcGIS matures
> into a first-class interface.
> 
> To me the lesson is that GIS (like math software) is extremely
> complex. To be useful it also needs to be extremely flexible. GUI's
> have the fundamental shortcoming that a designer has to anticipate
> every possible use scenario in order to provide appropriate buttons
> and panels. Advanced users will be hamstrung if the interface doesn't
> support flexibility. The CLI for all of its initial shortcomings is
> very easy to automate, easy to combine with other programs in ways not
> anticipated by the program designers...in short, flexible. (I am
> thinking here of your suggestion to remove the d.* commands in favor
> of an enhanced monitor GUI)
> 
> I would like to see a GUI wrapped around the CLI to cover things like
> setting up program directories, default environments, etc. It would be
> useful to have a GUI wrapped around the monitors for zooming,
> printing, moving objects on the display, etc. But I think that the
> design should be towards making the CLI easier to use rather than
> trying to replace it or hide it.
> 
> My 2 cents (more like a couple of bucks...)
> 
> --
> David Finlayson
> Marine Geology & Geophysics
> School of Oceanography
> Box 357940
> University of Washington
> Seattle, WA  98195-7940
> USA
> 
> Office: Marine Sciences Building, Room 112
> Phone: (206) 616-9407
> Web: http://students.washington.edu/dfinlays