SHEBS@UTAH-20.ARPA (10/01/84)
From: Stan Shebs <SHEBS@UTAH-20.ARPA>
I got several replies to my question about the relation between windows
and expert systems. The consensus seemed to be that since an expert
system development environment is like a programming environment, and
since PEs are known to benefit from having multiple windows available,
windows are an important part of expert system tools. Incidentally, the
issue of graphics is orthogonal - graphics is useful in a great number
of applications (try describing the weirder geologic formations in words!),
although perhaps not all.
I have a little trouble with both assumptions. I looked in my nifty
collection of reprints, "Interactive Programming Environments" (Barstow,
Shrobe, and Sandewall, eds., pub. by McGraw-Hill),
and found no research supporting the second assertion. Its main
support appeared to be anecdotal. My own anecdotal experience
is that even experienced users spend an inordinate amount of clock
time trying to do something right, but are not aware of just how
much time they're taking (pick a menu item, oops!, undo, try again,
then search all over the screen for 5 chars of text, then go through
an elaborate sequence of ops to grab those chars, paste them in the
wrong place when your mouse hand jiggles, delete, and try again, etc).
It's interesting to note that Winograd's two papers (from 1974 and 1979)
talk about all kinds of things that a PE should have, but with no mention
of graphics anywhere.
The first assertion appears to be true, and is a sad comment on the
sophistication of today's expert system tools. If expert system
environments are just PEs, why not just supply PEs? What's the
important difference between a Lisp stack backtrace and a rule
system backtrace? Why can't today's expert system tools at least
provide a TMS and some detailed explanation facilities? Why
hasn't anybody included some meta-level knowledge about the tool
itself, as opposed to supplying an inscrutable block of code and
a (possibly correct) user's manual? I don't understand. It seems
as though the programming mentality reigns supreme (if you don't
understand that remark, go back and carefully reread Winograd's
1979 paper "Beyond Programming Languages" (in CACM, and reprinted
in the abovementioned book).
stan shebs