|
|
MARK/SPACE, INC: The Missing Sync provides the very best in
synchronization for Mac users with BlackBerry, Palm OS, or
Windows Mobile devices. Integrates with Address Book, iCal,
Entourage, iPhoto, and iTunes. <http://www.markspace.com/bits>
|
TidBITS TidBITS TidBITS Talk 
Mac OS X Window Behavior mark522 (apparently) - 08:13am Mar 9, 2005 PSTvia emailI too iniitally found the OSX windowing behaviour difficult to get on
with initially. But I'm sort of mellowing towards finding it useful
now.
< http://db.tidbits.com/getbits.acgi?tbart=08012>
The G4Ti Powerbook isn't the largest screen real estate, and I'm now
finding uses for the OS X behaviour. But it does need some forethought
as to where you place the windows of different applications so you
can bring just the one window to the front that you want.
For instance I can bring just one BBEdit text document window to the
front along with a "Preview" window of a scan of a handwritten
document for transcription. I don't want all my BBEdit windows (or
GEDitCOM windows) jumping to the front, else I can't see the scan.
So I'm getting to the stage where I can make this non-OS 9 behaviour
work for me rather than against me.
But I must admit I still sometimes try to switch applications by
clicking top right in the menu bar. Old habits die hard.
Mark
Mark as Read
LKM (apparently)
-
Mar 16, 2005 8:53 am
(#45 Total: 64)
|
 |
|
|
via email - Lucas K. Mathis |
|
|
 |
| Posts: 80 |
Re: Mac OS X Window Behavior
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 15.3.2005, space aliens observed JolinWarren saying:
>I think from a new user's perspective the current situation is very
>confusing.
I can't quite follow the people who think the old windowing behaviour
was better for new users. The old windowing behaviour was bad, usability
wise, and a relic from older times when pre-Multifinder-Systems would
only run one app at a time.
Why is it bad? Because it introduces a side-effect to activating
windows. If you click on a window, you should expect this window to
become the frontmost window. Instead, the clicked window becomes the
frontmost window, while other windows from the same application move in
front of any other windows from other applications. This is clearly not
what a new user would expect, and it may look especially weird if said
new user doesn't yet fully grasp the idea that documents "belong" to
applications.
The current windowing behaviour seems more consistent and (apart from a
few applications) more useful.
One of the apps where the old behaviour worked better for me is
Mailsmith. I always have two windows open: Mailbox List and Connection
Status. Ideally, I would like those two to become active when I click on
a Mailsmith window, so right now I'm trying to duplicate fcchuan's idea
of using iKey for this. I have four commands in an iKey Shortcut:
"Activate Mailbox List", "Exchange with next", "Activate Connection
Status", "Exchange with next". These Commands have a "Mailsmith
activated" launcher. Unfortunately, its not quite working yet (it seems
to fire on "Mailsmith deactivated), but eventually I'll figure out
what's wrong.
So in most cases, the old windowing behaviour works better for me, and
for those where it doesn't, there are ways around it.
lucas
-----BEGIN PGP SIGNATURE-----
Version: PGP SDK 3.2.2
iQA/AwUBQjbJy7XYdom/dB2cEQLYnwCgyv6Pt56GjYBLtaFjiCJVVkqvQ30AoNEe
3KNLM+8nmVBPmyiKMqQVieJr
=teFj
-----END PGP SIGNATURE-----
|
|
 |  |
John C. Welch (apparently)
-
Mar 16, 2005 8:59 am
(#46 Total: 64)
|
 |
|
|
 |
| Posts: 773 |
Re: Mac OS X Window Behavior
On 3/16/05 7:04 AM, "Dan Frakes" <Dan  Frakes.org> wrote:
> First, the obvious one that no one has mentioned yet -- other than as a
> benefit -- is that OS X is inconsistent when it comes to windowing
> behavior. If you click on an application's icon in the Dock, all windows in
> that application are brought forward. If you use command+tab to switch to an
> application, all windows in that application are brought forward. But if you
> click on a window in an application to switch to that application, only that
> particular window is brought forward. Although power users may like this
> "flexibility," for a new user it's confusing (at least in my experiences
> working with new users). One of the Mac OS's hallmarks has always been
> consistency, and this behavior violates that consistency. Apple should
> approach this how they've done with many other interface options: Switching
> to an application always works the same way; if a different behavior is
> possible, it should be accessible either via a preference or via a modifier
> key.
You seem to be equating "Consistency" with "There can only ever be one
behavior for every action that has the same effect, i.e. App switching".
If you think the latter is consistency, then the Mac OS was never ever
consistent with regard to window behavior, not even in the Finder, and
indeed, went out of its way to make the most critical UI element for the
User, the Desktop, the most inconsistent and frustrating concept on the
planet. Just try explaining the Desktop to a new user:
"Where is it?"
"it's on your hard drive"
"Where?"
"At the base of your hard drive, just like the System Folder"
"I can't see it there"
"It's invisible"
"But I can see it all over the screen, and when I save a document, I can see
it there too"
"Well, it's only invisible in the Finder, and the contents aren't invisible"
"So I can open other invisible folders just like the Desktop?"
"No...well, sometimes...well, it depends...look, it doesn't make a lot of
sense, just try not to think about it a lot"
"Okay...hey, I ejected my Zip disk and all my files are gone"
"Well, they were on the disk"
"But I dragged them to my desktop"
"Each disk has its own desktop"
"But that doesn't happen with a CD"
"That's because the CD is read only, so when you drag it to the desktop it
copies"
"So how do I do this with a zip?"
"Option - Drag"
"but only sometimes?"
"Yes"
"And then I have two files with the same name, right next to each other, but
I can't really tell by looking which one is on my hard drive and which one
is on the zip, unless I eject the zip?"
"Precisely!"
"That's the stupidest thing I've ever heard."
"Precisely!"
Okay, so let's get off this idea that window behavior in OS 9 was consistent
by the "there can be only one access method" standard, because clearly, it
wasn't even close.
Is the result of your actions consistent when you click on the Dock? Yes.*
Is the result of your actions consistent when you cmd-tab? Yes*
*can app developers override this consistency at will and pooch the whole
thing up? Easily, and they often do, which makes the entire thing a mess.
>
> The second reason, which I concede is debatable but I contend is right ;-)
> is that OS X's default behavior just doesn't "seem right" to
> new-to-computers users. Say I'm a new user working on a Microsoft Word
> document, and I switch to Safari. I now want to get back to that document,
> but it's hidden behind the Safari window. If I see a different Word window
> peeking out, it seems logical to me that if I click on that Word window,
> I'll be switched back to Word -- and my desired document will be visible.
I've never seen any new user think this on their own. In fact, they seem to
expect the opposite, since that's how the real world works. If I have six
pieces of paper from the same project, and I cover one with a calendar, I
don't expect that when I stop using the calendar, that selecting a different
piece of paper will bring the one under the calendar out from under the
calendar.
The most common reaction I've seen was:
"Hey, where'd my browser go?"
"It's under all the Word windows"
"But I only clicked on that window, way over there"
"The OS Assumes that when you change apps, you want all the app windows."
"But I need to get stuff from the browser into THIS document"
"You'll have to make sure there's no word windows behind the browser, so
when you click on Word, the browser's still visible"
"That's stupid and really inconvenient"
"Yep, but it's consistent"
"Oh that's MUCH better"
Your statement assumes that the user is clicking on a different app window
to completely switch applications, for they are done working in the other
one, or, that they completely rely on cut/copy and past to move data between
applications. That's not the case, and a lot of people don't always use
cut/copy paste. They may want the same data, but formatted differently, in
which case they just re-type it, or they use drag and drop. In those two
very common cases, the OS 9 window behavior is a HUGE hindrance.
> In
> my experience with new users, this is exactly the scenario that occurs. Note
> that in Windows, this type of behavior makes more sense, because the menu
> bar is part of the document window -- each window is a discrete instance of
> the application/document. But in Mac OS X, where each application has a
> single menu bar along with separate document windows, it's counter-intuitive
> that switching to an application leaves some of its document windows hidden
> behind other applications.
Depends on what the user is doing. In a business setting, I've never seen
anyone who liked having to take minutes to position two windows so they can
read both at once.
>
> To be clear, I agree that the default OS X windowing behavior has
> advantages. I just think it should be an option rather than the default.
Only if there's a defaults to have it work the other way, ala more like the
physical world. There's enough inherent silliness with all computers where I
have to tell people 'You're right, it makes no sense at all, but at the same
time, that's just how it works." on ALL platforms. Making them HAVE to take
extra steps just to have two windows from two different apps simultaneously
visible isn't consistent, it's just annoying.
john
--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelch  bynkii.com
|
|
 |  |
