Re: Two questions
Re: Two questions
- Subject: Re: Two questions
- From: "David W. Halliday" <email@hidden>
- Date: Mon, 28 May 2001 13:53:27 -0500
- Organization: Latin AmeriCom, formerly Latino Online
Fritz Anderson wrote:
>
At 1:49 PM -0400 5/27/2001, Bill Cheeseman wrote:
>
>on 5/27/01 9:31 AM, Mal Paine at email@hidden wrote:
>
>
>
> >>> For the Cocoa apps that I've written, I noticed that when clicking on
>
>>>> the window when it's in the background, if I click on a control, not
>
> >>> only is the window brought to the front, but the control is activated.
>
...
>
> >> All cocoa apps behave like this.
>
>>
>
>> And it's how ALL apps are supposed to behave under the Aqua Human Interface
>
>> guidelines....
>
>
>
>Is that still true? I hope so, because I think it is much more useful than
>
>the old Mac model. But Mac OS X 10.0 seems to have abandoned it for most
>
>apps, even the Finder.
>
>
Gosh, and I was about to hope that it wasn't true.
>
>
My experience is that when I want another window, my locus of
>
attention is on wanting the window, and am not yet focusing on
>
hitting (or missing) a particular place on the window. I've been
>
seriously inconvenienced by thinking I was activating a window, and
>
finding I was also inadvertently changing at least the state of its
>
display. Hitting the scroll bar while activating a window is very,
>
very easy.
>
>
I'm willing to be persuaded (by an informal user study) that this is
>
just my problem, caused by my being accustomed to the pre-X way of
>
doing things. However, I find I've accommodated pretty quickly to
>
things like the Aqua window controls and the Dock.
>
>
-- F
Actually, if what you desire to find out from an informal, or formal, user
study is whether it's more "natural" to users to have controls active or inactive
in background windows, then the problem you have is in obtaining an untainted user
population---unlike in the early days of the Mac, it's very hard to find users that
have not been tainted by one UI or another. (The same problem exists with trying
to get any similar answers about most any UI aspect, such as case
differentiation.) The best you can do is obtain a sufficiently large and diverse
population that you can determine how the population in general will react to any
given case, given their present biased experiences. (Thus basically eliminating
informal user studies altogether.)
What is being done, is 1) make sure that active vs. inactive UI elements
(particularly controls), in background windows, are visually distinct
(unfortunately, this means that inactive text, in background windows must be
displayed as such, rather than being indistinguishable from active text in
foreground windows, as has been the case with classic Mac OS, and is still the case
is most any Carbon app [unfortunately, this would make such inactive text harder to
read]); and 2) deactivate "destructive" controls in background windows (to aid the
user in not being adversely surprised---unfortunately, I'm not sure there can ever
be a definitive definition for "destructive").
As another issue in this vein. If you require two clicks to bring a window
forward followed by activation of the desired interface element, you run into the
potential of accidentally timing such clicks too close---thus producing a double
click (and similarly for cases where the desired action is obtained via a
multi-click event, becoming a higher order multi-click event). I'm not sure it
really works to simply reinterpret such multi-click events as a single click
followed by a lower order multi-click event (especially from the user's
standpoint)---though I could be wrong (are there any formal or informal user
studies on this issue?).
David email@hidden