[GRASS-dev] r.colors confusion with "color", "rules", and "raster" options

[Hamish]

[stating my peace then dropping this to focus on far more ghastly UI issues]

> Hamish wrote:
> > I've just added some logic in 6.x SVN to more nicely handle different
> > user interpretations of the commands. "accept sloppy input, create
> > tight output" and all that. Sure 'color=rules rules=filename' is
> > redundant, but the intention is obvious. some people (especially those
> > unfamiliar) like to tick every box. if it doesn't hurt anything, let
> > 'em.
Glynn:
> Reverted.
> 
> If input is invalid, you report that it's invalid, not silently do
> what you *think* that the user meant (i.e. DWIM).

I accept the general point, but in this case can you offer an
alternative intent for 'color=rules rules=filename'?

I find "invalid" a bit strong in this case, but agree that if the user
misinterprets something then it is our task to make the instructions
clearer.


> If the user misunderstands something, you should educate them, not
> reinforce the misconception.

In cases where it is obvious what they meant, my view would be to focus on the goal and let a minor misappreciation for the underlying design pass.


trying to get into the head of a new user for a minute:

Gary the Grass user is presented with the r.colors GUI.
He starts filling in options from the top down. As a beginner he can
only guess what to put for each option. For "color=" he gets a drop
down menu, the top entry being blank and the bottom being rules. ummm...
The next is for "rules=" filename. That makes sense and he uses that.
But what to put for the colors= option now? Being slightly unsure of
himself with this new complex software, and wanting to make doubly sure
that the rules= option is used, and lacking the experience to follow 
the subtle logic, the points the colors= option at what he thinks is
for rules=. That gives an error not to use the colors= option. But then
he thinks that he *did* give the neutral answer to color=, and what to
set it to now? (blank may be far from obvious)

> > > -rules: create new color table based on user-specified rules
> > > +rules: create new color table based on user-specified rules read from stdin
> > 
> > I reverted that as it is somewhat misleading. It can mean either read
> > directly from stdin or if no stream is waiting then to enter into the
> > interactive environment.
> 
> Huh? It always means "read from stdin". If stdin is a tty, you get the
> interactive prompts; if it's a file or pipe, you don't.

Well technically, yes, but I feel that we're splitting hairs here.
To the same newly recruited user, what is a stdin and where can I go to
buy one? -----Do those extra words contribute to the clarity of meaning?
Or, although technically correct, do they needlessly confuse the matter?
I have a small goal that module and option labels should, whenever
possible, be concise enough to fit in 80 chars or less. (partly cosmetic,
partly it's a nice round number for the task) Unnecessary words must go!


> BTW, do we actually need to describe all of the color=
> options twice? 
> The description.html file includes all of the options, but
> the auto-generated portion already contains that information.

yep, they're redundant.


Hamish