Nigel Stanger (apparently)
-
Mar 17, 2005 10:28 am
(#47 Total: 64)
|
 |
|
|
via email - Dunedin, New Zealand |
|
|
 |
| Posts: 422 |
Re: Mac OS X Window Behavior
On 17/3/2005 2:04 AM, "Dan Frakes" <Dan  Frakes.org> spake thus:
> If I see a different Word window peeking out, it seems logical to me
> that if I click on that Word window, I'll be switched back to Word --
> and my desired document will be visible.
It seems logical, yes, but it doesn't always work. It's just as likely that
the document window that you _really_ wanted is buried under one of the
other Word windows, in which case you're no better off. This happens to me
all the time in BBEdit, as I can have up to ten or more files open at any
given time. It's almost a certainty in such cases that some windows will
cover others, and the ability to command-click (or right-click if you have a
two-button mouse, highly recommended) on the dock icon and choose exactly
the window I want is fantastic. The old behaviour used to drive me
completely berserk at times.
--
Nigel Stanger, Dunedin, NEW ZEALAND.
http://public.xdi.org/=nigel.stanger
|
|
 |  |
Nigel Stanger (apparently)
-
Mar 17, 2005 10:28 am
(#48 Total: 64)
|
 |
|
|
via email - Dunedin, New Zealand |
|
|
 |
| Posts: 422 |
Re: Mac OS X Window Behavior
On 17/3/2005 4:53 AM, "Michael T. Kupietz" <junk1204  kupietz.com> spake
thus:
> So when I'm in Eudora, and I need to bring a background finder window to
> the front to drag an icon into an open email as an attachment, then close
> that finder window, I want to be back in Eudora, where I was.
But what if you actually _want_ to stay in the Finder? In that case, jumping
back to Eudora would be equally infuriating. Despite our best efforts,
computers can't read minds yet :)
--
Nigel Stanger, Dunedin, NEW ZEALAND.
http://public.xdi.org/=nigel.stanger
|
|
 |  |
Dan Frakes (apparently)
-
Mar 17, 2005 10:43 am
(#49 Total: 64)
|
 |
|
|
 |
| Posts: 874 |
Re: Mac OS X Window Behavior
On 3/16/2005 7:59 AM, "John C. Welch" wrote:
>> First, the obvious one that no one has mentioned yet -- other than as a
>> benefit -- is that OS X is inconsistent when it comes to windowing
>> behavior. If you click on an application's icon in the Dock, all windows in
>> that application are brought forward. If you use command+tab to switch to an
>> application, all windows in that application are brought forward. But if you
>> click on a window in an application to switch to that application, only that
>> particular window is brought forward. Although power users may like this
>> "flexibility," for a new user it's confusing (at least in my experiences
>> working with new users). One of the Mac OS's hallmarks has always been
>> consistency, and this behavior violates that consistency. Apple should
>> approach this how they've done with many other interface options: Switching
>> to an application always works the same way; if a different behavior is
>> possible, it should be accessible either via a preference or via a modifier
>> key.
>
> You seem to be equating "Consistency" with "There can only ever be one
> behavior for every action that has the same effect, i.e. App switching".
Yep, that's correct. For a new user learning an OS, I definitely think the
act of switching between applications should be consistent. There can be
more than one way to perform the action, but the end result should be the
same. If there a different result is desired, the action should require a
modifier.
A good analogy is menu commands that have keyboard shortcuts -- two
different ways of doing the same thing. It would be confusing if using the
keyboard shortcut resulted in different behavior than selecting the menu
item with the mouse. So Apple and developers provide additional options via
modifier keys: File -> Get Info or Command+I in the Finder gives you the
Info window, whereas holding the Option key while performing either action
gives you the Inspector window.
From an interface standpoint, I just think it's bad UI to have three ways to
switch between applications where two behave one way and one behaves
another.
> If you think the latter is consistency, then the Mac OS was never ever
> consistent with regard to window behavior, not even in the Finder, and
> indeed, went out of its way to make the most critical UI element for the
> User, the Desktop, the most inconsistent and frustrating concept on the
> planet. Just try explaining the Desktop to a new user:
This is a valid criticism of the Desktop in OS 9, not a justification for
windowing behavior not being consistent ;-)
> Okay, so let's get off this idea that window behavior in OS 9 was consistent
> by the "there can be only one access method" standard, because clearly, it
> wasn't even close.
Again, this may well be the case, but my point here is that OS X's windowing
behavior should be consistent, not that OS 9 was or was not.
[more "seems right" vs. "seems wrong" stuff snipped, with all due respect to
John -- I'm just finding the above discussion more interesting right now ;-)
]
|
|
 |  |
nick170 (apparently)
-
Mar 17, 2005 10:43 am
(#50 Total: 64)
|
 |
|
|
via email - http://www.inmff.net |
|
|
 |
| Posts: 73 |
Re: Mac OS X Window Behavior
At 5:04 AM -0800 3/16/05, Google Kreme wrote:
>On 14 Mar 2005, at 14:00 :32, Chik Foo wrote:
>> I do like Mac OS X's "one-window-at-a-time" windowing behaviour for
>> the most part.
>>
>> However, for some applications this behaviour is not appropriate.
>> Stata 8 has a smallish command-line window which is senseless to use
>> without the results window visible at the same time.
>
>But this is a problem with Stata 8, not with OS X. Simply because an
>app does something like this (separate windows that are necessary at
>one) doesn't mean the OS is wrong. Sounds like the smallish
>command-line window maybe should be a floating window for Stata (I'm
>not familiar with the product) or else a single window with two panes.
An application can tell the OS to have two windows in the foreground
at the same time. Those of us using Eudora in Sponsored mode know
the behavior well. Anytime there is any Eudora window in the
foreground the ad is visible. If you have another window in the
foreground, the ad dissappears.
Nick
|
|
 |  |
nick170 (apparently)
-
Mar 17, 2005 10:43 am
(#51 Total: 64)
|
 |
|
|
via email - http://www.inmff.net |
|
|
 |
| Posts: 73 |
Re: Mac OS X Window Behavior
>On 3/16/05 7:04 AM, "Dan Frakes" <Dan  Frakes.org> wrote:
>If you think the latter is consistency, then the Mac OS was never ever
>consistent with regard to window behavior, not even in the Finder, and
>indeed, went out of its way to make the most critical UI element for the
>User, the Desktop, the most inconsistent and frustrating concept on the
>planet. Just try explaining the Desktop to a new user:
Ah, finally someone explains my annoyances with the old desktop.
When I fiddled around on OS 9 the whole desktop model confused me.
Part of the problem is the whole dynamic nature of it. I myself (and
I believe most users) find it makes more sense when the computer
stops thinking for you, and leaves things consistent.
Nick
|
|
 |  |
nick170 (apparently)
-
Mar 17, 2005 10:43 am
(#52 Total: 64)
|
 |
|
|
via email - http://www.inmff.net |
|
|
 |
| Posts: 73 |
Re: Mac OS X Window Behavior
At 7:53 AM -0800 3/16/05, Michael T. Kupietz wrote:
>When I followed the link in Tidbits, I actually thought this thread was
>going to be on a slightly different topic. Hopefully this isn't too
>off-topic, but I'm always amazed that the "should clicking on a window
>bring all forward for that app" question gets so much attention, while this
>one gets none: Was it really an improvement to make Finder windows slide
>out from under my mouse if I try to drop something into onto an icon within
>them, just because I chose to position them with one edge off the screen?
I had never run into this being a problem, so I played around and
found out what you're talking about.
I'll admit the behavior is a slight bit disconcerting if you're
attempting to move a file really quickly. But, the logic of it is
pretty clear: If you're going to drop something into a window, the
whole window must be visible before you do.
When using the Column view this is important. If this were not the
default behavior we'd have the problem to solve of when should the
window slide over to access the rest of the window? You could of
course define a threshold level at the edge of the screen, but you'd
run into the same problem then.
The default behavior could be the window doesn't move whatsoever.
Although this would probably create just as many discontent users.
I'd like to hear from some interface designers on this thread. I
know from my web development efforts that some people's "feature" is
the bane of my existence. (i.e. Java based sidebar menus, or Flash,
or bunches of dynamic HTML.)
Nick
|
|
 |  |
Michael T. Kupietz
-
Mar 17, 2005 10:43 am
(#53 Total: 64)
|
 |
|
|
 |
| Posts: 1 |
Re: Mac OS X Window Behavior
At 3/16/05 11:25 PM -0500, Nicholas Barnard wrote: At 7:53 AM -0800 3/16/05, Michael T. Kupietz (that's me!) wrote: >Hopefully this isn't too >off-topic, but I'm always amazed that the "should clicking on a window >bring all forward for that app" question gets so much attention, while >this >one gets none: Was it really an improvement to make Finder windows slide >out from under my mouse if I try to drop something into onto an icon >within >them, just because I chose to position them with one edge off the screen? I had never run into this being a problem, so I played around and found out what you're talking about. I'll admit the behavior is a slight bit disconcerting if you're attempting to move a file really quickly. I have to disagree with you on the matter of degree; I find it very
disconcerting. Maybe my particular reflexes are at precisely the wrong
speed for OS X but to me it's like a video game: I have to hit the target
before it moves. It doesn't help that there's a slight delay before it
slides, which means if you act quickly everything's where you expect but if
you think for half a second you miss it and wind up dropping something
somewhere you didn't want it. The problem, also, is that where the window moves to is essentially
arbitrary. I have a fundamental problem with trying to move something to a
target, but not knowing where that target will be until after you have
stopped moving - you have no way of knowing beforehand what will be under
your mouse at the end point of your motion. If you've ever read Bruce
Tognazzini, founder of the Apple Human Interface Group, he HATES this sort
of thing. (< http://www.asktog.com>) You need to be able to know the
position of your target (and of objects you *don't* want to target) before
you begin your gesture - not after you end it. That's just good design,
says I. But, the logic of it is pretty clear: If you're going to drop something into a window, the whole window must be visible before you do. That's just it.... I don't see why it is required that an entire window must* be showing. Why can't I make that decision for myself?
When using the Column view this is important. If this were not the default behavior we'd have the problem to solve of when should the window slide over to access the rest of the window?
Why should the window ever slide? If the user wanted part if it to be
showing, even in column view, they wouldn't have moved that part offscreen.
Ultimately in the situation of a window being partially off-screen, I would
rather make the user responsible 100% of the time than let the computer
second-guess the user 100% of the time, which is what happens now. Given
the choice I don't believe you should make a general rule of taking control
away from the user.
Wait, here's a second answer to your question: it should slide when your
mouse hits the edge of the screen, and no sooner. That's predictable,
unambiguous, and above all dragging something to the edge of the screen
isn't an ordinary behavior liable to be disrupted by it.
You could of course define a threshold level at the edge of the screen, but you'd run into the same problem then.
The default behavior could be the window doesn't move whatsoever. Although this would probably create just as many discontent users.
I have to respectfully disagree. I don't think there were complaints about
that behavior for the 16 years that it was the default. Popup windows,
when they arrived, definitely fulfilled a niche, but as I said, popup
windows were much better-designed than the current system, because they
never allowed you to think you were aiming for a particular target and then
at the last moment said "ha-ha!" and moved it out of the way. It was
either: all potential targets fully visible and stationary, or all
potential targets hidden except for the trigger that exposed them, and the
only movement was between those two states.
I'd like to hear from some interface designers on this thread.
I agree. I've taken the presumptuous step of cc'ing Tog on this, in the
hopes that his time & interest will allow him to participate in this
thread. (Tog, if you're with us, my original post which Nicholas Barnard is
responding to is #44 on this page:
<http://emperor.tidbits.com/TidBITS/Talk/367>) I'd definitely be interested
in anyone who can give some designer's-eye input.
I know from my web development efforts that some people's "feature" is the bane of my existence.
Heh. That's fer sure. I'm on leave from my job right now and they
"temporarily" handed my site over to someone else to work on without me
knowing... don't even get me started...
Thanks for some thought-provoking conversation!
Mike
|
|
 |  |
Chris Goedde
-
Mar 18, 2005 3:06 pm
(#54 Total: 64)
|
 |
|
|
 |
| Posts: 1 |
Re: Mac OS X Window Behavior
> Michael T. Kupietz wrote:
> I have to disagree with you on the matter of degree; I find it very
> disconcerting. Maybe my particular reflexes are at precisely the wrong
> speed for OS X but to me it's like a video game: I have to hit the
> target
> before it moves. It doesn't help that there's a slight delay before it
> slides, which means if you act quickly everything's where you expect
> but if
> you think for half a second you miss it and wind up dropping something
> somewhere you didn't want it.
Let me guess, you have the spring-loaded folders delay set to "short"
or there-abouts in the Finder's preference. I have mine set to "medium"
and it took me a bit of experimenting to figure out what you were
talking about, because my windows weren't sliding (until I
intentionally "hovered" for a good bit over the drop target). The
sliding only seems to occur when the spring-loaded action is triggered,
so if you have the delay set to short, it happens very quickly, and the
window jumps. Because of this, I see the logic of sliding the
window---the Finder is trying to show the entirety of the new target,
which is the contents of the old target.
I do agree that it is annoying though.
--
Chris Goedde
|
|
 |  |
John C. Welch (apparently)
-
Mar 18, 2005 3:06 pm
(#55 Total: 64)
|
 |
|
|
 |
| Posts: 773 |
Re: Mac OS X Window Behavior
[Since this discussion has devolved into one of the definition of "consistent," let's wrap it up. -Adam]
On 3/17/05 11:43 AM, "Dan Frakes" <Dan  Frakes.org> wrote:
>> You seem to be equating "Consistency" with "There can only ever be one
>> behavior for every action that has the same effect, i.e. App switching".
>
> Yep, that's correct. For a new user learning an OS, I definitely think the
> act of switching between applications should be consistent. There can be
> more than one way to perform the action, but the end result should be the
> same. If there a different result is desired, the action should require a
> modifier.
In that case, the Mac OS has never ever ever been consistent. Nor has any
other OS. Ever. Not even close. In fact, inconsistent behaviors have been
*championed* by Mac users as...being more intuitive.
Furthermore, nothing in life is that rigidly consistent. There are, with
almost everything you will ever do in your life, computer or otherwise,
multiple ways to do it, and multiple results for the same action.
So it's ridiculous to say that consistency is equal to "only one way to do
something", and in fact, your next paragraph is about to disprove it.
>
> A good analogy is menu commands that have keyboard shortcuts -- two
> different ways of doing the same thing. It would be confusing if using the
> keyboard shortcut resulted in different behavior than selecting the menu
> item with the mouse. So Apple and developers provide additional options via
> modifier keys: File -> Get Info or Command+I in the Finder gives you the
> Info window, whereas holding the Option key while performing either action
> gives you the Inspector window.
But now you have two ways to do something. Cmd+o or double click. That's
inconsistent. As well, cmd+o and double click is not consistent. You open
somethings with a double click, others without. Were we to follow the tenant
of absolute rigid consistency, then there is no sense in keyboard commands
that replicate mouse actions. If I can open a file via the mouse, then
creating a command key equivalent that perfectly replicates that action
creates multiple paths, and confusion.
Even swtiching applications. It used to be simple pre OS 8. You used the
mouse. Utterly consistent. And a real pain in the behind if you had 6 apps
open, and two had no windows. If you have no windows to click on, how do you
get to that application? So by creating multiple ways to do things, yes,
some consistency was lost, but the overall usability was increased.
Again, consistency is not an iron coat that is welded on and never removed,
never changed.
To force one behavior is to say that everyone will only ever use their
computer the same way. To force a modifier key is to start in with Eudora -
disease, where all the really useful stuff is hidden away in secret codes
that only the illuminati know about. Modifier key usage should be a last
resort, not a preferred method.
As well, the ALL OR NOTHING app switch in OS 9 was a total pain if you were
working with multiple documents in multiple apps at once. It was ungodly
painful. But you had no choice.
Now you do, and there's a lot of sense to it as well, but long time Mac
users tend to hate change.
1) I'm working in window a and I need data from window b. Click on window b,
get data, click on window a, use data. Simple. Under Mac OS 9, it was only
consistently simple if a and be were part of the same app. If they weren't,
then you frequently had to stop working to play window janitor. Under Mac OS
X, they're just containers for data. Window a contains html data from a
remote site, window b contains Word data that you're working on. Why do I
care about any other windows in either application? I'm only working with
those two. Forcing n other windows to spring forward and fall back just
creates more work for me, and computers are supposed to help me with that,
not hinder me.
2) I have a window in a program I'm working with, but I'm not sure where it
is, and in fact, it's buried under another window in that same program. OS
9's limited app switching/window management is again a hindrance here. OS X
allows me more flexibility with how I deal with windows, and I'm not even
talking about Expose. So I can work with the OS how *I* want to, not how the
OS forces me to. Macintosh, the computer for the rest of us? Well, the rest
of us don't all work the same, so why shouldn't the computer be more
flexible?
3) I finish printing a file and am working in another application. Okay,
printing's done, close the window. With OS 9: BAM...closing a window brings
up EVERY OTHER WINDOW in the application. With OS X, I close that one
window, but no context swtich between applications. So, with Mac OS 9, it
takes more steps to accomplish the same thing. Computers are supposed to
save time too.
And Mac OS X is consistent, but it has more options. However, each option is
consistent. Clicking a Dock icon produces a consistent response. Clicking a
window is a consistent response. Cmd-tab is consistent.
I get that people were used to the old way, but that's not better, that's
just familiar.
>
>> From an interface standpoint, I just think it's bad UI to have three ways to
> switch between applications where two behave one way and one behaves
> another.
>
>
>> If you think the latter is consistency, then the Mac OS was never ever
>> consistent with regard to window behavior, not even in the Finder, and
>> indeed, went out of its way to make the most critical UI element for the
>> User, the Desktop, the most inconsistent and frustrating concept on the
>> planet. Just try explaining the Desktop to a new user:
>
> This is a valid criticism of the Desktop in OS 9, not a justification for
> windowing behavior not being consistent ;-)
It shows that the whole "Mac OS 9 was more consistent" is a "in the good old
days" myth. It's a fable, a story, call it what you will. Mac OS 9 was never
a paragon of consistency, but we were all so used to it that we
unconsciously ignored the inconsistencies.
>
>
>> Okay, so let's get off this idea that window behavior in OS 9 was consistent
>> by the "there can be only one access method" standard, because clearly, it
>> wasn't even close.
>
> Again, this may well be the case, but my point here is that OS X's windowing
> behavior should be consistent, not that OS 9 was or was not.
>
> [more "seems right" vs. "seems wrong" stuff snipped, with all due respect to
> John -- I'm just finding the above discussion more interesting right now ;-)
> ]
The problem is, your definition of consistent is rather, to my eyes, rigid,
inflexible, and unusable in a modern computing environment. Mine is wildly
inconsistent, random, and hard to teach to you. So we can't even agree on a
definition for the core concept we're arguing here.
john
--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelch  bynkii.com
|
|
 |  |
John C. Welch (apparently)
-
Mar 18, 2005 3:06 pm
(#56 Total: 64)
|
 |
|
|
 |
| Posts: 773 |
Re: Mac OS X Window Behavior
On 3/17/05 11:43 AM, "Michael T. Kupietz" <junk1204  kupietz.com> wrote:
> I have to disagree with you on the matter of degree; I find it very
> disconcerting. Maybe my particular reflexes are at precisely the wrong
> speed for OS X but to me it's like a video game: I have to hit the target
> before it moves. It doesn't help that there's a slight delay before it
> slides, which means if you act quickly everything's where you expect but if
> you think for half a second you miss it and wind up dropping something
> somewhere you didn't want it.
Have you tried turning off Spring Loaded Folders in the Finder prefs?
--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelch  bynkii.com
|
|
 |  |
Nigel Stanger (apparently)
-
Mar 18, 2005 3:06 pm
(#57 Total: 64)
|
 |
|
|
via email - Dunedin, New Zealand |
|
|
 |
| Posts: 422 |
Re: Mac OS X Window Behavior
On 18/3/2005 6:43 AM, "Michael T. Kupietz" <junk1204  kupietz.com> spake
thus:
> It doesn't help that there's a slight delay before it
> slides, which means if you act quickly everything's where you expect but if
> you think for half a second you miss it and wind up dropping something
> somewhere you didn't want it.
The same effect occurs to a lesser extent with spring-loaded folders and
list views in the Finder. If you're dragging to a particular folder and
happen to linger too long over another, it pops open. I think there are
several ways to back of this, but it's still annoying.
More annoying (but probably not quite as annoying as the sliding window
effect) is when you drag something to a folder that appears near the bottom
of a list window, and there are more folders off the bottom. Again, if you
linger too long before dropping the item (and the delay isn't that long),
you find the list scrolls and you've just dropped the item into some random
folder. Undo helps, but this is again very annoying.
I think both of these situations could be improved by increasing the delay
before either action occurs (I know that the spring delay is configurable,
but I don't think the other is, unless the Finder uses the same value for
both). Both spring-loaded folders and auto-scroll in list views are
obviously far too useful to eliminate outright --- they just need tweaking.
--
Nigel Stanger, Dunedin, NEW ZEALAND.
http://public.xdi.org/=nigel.stanger
|
|
 |  |
Mark R. Williamson
-
Mar 18, 2005 3:06 pm
(#58 Total: 64)
|
 |
|
|
 |
| Posts: 1 |
Re: Mac OS X Window Behavior
At 9:43 -0800 2005-03-17, Michael T. Kupietz wrote:
>I have to disagree with you on the matter of degree; I find it very
>disconcerting. Maybe my particular reflexes are at precisely the wrong
>speed for OS X but to me it's like a video game: I have to hit the target
>before it moves. It doesn't help that there's a slight delay before it
>slides, which means if you act quickly everything's where you expect but if
>you think for half a second you miss it and wind up dropping something
>somewhere you didn't want it.
As with many other aspects of Mac OS X[1], I just got into the habit
of taking that half second for things to stabilize. I assume I'm
waiting for the frontmost application to get dispatched.
--Mark
[1] E,g,: If I'm too fast on the drag, I always miss the first few
characters of a string I'm trying to select, (Actually, it's usually
the last few characters, because I'm usually selecting from right to
left for some reason.)
|
|
 |  |
mwestley (apparently)
-
Mar 18, 2005 3:14 pm
(#59 Total: 64)
|
 |
|
|
 |
| Posts: 23 |
Re: Mac OS X Window Behavior
I have found this discussion interesting, but I have to say that I find
the windowing/application switching behavior consistent with the
concept that clicking on a window means you want to see that window,
and clicking on an application means you want to see that application.
I have a lot of windows open, and I often want to look at a web page,
for instance, to see information relevant to the application window I
am working with at the time. I appreciate the disentangling of windows
and applications, so I can use expose to grab the one window I need to
see, then go back to the application I am working on.
|
|
 |  |
SteveJ1 (apparently)
-
Mar 18, 2005 3:14 pm
(#60 Total: 64)
|
 |
|
|
 |
| Posts: 25 |
Re: Mac OS X Window Behavior
On Friday, March 18, 2005, at 05:13AM, <tidbits-talk  tidbits.com> wrote:
>
>From an interface standpoint, I just think it's bad UI to have three ways to
>switch between applications where two behave one way and one behaves
>another.
But, there are two possible ways of looking at the primary purpose of clicking on a window. It can either relate to switching applications, or to bringing a new window to the front. If you're viewing it as a method of switching applications, then it's inconsistent. If, however, you view it as a window function, you have to look at it this way: When you click on another window within an application, only that window comes forward. Thus, to be consistent as a window function, when you click on *any* background window, it should bring only that window forward, whether or not it's within the same application. If it's in a different application, it does switch active apps, but that's just a necessity to make the active window usable, it's not the purpose of the window click.
--Steve Johgart--
|
|
 |  |
Paul N. Schatz
-
Mar 18, 2005 3:14 pm
(#61 Total: 64)
|
 |
|
|
 |
| Posts: 1 |
Re: Mac OS X Window Behavior
Perhaps this is somewhat peripheral to the discussion, but an
extremely good way to avoid window clutter is to use an application
like CodeTek VirtualDesktop. With this kind of application, one can
make as many separate desktops as desired. Different projects, or
even different windows of the same project, can be accessed on
different desktops, and one can change desktops effortlessly by
simply clicking on a little pager in the corner of any desktop. This
is pretty much a standard feature of unix GUI implementations such as
Linux.
Extremely convenient.
--
Paul Schatz
Chem Dept
University of Virginia
|
|
 |  |
Dan Frakes (apparently)
-
Mar 21, 2005 1:09 pm
(#62 Total: 64)
|
 |
|
|
 |
| Posts: 874 |
Re: Mac OS X Window Behavior
> [Since this discussion has devolved into one of the definition of
> "consistent," let's wrap it up. -Adam]
Since John sort of (OK, pretty much completely ;-) ) misinterpreted my
position, one last response...
> Furthermore, nothing in life is that rigidly consistent. There are, with
> almost everything you will ever do in your life, computer or otherwise,
> multiple ways to do it, and multiple results for the same action.
>
> So it's ridiculous to say that consistency is equal to "only one way to do
> something"
Nowhere did I ever say there shouldn't be multiple ways to do something.
What I said is that if you have several ways to do the *same* thing, they
should be consistent in their result. Nothing more, nothing less.
[rest of the post snipped because it was in reaction to a position I never
took ;-)]
|
|
 |  |
JolinWarren (apparently)
-
Mar 21, 2005 1:09 pm
(#63 Total: 64)
|
 |
|
|
 |
| Posts: 150 |
Re: Mac OS X Window Behavior
At 14:06 on 18-3-05, John C. Welch wrote:
> I get that people were used to the old way, but that's not better, that's
> just familiar.
Being used to the old way does not _necessarily_ make it better. But
for some people it is better, for some people it isn't. "Better" is a
subjective term. I think it's clear that some people prefer one
behaviour, and some people prefer another. But there doesn't seem
much point in trying to prove that one way is definitively better
than the other, because it's a personal preference, not a case of
'right' and 'wrong.'
I think this thread of the discussion started as a debate of what
behaviour is more intuitive/less confusing for 'new' (or
inexperienced) users. But so far the evidence for what new users
prefer seems to have been from people's personal experience with
others which can lead to anecdotal evidence. It would be interesting
to know if anyone has properly studied how new users react to the two
different window-clicking behaviours (this is the kind of thing Apple
should be doing). Otherwise, I think all we can say is that we have
different personal experiences with this (which is a fantastic thing,
otherwise life would be very boring!) but it's difficult to draw
broad conclusions.
_________________
=> Jolin Warren, Edinburgh, Scotland
|
|
 |  |
John C. Welch (apparently)
-
Mar 22, 2005 10:35 am
(#64 Total: 64)
|
 |
|
|
 |
| Posts: 773 |
Re: Mac OS X Window Behavior
On 3/21/05 2:09 PM, "Dan Frakes" <Dan  Frakes.org> wrote:
>> Furthermore, nothing in life is that rigidly consistent. There are, with
>> almost everything you will ever do in your life, computer or otherwise,
>> multiple ways to do it, and multiple results for the same action.
>>
>> So it's ridiculous to say that consistency is equal to "only one way to do
>> something"
>
> Nowhere did I ever say there shouldn't be multiple ways to do something.
> What I said is that if you have several ways to do the *same* thing, they
> should be consistent in their result. Nothing more, nothing less.
They are that. Dock clicking gives a consistent response, as does window
clicking. What they don't give is the same response, nor should they. Not
every single click outside of the current application means you want to have
EVERY window for whatever you clicked in come to the front.
Mac OS X gives you a way to EITHER switch applications OR switch windows,
and it does so in a consistent fashion. OS 9 ONLY allowed app switching. You
couldn't just bring a window forward without bringing every window for that
application forward. I fail to see how limiting your ability to do work
without yet another modifier key combo is better.
--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelch  bynkii.com
|
|
|
TidBITS TidBITS TidBITS Talk Mac OS X Window Behavior
|
|