I agree. However, while grouping windows (after all, isn't that all a tabbed set of windows it?), we might as well be able to group windows from several different apps together rather than a single app. And then, windows have different sizes and shapes when they come from different apps, so maybe we should just leave them be their own, but keep the group together. In fact, this is sounding more like virtual desktops now....
This is exactly how I use the fluxbox WM under linux.
And this is how they can become a general-purpose UI feature.
Once you're thinking this way, then questions start falling out that push the feature in a direction that's truly Mac-like: What are the standard features that should be supported (drag and drop, for one - it's too fundamental a part of the OS for its support to ever be considered a "feature" of some widget)? What are the standard keyboard navigation commands? What are the commands (if any) for dismissing, or creating, or minimizing, a "dock" of windows? If one of these "docks" is foregrounded, does command-N create a new "tab"? Etc.
Once you have a consistent and complete framework in place, so that navigation and use of this kind of MDI is discoverable and intuitive, then we can start calling MDI on the Mac a feature. Right now, it's just a hack. An occasionally brilliant hack, perhaps. An occasionally suitable hack, arguably. But still a hack that breaks one of the most fundamental assumptions of the Mac UI - that a window corresponds exactly to a document - and which doesn't even try to fix it, or compensate.
Tabs are perhaps the most misused and abused UI element in the history of GUIs. While they do have excellent uses, too often they are used as a copout for proper interaction design.
Every few years these discussions come up and I get an itch to go dig up my old posts on the subject.
Here are a couple not yet posted to this board. They were written in response to a similar rumor about tabs being slated for the next release of Safari.
The dangers of tabs
There exist people who don't want even an option for tabs in safari. It is possible that some of these people are merely vindictive or egotistical, wanting everyone to do things 'their' way.
Yet, I believe that those who advocate a non-tabbed safari hold their position for purely benevolent reasons. Its not that we want to bend other people to our will, rather, we are striving for interfaces that are best for the greatest number of users.
Tabs can accelerate some users' typical workflows, yet are accompanied by inherent dangers. Most of these have to do with the broken association of 'the document is your window'. Window widget and File menu items have overloaded functionality whenever you introduce multiple documents into a single window.
Optional tabs would certainly make some people's lives easier. They are analogous to installing a non-shielded band saw in a high school wood shop. It will speed up some of the students' woodworking. Band saw use is optional and even advised against by default. But someday, the students will start using that band saw and this use can be quite dangerous. The delete key could function as a non-confirmed file-delete in the finder. Yet even if optional, this would be a bad feature.
Even optional features will eventually be turned on accidentally by novices. Experienced users are likely to make habitual errors. Example: While doing your taxes on line, you click on a help link, spawning a new window/tab. After reading the help, you close the window...
Widgets with overloaded functionality, capable of destroying non-visible user created data, are bad.
No matter how tabs are embodied, they still exhibit the flaws inherent to placing multiple documents in a single window.
More tab theory
To summarize: Tabs can accelerate some users' typical workflows. Tabs make it easy for many users to accidentally destroy data. Making tabs an optional feature does not obviate either of these two points.
Here are a few points that seem to have been neglected. The Macintosh is based upon a GUI philosophy/design known as direct manipulation. This means that objects in the interface are closely analogous to objects in the real world. They can be manipulated in the same manner as real world objects. The Macintosh GUI is also document driven. Meaning documents are the conceptual unit that users must deal with. They are represented as a single file in the Finder and when double clicked, open into a single window. The window IS your document.
Tabbed documents are theoretically an option for all document-based applications and the slew of new apps blurring the line between user generated data and 3rd party provided functionality. If we don't want to have different document interaction techniques for every single application, tab functionality must be built into the windowing system. Otherwise, every time you use a new application, you'll be left just guessing what the window close widget does.
Tabbed documents overload the functionality of window widgets and break the one to one ratio of documents to windows. This is a fundamental divergence from apple's direct manipulation GUI paradigm. Apple has only occasionally put multiple user-modified documents into a single window. The most notable instance is in project builder. However, web-browsers have a drastically different user base than do IDEs.
Apple analyzed the trade off. Window control ambiguity is an acceptable sacrifice if you assume that all users are experts. This assumption cannot be made for safari. I really hope that tabs don't get added to Mac OS X document based applications. Tabs are not a new concept and have been purposely left out of the window server.
I can't imagine trying to explain tabs to my grandma. Even my brother would probably mess up his online taxes. At first its simple... but then try to explain what the file menu items pertain to. With tabs, there is no constant scope for the File menu.
The 'Window is your document' metaphor is the least error prone metaphor yet invented for manipulating user created data.
The value of a 1-to-1 ratio between documents and windows is all too easily underestimated by people who didn't experience the pre-direct-manipulation-era.
Tabs are perhaps the most misused and abused UI element in the history of GUIs. While they do have excellent uses, too often they are used as a copout for proper interaction design.
Every few years these discussions come up and I get an itch to go dig up my old posts on the subject.
Here are a couple not yet posted to this board. They were written in response to a similar rumor about tabs being slated for the next release of Safari.
The dangers of tabs
There exist people who don't want even an option for tabs in safari. It is possible that some of these people are merely vindictive or egotistical, wanting everyone to do things 'their' way.
Yet, I believe that those who advocate a non-tabbed safari hold their position for purely benevolent reasons. Its not that we want to bend other people to our will, rather, we are striving for interfaces that are best for the greatest number of users.
Tabs can accelerate some users' typical workflows, yet are accompanied by inherent dangers. Most of these have to do with the broken association of 'the document is your window'. Window widget and File menu items have overloaded functionality whenever you introduce multiple documents into a single window.
Optional tabs would certainly make some people's lives easier. They are analogous to installing a non-shielded band saw in a high school wood shop. It will speed up some of the students' woodworking. Band saw use is optional and even advised against by default. But someday, the students will start using that band saw and this use can be quite dangerous. The delete key could function as a non-confirmed file-delete in the finder. Yet even if optional, this would be a bad feature.
Even optional features will eventually be turned on accidentally by novices. Experienced users are likely to make habitual errors. Example: While doing your taxes on line, you click on a help link, spawning a new window/tab. After reading the help, you close the window...
Widgets with overloaded functionality, capable of destroying non-visible user created data, are bad.
No matter how tabs are embodied, they still exhibit the flaws inherent to placing multiple documents in a single window.
More tab theory
To summarize: Tabs can accelerate some users' typical workflows. Tabs make it easy for many users to accidentally destroy data. Making tabs an optional feature does not obviate either of these two points.
Here are a few points that seem to have been neglected. The Macintosh is based upon a GUI philosophy/design known as direct manipulation. This means that objects in the interface are closely analogous to objects in the real world. They can be manipulated in the same manner as real world objects. The Macintosh GUI is also document driven. Meaning documents are the conceptual unit that users must deal with. They are represented as a single file in the Finder and when double clicked, open into a single window. The window IS your document.
Tabbed documents are theoretically an option for all document-based applications and the slew of new apps blurring the line between user generated data and 3rd party provided functionality. If we don't want to have different document interaction techniques for every single application, tab functionality must be built into the windowing system. Otherwise, every time you use a new application, you'll be left just guessing what the window close widget does.
Tabbed documents overload the functionality of window widgets and break the one to one ratio of documents to windows. This is a fundamental divergence from apple's direct manipulation GUI paradigm. Apple has only occasionally put multiple user-modified documents into a single window. The most notable instance is in project builder. However, web-browsers have a drastically different user base than do IDEs.
Apple analyzed the trade off. Window control ambiguity is an acceptable sacrifice if you assume that all users are experts. This assumption cannot be made for safari. I really hope that tabs don't get added to Mac OS X document based applications. Tabs are not a new concept and have been purposely left out of the window server.
I can't imagine trying to explain tabs to my grandma. Even my brother would probably mess up his online taxes. At first its simple... but then try to explain what the file menu items pertain to. With tabs, there is no constant scope for the File menu.
The 'Window is your document' metaphor is the least error prone metaphor yet invented for manipulating user created data.
The value of a 1-to-1 ratio between documents and windows is all too easily underestimated by people who didn't experience the pre-direct-manipulation-era.
[Edited formatting]
What about my notepad with it's little tabs I can use to choose to skip on to what I want to use? It's a real world analogy if any.
first off, i have to say this discussion is very enlightening. but i'll submit my opinion on the matter as a user rather than an interface designer.
i find tabs to be invaluable because i value having my workspace on my computer organized. even with expose i simply do NOT like having many open windows. however, i like to pre-open all of the webpages that i'd like to read in the near future. this thread, for instance is one of the many threads in the os x subforum that i'd like to read. so i open each new thread into a tab and close each tab when i'm done with the thread (as i will do in a few minutes here). for webbrowsing i find tabs to be a fantastic interface design because i PREFER to have all the pages open under one umbrella app window. if i need to spawn a separate window because i'm dealing with different subject matter or a page that i feel warrants its own window for emphasis, i can still do that as well.
as for adium, tabs are one of the major reasons i use that app. while some of you may feel that expose performs the same purpose as tabs in an im app, i'll simply say i disagree with you from my own experience. one of the major issues i have with ichat and window-cycling ichat windows is that it's not clear which order the windows will be focused. i don't always arrange my windows in side-by-side, sometimes i'll have them in a 2x2 grid. in that case, window cycling is inconvenient because i can't say with certainty which window will be cycled to next. with tabs, i can decide direction without doubt and it's very easy to count the number of steps necessary to reach the desired window.
you could say that i could expose the whole app and then cycle or click to the window. i find in that case that the most recently active window is hard to discern from the others. in adium, the tab has an indication of which window has most recently been updated. i actually don't like to leave buddy icons activated in my chat windows because i find them obnoxious. the arguments some of you are making in favor of expose seem to assume buddy icons are active. also, i don't use single application expose very often. while that might be more of an issue of my habits, it is still obviously an interface issue since i prefer tabs to single-app expose.
the real reason i like tabs in expose (and safari) is probably why most people like them: i simply don't like having so many windows open. i've had 4 or 5 chats open at the same time in ichat. i don't like seeing that many windows open, especially since some of those chats have very slow interaction. if one person replies to me every 5 minutes, it's irritating for me to have that one window open and as visually prominent as a window that is very active. and i'd rather not dispose of a chat window for the infrequent repliers because it disrupts the continuity of the chat lot. to me, it's a much better solution to leave it there and just tab to it when i need it. the logic is similar to why i don't quit apps anymore in os x. i'd rather have it there for immediate use and reaction. and when i'm not using it it remains relatively hidden.
That's because Windows isn't a multitasker's OS and you're not a multitasker. I am however...I like to be able to see things going on in multiple windows at the same time.
Huh? I _am_ a multitasker. I usually have about five to ten programs running, ten tabs in the browser, two IM conversations, etc. I just think a window should be either well visible, or not visible at all. Having a little corner of a window visible underneath other ones is useless, and it becomes more useless when there are 20 of those little corners peeking out below the frontmost program. It's very useful to have a full-sized text editor, an almost full-sized web browser and a small text editor window open, fully visible, not on top of each other.
Many times I have seen my mom struggle because she has lost some window behind all other windows, and it's not evident that the window is still open. IMO this is worse than Windows' approach, which is not exactly stellar either. There you at least have clear indicator (the Taskbar) that tells you which windows exist either in minimized or visible form. On OS X, the windows can be behind each other, plain hidden (cmd-H), or the most useless of all, minimized as microscopic icons in the Dock. The only tools that bring some order to this chaos, option-tab and Expose, are both stateful interfaces, weak (think about drag and drop for instance), need memorized keys, aren't clean and orthogonal, don't help at all when using minimized windows.
Huh? I _am_ a multitasker. I usually have about five to ten programs running, ten tabs in the browser, two IM conversations, etc. I just think a window should be either well visible, or not visible at all. Having a little corner of a window visible underneath other ones is useless, and it becomes more useless when there are 20 of those little corners peeking out below the frontmost program. It's very useful to have a full-sized text editor, an almost full-sized web browser and a small text editor window open, fully visible, not on top of each other.
Absolutely. I currently have 12 windows open in SubEthaEdit, where I'm coding my research, each about 1/2 full screen, and three Terminal windows, about the same size... and that's just on one of four virtual desktops.
Tabs would kill my workflow dead, however. I'm constantly moving text from window to window, using translucency of Terminal windows to check running processes behind the current window, etc. I could never do that with tabs. Expose makes window selection fast, easy, and straightforward, *without* breaking drag and drop, for instance, which I use constantly.
Quote:
Many times I have seen my mom struggle because she has lost some window behind all other windows, and it's not evident that the window is still open. IMO this is worse than Windows' approach, which is not exactly stellar either. There you at least have clear indicator (the Taskbar) that tells you which windows exist either in minimized or visible form. On OS X, the windows can be behind each other, plain hidden (cmd-H), or the most useless of all, minimized as microscopic icons in the Dock. The only tools that bring some order to this chaos, option-tab and Expose, are both stateful interfaces, weak (think about drag and drop for instance), need memorized keys, aren't clean and orthogonal, don't help at all when using minimized windows. [/B]
Er, actually Expose works perfectly with drag and drop, and Cmd-Tab/Cmd-` (not option-tab, I'll assume that was a simple mistake on your part) are *absolutely* orthogonal.
Cmd-Tab: cycle applications
Cmd-`: cycle windows in one application
Expose: random, direct graphical access
You can't get much more orthogonal than that.
If your mother (or you) is having problems finding windows, try ctrl-clicking, right-clicking, or click-and-hold on a app's Dock icon for a list of all windows for that app. Or use the Window menu. Very little room for confusion there.
Tabs would kill my workflow dead, however. I'm constantly moving text from window to window, using translucency of Terminal windows to check running processes behind the current window, etc. I could never do that with tabs. Expose makes window selection fast, easy, and straightforward, *without* breaking drag and drop, for instance, which I use constantly.
I wasn't defending tabs, actually. I was criticizing the OS X window management as a whole.
Quote:
Er, actually Expose works perfectly with drag and drop, and Cmd-Tab/Cmd-` (not option-tab, I'll assume that was a simple mistake on your part) are *absolutely* orthogonal.
Cmd-Tab: cycle applications
Cmd-`: cycle windows in one application
Expose: random, direct graphical access
You can't get much more orthogonal than that.
Hiding windows, minimizing them to the Dock - are those orthogonal? What's the logical model that ties the two together? What is "minimize to the Dock" useful for? And if we are really supposed to use Hide, why isn't there a button to click in the window border, just a menu item and shortcut? Why isn't there a systemwide Hide All command?
Quote:
If your mother (or you) is having problems finding windows, try ctrl-clicking, right-clicking, or click-and-hold on a app's Dock icon for a list of all windows for that app. Or use the Window menu.
I could add "click app's Dock icon, then use Expose to find program windows". I frequently also click one window of a program (VLC controller for example) and double-Expose without even looking, this brings out the other windows. What am I complaining about, you ask?
- When a window is not visible, you have to remember it exists and go looking for it. Nothing on the screen tells you you have a window open.
- Even if you only have one app running, and you have hidden a window, you have to pick the app icon from the middle of a 20-item Dock. You have to remember which app your window/document is in.
- Clicking in the app's Dock icon can have side effects (single document window apps with no windows open a new window, many other things may happen as well if the app was not running). I know the logic, but try explaining it to my mom.
- You suggested a ctrl-click, right-click or hold-click to the Dock icon, or click + use Window menu, even though this is the simplest window management task in existence, merely activating a window. I don't think it should take anything beyond a simple click to something that is already visible, or becomes visible when hovered over.
AFAIK, minimizing to the Dock is still around in Panther because Apple would be removing a feature some people use. But minimizing to the Dock has always, IMO, been a mistake.
The Dock should only be a launcher for favorite apps or documents and show currently running apps. Bringing in a new dimension to the Dock was a mistake and I'm hoping minimizing to Dock will slowly disappear now that Expose is here to stay.
It's difficult to remove features that already exist without an outcry from end-users. All developers know this.
I wasn't defending tabs, actually. I was criticizing the OS X window management as a whole.
Hiding windows, minimizing them to the Dock - are those orthogonal?
Please show me how to hide a window *WITHOUT* sending it to the Dock.
One Hides *applications*, not windows.
Quote:
What's the logical model that ties the two together?
I think you misunderstand what orthogonal means.
OTOH, the above questions may have been rhetorical: "What does minimizing have to do with hiding?" Well, think of it this way: hiding windows or apps is a way of getting them out of the way, yes? And as you point out below, a visual reminder/target onscreen to get back to them is a good thing, yes? Then explain how one would hide the window (totally offscreen, no target), and still have the benefits of a visible direct target? You can't. Which is why it isn't how MacOS X works.
Quote:
What is "minimize to the Dock" useful for?
See below.
Quote:
And if we are really supposed to use Hide, why isn't there a button to click in the window border, just a menu item and shortcut? Why isn't there a systemwide Hide All command?
Hide is *for applications*. Hide *is* 'Hide All' for that application.
Minimize is *for windows*. And it has a windowbar widget.
Quote:
I could add "click app's Dock icon, then use Expose to find program windows". I frequently also click one window of a program (VLC controller for example) and double-Expose without even looking, this brings out the other windows. What am I complaining about, you ask?
- When a window is not visible, you have to remember it exists and go looking for it. Nothing on the screen tells you you have a window open.
Wrong.
When minimized, you see it in the Dock.
When you have the application hidden, you see it active in the Dock.
I *HATE* it when an OS (cf Windows) insists on keeping little reminders around for windows that I've explicitly hidden by hiding the application.
Think of it this way:
Minimize: I'm still working with this, but want it out of the way for now. Leave me a reminder of the window in the Dock.
Hide: I'm not really working with *anything* in this app right now, so make it all go away, except for the reminder of the app in the Dock.
Quote:
- Even if you only have one app running, and you have hidden a window, you have to pick the app icon from the middle of a 20-item Dock. You have to remember which app your window/document is in.
Er, I'd say that if you can't remember what app a document is in, you've got bigger problems than window management issues.
Besides... you can't hide a window without minimizing it.
Quote:
- Clicking in the app's Dock icon can have side effects (single document window apps with no windows open a new window, many other things may happen as well if the app was not running). I know the logic, but try explaining it to my mom.
If you have a hidden window, then it comes to the fore.
If you have no windows open, then you obviously clicked the app for a reason, and it is providing a new window for your use.
If you clicked the app just to see if you had windows open, then you should have ctrl/right-clicked on the icon to see. Right tool, right job.
Quote:
- You suggested a ctrl-click, right-click or hold-click to the Dock icon, or click + use Window menu, even though this is the simplest window management task in existence, merely activating a window. I don't think it should take anything beyond a simple click to something that is already visible, or becomes visible when hovered over.
And as I've pointed out repeatedly above, you cannot hide a window, just a window, with no visible target on screen to do exactly what you want.
Ergo, the system does what you say you want. If you have other complaints about it, perhaps they also stem from similar misunderstandings, and can be cleared up here?
Kickaha, what are your thoughts on what kim kap sol said about 'Minimize to Dock'? Do you also see it as a superflous, or, perhaps, wrongfully implemented function?
Please show me how to hide a window *WITHOUT* sending it to the Dock.
One Hides *applications*, not windows.
One Hides applications in order to hide windows, because the minimize feature is terrible. The minimized windows in Dock don't support drag and drop. They are often indistinguishable from each other, needing mouseover. When you switch apps, when you use Expose, you don't get any hint that your particular app has windows minimized in the Dock.
Er, I'd say that if you can't remember what app a document is in, you've got bigger problems than window management issues.
Irrespective whether *I* can remember what app a document is in, in good GUI design the user should have to remember as few things as possible, and shouldn't have to go through a lot of trouble to find them out. The same document (say graphic, or word processing document) can reasonably be open in different applications.
[B]One Hides applications in order to hide windows, because the minimize feature is terrible.
Er... so what do you do when you want to get one or two windows out of many open in an app out of the way? D'oh.
If you're really wanting to get all the windows out of the way, then Hiding the app *is* appropriate. I use it all the time. Mail, iCal, iTunes all stay Hidden unless I am directly using them.
In SubEthaEdit and Terminal, however, minimizing rules the day because I'm using those apps on a regular basis, but don't want all the windows in place all the time. I'm almost over having to use minimization, but I actually lately have gotten to the point where in Exposé, with 10-14 SubEthaEdit windows, they get small enough that I really *do* need to mouseover to determine which is which. So, I minimize the ones I'm not currently working with (generally I only directly work on about five or six for any one task), and then I have no problems distinguishing which is which.
It's a mixed bag of tools, and together they work *beautifully*. Not perfectly, but better than any other window management system I've seen out there. You see only what you want to see, items you've requested to be hidden away are left with a simple visible representation that is easy to find, and the remaining visible windows are easily (and intelligently) cycled through, or directly accessed, your preference.
Quote:
The minimized windows in Dock don't support drag and drop. They are often indistinguishable from each other, needing mouseover. When you switch apps, when you use Expose, you don't get any hint that your particular app has windows minimized in the Dock.
True, sorta true, and hell no.
There's a baseline assumed intelligence on the part of the user, I feel. Expose pulls up all the *visible* windows. I'd be *damned* annoyed if I had hidden several applications, but their windows popped into the Expose selection system. I hide those apps and minimized those windows *for a reason*... I don't want to see them. I want them out of the way. I don't want to deal with them at the moment. Having them pop up to get in the way would be a real pain. How very... Windows. "Here! Let me *help*!" Bleah.
I do think that the lack of drag and drop onto minimized windows is a major screw-up with the Dock... point taken, and I agree with you.
But I really don't see how it can be that difficult to lose a window.
1) Is it minimized in the Dock? If so, then you have a direct target.
2) Is it hidden behind another window? If so, then Expose brings it right to you. Another direct target.
3) Neither? Then is the app hidden? (If you can't remember what app it was from, back away from the computer slowly, you haven't the neurons to be considered safe with it. ) If the app was hidden, then clicking on the obvious and visible Dock icon gets you there. If the app was *not* hidden, then you closed out the window, sorry bub.
At every step there is a direct visible target for your mouse to click on. At every step there is a logical next place to check.
There is a certain level of user education that needs to happen, absolutely... but the fact that this suite of approaches (Dock, minimization, hiding, Expose) can scale from a few windows for the newbie to dozens of windows and apps for the power user is a stunning accomplishment.
Irrespective whether *I* can remember what app a document is in, in good GUI design the user should have to remember as few things as possible, and shouldn't have to go through a lot of trouble to find them out. The same document (say graphic, or word processing document) can reasonably be open in different applications.
True. But come on... how low of a common denominator do you want to go for here?
"You could lose a window if you hide it, so we won't let you hide them." <- default X11 behaviour a few years ago
"You could lose a window if you hide it, so we'll make sure that every window, at every moment, has *another* representation somewhere taking up screen space... oh, and if that space gets too cramped, the whole thing goes to hell and is unusable anyway, so try not to open too many windows." <- Windows taskbar
Seriously, if which app a document was in is the worst of your concerns, Apple has succeeded tremendously.
You can't lose a window. You always have a direct target, one way or another. (Heck, I didn't even mention the Window menu, which every newbie should be pointed to... it shows visible *and* minimized windows.)
No one method is perfect (Dock not taking drops is my *BIGGEST* beef) but the combination of them is brilliant.
Kickaha, what are your thoughts on what kim kap sol said about 'Minimize to Dock'? Do you also see it as a superflous, or, perhaps, wrongfully implemented function?
I think it is a useful addition to the stable of window management tools for the user, but far from perfect.
Not being able to use the minimized icons as drop targets is just bad, bad, bad, and a glaring omission IMNSHO.
But if they added that, I wouldn't have a problem with it. Like I've said before, I use it in combination with other approaches (Exposé, app/window cycling) and the whole is definitely greater than the sum of the parts.
This discussion of window management seems to boil down to whether the OS is doc-centric or app-centric. The situation might be a bit cloudy at this point, and maybe that's a big part of the problem. The Dock is part of that problem. Tabs might be another. The basic problem is that people kind of want or expect all their stuff to be available to them all the time, but not get in the way when they're focusing on a specific file or workflow. I'm not sure that there's any perfect solution, and that there probably isn't one mechanism that can satisfy all desires. I'd rather see a few means of handling this issue so that the user can pick and choose their priorities for managing their workflow. In a way, I think the current argument is, to use a cliché, not seeing the forest from the trees. The issue to me is more about your process or workflow than about how you handle windows per se. How you want to manage your data on screen is a function of how you work with it, so maybe the issue should be reframed as how do you work with Chat, Safari, etc. especially relative to your other docs and apps? Different answers will lead to different solution that work best for that person. I don't see why they couldn't all be accommodated to some degree anyway. The question is whether there's an elegant and sophisticated mechanism for doing so, or whether we have options, how many, and how do they interact?
Ok, I think I just spoke in a circle and didn't contribute anything. Maybe we need to reframe the argument though or pull back a little?
(regarding what happens when you click a Dock icon)
If you have a hidden window, then it comes to the fore.
If you have no windows open, then you obviously clicked the app for a reason, and it is providing a new window for your use.
If you clicked the app just to see if you had windows open, then you should have ctrl/right-clicked on the icon to see. Right tool, right job.
Usually I have to close that new window to do what I originally meant to do, like opening a file. How am I supposed to know I have no windows open in that app? We're back to remembering things we shouldn't have to. I think it would be simpler and more logical if those apps didn't do anything when activated. The ctrl-click is much too contrived a method to use "just in case" every time you want to switch windows.
Say I'm d&d:ing an image file to a word processor, with the intention of dropping it in one of several existing document windows. I can't do that through the Dock icon, and if I have hidden it or it is behind the rest, I might have no other visible representation of the app. IMO an intelligent design would let me access the individual windows after I've started drag and drop. It could do this, for example, showing the individual windows Expose-style next to the Dock when I mouseover the app icons.
Say I have two apps running, each with five windows/documents. I want to work with two windows only, one from each app, side to side using the available space. I don't want the rest of the windows visually cluttering the background. Most of all, I don't want them jumping up in my way by accident. I don't want to use the awkward minimize. I like tabs because they work around the minimizing.
Usually I have to close that new window to do what I originally meant to do, like opening a file. How am I supposed to know I have no windows open in that app? We're back to remembering things we shouldn't have to. I think it would be simpler and more logical if those apps didn't do anything when activated. The ctrl-click is much too contrived a method to use "just in case" every time you want to switch windows.
Now you're into the behaviour of apps that have no windows open, but are brought forward. Totally different issue than generalized window management. (FWIW, I also find such behaviour to be annoying more often than not, but studies with new users (particularly switchers) have found that they do better because they aren't trained to realize that the app *did* come to the fore, with the changed menu bar...)
Quote:
Say I'm d&d:ing an image file to a word processor, with the intention of dropping it in one of several existing document windows. I can't do that through the Dock icon, and if I have hidden it or it is behind the rest, I might have no other visible representation of the app. IMO an intelligent design would let me access the individual windows after I've started drag and drop. It could do this, for example, showing the individual windows Expose-style next to the Dock when I mouseover the app icons.
Agreed, I think that's an excellent idea. Adding drag and drop to the minimized windows is a good start in this direction, as I've been saying all along.
Quote:
Say I have two apps running, each with five windows/documents. I want to work with two windows only, one from each app, side to side using the available space. I don't want the rest of the windows visually cluttering the background. Most of all, I don't want them jumping up in my way by accident. I don't want to use the awkward minimize. I like tabs because they work around the minimizing.
That works fine if you want *ONE* window from each app... I generally have several from each app active at once. It would drive me *insane* if I had to keep clicking on the correct tab to get to the window I wanted. How on earth do I refer to window A, but type in window B in the same app? You can't.
Tabs are fine if you are going to have *exactly one* window in each app active. They immediately break for 2 or more. Tabs simply don't scale. Minimizing + Expose + Cmd-` does, and in such a way that lets you choose your approach that works best for you.
I'll say it again, tabs are a UI widget that works in *a very small number of boundary cases* under MacOS X. On other lesser window management systems, they are essential. Under MacOS X, they are of extremely limited utility, in extremely limited cases.
Now, if you want to talk about window grouping methodologies that work *across apps* to create workspace environments, tabs end up being a simplistic base case that you get for free. And generalized window grouping is something I think many people would get behind as useful.
Kickaha, I think we have been more of the same opinion than either of us realized initially. In addition to that, contrary to the usual "arguing on the Internet" experience, I have learned a great deal in this thread. I'll say "thanks" at this point, lest I forgot later.
Regarding Minimize and Hide, obviously Minimize hides a window and Hide hides an application's windows plus takes that application to the background. But this is essentially the same thing: to put something out of sight for a while. I think that whether the windows are hidden one at a time or whole application at a time, they should end up in the same place, where they would not take up permanent screen real estate (like Minimized items currently do), but you could peek at what's hidden (not currently possible with Hidden things) and therefore bring things forward knowing just which windows are going to appear.
Done right, I think this would enable people to only view the active work windows at a time and not have the unused windows in the background cluttering the view unless they want to. It would pretty much remove the need for tabs as well. The next step would be to develop workspaces/grouping/multi-desktops like you mention, but I don't know much about that.
I'm starting to see that there isn't anything wrong with Expose, it's the deficiencies in the underlying hide/minimize jumble that caused me to criticize Expose. I unreasonably expected it to work like a swiss army knife to patch the gaps of the other UI elements. It's good that Apple has in fact kept it very clean, now they just have to get their other stuff together. I imagine Expose might eventually melt into the rest of the interface, so there is no longer an expressly activated "Expose" feature and people will forget its name, but many elements in the interface use the same effect. This ties into resolution independence, UI elements will no longer have a "normal size" and "Expose size" but might change very subtly depending on what the system senses you doing.
Comments
Originally posted by rrabu
I agree. However, while grouping windows (after all, isn't that all a tabbed set of windows it?), we might as well be able to group windows from several different apps together rather than a single app. And then, windows have different sizes and shapes when they come from different apps, so maybe we should just leave them be their own, but keep the group together. In fact, this is sounding more like virtual desktops now....
This is exactly how I use the fluxbox WM under linux.
Originally posted by Kickaha
BING BING BING
Because that's precisely what they ARE.
And this is how they can become a general-purpose UI feature.
Once you're thinking this way, then questions start falling out that push the feature in a direction that's truly Mac-like: What are the standard features that should be supported (drag and drop, for one - it's too fundamental a part of the OS for its support to ever be considered a "feature" of some widget)? What are the standard keyboard navigation commands? What are the commands (if any) for dismissing, or creating, or minimizing, a "dock" of windows? If one of these "docks" is foregrounded, does command-N create a new "tab"? Etc.
Once you have a consistent and complete framework in place, so that navigation and use of this kind of MDI is discoverable and intuitive, then we can start calling MDI on the Mac a feature. Right now, it's just a hack. An occasionally brilliant hack, perhaps. An occasionally suitable hack, arguably. But still a hack that breaks one of the most fundamental assumptions of the Mac UI - that a window corresponds exactly to a document - and which doesn't even try to fix it, or compensate.
Every few years these discussions come up and I get an itch to go dig up my old posts on the subject.
Here are a couple not yet posted to this board. They were written in response to a similar rumor about tabs being slated for the next release of Safari.
The dangers of tabs
There exist people who don't want even an option for tabs in safari. It is possible that some of these people are merely vindictive or egotistical, wanting everyone to do things 'their' way.
Yet, I believe that those who advocate a non-tabbed safari hold their position for purely benevolent reasons. Its not that we want to bend other people to our will, rather, we are striving for interfaces that are best for the greatest number of users.
Tabs can accelerate some users' typical workflows, yet are accompanied by inherent dangers. Most of these have to do with the broken association of 'the document is your window'. Window widget and File menu items have overloaded functionality whenever you introduce multiple documents into a single window.
Optional tabs would certainly make some people's lives easier. They are analogous to installing a non-shielded band saw in a high school wood shop. It will speed up some of the students' woodworking. Band saw use is optional and even advised against by default. But someday, the students will start using that band saw and this use can be quite dangerous. The delete key could function as a non-confirmed file-delete in the finder. Yet even if optional, this would be a bad feature.
Even optional features will eventually be turned on accidentally by novices. Experienced users are likely to make habitual errors. Example: While doing your taxes on line, you click on a help link, spawning a new window/tab. After reading the help, you close the window...
Widgets with overloaded functionality, capable of destroying non-visible user created data, are bad.
No matter how tabs are embodied, they still exhibit the flaws inherent to placing multiple documents in a single window.
More tab theory
To summarize: Tabs can accelerate some users' typical workflows. Tabs make it easy for many users to accidentally destroy data. Making tabs an optional feature does not obviate either of these two points.
Here are a few points that seem to have been neglected. The Macintosh is based upon a GUI philosophy/design known as direct manipulation. This means that objects in the interface are closely analogous to objects in the real world. They can be manipulated in the same manner as real world objects. The Macintosh GUI is also document driven. Meaning documents are the conceptual unit that users must deal with. They are represented as a single file in the Finder and when double clicked, open into a single window. The window IS your document.
Tabbed documents are theoretically an option for all document-based applications and the slew of new apps blurring the line between user generated data and 3rd party provided functionality. If we don't want to have different document interaction techniques for every single application, tab functionality must be built into the windowing system. Otherwise, every time you use a new application, you'll be left just guessing what the window close widget does.
Tabbed documents overload the functionality of window widgets and break the one to one ratio of documents to windows. This is a fundamental divergence from apple's direct manipulation GUI paradigm. Apple has only occasionally put multiple user-modified documents into a single window. The most notable instance is in project builder. However, web-browsers have a drastically different user base than do IDEs.
Apple analyzed the trade off. Window control ambiguity is an acceptable sacrifice if you assume that all users are experts. This assumption cannot be made for safari. I really hope that tabs don't get added to Mac OS X document based applications. Tabs are not a new concept and have been purposely left out of the window server.
I can't imagine trying to explain tabs to my grandma. Even my brother would probably mess up his online taxes. At first its simple... but then try to explain what the file menu items pertain to. With tabs, there is no constant scope for the File menu.
The 'Window is your document' metaphor is the least error prone metaphor yet invented for manipulating user created data.
The value of a 1-to-1 ratio between documents and windows is all too easily underestimated by people who didn't experience the pre-direct-manipulation-era.
[Edited formatting]
Originally posted by dfiler
Tabs are perhaps the most misused and abused UI element in the history of GUIs. While they do have excellent uses, too often they are used as a copout for proper interaction design.
Every few years these discussions come up and I get an itch to go dig up my old posts on the subject.
Here are a couple not yet posted to this board. They were written in response to a similar rumor about tabs being slated for the next release of Safari.
The dangers of tabs
There exist people who don't want even an option for tabs in safari. It is possible that some of these people are merely vindictive or egotistical, wanting everyone to do things 'their' way.
Yet, I believe that those who advocate a non-tabbed safari hold their position for purely benevolent reasons. Its not that we want to bend other people to our will, rather, we are striving for interfaces that are best for the greatest number of users.
Tabs can accelerate some users' typical workflows, yet are accompanied by inherent dangers. Most of these have to do with the broken association of 'the document is your window'. Window widget and File menu items have overloaded functionality whenever you introduce multiple documents into a single window.
Optional tabs would certainly make some people's lives easier. They are analogous to installing a non-shielded band saw in a high school wood shop. It will speed up some of the students' woodworking. Band saw use is optional and even advised against by default. But someday, the students will start using that band saw and this use can be quite dangerous. The delete key could function as a non-confirmed file-delete in the finder. Yet even if optional, this would be a bad feature.
Even optional features will eventually be turned on accidentally by novices. Experienced users are likely to make habitual errors. Example: While doing your taxes on line, you click on a help link, spawning a new window/tab. After reading the help, you close the window...
Widgets with overloaded functionality, capable of destroying non-visible user created data, are bad.
No matter how tabs are embodied, they still exhibit the flaws inherent to placing multiple documents in a single window.
More tab theory
To summarize: Tabs can accelerate some users' typical workflows. Tabs make it easy for many users to accidentally destroy data. Making tabs an optional feature does not obviate either of these two points.
Here are a few points that seem to have been neglected. The Macintosh is based upon a GUI philosophy/design known as direct manipulation. This means that objects in the interface are closely analogous to objects in the real world. They can be manipulated in the same manner as real world objects. The Macintosh GUI is also document driven. Meaning documents are the conceptual unit that users must deal with. They are represented as a single file in the Finder and when double clicked, open into a single window. The window IS your document.
Tabbed documents are theoretically an option for all document-based applications and the slew of new apps blurring the line between user generated data and 3rd party provided functionality. If we don't want to have different document interaction techniques for every single application, tab functionality must be built into the windowing system. Otherwise, every time you use a new application, you'll be left just guessing what the window close widget does.
Tabbed documents overload the functionality of window widgets and break the one to one ratio of documents to windows. This is a fundamental divergence from apple's direct manipulation GUI paradigm. Apple has only occasionally put multiple user-modified documents into a single window. The most notable instance is in project builder. However, web-browsers have a drastically different user base than do IDEs.
Apple analyzed the trade off. Window control ambiguity is an acceptable sacrifice if you assume that all users are experts. This assumption cannot be made for safari. I really hope that tabs don't get added to Mac OS X document based applications. Tabs are not a new concept and have been purposely left out of the window server.
I can't imagine trying to explain tabs to my grandma. Even my brother would probably mess up his online taxes. At first its simple... but then try to explain what the file menu items pertain to. With tabs, there is no constant scope for the File menu.
The 'Window is your document' metaphor is the least error prone metaphor yet invented for manipulating user created data.
The value of a 1-to-1 ratio between documents and windows is all too easily underestimated by people who didn't experience the pre-direct-manipulation-era.
[Edited formatting]
What about my notepad with it's little tabs I can use to choose to skip on to what I want to use? It's a real world analogy if any.
Just admit it, tabs confuse you
i find tabs to be invaluable because i value having my workspace on my computer organized. even with expose i simply do NOT like having many open windows. however, i like to pre-open all of the webpages that i'd like to read in the near future. this thread, for instance is one of the many threads in the os x subforum that i'd like to read. so i open each new thread into a tab and close each tab when i'm done with the thread (as i will do in a few minutes here). for webbrowsing i find tabs to be a fantastic interface design because i PREFER to have all the pages open under one umbrella app window. if i need to spawn a separate window because i'm dealing with different subject matter or a page that i feel warrants its own window for emphasis, i can still do that as well.
as for adium, tabs are one of the major reasons i use that app. while some of you may feel that expose performs the same purpose as tabs in an im app, i'll simply say i disagree with you from my own experience. one of the major issues i have with ichat and window-cycling ichat windows is that it's not clear which order the windows will be focused. i don't always arrange my windows in side-by-side, sometimes i'll have them in a 2x2 grid. in that case, window cycling is inconvenient because i can't say with certainty which window will be cycled to next. with tabs, i can decide direction without doubt and it's very easy to count the number of steps necessary to reach the desired window.
you could say that i could expose the whole app and then cycle or click to the window. i find in that case that the most recently active window is hard to discern from the others. in adium, the tab has an indication of which window has most recently been updated. i actually don't like to leave buddy icons activated in my chat windows because i find them obnoxious. the arguments some of you are making in favor of expose seem to assume buddy icons are active. also, i don't use single application expose very often. while that might be more of an issue of my habits, it is still obviously an interface issue since i prefer tabs to single-app expose.
the real reason i like tabs in expose (and safari) is probably why most people like them: i simply don't like having so many windows open. i've had 4 or 5 chats open at the same time in ichat. i don't like seeing that many windows open, especially since some of those chats have very slow interaction. if one person replies to me every 5 minutes, it's irritating for me to have that one window open and as visually prominent as a window that is very active. and i'd rather not dispose of a chat window for the infrequent repliers because it disrupts the continuity of the chat lot. to me, it's a much better solution to leave it there and just tab to it when i need it. the logic is similar to why i don't quit apps anymore in os x. i'd rather have it there for immediate use and reaction. and when i'm not using it it remains relatively hidden.
Originally posted by kim kap sol
That's because Windows isn't a multitasker's OS and you're not a multitasker. I am however...I like to be able to see things going on in multiple windows at the same time.
Huh? I _am_ a multitasker. I usually have about five to ten programs running, ten tabs in the browser, two IM conversations, etc. I just think a window should be either well visible, or not visible at all. Having a little corner of a window visible underneath other ones is useless, and it becomes more useless when there are 20 of those little corners peeking out below the frontmost program. It's very useful to have a full-sized text editor, an almost full-sized web browser and a small text editor window open, fully visible, not on top of each other.
Many times I have seen my mom struggle because she has lost some window behind all other windows, and it's not evident that the window is still open. IMO this is worse than Windows' approach, which is not exactly stellar either. There you at least have clear indicator (the Taskbar) that tells you which windows exist either in minimized or visible form. On OS X, the windows can be behind each other, plain hidden (cmd-H), or the most useless of all, minimized as microscopic icons in the Dock. The only tools that bring some order to this chaos, option-tab and Expose, are both stateful interfaces, weak (think about drag and drop for instance), need memorized keys, aren't clean and orthogonal, don't help at all when using minimized windows.
Originally posted by Gon
Huh? I _am_ a multitasker. I usually have about five to ten programs running, ten tabs in the browser, two IM conversations, etc. I just think a window should be either well visible, or not visible at all. Having a little corner of a window visible underneath other ones is useless, and it becomes more useless when there are 20 of those little corners peeking out below the frontmost program. It's very useful to have a full-sized text editor, an almost full-sized web browser and a small text editor window open, fully visible, not on top of each other.
Absolutely. I currently have 12 windows open in SubEthaEdit, where I'm coding my research, each about 1/2 full screen, and three Terminal windows, about the same size... and that's just on one of four virtual desktops.
Tabs would kill my workflow dead, however. I'm constantly moving text from window to window, using translucency of Terminal windows to check running processes behind the current window, etc. I could never do that with tabs. Expose makes window selection fast, easy, and straightforward, *without* breaking drag and drop, for instance, which I use constantly.
Many times I have seen my mom struggle because she has lost some window behind all other windows, and it's not evident that the window is still open. IMO this is worse than Windows' approach, which is not exactly stellar either. There you at least have clear indicator (the Taskbar) that tells you which windows exist either in minimized or visible form. On OS X, the windows can be behind each other, plain hidden (cmd-H), or the most useless of all, minimized as microscopic icons in the Dock. The only tools that bring some order to this chaos, option-tab and Expose, are both stateful interfaces, weak (think about drag and drop for instance), need memorized keys, aren't clean and orthogonal, don't help at all when using minimized windows. [/B]
Er, actually Expose works perfectly with drag and drop, and Cmd-Tab/Cmd-` (not option-tab, I'll assume that was a simple mistake on your part) are *absolutely* orthogonal.
Cmd-Tab: cycle applications
Cmd-`: cycle windows in one application
Expose: random, direct graphical access
You can't get much more orthogonal than that.
If your mother (or you) is having problems finding windows, try ctrl-clicking, right-clicking, or click-and-hold on a app's Dock icon for a list of all windows for that app. Or use the Window menu. Very little room for confusion there.
Originally posted by Kickaha
Tabs would kill my workflow dead, however. I'm constantly moving text from window to window, using translucency of Terminal windows to check running processes behind the current window, etc. I could never do that with tabs. Expose makes window selection fast, easy, and straightforward, *without* breaking drag and drop, for instance, which I use constantly.
I wasn't defending tabs, actually. I was criticizing the OS X window management as a whole.
Er, actually Expose works perfectly with drag and drop, and Cmd-Tab/Cmd-` (not option-tab, I'll assume that was a simple mistake on your part) are *absolutely* orthogonal.
Cmd-Tab: cycle applications
Cmd-`: cycle windows in one application
Expose: random, direct graphical access
You can't get much more orthogonal than that.
Hiding windows, minimizing them to the Dock - are those orthogonal? What's the logical model that ties the two together? What is "minimize to the Dock" useful for? And if we are really supposed to use Hide, why isn't there a button to click in the window border, just a menu item and shortcut? Why isn't there a systemwide Hide All command?
If your mother (or you) is having problems finding windows, try ctrl-clicking, right-clicking, or click-and-hold on a app's Dock icon for a list of all windows for that app. Or use the Window menu.
I could add "click app's Dock icon, then use Expose to find program windows". I frequently also click one window of a program (VLC controller for example) and double-Expose without even looking, this brings out the other windows. What am I complaining about, you ask?
- When a window is not visible, you have to remember it exists and go looking for it. Nothing on the screen tells you you have a window open.
- Even if you only have one app running, and you have hidden a window, you have to pick the app icon from the middle of a 20-item Dock. You have to remember which app your window/document is in.
- Clicking in the app's Dock icon can have side effects (single document window apps with no windows open a new window, many other things may happen as well if the app was not running). I know the logic, but try explaining it to my mom.
- You suggested a ctrl-click, right-click or hold-click to the Dock icon, or click + use Window menu, even though this is the simplest window management task in existence, merely activating a window. I don't think it should take anything beyond a simple click to something that is already visible, or becomes visible when hovered over.
The Dock should only be a launcher for favorite apps or documents and show currently running apps. Bringing in a new dimension to the Dock was a mistake and I'm hoping minimizing to Dock will slowly disappear now that Expose is here to stay.
It's difficult to remove features that already exist without an outcry from end-users. All developers know this.
Originally posted by Gon
I wasn't defending tabs, actually. I was criticizing the OS X window management as a whole.
Hiding windows, minimizing them to the Dock - are those orthogonal?
Please show me how to hide a window *WITHOUT* sending it to the Dock.
One Hides *applications*, not windows.
What's the logical model that ties the two together?
I think you misunderstand what orthogonal means.
OTOH, the above questions may have been rhetorical: "What does minimizing have to do with hiding?" Well, think of it this way: hiding windows or apps is a way of getting them out of the way, yes? And as you point out below, a visual reminder/target onscreen to get back to them is a good thing, yes? Then explain how one would hide the window (totally offscreen, no target), and still have the benefits of a visible direct target? You can't. Which is why it isn't how MacOS X works.
What is "minimize to the Dock" useful for?
See below.
And if we are really supposed to use Hide, why isn't there a button to click in the window border, just a menu item and shortcut? Why isn't there a systemwide Hide All command?
Hide is *for applications*. Hide *is* 'Hide All' for that application.
Minimize is *for windows*. And it has a windowbar widget.
I could add "click app's Dock icon, then use Expose to find program windows". I frequently also click one window of a program (VLC controller for example) and double-Expose without even looking, this brings out the other windows. What am I complaining about, you ask?
- When a window is not visible, you have to remember it exists and go looking for it. Nothing on the screen tells you you have a window open.
Wrong.
When minimized, you see it in the Dock.
When you have the application hidden, you see it active in the Dock.
I *HATE* it when an OS (cf Windows) insists on keeping little reminders around for windows that I've explicitly hidden by hiding the application.
Think of it this way:
Minimize: I'm still working with this, but want it out of the way for now. Leave me a reminder of the window in the Dock.
Hide: I'm not really working with *anything* in this app right now, so make it all go away, except for the reminder of the app in the Dock.
- Even if you only have one app running, and you have hidden a window, you have to pick the app icon from the middle of a 20-item Dock. You have to remember which app your window/document is in.
Er, I'd say that if you can't remember what app a document is in, you've got bigger problems than window management issues.
Besides... you can't hide a window without minimizing it.
- Clicking in the app's Dock icon can have side effects (single document window apps with no windows open a new window, many other things may happen as well if the app was not running). I know the logic, but try explaining it to my mom.
If you have a hidden window, then it comes to the fore.
If you have no windows open, then you obviously clicked the app for a reason, and it is providing a new window for your use.
If you clicked the app just to see if you had windows open, then you should have ctrl/right-clicked on the icon to see. Right tool, right job.
- You suggested a ctrl-click, right-click or hold-click to the Dock icon, or click + use Window menu, even though this is the simplest window management task in existence, merely activating a window. I don't think it should take anything beyond a simple click to something that is already visible, or becomes visible when hovered over.
And as I've pointed out repeatedly above, you cannot hide a window, just a window, with no visible target on screen to do exactly what you want.
Ergo, the system does what you say you want. If you have other complaints about it, perhaps they also stem from similar misunderstandings, and can be cleared up here?
Originally posted by Kickaha
Please show me how to hide a window *WITHOUT* sending it to the Dock.
One Hides *applications*, not windows.
One Hides applications in order to hide windows, because the minimize feature is terrible. The minimized windows in Dock don't support drag and drop. They are often indistinguishable from each other, needing mouseover. When you switch apps, when you use Expose, you don't get any hint that your particular app has windows minimized in the Dock.
Originally posted by Kickaha
Er, I'd say that if you can't remember what app a document is in, you've got bigger problems than window management issues.
Irrespective whether *I* can remember what app a document is in, in good GUI design the user should have to remember as few things as possible, and shouldn't have to go through a lot of trouble to find them out. The same document (say graphic, or word processing document) can reasonably be open in different applications.
Originally posted by Gon
[B]One Hides applications in order to hide windows, because the minimize feature is terrible.
Er... so what do you do when you want to get one or two windows out of many open in an app out of the way? D'oh.
If you're really wanting to get all the windows out of the way, then Hiding the app *is* appropriate. I use it all the time. Mail, iCal, iTunes all stay Hidden unless I am directly using them.
In SubEthaEdit and Terminal, however, minimizing rules the day because I'm using those apps on a regular basis, but don't want all the windows in place all the time. I'm almost over having to use minimization, but I actually lately have gotten to the point where in Exposé, with 10-14 SubEthaEdit windows, they get small enough that I really *do* need to mouseover to determine which is which. So, I minimize the ones I'm not currently working with (generally I only directly work on about five or six for any one task), and then I have no problems distinguishing which is which.
It's a mixed bag of tools, and together they work *beautifully*. Not perfectly, but better than any other window management system I've seen out there. You see only what you want to see, items you've requested to be hidden away are left with a simple visible representation that is easy to find, and the remaining visible windows are easily (and intelligently) cycled through, or directly accessed, your preference.
The minimized windows in Dock don't support drag and drop. They are often indistinguishable from each other, needing mouseover. When you switch apps, when you use Expose, you don't get any hint that your particular app has windows minimized in the Dock.
True, sorta true, and hell no.
There's a baseline assumed intelligence on the part of the user, I feel. Expose pulls up all the *visible* windows. I'd be *damned* annoyed if I had hidden several applications, but their windows popped into the Expose selection system. I hide those apps and minimized those windows *for a reason*... I don't want to see them. I want them out of the way. I don't want to deal with them at the moment. Having them pop up to get in the way would be a real pain. How very... Windows. "Here! Let me *help*!" Bleah.
I do think that the lack of drag and drop onto minimized windows is a major screw-up with the Dock... point taken, and I agree with you.
But I really don't see how it can be that difficult to lose a window.
1) Is it minimized in the Dock? If so, then you have a direct target.
2) Is it hidden behind another window? If so, then Expose brings it right to you. Another direct target.
3) Neither? Then is the app hidden? (If you can't remember what app it was from, back away from the computer slowly, you haven't the neurons to be considered safe with it.
At every step there is a direct visible target for your mouse to click on. At every step there is a logical next place to check.
There is a certain level of user education that needs to happen, absolutely... but the fact that this suite of approaches (Dock, minimization, hiding, Expose) can scale from a few windows for the newbie to dozens of windows and apps for the power user is a stunning accomplishment.
Originally posted by Gon
Irrespective whether *I* can remember what app a document is in, in good GUI design the user should have to remember as few things as possible, and shouldn't have to go through a lot of trouble to find them out. The same document (say graphic, or word processing document) can reasonably be open in different applications.
True. But come on... how low of a common denominator do you want to go for here?
"You could lose a window if you hide it, so we won't let you hide them." <- default X11 behaviour a few years ago
"You could lose a window if you hide it, so we'll make sure that every window, at every moment, has *another* representation somewhere taking up screen space... oh, and if that space gets too cramped, the whole thing goes to hell and is unusable anyway, so try not to open too many windows." <- Windows taskbar
Seriously, if which app a document was in is the worst of your concerns, Apple has succeeded tremendously.
You can't lose a window. You always have a direct target, one way or another. (Heck, I didn't even mention the Window menu, which every newbie should be pointed to... it shows visible *and* minimized windows.)
No one method is perfect (Dock not taking drops is my *BIGGEST* beef) but the combination of them is brilliant.
Originally posted by Gavriel
Kickaha, what are your thoughts on what kim kap sol said about 'Minimize to Dock'? Do you also see it as a superflous, or, perhaps, wrongfully implemented function?
I think it is a useful addition to the stable of window management tools for the user, but far from perfect.
Not being able to use the minimized icons as drop targets is just bad, bad, bad, and a glaring omission IMNSHO.
But if they added that, I wouldn't have a problem with it. Like I've said before, I use it in combination with other approaches (Exposé, app/window cycling) and the whole is definitely greater than the sum of the parts.
And no lost windows.
Ok, I think I just spoke in a circle and didn't contribute anything. Maybe we need to reframe the argument though or pull back a little?
Originally posted by Kickaha
(regarding what happens when you click a Dock icon)
If you have a hidden window, then it comes to the fore.
If you have no windows open, then you obviously clicked the app for a reason, and it is providing a new window for your use.
If you clicked the app just to see if you had windows open, then you should have ctrl/right-clicked on the icon to see. Right tool, right job.
Usually I have to close that new window to do what I originally meant to do, like opening a file. How am I supposed to know I have no windows open in that app? We're back to remembering things we shouldn't have to. I think it would be simpler and more logical if those apps didn't do anything when activated. The ctrl-click is much too contrived a method to use "just in case" every time you want to switch windows.
Say I'm d&d:ing an image file to a word processor, with the intention of dropping it in one of several existing document windows. I can't do that through the Dock icon, and if I have hidden it or it is behind the rest, I might have no other visible representation of the app. IMO an intelligent design would let me access the individual windows after I've started drag and drop. It could do this, for example, showing the individual windows Expose-style next to the Dock when I mouseover the app icons.
Say I have two apps running, each with five windows/documents. I want to work with two windows only, one from each app, side to side using the available space. I don't want the rest of the windows visually cluttering the background. Most of all, I don't want them jumping up in my way by accident. I don't want to use the awkward minimize. I like tabs because they work around the minimizing.
Originally posted by Gon
Usually I have to close that new window to do what I originally meant to do, like opening a file. How am I supposed to know I have no windows open in that app? We're back to remembering things we shouldn't have to. I think it would be simpler and more logical if those apps didn't do anything when activated. The ctrl-click is much too contrived a method to use "just in case" every time you want to switch windows.
Now you're into the behaviour of apps that have no windows open, but are brought forward. Totally different issue than generalized window management. (FWIW, I also find such behaviour to be annoying more often than not, but studies with new users (particularly switchers) have found that they do better because they aren't trained to realize that the app *did* come to the fore, with the changed menu bar...)
Say I'm d&d:ing an image file to a word processor, with the intention of dropping it in one of several existing document windows. I can't do that through the Dock icon, and if I have hidden it or it is behind the rest, I might have no other visible representation of the app. IMO an intelligent design would let me access the individual windows after I've started drag and drop. It could do this, for example, showing the individual windows Expose-style next to the Dock when I mouseover the app icons.
Agreed, I think that's an excellent idea. Adding drag and drop to the minimized windows is a good start in this direction, as I've been saying all along.
Say I have two apps running, each with five windows/documents. I want to work with two windows only, one from each app, side to side using the available space. I don't want the rest of the windows visually cluttering the background. Most of all, I don't want them jumping up in my way by accident. I don't want to use the awkward minimize. I like tabs because they work around the minimizing.
That works fine if you want *ONE* window from each app... I generally have several from each app active at once. It would drive me *insane* if I had to keep clicking on the correct tab to get to the window I wanted. How on earth do I refer to window A, but type in window B in the same app? You can't.
Tabs are fine if you are going to have *exactly one* window in each app active. They immediately break for 2 or more. Tabs simply don't scale. Minimizing + Expose + Cmd-` does, and in such a way that lets you choose your approach that works best for you.
I'll say it again, tabs are a UI widget that works in *a very small number of boundary cases* under MacOS X. On other lesser window management systems, they are essential. Under MacOS X, they are of extremely limited utility, in extremely limited cases.
Now, if you want to talk about window grouping methodologies that work *across apps* to create workspace environments, tabs end up being a simplistic base case that you get for free. And generalized window grouping is something I think many people would get behind as useful.
Regarding Minimize and Hide, obviously Minimize hides a window and Hide hides an application's windows plus takes that application to the background. But this is essentially the same thing: to put something out of sight for a while. I think that whether the windows are hidden one at a time or whole application at a time, they should end up in the same place, where they would not take up permanent screen real estate (like Minimized items currently do), but you could peek at what's hidden (not currently possible with Hidden things) and therefore bring things forward knowing just which windows are going to appear.
Done right, I think this would enable people to only view the active work windows at a time and not have the unused windows in the background cluttering the view unless they want to. It would pretty much remove the need for tabs as well. The next step would be to develop workspaces/grouping/multi-desktops like you mention, but I don't know much about that.
I'm starting to see that there isn't anything wrong with Expose, it's the deficiencies in the underlying hide/minimize jumble that caused me to criticize Expose. I unreasonably expected it to work like a swiss army knife to patch the gaps of the other UI elements. It's good that Apple has in fact kept it very clean, now they just have to get their other stuff together. I imagine Expose might eventually melt into the rest of the interface, so there is no longer an expressly activated "Expose" feature and people will forget its name, but many elements in the interface use the same effect. This ties into resolution independence, UI elements will no longer have a "normal size" and "Expose size" but might change very subtly depending on what the system senses you doing.
So.. are we on the same track now?