chac@aratar.UUCP (Chuck Clanton) (11/16/88)
i would like to know what other people think about an issue that don norman provoked me into thinking about... the question has to do with the nature of feedback. any good tool provides feedback as you use it, for example you feel the hammer's position in your hand as you are pounding nails. this feedback is different in kind, i believe, from the information a tool may be designed to provide. for example, i should be able to read a measurement off of a ruler easily and quickly. that is what it is designed for. i may know very little about what makes a good hammer. for example, i know that the balance should be right, but i have no idea what "right" means except by feel. clearly its balance is not information that the hammer is intended to provide information about, rather it is intended to have balance as a property of its usage. so, we can categorize the information derived from a tool into two categories. the first, what i tend to call feedback, serves the specific purpose of making the tool easier to use, more comforting, less tiring, and less error prone. it is more a property than an intention. the second, what i tend to call the display data though this term is misleadingly descriptive (suggestions?), is unrelated to the first and has to do with providing the information the tool is designed to provide its user. this property may be very complex. for example, larry tesler has pointed out that the tracking properties for a mouse during selections on the screen should include hysteresis during tracking, and careful disregard of the final mouse movement during a button up. chris crawford provided very realistic ballistics in his atari game of Tank, and believes that complexity was important. these cases illustrate that complex feedback properties can simplify and enliven the use of some tool. unlike a complex display of data, well-designed but complex feedback may reduce the apparent complexity of the interface. here is the issue that brought this up. i have been using workstations with multiple windows for years. the first one i used, a long time ago, provided feedback about my current window (the window receiving my typing) that was sufficiently subtle that i was rarely conscious of it, but sufficiently apparent that i almost never made any mistakes. so, my awareness of my current window was subliminal. i was not even aware of the fact that i needed to pay attention to this. of course, the first few times i used this system, i noticed (and learned) the cues. after that it was second nature, as the feedback from a good tool should usually be, i think. my current windowing system has inadequate feedback. i often start typing when i think i am in one window, and i am actually in another (keyboard focus errors). it does provide feedback...if i look at the cursor or the window border, i see the information displayed. but it is not easily obtained, and i miss the cues often. here is what i conclude. in general, when designing an object to display data, i expect that the user wants the information and will acquire it intentionally. it should be displayed so that it is easy to obtain when the user makes the effort to acquire it. however, when designing an object for the user to work with, its feedback properties should by and large be very quiet. that is, i would like the user to always know what he or she needs to know while using this object, without ever making any effort to acquire that information. the needed information should be provided as feedback that requires no added effort to obtain, no intent. Chuck Clanton Seilergasse 8 CH-4500 Solothurn Switzerland uunet!mcvax!cernvax!pan!aratar!chac
trejo@nprdc.arpa (Leonard J. Trejo) (11/17/88)
In article <318@aratar.UUCP> chac@aratar.UUCP (Chuck Clanton) writes: >here is what i conclude. in general, when designing an object to display >data, i expect that the user wants the information and will acquire it >intentionally. it should be displayed so that it is easy to obtain when >the user makes the effort to acquire it. however, when designing an object >for the user to work with, its feedback properties should by and large >be very quiet. that is, i would like the user to always know what he or >she needs to know while using this object, without ever making any effort >to acquire that information. the needed information should be provided as >feedback that requires no added effort to obtain, no intent. Excuse the sarcasm, but... one excellent tool for displaying data is typed English text. By your own criteria, ease of acquisition, etc., writers ought to take advantage of well-overlearned features of typed text, such as capitalization of proper pronouns and the first word in a sentence. Seriously, I always find that it requires more effort to read text without capitalization than with it. This issue needn't bear directly on the questions you raise about feedback, although one might argue that capitalization provides a kind of positional feedback cue for the eye movement system during reading. Extending this concept to windows on computers, the symbols (cursors, borders, backgrounds, even colors?) which serve as a form of pictorial punctuation for the user, ought to be standardized soon so that the same kind of automaticity that develops in reading behavior will develop for window interactions. Perhaps the merits of automaticity in "window-reading" by early adoption of standards would outweigh the advantages of contiued refinements of window features. L. J. T. ============================================================================ ARPANET : trejo@nprdc.arpa UUCP: ucsd!nprdc!trejo Phone: (619) 553-7981 Postal Address: Leonard J. Trejo, Ph. D. (AV) 553-7981 NPRDC Code 14 San Diego, CA 92152-6800
norman@sdics.ucsd.EDU (Donald A Norman-UCSD Cog Sci Dept) (11/18/88)
A comment on Chuck Clanton's comment on feedback. The issue arose
from a private set of communicatins he and I had over his earlier
posting of a question about the "focus": problem -- how to specify
which window is active so that the user would not make the (common)
mode error of intending to operate upon the contens of one window, but
because it had not been formally selected, having the actionstake
effect upon another window.
Clanton thought the indicator ought to be subtle and "subliminal." I
suggested it should be fairly significant and available to conscious
knowledge. But the signal should not be overwhelming in magnitude,
because:
1. the signal should not distract (flashing the selected
window would be a very poor solution);
2. The non-selected windows should still be easy to use,
because one often is reading from or otherwise using the
material in the non-selected windows while working in the
selected one.
So, this leads to the very important set of questions Chuck Clanton
just asked in his last contribution.
The goal is to make the properties of the system obvious enough that
the new user can learn them (hence the need for signals that are
consciously available), yet subtle enough that the frequent user does
not have the normal work interfered with, so that the usage is
automatic, and, as a result, the user is not consciously aware of them.
This is a difficult and delicate question: providing just the level of
information that can serve these two different requirements.
A very good topic.
don norman
Donald A. Norman [ danorman@ucsd.edu BITNET: danorman@ucsd ]
Department of Cognitive Science C-015
University of California, San Diego
La Jolla, California 92093 USA
UNIX: {gatech,rutgers,ucbvax,uunet}!ucsd!danorman
[e-mail paths often fail: please give postal address and all e-mail addresses.]trejo@nprdc.arpa (Leonard J. Trejo) (11/20/88)
In article <651@sdics.ucsd.EDU> norman@sdics.UUCP (Donald A Norman-UCSD Cog Sci Dept) writes: >Clanton thought the indicator ought to be subtle and "subliminal." I >suggested it should be fairly significant and available to conscious >knowledge. But the signal should not be overwhelming in magnitude, >because: > 1. the signal should not distract (flashing the selected > window would be a very poor solution); > 2. The non-selected windows should still be easy to use, > because one often is reading from or otherwise using the > material in the non-selected windows while working in the > selected one. > >So, this leads to the very important set of questions Chuck Clanton >just asked in his last contribution. > >The goal is to make the properties of the system obvious enough that >the new user can learn them (hence the need for signals that are >consciously available), yet subtle enough that the frequent user does >not have the normal work interfered with, so that the usage is >automatic, and, as a result, the user is not consciously aware of them. >This is a difficult and delicate question: providing just the level of >information that can serve these two different requirements. > >A very good topic. > I agree that this is an important topic for discussion. Now feeling a bit guitly for jumping on Chuck's style versus content, I'd like to try to contribute something (sorry, Chuck!). One thing that is becoming increasingly clear in vision research is the value of color for defining objects against their backgrounds. Color is frequently abused in many displays but it does appear to significantly improve performance for two kinds of things: defining the extent of an object in the scene and for rapid search for objects distinguished from the background by color contrast. The first of these factors is greatly aided by color and lightness constancies, which operate to keep objects perceptually unitary in spite of significant variations in the light being emitted or reflected from them. This applies to CRT displays where we can easily ignore large gradual brightness fluctuations between the center and the edges. In addition, research has shown that searching based on large color differences is essentially automatic. For these reasons I'd expect that assignment of a unique background color to the active window would be superior to peripheral spatial cues (e.g., borders) or to temporal cues (e.g., flicker--I agree with Don Norman that this would be distracting). Many unobtrusive, yet easily discriminable color contrast combinations exist that would work for nearly all observers including those with red-green color deficiency. In order to avoid strong luminance contrasts between different windows--which could produce shifts in light adaptation levels and afterimages as the observer reads different areas-- the designer could use white for unselected windows and an isoluminant amber, blue, or other suitable shade for the selected window. The degree of saturation needed to distinguish the selected window needn't be so large as to produce colored afterimages when looked away from (in fact colors on CRTs are rarely saturated enough to do this). A big problem is the increased cost of high resolution color displays as compared to monochrome. But in its proper sense, "color" includes different shades of white. Therefore, it may be possible to choose a gray background which is easily discriminable from that of the rest of the display but which maintains enough luminance contrast to provide for unimpaired reading. One design would be to have black text on white background in the active window and white on black elsewhere. But having large differences between the different background areas on the display would impair legibility. A better design might use maximum contrast in the active window and 90% contrast in other windows. A bit of experimentation could determuine good contrast differences. I don't think we can eliminate borders--they will define the edges of windows much better than color contrast. L. J. T. ============================================================================ ARPANET : trejo@nprdc.arpa UUCP: ucsd!nprdc!trejo Phone: (619) 553-7981 Postal Address: Leonard J. Trejo, Ph. D. (AV) 553-7981 NPRDC Code 14 San Diego, CA 92152-6800
nick@hp-sdd.HP.COM (Nick Flor) (11/20/88)
Chuck Clanton writes (>) >here is what i conclude. in general, when designing an object to display >data, i expect that the user wants the information and will acquire it >intentionally. it should be displayed so that it is easy to obtain when >the user makes the effort to acquire it. Easy to obtain and understand... >however, when designing an object for the user to work with, its feedback >properties should by and large be very quiet. But what does that mean? If it's "quiet", you'll never notice the feedback. When my mouse pointer isn't on the proper window, it's being quiet and yet this property doesn't insure that "focus" errors won't occur. Clearly, a mouse pointer not being in the window the user wants to work in is quiet, but not good, feedback. (You even mentioned that the information for the windowing system you were using was on the side of the window and you often missed it. This is quiet feedback...) I feel that the feedback necessary to operate the tool correctly, i.e. the operational feedback, should be "loud" yet not interfere that much with the user's acquisition of data from the tool, i.e. informational feedback. Also, the operational feedback should be apparent in the visual area of interest. I think the problem is coming up with operational feedback that don't interfere with the informational feedback. I think some good examples are: a) Ghosting the non-active windows. This is the approach my Amiga takes. (ghosting is only displaying every other pixel) b) Making the non-active windows have a red background, or rather a background color different from the active window. c) Flashing the border of the non-active windows. > Chuck Clanton Or maybe we're just arguing about semantics... Nick
nick@hp-sdd.HP.COM (Nick Flor) (11/20/88)
In article <651@sdics.ucsd.EDU> norman@sdics.UUCP (Donald A Norman-UCSD Cog Sci Dept) writes: > >The goal is to make the properties of the system obvious enough that >the new user can learn them (hence the need for signals that are >consciously available), yet subtle enough that the frequent user does >not have the normal work interfered with, so that the usage is >automatic, and, as a result, the user is not consciously aware of them. >This is a difficult and delicate question: providing just the level of >information that can serve these two different requirements. > But if the operational feedback doesn't interfere with the informational feedback, then the expert user doesn't really care if these beginner feedback mechanisms exist or not. I don't feel the problem involves figuring out what level of feedback to provide, as much as it involves figuring out how to place the feedback mechanisms so that they don't interfere with the expert user. For instance, the terminal emulator program I am using has the name of the terminal emulator in the title bar of the window. I don't need that feedback, but I don't mind it being there. I still have an 80X24 line non-obscured display. Of course I'd take exception if it was in the middle of the display, or cut my working area to 60X24 lines. Nick
marty@homxc.UUCP (M.B.BRILLIANT) (11/22/88)
In article <651@sdics.ucsd.EDU>, norman@sdics.ucsd.EDU (Donald A Norman-UCSD Cog Sci Dept) writes: > A comment on Chuck Clanton's comment on feedback. The issue arose > from a private set of communicatins he and I had over his earlier > posting of a question about the "focus": problem -- how to specify > which window is active so that the user would not make the (common) > mode error of intending to operate upon the contens of one window, but > because it had not been formally selected, having the actionstake > effect upon another window. > ..... > The goal is to make the properties of the system obvious enough that > the new user can learn them (hence the need for signals that are > consciously available), yet subtle enough that the frequent user does > not have the normal work interfered with, so that the usage is > automatic, and, as a result, the user is not consciously aware of them. Two points an experienced (I won't say ``expert'') user would like to make. In the first place: Except for the first day, it isn't the new users who make focus errors. It's the expert users who have become so familiar with the system as to do things without much thought. The key term in the first paragraph is ``formally selected.'' Inexperenced users are careful to keep the formal requirements of the system in mind; experienced users keep in mind the work they use the system for. In the second place: Experienced users could work faster if they did not have to ``formally select'' the window to be worked in. A smart system would know which window the user is looking at, just as a person at a meeting can tell which member or members of the group the talker is talking to. For now, we have to put the burden on the user to know which window the stupid machine expects input for. As a goal, let's put the burden on the machine to figure out what the user wants. Ever since computer programming began, it has been a truism that the machine ``does what you tell it, not what you want.'' When will we advance beyond that? M. B. Brilliant Marty AT&T-BL HO 3D-520 (201) 949-1858 Holmdel, NJ 07733 att!houdi!marty1 Disclaimer: Opinions stated herein are mine unless and until my employer explicitly claims them; then I lose all rights to them.
ok@quintus.uucp (Richard A. O'Keefe) (11/23/88)
In article <4294@homxc.UUCP> marty@homxc.UUCP (M.B.BRILLIANT) writes: >In the second place: Experienced users could work faster if they did >not have to ``formally select'' the window to be worked in. A smart >system would know which window the user is looking at That isn't always the window I want selected, though. If my mailbox window flashes to indicate new mail, I'll look at it, but most of the time I'll stay with the window I'm working in. In a similar vein, when using a Sun I have click-to-type set, because when using non-mouse-oriented things I like to shove the mouse out of the way, and would be very frustrated if that deselected the window.
rogerh@arizona.edu (Roger Hayes) (12/02/88)
In article <1073@arctic.nprdc.arpa> trejo@nprdc.arpa (Leonard J. Trejo)
suggests background color as a cue to mark the active window.
It might be good to use a blue tint to mark the inactive window,
as blue tends to recede visually (as in "atmospheric perspective").
Note that stippling is an approximation to coloring.
I think the effect we want is a difference which is just above a
"just-noticable-difference". We want (or at least I think that I would
like) a difference which is perceptible if looked for, so that it is
accessible consciously, but which does not intrude, so that it
can be treated as a subliminal cue by experts.
I like the idea of a color change as it does not require a change
in focus to determine the active window. A border change requires
a change in focus to read, as does a change in the titlebar.
Roger Hayes
rogerh@arizona.educhac@aratar.UUCP (Chuck Clanton) (12/07/88)
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?