CLIM mail archive
[Prev][Next][Index][Thread]

[Daniel D Suthers <suthers+@pitt.edu>: Re: Acceptance of Accepting Value]


    Date: Sat, 12 Feb 1994 16:16:00 -0500 (EST)
    From: Daniel D Suthers <suthers+@pitt.edu>
    To: clim@BBN.COM
    Subject: Re: Acceptance of Accepting Values Panes
    Cc: buhr@ki6.informatik.uni-hamburg.de
    In-Reply-To: <9402112149.AA02700@ki6.informatik.uni-hamburg.de>

    > Some user testing showed, that 
    > 
    >     1. Users don't want to move the pointer into a text-field if
    >        there's only one at all. They immediately start typing 
    >        if the pointer is already in the AVPane.
    >         -- This has disturbing consequences: Characters are printed
    >        somewhere into the AVP itself or into other Panes, only Control-Z
    >        will lead out of this. 
    > 
    >     2. Users want to type <Return> instead of clicking the OK Button

    Similar experience here -- these problems are very consistent across
    users with various backgrounds. 

    It's unfortunate that a significant opportunity to come up with a usable
    standard was missed when early CLIM designers apparently assumed that
    existing interaction procedures they were familiar with were usable.  It
    would have been nice to see the CLIM standard justified by user testing.
    --------------------------------------------------
     Dan Suthers           | LRDC, room 505A
     suthers+@pitt.edu     | 3939 O'Hara Street
     (412) 624-7036 office | University of Pittsburgh
     (412) 624-9149 fax    | Pittsburgh, PA 15260
    --------------------------------------------------

Did anyone else notice the X-windows (vs, say Mac or Genera or
(default) Openwidows) presumption above: "if the pointer is already in
the AVPane"?  I guess everyone gets used to one way of doing things
and thinks it is the best, or at least obvious.   One goal that
Clim has is (eventually) striving for being consistent with the
base window system.  

Personally, I get very annoyed on my Mac when it asks me to log into a
file server and presents me with two fields (User name and Password)
to fill in.  I have to remember to type a <TAB> to go between them,
not a <CR> as I've used for a couple of decades.  The <CR> results in
a failed login attempt.  (I also just ran a Mac program with the "OK"
box having a double outline but it didn't activate on a <CR>.)

So, I disagree with the concept that a <CR> is the "best" way to
terminate the AVV queries.  When I'm typing in a non-AVV situation,
<CR> is what I use to terminate fields.  (eg, Paragraphs in MS Word or
lines in normal text).

In some sense it would make sense to exit on <CR> when I have only one
query in a AVV but then should that be different than when I have two
queries?  Imagine if you were presented with a system that had one way
of terminating one-query AVVs versus two-query AVVs!  I think the
confusion would be greater.  (I think having a key, such as "END" or
"F-99" is great -- I don't like going to the mouse.  But <CR> is
way too much overworked here.)

If you want to be consistent to the OS's "standard" window system, at
least in this case, you should be able to do it with CLIM.  I haven't
used MCL CLIM but it would seem to me that it would be trivial to
modify it so that the standard activation character was <TAB> (to
terminate inputs) and <CR> was taken to be the "<END>" key.  I suspect
that could be done without modifying any standard CLIM function by
just setting variables or wrapping a WITH-ACTIVATION-CHARACTERS around
the toplevel loop and using ADD-KEYSTROKE-TO-COMMAND-TABLE.     

(I don't know about going from field to field with a TAB.  I thought
Dynamic Windows may have had something like that (or maybe it was some 
specialized menus) but I don't recall anything like that in CLIM.  I
suspect this would require modifying AVV functions.)

Maybe the confusion would be less if people were lead to think of the
AVV exit as a "CONFIRM" button rather than an "OK" button.
-------
Main Index | Thread Index