[GRASS5] A naive opinion on how grass *should* work

[Russell Nelson]

Glynn Clements writes:
 > Russell Nelson wrote:
 > 
 > > Let me explain the problem that I'm trying to solve.  I want to reduce 
 > > the learning curve.  I want early rewards.  I want a new grass user to 
 > > be able to see her map by running three commands: "grass5, r.in.png
 > > image, d.rast".
 > 
 > If all that you are going to do is import an image then look at it,
 > GRASS is the wrong package.

What's the *very* first thing a newbie is going to want to do?  Load a
raster map and look at it.  If you give somebody a hammer and a nail,
they're going to go looking for a piece of wood!  That doesn't mean
that they don't want to do anything else!  What it means is that they
want early feedback on whether their mental model of GRASS operation
is correct.

You don't have to believe me.  Take one of your colleagues who has
never run GRASS, and sit them at the Unix prompt.  Tell them to start
up grass5, give them a sample raster map, and watch what they do.
Heck, the very first tutorial I downloaded basically said "select the
spearfish location, start up a monitor and view a raster".

It can be very enlightening to watch a newbie try to use your
software.  Some companies go so far as to videotape newbies as they
struggle (or not) with the software.

 > The kind of user for which GRASS is likely to be the right solution is
 > probably not going to evaluate it by "fiddling with it for a couple of
 > hours".

You're right.  They're not even going to play with it for that
long. They're going to fiddle with it for fifteen minutes, then go get
a purchase requisition for ARCInfo.  C'mon, get real.  It's not like
you have no competition.  "GRASS sucks, but it's free" is not a very
persuasive advertising slogan!

If you think I'm nutso, I was just talking to someone from the NPS who 
makes cave drainage maps.  I asked if he used GRASS.  He said "We used 
to, but now we use ARCInfo".

 > When it comes to the simplicity-vs-functionality tradeoff, GRASS leans
 > more heavily towards the functionality end of the scale than is the
 > norm these days. Sure, simplicity is important; but reliability,
 > flexibility and functionality are more important, IMHO.

So is a shallow learning curve, if you want to have any users besides
dedicated free software partisans and people who are already experts
at GRASS and/or GIS.

 > > I'm asking for reasonable defaults.  If I load a georeferenced map
 > > (e.g. GeoTIFF) into an empty location, is there any reason not to set
 > > the default region to that of the map?
 > 
 > Yes; the default region is explicitly chosen by the user. Same for the
 > current region. The only time that the current region is changed is if
 > the user decides to change it.

That is how it currently works.  I am asking you to change it.

 > If the user wants to change the region to match a particular map, they
 > can use e.g. "g.region rast=map".

And if it's been resampled because I had no clue what I was doing when 
I loaded the map???

 > > When a newbie first loads a raster, that's the only raster he's going
 > > to have.
 > 
 > Not necessarily; the user may well have access to pre-existing maps,
 > installed by their co-workers, tutor, or even the default GRASS
 > installation.

Then they'll already have a default region set *for* them by somebody
who already knows what they're doing.  Wouldn't it be nice if
everybody had that benefit?

 > > That is not a "fairly bizarre instance".  From the newbie's
 > > point of view, it's normal (everything a newbie does is normal).
 > 
 > "Bizarre" is a subjective term, but having exactly one raster map
 > available is objectively an unusual situation. Sufficiently unusual
 > that it's not worth adding special-case code for.

Everybody who first runs GRASS is going to have to go from zero maps
loaded to having one.  It's not unusual at all.

 > There's also the consistency issue. IMHO, it's preferable for an
 > option to always be required than for it to almost always be required. 

I think you're confusing consistency with user expectations.  People
do not always expect consistency!

 > It's one thing if an option is required or not depending upon other
 > options (i.e. you have to specify either "foo=..." or "bar=..."), but
 > introducing a dependency upon environment (e.g. how many raster maps
 > are in the current location) complicates the general case to simplify
 > a special case.

If that's what the user expects, then it's correct.  Doesn't matter if 
it makes the code more complicated.  The customer is always correct -- 
and so is the user.

 > >  > Personally I think there's a lot more important issues.
 > > 
 > > I *did* point out that I'm not unwilling to submit patches.
 > 
 > The adding code isn't just about whether the code is available. One of
 > GRASS' main problems is the sheer volume of code present, given the
 > small number of active developers. Any increase in quantity or
 > complexity has to be justified.

Perhaps, then, GRASS is not well organized.  Rather than being a
single body of code, perhaps it should be a standard, and set of
programs?  Unix has a well-defined API and many programs run under
Unix, and can interoperate with each other.

 > The same problem applies to anything which accepts "names" as input. 
 > Having tab completion would be nice, but it isn't the one-and-only
 > factor in determining the structure of the database.

Then maybe GRASS should use the GNU Readline library and explicitly
hand the name completion list to the library?

-- 
-russ nelson              http://russnelson.com | Okay, enough is enough!
Crynwr sells support for free software  | PGPok | Can we PLEASE all stop
521 Pleasant Valley Rd. | +1 315 268 1925 voice | using insecure Microsoft
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | email products???