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

[Michael Barton]

I agree!

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

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


> From: Hamish <hamish_nospam at yahoo.com>
> Date: Wed, 19 Jul 2006 02:10:44 +1200
> To: <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl,
> 1.24, 1.25
> 
>> ... 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
> 
>