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?