Apple's iChat to gain tabs, integration with iTunes - Page 3

Originally posted by Kickaha[Tabs] don't work for all applications, and they really don't work for situations where windows need to be various sizes.

I agree!!

I'm only speaking about tabs (or a source list in a drawer) as a means to unify content within a common interface in the specific example of an IM client. If you keep the discussion focused on the use of tabs in an IM client, it should be easy to see the benefits they provide.

Much like expose, tabs are not the best solution for every application. But a lot of us feel that they are one of the best solutions for an IM client at this time, not to say something better won't come up in the future

Originally posted by resimada
If you really want me to... (Keep in mind I am referring to tabs in an IM client - one of the topics in this thread - not the proliferation of tabs into apps where they do not solve a particular need, which I am against).

Fair enough. Above gedanken experiment does not apply to this topic then, although it still holds in my mind for the illustration of the inelegance of tabs in general.

Quote:

Actually you can, using a bar of tabs with simple icons on them.

Not to be persnickety, but how does a simple icon show *MORE* state than actually showing the *content of the window*?? You've abstracted the content into a set of icons, and it shows more state? Er... It may be quicker to glance at and see change indicators, but it can't be showing *more* state.

Quote:

No, I do not. I mean the simplification of application interfaces by moving away from multiple windows. The source list in iTunes, the account drawer in mail, the tabs in safari, the source list in iPhoto. Interfaces simplified into a single window (for great benefit!) by using some sort of tab or source list control.

But chats aren't sources or destinations. They aren't collections, or sets, or libraries. They are documents, for lack of a better analogy.

Quote:

Tabs are not a hack, and tabs in an IM client work in addition to the window management system, they are not meant to replace it.

But they do actually replace it, by taking over the window management. N windows become 1 with N subwindows... that's the very definition of taking over management of the content.

Quote:

Tabs (or a source list in a drawer) are used in an IM client to simplify the interface by keeping related information together in an organized fashion in a common place. Tabs are not a "throwback".

They are a throwback on the Mac in that they are looking for a problem to solve that is different than their original purpose on other systems.

I see an IM client as being like a text editor, but the documents are shared. I would never *dream* of using a text editor that was tabbed! Would you?

For one thing, tabs (in many implementations) break drag and drop between documents. Ouch. Big no-no.

And they have many drawbacks as well, not the least of which is that they don't scale well, they don't work with many app content, and most implementations break drag-and-drop. I mean come on, that last one has got to be a biggie. You (generic programmer, not you in particular) just broke one the most *fundamental* UI elements, and it's not a hack? Hmmm.

Quote:

Without tabs, there are many conversation windows on my screen (clutter). With tabs, there is a common conversation window on my screen that holds all my conversations (organization). Did I explain it more clearly that time? [/B]

Yes, you did, but no more convincingly, sorry. I see why some people like them... but I refuse to accede that they are a general solution widget. The original problem they were designed to solve simply isn't an issue on the Mac.

Edit: Just saw your above reply... fair enough, you're limiting it to just the IM client, and that's it. I think at that point, it becomes merely an issue of personal taste, and we can agree to disagree?

Edit #2: Just saw your *below* reply... good to see your implementation does it right. Maybe you'll convince me yet... with a few more iterations...

Originally posted by KickahaNot to be persnickety, but how does a simple icon show *MORE* state than actually showing the *content of the window*??

The key word here is state. A simple icon can quickly show me which of my contacts are typing or have unviewed messages, and do not require me to stop what I'm doing (by hitting expose and looking all over the screen at the various windows) to see this information.

Quote:

Originally posted by KickahaBut chats aren't sources or destinations.

A chat is communication between a source and a destination.

Quote:

Originally posted by KickahaYes, you did, but no more convincingly, sorry. I see why some people like them... but I refuse to accede that they are a general solution widget.

Originally posted by KickahaActually, as long as you don't move the windows, Expose *does* put them right back where they were the last time you invoked it.

This is not true, unless you consider moving a changing window focus to be moving.

I just opened a bunch of windows, and if I used cmd~ to change focus before I used expose, the window positions in expose changed. If I reduced the number of windows to four, expose still changed window position, but was consistent in which quadrant it located each window.

