Re: Benchmarking the Explorer vs. the Symbolics

["Daniel L. Weinreb" <DLW@alderaan.scrc.symbolics.com>]

    Date: Wed, 24 Dec 86 19:41 EST
    From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>

    Who-calls is a good example. 

Actually, who-calls is a good example of one of the biggest problems
that faces us as system designers: different users have different needs.
You report that you use it twice a month.  Indeed, if you only NEED it
twice a month, then the expense of maintaining the table isn't worth it
for you.  On the other hand, now that who-calls (m-X List Callers, that
is, of course) is so fast, I use it very frequently.  During periods
when I'm doing serious programming, maintenance, etc, I use it many
times each hour.  Now, we know that there are different kinds of users,
but it's hard for us to know exactly how many there are of each kind.
So we put in options and switches so that you can customize and optimize
things for your own individual usage of the system.  Then we have to
choose a default, based on many considerations.  This particular default
setting was chosen only after a great deal of discussion and
consideration; I don't think I could do the discussion justice if I
tried to summarize it.  Then we described the switch settings in the
release notes, knowing that some people would immediately want to change
from the default setting to another setting.

    Overall, I think it may be a good thing to keep in mind that different users
    have different levels of expertese and different needs from the system.
    Advanced users should not have to pay the price of making the machine easy to
    use for novices. Novices should not have to have an unlearnable machine to
    make the machine powerful for experts. 

Indeed.  This is exactly the design philosophy we strive to apply.
Nearly every single user interface in our system shows some aspect of
this kind of design.  The use of the "accelerator" paradigm is a
pervasive example:  you provide menu-based or spelled-out ways to do
things, for people who are learning, and then provide single-character
or mouse-click ways for people who use the command often enough that
it's worth learning a less-mnemonic but faster command.  Now, you can
certainly debate the extent to which we actually succeed in attaining
those goals (especially in the older parts of the system).  But you'll
certainly get a lot of agreement about the desirability of the goals.

					   No one should have to pay a performance
    penalty for features they don't really need or at least rarely use, until they
    START to use them... Obviously this is an idealization...

Yes, exactly.  Sometimes you can't quite achieve this, because the system
sometimes needs to make a guess or prediction about what you are likely
to want.  For example, it wants to have that who-calls information nice
and ready for you, so that it can do a List Callers fast.  But it
doesn't know whether or not you are going to do a List Callers!  In these
cases, one solution is to put in those option switches I mentioned earlier.