[GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/initgis_set.t cl, 1.24, 1.25

[Patton, Eric]

Hamish, All, 

Resonses interspersed...

Hamish:
>"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.

This is analogous to the layer/layer dichotomy that was discussed a while
back: A layer is sometimes understood to mean a map in the display manager
and also one or more vector database connections. I agree with Hamish that
if anything should change, 'database' should because of the use of the word
in relation to table connections in the vector engine. Even if you only have
a background in Microsoft Office, you're familiar with databases as dbf
files; so I think most new users would come to Grass with at least that
initial understanding of what the word meant.

Hamish:
>"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.

Interestingly, of the other smattering of Grass users at my office, (3-5
depending on the day), no one ever refers to their Grass GIS Locations as
"Locations"...everyone uses "Grass Projects" as a synonym of "Grass
Locations". Not representative of the average user, perhaps, but it's
revealing how all newer users seem to gravitate to a common term like that.
When I mention "Open that Grass Location of Sydney Harbour", they say "oh,
you mean my Sydney Grass Project?". 

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

Hamish:
>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

Hamish:
>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.

I think I side with Markus here, project location sounds good. I never had
considered that it could mean the "location of data on hard disk" until
Hamish mentioned it, but maybe use a globe or map icon next to the words
"Project Location" to denote that we are talking about spatial locations
here, not disk locations.


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

Agreed.


Hamish:
>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.

Hamish:
>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.

Hamish:
>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 new user who gets excited about Grass is a potential alpha-tester/power
user; a new power-user is a (perhaps) a potential developer. So getting
people productive in Grass as soon as possible seems to me a critical issue.


>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.]

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


Hamish:
>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.

Agreed. 

~ Eric.