Originally posted by resimada
The key word here is state. A simple icon can quickly show me which of my contacts are typing or have unviewed messages, and do not require me to stop what I'm doing (by hitting expose and looking all over the screen at the various windows) to see this information.

Right. It can show abstraction or simplification of relevant state, but does not show *more* state. I think we're in agreement here, with a slight issue of terminology muddying the water.

Quote:

A chat is communication between a source and a destination.

...

Oh come now. That's just...

...

Please tell me that was an attempt at humor.

Quote:

Who is asking you to accede on that point?

[/B]

In this thread, you are not. In previous threads, the battle has been between those of us who tried to point out that tabs are not the end all and be all of UI design, and the folks who thought every app would benefit from them. And it was FRICKING ANNOYING. *pant pant pant*

Originally posted by resimadaWithout tabs, there are many conversation windows on my screen (clutter). With tabs, there is a common conversation window on my screen that holds all my conversations (organization). Did I explain it more clearly that time?

Why organize highly dynamic objects such as chat conversations?

I can understand iTunes sources and Mail mailboxes which stay put and hardly change...but chat conversations that come and go don't need organization.

Originally posted by resimadaYes, a drawer/source list combination would handle that situation better than tabs (assuming the window was tall enough vertically).

Each (tabs vs source list) has its strength and weaknesses and any ideas on improving either are always welcome.

It's already there with Exposé.

I don't know why developers waste time reinventing the wheel or regressing the GUI (IMO, tabs are a regression in usability) when Apple provides an excellent and visual solution that allows you too see all your windows live.

Instead of spending weeks creating a tab system, just slap a big ol' buddy picture icon on conversation windows and the name of the contact in bold letters and Exposé will handle 1-12 conversations with ease.

Originally posted by kim kap solThe truncation is already pretty bad but the worst is the non-destructive click targets and destructive click-targets are almost equal in proportion at this point.

For those that don't understand what I mean and haven't used Adium, the colored status indicators also double as close buttons for tabs.

For those of you that haven't used Adium, please be aware that you can only close the active tab (In the default configuration), so this is not an issue

More commonly you'll find yourself not clicking, but navigating tabs using the keyboard shortcuts since they are very convenient to hit with your hands already on the keyboard.

Quote:

Originally posted by kim kap solIt's already there with Exposé.

I don't know why developers waste time reinventing the wheel or regressing the GUI (IMO, tabs are a regression in usability) when Apple provides an excellent and visual solution that allows you too see all your windows live.

To me, tabs play a role in grouping information together.
The natural progression for tabs is for them to exist in the window manager, as a way of grouping windows together.

I havent worked out the exact UI yet, but something like drag a window title onto another window title and the two windows will dock together as tabs. You can then combine any set of windows together into a group. You can also untab windows and reorder them.

Drag and drop onto tabs should bring them forward. I just tested dragging some text between windows ( something I very rarely do ) and Panther fails to bring windows to the front, which is broken.

Another natural extension is having windows dock their edges together. When you minimise one, the whole dock structure minimises, etc.

I guess I dont think the tabs should be a UI widget, they should be a window manager tool.

Originally posted by kim kap solInstead of spending weeks creating a tab system, just slap a big ol' buddy picture icon on conversation windows and the name of the contact in bold letters and Exposé will handle 1-12 conversations with ease.

oh HEY...

There's an idea.

I haven't dealt with that end of the app pipeline lately, but does Expose trigger any sort of event to apps to let them know that it's been activated?

You could slap a huge buddy icon across the window, at say 50% translucency, and then remove it when Expose goes off. Expose handles the rest, and you avoid much of the problem of not being able to identify text windows.

Take the idea of tabs, and abstract it out to window docking, and *now* you have something worth investigating.

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....

Originally posted by rrabuI 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....

And how would you manage windows on a virtual desktop?

Window cycling and Expose. We come full circle.

I would actually love to see window groupings across apps based on task. That's an idea worth pursuing. Grouping *within* an app then becomes a sub-idea of that, and you get it for free.

Originally posted by rrabuI 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....

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.

Originally posted by dfilerTabs 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.

Originally posted by kim kap solThat'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.

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.

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 KickahaTabs 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.

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.

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.

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?

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?

Originally posted by KickahaPlease 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 KickahaEr, 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.

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.

Originally posted by GonIrrespective 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 GavrielKickaha, 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?

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...)

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.