Jerry Balzano (gjbalzano@ucsd.edu)
Thu, 9 Sep 1999 17:29:51 -0700
Date: Thu, 9 Sep 1999 17:29:51 -0700 From: Jerry Balzano <gjbalzano@ucsd.edu> Subject: the point-and-click paradox
List address to send message to everyone: ifets-discuss@LISTSERV.READADP.COM
Details of current discussion: http://grouper.ieee.org/ltsc/ifets/discussions/discuss.html
---------------------------------------------------------------------------
Hello everyone. I am really not slogan-mongering here, but the
"point-and-click-paradox" is a phrase I use in my classes to help advance
the argument for programming to my students. If anyone here has a
different label or wants to deconstruct the label and the argument
altogether, that's OK too (in principle at least). So here's the argument:
When point-and-click (instead of remember-and-type) computers and software
became more popular (starting mid 80's with the Macintosh) we saw
increasing numbers of arguments against learning to program. After all,
now you could do all sorts of incredibly powerful things with computers
just by pointing and clicking that you couldn't do before without either
(a) learning to program or (b) learning to use complicated software that
had commands and syntax and all the rest of it. (The following paragraph
can be skipped by readers in a hurry.)
[The UNIX "vi" text editor is an interesting case in point with regard to
case "b". At the time, "vi" was, in comparison to what existed previously,
a VISUAL text editor (hence the "vi", as in "VIsual"). You could actually
see something like what your page of text was going to look like,
represented on the screen, and to edit a line of text, you actually moved a
cursor to that line and inserted text "directly" into the place you wanted
it. However, in order to do this, you needed to know that the "h","j","k",
and "l" keys were "commands" for moving the cursor (left, down, up, &
right, respectively), and once you had gotten the cursor to where you
wanted it, you needed to issue an "i" command to enter "insert mode", which
would result in any ensuing keystrokes being inserted into the text instead
of being interpreted as commands. The "leave insert mode" command was the
ESC key. You could also jump to a different part of the text by typing
something like ":50,70p<RETURN>" (without the quotes), which meant "enter
command mode (the colon did this), then print lines 50 through 70 out on
the display screen" (the RETURN key re-entered "edit" mode, where
"h","j","k" etc worked as cursor control commands). For many people "vi"
was just too hard to learn (as was UNIX itself), and they stuck to doing
"word processing" on their typewriters, thank you very much.]
Both (a) and (b) are important, because learning-commands-and-syntax is
hard enough for most people EVEN IF we don't grant that people who have
done so have in any useful sense "learned to program". By stripping away
as much as possible of the "learning commands and syntax" part of learning
to program, software like ToonTalk and Stagecast Creator constitute
significant breakthroughs to those of us who think kids learning to program
is a good thing. Let me summarize the point here even though it's a bit of
a digression from my main argument: Learning one's first programming medium
("language" is a special case of "medium") is doubly hard if that medium is
also a programming *language*, because then the novice learner has to learn
two kinds of things: (1) how to think through and create algorithms to
accomplish a task, like "when pac-man encounters a pellet, he eats it", and
(2) the commands and syntax of a programming language. ToonTalk and
Creator, as far as I can see, are answers to the question, "what if you
could learn to program by focusing as much of your learning energy on #1,
and defer as long as possible the need to learn #2?"
Back to the main thread: With all this cool new point-and-click software,
people could now do things with computers that they could hardly even
imagine themselves doing before. With their imaginations thus fired up,
users started to dream of doing even more cool things, many of which were
things that the current version of their favorite software was unable to
do. The solution? Add the desired "features" into the next version of the
software, which necessarily made that software bigger and bulkier than the
previous version. In the point-and-click world, extending a program's
functionality meant adding new menus, new dialog boxes, new tools, and so
forth. The amazing thing (to me) is that users continue to soak up this
added complexity and keep asking for more. The latest versions of programs
like Microsoft Word, Canvas -- actually, take your pick -- are vivid
demonstrations of what someone (I can't recall who) has called "creeping
feature-itis", and there is no end in sight.
And that is the problem, and the paradox, if you will. No matter how many
features we add to our point-and-click software in this way, there will
*always* be things that users will want to do that the designers didn't
anticipate in advance. The solution is *not* to keep making programs
bigger, clunkier, and more byzantine, but to make them **programmable** so
that they have embedded in their structure the ability to respond to needs
of users not anticipated by the software designers. Making computers
easier to use via point-and-click interfaces, even though it seemed at
first to obviate the need for learning to program, has (I submit) if
anything accelerated the situation to the point where programmability seems
the only viable (and sustainable) way forward.
I've talked long enough here. I'd be very interested in any reactions
people have.
- Jerry Balzano
-------------------------
Dr. Gerald J. Balzano
Teacher Education Program
Dept of Music
Laboratory for Comparative Human Cognition
Cognitive Science Program
UC San Diego
La Jolla, CA 92093
(619) 822-0092
gjbalzano@ucsd.edu
---------------------------------------------------------
Forum website: http://ifets.gmd.de/
Forum's contact person: kinshuk@ieee.org
Info on Join/Leave List: http://ifets.gmd.de/maillist.html
---------------------------------------------------------
This archive was generated by hypermail 2.0b3 on Fri 10 Sep 1999 - 04:43:17 MEST