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.