On Thu, 17 Mar 1994, Simon Cox wrote:
Brief observations from one who knows little about oo programming,
modern guis, etc:
No need for such a disclaimer. Nobody is going to force you to join the
90's or anything. 
(i) This sequence
"object - operation"
reminds me of the old RPN HP calculators or low level programming
languages like Forth, etc. It seemed like a great leap forward when we could
type the way we had learned to write mathematical operations, ie
"function - argument"
I don't think you can compare numerical operands (as with calculators)
with map layers, region files, fonts or such. With numerical operations,
we're accustomed to dealing with formulaic tasks, so a user interface
supporting that formalism is probably best suited to most users. With the
user interface to a data-oriented system (including GIS), the best user
interface for most users will be one which best conforms to the way the
user structures her tasks in her mind. I am very, very sure that most
users do *not* approach GIS tasks thinking, "Well, today I'm going to
calculate some buffer zones. Let's see, I wonder what of? Well, the
secondary streams here in my county might be nice, since I'm currently
getting paid to map some buffers for them.".
In all the empirical human-computer interaction (HCI) research I'm aware
of that deals with this phenomenon, the results have shown that people
structure their tasks in terms of the objects they need to manipulate, not
in terms of operations irregardless of the object eventually operated on.
In calling for such an object-oriented, as opposed to operation- or
function-oriented approach to a GRASS GUI, I do seem to be in reasonably
good company: all the GUI style-guides I've seen *legislate* the
object-oriented approach. This includes the CUA style-guide (a la
Presentation Manager and derivative products) which is part of IBM's
much-touted SAA applications architecture standard, the OSF/Motif
style-guide, and several corporate GUI style-guides I've seen over the
last few years.
BTW, I wouldn't call FORTH a low-level language just because it uses
postfix notation. Semantically, it is no more low-level than C (which is,
of course, more low-level than Tcl, Icon or Perl, if that's what you
meant).
(ii) This discussion should really be on grassp I think.
I disagree. The discussion that has been going on so far should be on
grassu, right where it is. A good GUI for GRASS is *not* something a bunch
of ambitious programmers should sit down and shake out of their sleeves.
We already have several GRASS GUI's that seem to have been developed that
way, with only small-scale input from real users. If I involve myself with
the development of a new Tcl/Tk GUI on an object-oriented paradigm, then
only with wideband input from the user community, with fast, ongoing
turn-around of prototype evaluation by non-developing users.
When the GUI developers start having to ask each other how to get a scale
widget packed into its parent frame right and how to get callbacks to work
linking it to a listbox geometry in a sibling frame, then we can take
*that* kind of thing to grassp. However, I suspect that that kind of thing
will just get handled by direct email unless the number of contributing
developers grows considerably.
------
Thanks for your constructive comments, though, Simon. Keep them coming.
-- Mark
--------------------------------------------------------------------
Mark P. Line Phone: +1-206-733-6040
Open Pathways Fax: +1-206-733-6040
P.O. Box F Email: markline@henson.cc.wwu.edu
Bellingham, WA 98227-0296
--------------------------------------------------------------------