[GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl, 1.24, 1.25

[Hamish]

> ... what does "existing projection location" mean?


my overspent 2c re. startup GUI wording:


"database". This one should change in the GUI startup screen now that
the vector engine talks to "real" databases. I like simple two words:
"data path:" for the GUI's database needs. g.gisenv and internally can
still use "database" without harm, although r.proj et al. will refer to
it, the help pages can provide the meaning.

r.proj:
    dbase   Path to GRASS database of input location

shrug. At first I thought this was easy to understand, on second reading
I'm not so sure.


"location" is a bit ??? at first glance, but I still haven't heard
anything I like better. It is not confusing once you know what it refers
to, albeit somewhat non-intuitive at first.

Michael:
> Maybe "Select an existing 'location' (projection/coordinate system)

This sounds ok to me, but note you can have multiple locations which
use the same projection. (e.g. ll_world, ll_canada)  The common
projection is a feature of a location, but not its only quality.

Markus:
> "project location" would be even ok

but then it could be read like "location of project on the hard drive"
when it is intended to refer to geo-location ??? or maybe "geo-location"
is better reserved for a mapset name, refering to an area somewhere
within the projection's domain.


"mapset" is relatively clear; don't clutter it with "GIS mapset" ("GIS"
is redundant) or "available mapsets" (what are the unavailable ones?!)

maybe make more use of the filing cabinet, drawer, and folder analogy.


Michael:
> but also feel that some hand-holding to new users would be worthwhile.

sure. the idea is to be both easy/quick to understand and exact in
meaning. A hard task in practice.


Glynn:
> A user isn't going to be able to do anything useful with GRASS without
> having first read some documentation, so it doesn't really matter
> whether they have to read the documentation before they get to the
> startup screen or afterwards.

In order to get a new user hooked (or at least not give up after hours
of frustration with nothing to show for it), the startup -> "first
light" of a map steps are crucial to get in the first 10-20 minutes of
use.

People are egotistical by nature. They'll either figure the software is
broken or that they aren't as smart as they thought they were. Both may
or may not be true, but neither is anything close to a productive way to
sell your product. They need to keep using the software long enough to
see the power and options available to them at which point they will
sell it to themselves. A cryptic brick wall that asks them to press
<esc><enter> for unknown reasons doesn't help.

solution: tooltips (paragraphs!) on the startup screen so they can
stumble past that, do a good job on the new GUI, pump the tutorials like
mad, and gratuitously link to the help pages.

Glynn:
> [And the latter are frequently answered with the (bogus) advice of:
> use "g.region rast=..." to move the region to the map, when they
> should be using r.region to move the map.]

a) that assumes typical import data is unprojected, and b) you still
run into the "g.region rast=" problem 5 minutes later.


It is possible to be both beginner-friendly and not have to dumb
everything down until it is useless. I think we are lucky to be fighting
to make something powerful easy to use, rather than fighting to make
something easy to use useful for something beyond the most simple tasks.


Hamish