Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!cernvax!pan!aratar!chac
From: chac@aratar.UUCP (Chuck Clanton)
Newsgroups: comp.cog-eng
Subject: Re: subliminal feedback
Summary: summary of what i have learned from the net, with additions
Keywords: feedback windowing interfaces
Message-ID: <329@aratar.UUCP>
Date: 7 Dec 88 03:49:18 GMT
References: <318@aratar.UUCP> <651@sdics.ucsd.EDU> <1073@arctic.nprdc.arpa> <8134@megaron.arizona.edu>
Lines: 66


i found everyone's comments about my posting on subliminal feedback 
most interesting.  i had not recognized that this is primarily an expert 
user interface issue, as pointed out by nick flor, though obviously that
is indeed so.  i also liked his use of the words "operational vs
informational feedback".  i believe that my original question was well 
answered by don norman--the ideal operational feedback should be sufficiently
obvious that it is readily available to conscious knowledge for the novice
learning it and sufficiently non-distracting (quiet) that it can readily
become subliminal for the expert.  (hope i am not putting unintended words
in your mouth, don.)  as he says, it is the designer's art to find this 
balance.  this seems like the opposite of a "just noticable difference" 
phenomena.  in some sense i would like the most available possible
feedback for the novice that can somehow also be the least distracting to
the expert.  the example i mentioned was operational feedback indicating the 
current focus window.  several responses clarified this specific situation 
for me.

while don norman and leonard trejo both pointed out the disadvantage of
temporal feedback like flicker or flashing the window, i tried it before
reading their comments.  my theory was that central (foveal) vision is
primarily designed for high acuity static visual perception, and peripheral
vision is designed primarily for recognition of movement (which provokes
orientation toward the movement).  so, if a peripheral stimuli can be used,
it should probably be changing rather than a static border difference for
example.  i implemented a marquis border in several different patterns
and speeds.  my anecdotal report is...ugh, they are right.  it is far too
distracting, and this distracting effect attenuates very slowly.

however i dont find that static border differences (as used by X windows) 
are an adequate solution.  that is precisely the environment where i have 
been observing focus errors for over a year in a small number of highly 
experienced programmers.  (i have noticed that on a 14" screen i make fewer 
focus errors than on a 17" screen with the same number of pixels.  this adds 
to my suspicion that the information needs to be presented within foveal 
vision.)  i also do not think any cursor effects can be the solution. to 
explain why, let me state my assumptions which were not clear before.  i 
am interested in environments where several different applications are 
likely to be running concurrently in different windows.  the selection of
the focus window, and the display information which indicates the focus 
window, should be handled by the window manager not the application.  this 
operational feedback must not interfere with the informational feedback.
many replies assumed that windows contain text and the color of that text 
and its background can be freely changed.  this is a very limited subset of
all interesting applications.  many applications are likely to use color 
and cursor shapes as part of their informational feedback.   these cannot
be safely overridden by the window manager to provide operational feedback.  

logically, it seems to me that the places to look for operational feedback
are outside the window (the border) and "over" the window.  the former
has the problem of distance from the direction of gaze (which worsens with
larger windows and screens), so it is too quiet to meet our initial criteria
of balancing availability with minimal distraction.  that leaves us with
"over" the window.  in my experience, stippling with a sparse grid of dots
has worked on monochrome screens with primarily text based applications.  
(presumably the dots should be somewhat closer together than the diameter
of foveal vision).  i am not surprised to hear that ghosting also works.  
however, i am not sure how well either of these work with applications 
using color to provide important information.  and how do you select the 
color of the stipple?  to avoid disappearing, it should be a contrasting 
color, but if the window contains a highly patterned object, it is not 
clear that merely picking a contrasting color for each ghosted or stippled 
dot is adequate.  any thoughts?  and of course, by definition, a stipple
will interfere with informational feedback, is it reasonable to assume
that for all reasonable applications, the interference of a sparse stipple 
is slight enough to be an acceptable choice?