norman@sdics.ucsd.EDU (Donald A Norman-UCSD Cog Sci Dept) (12/09/88)
In thinking over Chuck Clanton's excellent summary of the issues and
findings of his experiments on the "window focus" problem, it occurred
to me that all of this may simply be a reflection of our current
primative technology. In many ways, the use of multiple windows is
like the multiple work areas and stacks of papers on our desks. I
have many piles of paper on my desk and shelves, but when I wish to
add some thoughts to one working paper, I never make the mistake of
writing onto the wrong paper. This is because in the real world,
there is a direct coupling between the item being worked on and the
tools and place of working. With most of today's computer systems,
there is a decoupling of these: the work area is on the screen, but
the tool is a mouse or keyboard on the desk.
When we reach the point of having high-resolution, touch and
stylus sensitive work surfaces mounted within the desk (or like a
clipboard), then the entire problem will disappear, because when we
will wish to work on one task, we will write directly onto the screen
representation for that task.
Maybe.
(And thinking of the issue this way makes me realize that it is
exactly what Steve Draper was referring to in his chapter on
"inter-referential i-o," this horrible name meaning the relationship
between what is referred to by the input and the output: in direct
manipulation (DM) systems, the input and the output are the same. My
pen working on the manuscript on the table is this kind of a DM
system. My mouse-based window-driven Macintosh is a mimic of a DM
system, but it loses in directness because of the loose coupling
between the place on which I do my actions (the keyboard and mouse)
and the place on which the output occurs (the window). Which is why
my input sometimes go to the wrong place.
Draper, S. (1986). Display managers as the basis for user-machine
communication. In D. A. Norman & S. W. Draper (Eds.), User centered
system design. Hillsdale, NJ: Lawrence Erlbaum Associates
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.]johnm@amdahl.uts.amdahl.com (John Murray) (12/13/88)
In article <663@sdics.ucsd.EDU>, norman@sdics.ucsd.EDU (Donald A Norman-UCSD Cog Sci Dept) writes: > I have many piles of paper on my desk and shelves, but when I wish to > add some thoughts to one working paper, I never make the mistake of > writing onto the wrong paper. I don't think I agree here. When in a hurry (to note a phone number or something), I find myself scribbling on the corner of a convenient piece of paper without checking whether it should be "defaced" or not. It seems there are circumstances where (some) people use whatever is to hand - usually those who don't keep Postit pads all around them! Of course, this is a case where one's attention is elsewhere; I usually "add some thoughts" to the right paper, as Don says (assuming I can find it!). Given the subject line of this discussion, I find it odd that no-one has mentioned the possibility of actually de-focussing the non-active windows. I envision making them fuzzy enough to be difficult to read, but not so much that changes and incoming messages could not be noticed. For many terminal displays, the resolution may not be good enough to achieve the right effect, but I haven't heard of anyone trying the idea. - John Murray, Amdahl Corp., Sunnyvale, CA (408) 746 6282 ...amdahl.amdahl.com!johnm
trejo@nprdc.arpa (Leonard J. Trejo) (12/14/88)
In article <dfaFK09aNA1010vk5y2@amdahl.uts.amdahl.com> johnm@amdahl.uts.amdahl.com (John Murray) writes: >Given the subject line of this discussion, I find it odd that no-one >has mentioned the possibility of actually de-focussing the non-active >windows. I envision making them fuzzy enough to be difficult to read, >but not so much that changes and incoming messages could not be noticed. >For many terminal displays, the resolution may not be good enough to >achieve the right effect, but I haven't heard of anyone trying the idea. In my second contribution to this discussion I suggested that lowering the contrast in unselected portions of the display might be an effective way of perceptually segregating those portions from the selected area, which would remain at normal contrast. Lowering contrast would be easier to achieve than simulated blurring on most displays since only moderate gray-scale resoution--not high spatial resolution--is required. I think physical blurring of selected display areas under software control is not technologically possible now. Nor do I think it ought to be, since all blurring would do is lower contrast at critical spatial frequencies anyway. Finally, blurring might affect visual performance more adversely than a direct contrast adjustment if it selectively attenuates contrast at spatial frequencies that serve as cues for accomodation--but this is probably an empirical issue. Overall, I've found the discussions very interesting. I'd like to comment soon about the issue of differential effects of wavelength on physiological measures. However, I'm afraid I'll have to wait until I have a bit more disposable time. 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 141 San Diego, CA 92152-6800
emoffatt@cognos.uucp (Eric Moffatt) (12/15/88)
In article <dfaFK09aNA1010vk5y2@amdahl.uts.amdahl.com> johnm@amdahl.uts.amdahl.com (John Murray) writes: [stuff deleted] > >Given the subject line of this discussion, I find it odd that no-one >has mentioned the possibility of actually de-focussing the non-active >windows. I envision making them fuzzy enough to be difficult to read, >but not so much that changes and incoming messages could not be noticed. >For many terminal displays, the resolution may not be good enough to >achieve the right effect, but I haven't heard of anyone trying the idea. > I too have never seen anything on this. It certainly is not used in any interface I have ever encountered. We have discussed the problem here, however, in relation to a multi-window application I'm doing the UI for so I can give a couple of possible implementations for interested parties: DE-FOCUS vers 1.0: a) Pick a dithering pattern of a desired density (amout of "defocus"). b) BLT the pattern to the WHOLE screen using INVERT raster op. c) BLT the pattern again ONLY in the areas which have "Focus". The result is that the areas with focus are "clear" while the rest of the screen is "smeared". Note that this implementation does not need to know ANYTHING about the status of the other areas of the screen. This version could be used on monochrome devices. DE-FOCUS vers 2.0 a) reserve a bitplane (ie. the highest) for this purpose. b) arrange the colour lookup table so that all colours which have '1' in the selected bitplane are "full colour" while those colours which have '0' are shown at some %age of the desired "full" colour. c) Draw a FILLED RECT on the selected bitplane (only) over the areas which have "focus" The result is a variable contrast adjustment (0-100% of "full colour") over ANY AREA of the screen. You could just as easily "hilite" circles, polygons, individual lines... It's a little expensive (costs half your colours) but produces a nice controllable "Fader" effect. Note that both these examples effectively do the same operation; they "dim/blurr" the WHOLE screen and then "hilight" are desired areas. This allows window focus to be accomplished only knowing about the window to be focused, not ALL the windows. Eric (Pixel Pusher) Moffatt P.S. While I'm posting, does anybody have any ideas on how to reflect that a given window is "Out of Date" (ie. MAY contain invalid data) ?? -- Eric Moffatt - Cognos Incorporated: 3755 Riverside Drive Voice: (613)738-1440 (Research) FAX: (613)738-0002 P.O. Box 9707 uucp: uunet!mitel!sce!cognos!emoffatt Ottawa, Ontario, arpa/internet: emoffatt%cognos.uucp@uunet.uu.net CANADA K1G 3Z4
wex@banzai-inst.sw.mcc.com (Alan Wexelblat) (12/15/88)
In article <1168@arctic.nprdc.arpa>, trejo@nprdc.arpa (Leonard J. Trejo)
suggests that we help focus by some sort of reduced-contrast or blurring
scheme. I just wanted to point out that the user's focus is not always so
simple as the-window-where-the-mouse-currently-sits.
For example, I frequently have tasks running in two or more windows at once.
I then use a buffering interface (such as more(1)) to allow me to control
the rate at which information is presented in one window while I type/take
action in another window. Even though my cursor remains most of the time in
the latter window, I would be extremely annoyed by a system that reduced my
ability to read other windows.
In summary - let's not get so hung up on focus that we forget why we
invented multi-window systems in the first place.
--
--Alan Wexelblat ARPA: WEX@MCC.COM
UUCP: {rutgers, uunet, &c}!cs.utexas.edu!milano!wex
The only problem is: what do you do when they come back with the broom?garye@hpdsla.HP.COM (Gary Ericson) (12/20/88)
> For example, I frequently have tasks running in two or more windows at once. > ... > Even though my cursor remains most of the time in > the latter window, I would be extremely annoyed by a system that reduced my > ability to read other windows. > --Alan Wexelblat ---------- I agree that de-focusing all windows but *the one I'm using* would probably be annoying. What about using some optical tricks to give a 3D *look* to the display so that windows on top seem to be *closer* than ones underneath? For instance using shadows and/or making the windows in the back smaller (including the font size) - the ones furthest back would be the smallest, and the user could choose how quickly windows got smaller (i.e., the *depth* of his overall display), and two windows side-by-side would be the same size. Gary Ericson - Hewlett-Packard, Technical Systems Division phone: (408)746-5098 mailstop: 101N email: gary@hpdsla9.hp.com
trejo@nprdc.arpa (Leonard J. Trejo) (12/21/88)
In article <1730@banzai-inst.sw.mcc.com> wex@banzai-inst.sw.mcc.com (Alan Wexelblat) writes: >In article <1168@arctic.nprdc.arpa>, trejo@nprdc.arpa (Leonard J. Trejo) >suggests that we help focus by some sort of reduced-contrast or blurring >scheme. I just wanted to point out that the user's focus is not always so >simple as the-window-where-the-mouse-currently-sits. > >For example, I frequently have tasks running in two or more windows at once. >I then use a buffering interface (such as more(1)) to allow me to control >the rate at which information is presented in one window while I type/take >action in another window. Even though my cursor remains most of the time in >the latter window, I would be extremely annoyed by a system that reduced my >ability to read other windows. > >In summary - let's not get so hung up on focus that we forget why we >invented multi-window systems in the first place. I think this is a very good point. Perceptual segregation schemes of the figure-ground variety, such as my color/contrast suggestion for windows, should not ignore task-related associations between different windows on the screen. Of course, my original proposal did not necessarily imply that readability would be significantly reduced in unselected windows, but I did ignore the possibility of task-related associations between windows. Perhaps in the situation that Alan Wexelblat describes the window which supports information processing in the active (e.g., mouse-containing) window could be tagged with the same color background or achromatic contrast level as the active window itself. In general, a group of windows defined by relationship to a specific task could all be marked the same way. This brings us back, then, to the need for a unique marker for the active window. Hmmm. Perhaps in such cases we could have the active window stand out in space using binocular depth cues. However, I think were at least 10 years away from having 3D displays on ordinary workstations. I wonder what others' frequency of task-related window groupings is? I have encountered two-window groupings in my work. Can't say I've ever had three. 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
steven@kylie.oz (Steven Sweeting) (12/22/88)
>In article <dfaFK09aNA1010vk5y2@amdahl.uts.amdahl.com> johnm@amdahl.uts.amdahl.com (John Murray) writes: > >DE-FOCUS vers 2.0 > > a) reserve a bitplane (ie. the highest) for this purpose. > > b) arrange the colour lookup table so that all colours which have '1' > in the selected bitplane are "full colour" while those colours which > have '0' are shown at some %age of the desired "full" colour. > > c) Draw a FILLED RECT on the selected bitplane (only) over the areas > which have "focus" I implemented this on an Amiga with a slight twist. I used the extra bitplane to give a different background colour to the active window. i.e. Normally white on black, active white on dark red. I quite liked it and would be using it all the time but for some reason after about 5 minutes my free list (Amigas have 1 per machine) was torn to bits. (O/S bug of course :-)) Being one bit-plane and a solid rectangular shape, it was always faster than the screen could refresh. For amigans, I added a dual-playfield to Workbench, which meant my own personalised bit-plane which didn't interfere with Workbench's colour set. >P.S. While I'm posting, does anybody have any ideas on how to reflect that > a given window is "Out of Date" (ie. MAY contain invalid data) ?? Clear the window. :-)/2 _____"I must create a system or be enslaved by another man's"__-Blake Steven Sweeting ACSnet: steven@kylie.oz Optech Research Pty. Ltd. Internet: steven@kylie.oz.au@uunet.uu.net Level 60, MLC Centre, PH +61(2) 235-0255 __ __ Martin Place Sydney 2000 FAX +61(2) 232-5067 /. `v' \ NSW Australia. \_/\+/\_/