I wasn't laying out the Commandments. I was discussing. I even came around and thought to use cmd-w instead on my own before your post. But even had you suggested it first, great, I'm hoping to hammer out what a more evolved Exposé would look and act like. Make suggestions, thats fine.
But I'm realizing that there needs to be (edit: read "might be useful to have") a pan-application method to close multiple windows at an Exposé level.
It's the same kind of global window closing command that Logout or Restart would trigger. if Exposé cycled through the apps in alphabetical order to give the user the chance to close multiple dirty windows then great. I don't see why we need to logout to be able to close a ton of windows all at once.
The cmd-tab application switcher lets you also quit applications, I see no reason whatsoever why a window navigator couldn't/shouldn't allow for closure.
"Wait, what do you mean I *quit* System Preferences??"
See how messy it gets? This would be a the addition of an entirely new layer of interaction, in addition to document/application, now you'd have meta-application. What are the semantics for dealing with several applications at once? How do you resolve semantic conflicts? How do you handle contextual failures?
First, I omitted the delete-based comments since I agree.
Second, the quitting System Preferences thing is silly, since the logical end to that line of thinking is to say something funny like "(existing) cmd-w is a bad thing since it leads to multiple, different outcomes, therefore we should not use cmd-w" which of course is nonsense. Better to nicely resolve things at the other end. In this case, just let all apps stay running despite having no windows open. Whatever, I'm not proposing one way or another, but Apple should decide it at that end. It shouldn't prevent using cmd-w or identical window closing methods such as via Exposé as suggested.
Regarding semantics/contextual failures etc. They could be hashed out by interested parties. Barring any besides me it might not be worth talking about.
I'd suggest that dirty windows could be cycled inside Exposé (with the blackened background ala F10) but shown at 100% to allow clicking the sheet/dialogs. Go to each window in order clicked, allowing saves/cancels and leaving cmd-period as the fuhgetaboutit for the multiple closings.
Remember, I'm suggesting, not dictating, so feel free to comment. I don't really even mind "I don't use Exposé" posts but they are kinda useless. But they can be enlightening in some ways.
I think the big problem is that some people want to add complexities to simple things.
How many times have I heard people ask for a tabbed-Dock to seperate groups of apps. The idea is interesting but, in practice, it's terrible. The beauty of the Dock is that it's simple. It allows easy access to favorite apps and shows all open apps (and stores minimized windows which is something I don't like as much but...) Adding any more features to the Dock would kill it's simplicity. If you want such complexities the Windows taskbar can be found on 97% of the computers out there.
Exposé is the same...why kill it with features unrelated to it's core purpose: switch windows.
Window management is more complicated than it looks. Document windows can rarely be closed without a sheet popping down and asking whether you want to save the changes that were made. Other windows might require another action before the window is closed depending on how it was programmed. This is why you can't add some easy quick-key to close windows in the first place.
I think the big problem is that some people want to add complexities to simple things.
...
Lets not make the Mac GUI complicated.
The first priority is to make it powerful. Experience shows you can best make UIs powerful by making them logical, orthogonal and extensible.
Because the interface is logical and orthogonal, if you hide the extensibility, it appears simple.
It's much harder (impossible, even) to make a simple interface by focusing on ease of use, then try to extend it so it becomes powerful *and* retains its orthogonality and logic. See Windows for an example.
If compromises have to be made, I for one will always take power over initial learnability. It's an often forgotten fact that users remain as novices only for a few months or so, but in all probability they use computers their whole life.
Edit: I'm eager to get a new Mac so I can try Expose, but frankly it would appear to be a "cool" solution to a problem that should have been avoided in the first place. On Windows, I never have trouble finding any window, because after a while it's very intuitive to minimize and restore windows with left-click in the taskbar. On OS X (10.2) it was considerably more work because the Dock is not as strong as the Windows taskbar.
I think the big problem is that some people want to add complexities to simple things.
(...)
Lets not make the Mac GUI complicated.
Right, but kim kap sol, if Apple listened to that logic we would not have the Dock, Exposé, cmd-tab switching and many other Mac OS X features.
Millions of people still think all the great things in Mac OS X are "complex" "bloated" "inelegant" "extravagant" "unintuitive" etc and prefer Mac OS 9/8/7/6/5/4/3/2/1/stone age.
I don't think Apple is handcuffed to the first thing that rolls out the door. They can subtly roll-in features over time. If well done, it's seamless.
None of us realized we needed Exposé until it came out. So too can future improvements seem obvious - if we allow them to happen. Thankfully such stuff is not opensource at Apple, as death by design-by-committee sucks. Look at anything Netscape.
Look at the people that still don't use Exposé. To them it's needless fluff.
Is it? Certainly not to those that see its usefulness.
The first priority is to make it powerful. Experience shows you can best make UIs powerful by making them logical, orthogonal and extensible.
Because the interface is logical and orthogonal, if you hide the extensibility, it appears simple.
It's much harder (impossible, even) to make a simple interface by focusing on ease of use, then try to extend it so it becomes powerful *and* retains its orthogonality and logic. See Windows for an example.
If compromises have to be made, I for one will always take power over initial learnability. It's an often forgotten fact that users remain as novices only for a few months or so, but in all probability they use computers their whole life.
(Not directed to you Gon, just basing it on the complexity thing)
Most Mac OS X user's I've seen and read do not fully understand the power of Exposé as it is. Immense usability and functionality nearly totally hidden.
The dual nature of the F keys is too subtle for them. (ask if you don't know)
The ability to drag files and folders to minimized windows via Exposé it underutilized if at all.
The ability to drag text and image selections to other apps via Exposé is so well hidden I've never seen anyone do it.
Sure there probably are myriad hints and tips floating around, so maybe some people know these.
But the point is Exposé is no mere minimize function. It's already robust and complex. Were I to outline everything it does and how it is done you'd hate Exposé based on the outline alone (had you never used it).
(Not directed to you Gon, just basing it on the complexity thing)
Most Mac OS X user's I've seen and read do not fully understand the power of Exposé as it is. Immense usability and functionality nearly totally hidden.
Ayup, and during this thread it occurred to me: "Why isn't Expose in the Apple menu? It's a system-level event." (Off to send feedback to Apple...)
Quote:
The ability to drag files and folders to minimized windows via Exposé it underutilized if at all.
The ability to drag text and image selections to other apps via Exposé is so well hidden I've never seen anyone do it.
Heck, these are the two things I do most with Expose... I almost never use it to *find* a window, I use it to move things *between* windows.
Quote:
Sure there probably are myriad hints and tips floating around, so maybe some people know these.
But the point is Exposé is no mere minimize function. It's already robust and complex. Were I to outline everything it does and how it is done you'd hate Exposé based on the outline alone (had you never used it).
Not really...
Expose has three modes: one app, all apps, desktop
One app and all app are drop-ready. Desktop is drag and/or drop ready.
That's about it, really. Nothing special, nothing unusual, just click to select which window, or drag and/or drop. Motions and actions that are already part and parcel of the UI canon of OS X. You bet your bippy it's powerful, but it's *because* of the simplicity, not in spite of it.
If you think about it, you can already drop into any window that's visible... *all* Expose does in that case is make all windows visible. Likewise, you can click on any window to make it come forward. All Expose does in that case is... make all windows visible. You can grab any Desktop item that's visible. All Expose does there is make the entire Desktop visible.
That's pretty darned simple. Expose does one thing... *EXPOSE*.
Now, if you wanted to argue that you should be able to click on window widgets in Expose mode just like you do for background windows, and have it register, then I can't really argue against that one, except on the grounds of usability of hitting such a *teensy* target. (In which case the user is more likely to hit the wrong widget and close when they mean to Dockify, etc... which is a good reason not to allow it.)
Altering Expose to be a meta-app-level window manager is adding a *lot* of functionality to it that would require serious thought on the general semantics. As it is, Expose does exactly one thing, and does it very well. The reason it's so powerful is that the *rest* of the UI supports the rest of the actions you perform with it.
That's pretty darned simple. Expose does one thing... *EXPOSE*.
Right, what I meant was that you can outline how Exposé works in detail and it will look as "complex" as I made the other thing I wrote. But it in and of itself is not complex to use.
Quote:
Originally posted by Kickaha
Now, if you wanted to argue that you should be able to click on window widgets in Expose mode just like you do for background windows, and have it register, then I can't really argue against that one, except on the grounds of usability of hitting such a *teensy* target. (In which case the user is more likely to hit the wrong widget and close when they mean to Dockify, etc... which is a good reason not to allow it.)
No no. I definitely do not want to be able to manipulate widgets/data/things in minimized windows at all. Only if made 100% size.
Quote:
Originally posted by Kickaha
Altering Expose to be a meta-app-level window manager is adding a *lot* of functionality to it that would require serious thought on the general semantics. As it is, Expose does exactly one thing, and does it very well. The reason it's so powerful is that the *rest* of the UI supports the rest of the actions you perform with it.
It adds no more complexity than adding "quit" functionality to a cmd-tab application switcher did.
It would use semantics already used elsewhere.
Ok, better design:
In Exposé just shift-click whatever windows you want to close (or use a selection marquee as in Finder). Then either do cmd-w or right click anywhere and choose "Close selected windows".
Exposé should have a contextual menu.
Contextual items should include:
Close Window (Closes the window immediately, repositions/rescales remaining windows, exits to application if dialog is presented)
Close Selected Windows (if multiple windows are selected; Closes the windows immediately, repositions/rescales remaining windows, exits to application if dialog is presented - same as current method of switching to each app for saving upon Logging out or Restart)
Keep Minimized (aka Minimize In Place; Keeps the window where it is, the size it is upon exiting Exposé)
Minimize to Dock (removes the window from the Exposé context - add it back in by clicking on it in the Dock again.)
---
Anyway I don't think applying commands cross application is a bad thing.
When you Shut Down/Restart/Log Out you magically go from one application to another making saving/not saving decisions and the OS hand holds you to all the appropriate applications. My only change is that rather than shutting the machine off or logging out, you can just be back where you were (where this should be is debatable) but having gracefully shut a ton of windows in a meta-application level from Exposé.
Other 3rd party cmd-tab switchers let you queue up multiple apps for quitting as opposed to the current "quit only what is selected" method. I'd like to be able to queue up windows for closing across application lines at the Exposé level.
I haven't needed to invent any new semantics. Merely using existing conventions.
Yes I do favor treating minimized windows as draggable objects (although I absolutely do not want interaction with their contents while minimized) so that's a bias that is contentious to some.
Of course, tabbed browsing messes everything up now doesn't it.
My hope is that since Apple typically muddies up the so called elegance eventually I'll get my way someday
They combine things all the time in the dubious name of consolidation and refinement; usually in an arguable manner just to justify having made enough changes to warrant an upgrade
I agree that adding window state functionality to Exposé would create as many or more problems that would have to be solved, as the amount of useful functionality it adds; it doesn't seem like a step in the right direction.
I am interested how Apple can make Exposé more available to everyday users, though. It's currently tucked away rather on purpose, seems to me, as it's somewhat advanced, and could potentially bewilder novice users (esp. if activated by screen corners).
Exposé preferences in the Apple menu, including an option for toggling it on or off with a single command, are a no-brainer. That'd be great.
Should Apple offer the option of activating Exposé from buttons on the Dock? Probably not -- three big buttons that take up a lot of space and could move around seems out of place, and not a great solution. Nor can Apple mark the F9 /F10 / F11 keys with keyboard symbols, as Exposé is so customizable.
This reminds me of when Apple included a 'close window' command in the contextual menu on a minimized window in the dock in the 10.3 beta. They ended up leaving it out due to the complexity of dealing with sheets and quitting apps. If it's too complex to do one window at a time from the dock, I don't think it's a good idea for Expose.
How much faster do you want it? The only thing I would suggest would be the ability to use cmd+w or cmd+q keys over the highlighted exposéd window.
All this about shift-clicking and shift deleting is silly when we already have key sequences for closing windows and quitting applications.
As for dirty windows, they would work like the cmd-tab selector works when you use it to quit. The window will simply pop out its sheet asking to save. If you don't then goto that app, it simply sits in the background waiting for your attention.
How much faster do you want it? The only thing I would suggest would be the ability to use cmd+w or cmd+q keys over the highlighted exposéd window.
All this about shift-clicking and shift deleting is silly when we already have key sequences for closing windows and quitting applications.
As for dirty windows, they would work like the cmd-tab selector works when you use it to quit. The window will simply pop out its sheet asking to save. If you don't then goto that app, it simply sits in the background waiting for your attention.
The reason shift is suggested is that obviously some modifier is required since single clicking merely exposes the fullsize window.
You would not be able to "click-click-cmd-w" (if I understand you correctly) to close two windows since clicking the once pulls you out of Exposé.
Yes, use the existing key sequences for closing windows and quitting applications, but you still need a way to select multiple minimized windows. What better way than the existing Finder methods, namely Selection Marquee and Shift-Click Multiple Selection.
Unfortunately this is one of those things that needs to be built first, only then can people play with it and get it.
This reminds me of when Apple included a 'close window' command in the contextual menu on a minimized window in the dock in the 10.3 beta. They ended up leaving it out due to the complexity of dealing with sheets and quitting apps. If it's too complex to do one window at a time from the dock, I don't think it's a good idea for Expose.
I say nay.
It needn't be the slightest bit confusing.
The user uses the contextual menu in the Dock (nothing new except the Close Window command itself), the window would merely de-minimize from the Dock (nothing new), then the user decides to save or not save (nothing new).
I don't see the chaos in that.
You are merely offsetting the verb to take place after the de-minimize effect.
Currently:
(Window is minimized in Dock)
1. Click to icon to de-minimize it
2. Choose Close Window/hit red widget/cmd-w/whichever
3. Answer the sheet to save or not
The in-Dock method:
(Window is minimized in Dock)
1. Click and hold the icon to trigger the contextual menu and choose Close Window
(Window de-minimizes)
2. Answer the sheet to save or not
I don't see it being worse. Granted contextual commands should not be the only way to do something.
Granted contextual commands should not be the only way to do something.
BINGO.
So, 'splain how you're going to create a non-contextual menu item that allows for an Expose-mode multiple closing?
Perhaps have the menu bar just plain convert to an Expose menu bar, making it an application that's really a meta-application, but not really since it's just an application?
Well, Brad gets todays Kudos award for at least bothering to lay out particulars of what he doesn't like.
I laid out the particulars before you even started participating in the thread...
Exposé isn't for manipulating windows, but rather for choosing them. When you invoke Exposé you are not really manipulating them, but observing them from a different point of fiew. Imagine a bunch of stacked windows as on a crumpled piece of paper. You're uncrumpling the paper to see all the windows at once, but you aren't literally changing the positions of the windows relative to another.
No actions should be able to be done on windows while in Exposé. When invoked, it's like a frozen moment of time. you have to choose a window to get everything started again.
The reason shift is suggested is that obviously some modifier is required since single clicking merely exposes the fullsize window.
You would not be able to "click-click-cmd-w" (if I understand you correctly) to close two windows since clicking the once pulls you out of Exposé.
I think what Gargoyle was trying to say is that, currently, CLICK to open expose, CLICK to open a window, CMD-W to close that window.. simply stating that it's really not that difficult, something i happen to agree with. However, Gargoyle goes on to suggest allowing CMD-W to work within Expose, closing the window the mouse is hovering over. I think this is the best solution. Doesn't change the standard key combination. Some people seem to be begging for selecting multiple windows to give them all the same instruction (close window, etc..), I believe hovering the mouse over each window and pressing CMD-W is really just as elegant and quick a solution as being able to select multiples first.
At the same time, I also think CMD-Q should be enabled. When in "Application Window" Expose, it would close the app and switch to "Show All Window" Expose.
Ayup, and during this thread it occurred to me: "Why isn't Expose in the Apple menu? It's a system-level event." (Off to send feedback to Apple...)
I think one reason why it's not in the Apple menu is because it makes the Apple menu inaccessible in the process. As you noticed, the menu bar remains, but it becomes untouchable. Most users expect to be able to select the menu option again to toggle off again.
The only Exposé mode that I might allow in the Apple menu is the "Show Desktop" one...
I believe hovering the mouse over each window and pressing CMD-W is really just as elegant and quick a solution as being able to select multiples first.
At the same time, I also think CMD-Q should be enabled. When in "Application Window" Expose, it would close the app and switch to "Show All Window" Expose.
That still doesn't really address how the menu bar is inactive in Exposé when you want to use these commands. And it also doesn't address the save dialogs and other unexpected window behavior (non-behavior) in apps that don't conform to the HIG.
Exposé is for viewing/observing/exposing and not for manipulating.
That still doesn't really address how the menu bar is inactive in Exposé when you want to use these commands. And it also doesn't address the save dialogs and other unexpected window behavior (non-behavior) in apps that don't conform to the HIG.
Exposé is for viewing/observing/exposing and not for manipulating.
technically, you're right.. however, it wouldn't be the first time Apple ignored their own guidelines (see this thread for proof of that).. i believe a minimal undocumented feature such as this wouldn't really hurt anything as far as user friendliness goes, as it would go unnoticed by most users.. it'd only help the "power users" who want to use it.
Comments
I wasn't laying out the Commandments. I was discussing. I even came around and thought to use cmd-w instead on my own before your post. But even had you suggested it first, great, I'm hoping to hammer out what a more evolved Exposé would look and act like. Make suggestions, thats fine.
But I'm realizing that there needs to be (edit: read "might be useful to have") a pan-application method to close multiple windows at an Exposé level.
It's the same kind of global window closing command that Logout or Restart would trigger. if Exposé cycled through the apps in alphabetical order to give the user the chance to close multiple dirty windows then great. I don't see why we need to logout to be able to close a ton of windows all at once.
The cmd-tab application switcher lets you also quit applications, I see no reason whatsoever why a window navigator couldn't/shouldn't allow for closure.
Originally posted by Kickaha
"Wait, what do you mean I *quit* System Preferences??"
See how messy it gets? This would be a the addition of an entirely new layer of interaction, in addition to document/application, now you'd have meta-application. What are the semantics for dealing with several applications at once? How do you resolve semantic conflicts? How do you handle contextual failures?
First, I omitted the delete-based comments since I agree.
Second, the quitting System Preferences thing is silly, since the logical end to that line of thinking is to say something funny like "(existing) cmd-w is a bad thing since it leads to multiple, different outcomes, therefore we should not use cmd-w" which of course is nonsense. Better to nicely resolve things at the other end. In this case, just let all apps stay running despite having no windows open. Whatever, I'm not proposing one way or another, but Apple should decide it at that end. It shouldn't prevent using cmd-w or identical window closing methods such as via Exposé as suggested.
Regarding semantics/contextual failures etc. They could be hashed out by interested parties. Barring any besides me it might not be worth talking about.
I'd suggest that dirty windows could be cycled inside Exposé (with the blackened background ala F10) but shown at 100% to allow clicking the sheet/dialogs. Go to each window in order clicked, allowing saves/cancels and leaving cmd-period as the fuhgetaboutit for the multiple closings.
Remember, I'm suggesting, not dictating, so feel free to comment. I don't really even mind "I don't use Exposé" posts but they are kinda useless. But they can be enlightening in some ways.
How many times have I heard people ask for a tabbed-Dock to seperate groups of apps. The idea is interesting but, in practice, it's terrible. The beauty of the Dock is that it's simple. It allows easy access to favorite apps and shows all open apps (and stores minimized windows which is something I don't like as much but...) Adding any more features to the Dock would kill it's simplicity. If you want such complexities the Windows taskbar can be found on 97% of the computers out there.
Exposé is the same...why kill it with features unrelated to it's core purpose: switch windows.
Window management is more complicated than it looks. Document windows can rarely be closed without a sheet popping down and asking whether you want to save the changes that were made. Other windows might require another action before the window is closed depending on how it was programmed. This is why you can't add some easy quick-key to close windows in the first place.
Lets not make the Mac GUI complicated.
Originally posted by kim kap sol
I think the big problem is that some people want to add complexities to simple things.
...
Lets not make the Mac GUI complicated.
The first priority is to make it powerful. Experience shows you can best make UIs powerful by making them logical, orthogonal and extensible.
Because the interface is logical and orthogonal, if you hide the extensibility, it appears simple.
It's much harder (impossible, even) to make a simple interface by focusing on ease of use, then try to extend it so it becomes powerful *and* retains its orthogonality and logic. See Windows for an example.
If compromises have to be made, I for one will always take power over initial learnability. It's an often forgotten fact that users remain as novices only for a few months or so, but in all probability they use computers their whole life.
Edit: I'm eager to get a new Mac so I can try Expose, but frankly it would appear to be a "cool" solution to a problem that should have been avoided in the first place. On Windows, I never have trouble finding any window, because after a while it's very intuitive to minimize and restore windows with left-click in the taskbar. On OS X (10.2) it was considerably more work because the Dock is not as strong as the Windows taskbar.
Originally posted by kim kap sol
I think the big problem is that some people want to add complexities to simple things.
(...)
Lets not make the Mac GUI complicated.
Right, but kim kap sol, if Apple listened to that logic we would not have the Dock, Exposé, cmd-tab switching and many other Mac OS X features.
Millions of people still think all the great things in Mac OS X are "complex" "bloated" "inelegant" "extravagant" "unintuitive" etc and prefer Mac OS 9/8/7/6/5/4/3/2/1/stone age.
I don't think Apple is handcuffed to the first thing that rolls out the door. They can subtly roll-in features over time. If well done, it's seamless.
None of us realized we needed Exposé until it came out. So too can future improvements seem obvious - if we allow them to happen. Thankfully such stuff is not opensource at Apple, as death by design-by-committee sucks. Look at anything Netscape.
Look at the people that still don't use Exposé. To them it's needless fluff.
Is it? Certainly not to those that see its usefulness.
Originally posted by Gon
The first priority is to make it powerful. Experience shows you can best make UIs powerful by making them logical, orthogonal and extensible.
Because the interface is logical and orthogonal, if you hide the extensibility, it appears simple.
It's much harder (impossible, even) to make a simple interface by focusing on ease of use, then try to extend it so it becomes powerful *and* retains its orthogonality and logic. See Windows for an example.
If compromises have to be made, I for one will always take power over initial learnability. It's an often forgotten fact that users remain as novices only for a few months or so, but in all probability they use computers their whole life.
(Not directed to you Gon, just basing it on the complexity thing)
Most Mac OS X user's I've seen and read do not fully understand the power of Exposé as it is. Immense usability and functionality nearly totally hidden.
The dual nature of the F keys is too subtle for them. (ask if you don't know)
The ability to drag files and folders to minimized windows via Exposé it underutilized if at all.
The ability to drag text and image selections to other apps via Exposé is so well hidden I've never seen anyone do it.
Sure there probably are myriad hints and tips floating around, so maybe some people know these.
But the point is Exposé is no mere minimize function. It's already robust and complex. Were I to outline everything it does and how it is done you'd hate Exposé based on the outline alone (had you never used it).
Originally posted by johnq
(Not directed to you Gon, just basing it on the complexity thing)
Most Mac OS X user's I've seen and read do not fully understand the power of Exposé as it is. Immense usability and functionality nearly totally hidden.
Ayup, and during this thread it occurred to me: "Why isn't Expose in the Apple menu? It's a system-level event." (Off to send feedback to Apple...)
The ability to drag files and folders to minimized windows via Exposé it underutilized if at all.
The ability to drag text and image selections to other apps via Exposé is so well hidden I've never seen anyone do it.
Heck, these are the two things I do most with Expose... I almost never use it to *find* a window, I use it to move things *between* windows.
Sure there probably are myriad hints and tips floating around, so maybe some people know these.
But the point is Exposé is no mere minimize function. It's already robust and complex. Were I to outline everything it does and how it is done you'd hate Exposé based on the outline alone (had you never used it).
Not really...
Expose has three modes: one app, all apps, desktop
One app and all app are drop-ready. Desktop is drag and/or drop ready.
That's about it, really. Nothing special, nothing unusual, just click to select which window, or drag and/or drop. Motions and actions that are already part and parcel of the UI canon of OS X. You bet your bippy it's powerful, but it's *because* of the simplicity, not in spite of it.
If you think about it, you can already drop into any window that's visible... *all* Expose does in that case is make all windows visible. Likewise, you can click on any window to make it come forward. All Expose does in that case is... make all windows visible. You can grab any Desktop item that's visible. All Expose does there is make the entire Desktop visible.
That's pretty darned simple. Expose does one thing... *EXPOSE*.
Now, if you wanted to argue that you should be able to click on window widgets in Expose mode just like you do for background windows, and have it register, then I can't really argue against that one, except on the grounds of usability of hitting such a *teensy* target. (In which case the user is more likely to hit the wrong widget and close when they mean to Dockify, etc... which is a good reason not to allow it.)
Altering Expose to be a meta-app-level window manager is adding a *lot* of functionality to it that would require serious thought on the general semantics. As it is, Expose does exactly one thing, and does it very well. The reason it's so powerful is that the *rest* of the UI supports the rest of the actions you perform with it.
Originally posted by tchwojko
F10 for mini single app, Cmd-Tab to switch between mini single apps.
Not exactly the grouping you're looking for, but functionally might do the job?
It does the job, so does the standard F9 command, just much less effective.
Originally posted by Kickaha
That's pretty darned simple. Expose does one thing... *EXPOSE*.
Right, what I meant was that you can outline how Exposé works in detail and it will look as "complex" as I made the other thing I wrote. But it in and of itself is not complex to use.
Originally posted by Kickaha
Now, if you wanted to argue that you should be able to click on window widgets in Expose mode just like you do for background windows, and have it register, then I can't really argue against that one, except on the grounds of usability of hitting such a *teensy* target. (In which case the user is more likely to hit the wrong widget and close when they mean to Dockify, etc... which is a good reason not to allow it.)
No no. I definitely do not want to be able to manipulate widgets/data/things in minimized windows at all. Only if made 100% size.
Originally posted by Kickaha
Altering Expose to be a meta-app-level window manager is adding a *lot* of functionality to it that would require serious thought on the general semantics. As it is, Expose does exactly one thing, and does it very well. The reason it's so powerful is that the *rest* of the UI supports the rest of the actions you perform with it.
It adds no more complexity than adding "quit" functionality to a cmd-tab application switcher did.
It would use semantics already used elsewhere.
Ok, better design:
In Exposé just shift-click whatever windows you want to close (or use a selection marquee as in Finder). Then either do cmd-w or right click anywhere and choose "Close selected windows".
Exposé should have a contextual menu.
Contextual items should include:
Close Window (Closes the window immediately, repositions/rescales remaining windows, exits to application if dialog is presented)
Close Selected Windows (if multiple windows are selected; Closes the windows immediately, repositions/rescales remaining windows, exits to application if dialog is presented - same as current method of switching to each app for saving upon Logging out or Restart)
Keep Minimized (aka Minimize In Place; Keeps the window where it is, the size it is upon exiting Exposé)
Minimize to Dock (removes the window from the Exposé context - add it back in by clicking on it in the Dock again.)
---
Anyway I don't think applying commands cross application is a bad thing.
When you Shut Down/Restart/Log Out you magically go from one application to another making saving/not saving decisions and the OS hand holds you to all the appropriate applications. My only change is that rather than shutting the machine off or logging out, you can just be back where you were (where this should be is debatable) but having gracefully shut a ton of windows in a meta-application level from Exposé.
Other 3rd party cmd-tab switchers let you queue up multiple apps for quitting as opposed to the current "quit only what is selected" method. I'd like to be able to queue up windows for closing across application lines at the Exposé level.
I haven't needed to invent any new semantics. Merely using existing conventions.
Yes I do favor treating minimized windows as draggable objects (although I absolutely do not want interaction with their contents while minimized) so that's a bias that is contentious to some.
Of course, tabbed browsing messes everything up now doesn't it.
My hope is that since Apple typically muddies up the so called elegance eventually
They combine things all the time in the dubious name of consolidation and refinement; usually in an arguable manner just to justify having made enough changes to warrant an upgrade
I am interested how Apple can make Exposé more available to everyday users, though. It's currently tucked away rather on purpose, seems to me, as it's somewhat advanced, and could potentially bewilder novice users (esp. if activated by screen corners).
Exposé preferences in the Apple menu, including an option for toggling it on or off with a single command, are a no-brainer. That'd be great.
Should Apple offer the option of activating Exposé from buttons on the Dock? Probably not -- three big buttons that take up a lot of space and could move around seems out of place, and not a great solution. Nor can Apple mark the F9 /F10 / F11 keys with keyboard symbols, as Exposé is so customizable.
Perhaps the Exposé gospel just has to spread...
I say nay.
How much faster do you want it? The only thing I would suggest would be the ability to use cmd+w or cmd+q keys over the highlighted exposéd window.
All this about shift-clicking and shift deleting is silly when we already have key sequences for closing windows and quitting applications.
As for dirty windows, they would work like the cmd-tab selector works when you use it to quit. The window will simply pop out its sheet asking to save. If you don't then goto that app, it simply sits in the background waiting for your attention.
Originally posted by Gargoyle
Click - Click - cmd+W
How much faster do you want it? The only thing I would suggest would be the ability to use cmd+w or cmd+q keys over the highlighted exposéd window.
All this about shift-clicking and shift deleting is silly when we already have key sequences for closing windows and quitting applications.
As for dirty windows, they would work like the cmd-tab selector works when you use it to quit. The window will simply pop out its sheet asking to save. If you don't then goto that app, it simply sits in the background waiting for your attention.
The reason shift is suggested is that obviously some modifier is required since single clicking merely exposes the fullsize window.
You would not be able to "click-click-cmd-w" (if I understand you correctly) to close two windows since clicking the once pulls you out of Exposé.
Yes, use the existing key sequences for closing windows and quitting applications, but you still need a way to select multiple minimized windows. What better way than the existing Finder methods, namely Selection Marquee and Shift-Click Multiple Selection.
Unfortunately this is one of those things that needs to be built first, only then can people play with it and get it.
Originally posted by bauman
This reminds me of when Apple included a 'close window' command in the contextual menu on a minimized window in the dock in the 10.3 beta. They ended up leaving it out due to the complexity of dealing with sheets and quitting apps. If it's too complex to do one window at a time from the dock, I don't think it's a good idea for Expose.
I say nay.
It needn't be the slightest bit confusing.
The user uses the contextual menu in the Dock (nothing new except the Close Window command itself), the window would merely de-minimize from the Dock (nothing new), then the user decides to save or not save (nothing new).
I don't see the chaos in that.
You are merely offsetting the verb to take place after the de-minimize effect.
Currently:
(Window is minimized in Dock)
1. Click to icon to de-minimize it
2. Choose Close Window/hit red widget/cmd-w/whichever
3. Answer the sheet to save or not
The in-Dock method:
(Window is minimized in Dock)
1. Click and hold the icon to trigger the contextual menu and choose Close Window
(Window de-minimizes)
2. Answer the sheet to save or not
I don't see it being worse. Granted contextual commands should not be the only way to do something.
Originally posted by johnq
Granted contextual commands should not be the only way to do something.
BINGO.
So, 'splain how you're going to create a non-contextual menu item that allows for an Expose-mode multiple closing?
Perhaps have the menu bar just plain convert to an Expose menu bar, making it an application that's really a meta-application, but not really since it's just an application?
Ain't this *FUN*?
Originally posted by johnq
Well, Brad gets todays Kudos award for at least bothering to lay out particulars of what he doesn't like.
I laid out the particulars before you even started participating in the thread...
Exposé isn't for manipulating windows, but rather for choosing them. When you invoke Exposé you are not really manipulating them, but observing them from a different point of fiew. Imagine a bunch of stacked windows as on a crumpled piece of paper. You're uncrumpling the paper to see all the windows at once, but you aren't literally changing the positions of the windows relative to another.
No actions should be able to be done on windows while in Exposé. When invoked, it's like a frozen moment of time. you have to choose a window to get everything started again.
Originally posted by johnq
The reason shift is suggested is that obviously some modifier is required since single clicking merely exposes the fullsize window.
You would not be able to "click-click-cmd-w" (if I understand you correctly) to close two windows since clicking the once pulls you out of Exposé.
I think what Gargoyle was trying to say is that, currently, CLICK to open expose, CLICK to open a window, CMD-W to close that window.. simply stating that it's really not that difficult, something i happen to agree with. However, Gargoyle goes on to suggest allowing CMD-W to work within Expose, closing the window the mouse is hovering over. I think this is the best solution. Doesn't change the standard key combination. Some people seem to be begging for selecting multiple windows to give them all the same instruction (close window, etc..), I believe hovering the mouse over each window and pressing CMD-W is really just as elegant and quick a solution as being able to select multiples first.
At the same time, I also think CMD-Q should be enabled. When in "Application Window" Expose, it would close the app and switch to "Show All Window" Expose.
Originally posted by Kickaha
Ayup, and during this thread it occurred to me: "Why isn't Expose in the Apple menu? It's a system-level event." (Off to send feedback to Apple...)
I think one reason why it's not in the Apple menu is because it makes the Apple menu inaccessible in the process. As you noticed, the menu bar remains, but it becomes untouchable. Most users expect to be able to select the menu option again to toggle off again.
The only Exposé mode that I might allow in the Apple menu is the "Show Desktop" one...
Originally posted by confirmed
I believe hovering the mouse over each window and pressing CMD-W is really just as elegant and quick a solution as being able to select multiples first.
At the same time, I also think CMD-Q should be enabled. When in "Application Window" Expose, it would close the app and switch to "Show All Window" Expose.
That still doesn't really address how the menu bar is inactive in Exposé when you want to use these commands. And it also doesn't address the save dialogs and other unexpected window behavior (non-behavior) in apps that don't conform to the HIG.
Exposé is for viewing/observing/exposing and not for manipulating.
Originally posted by Eugene
That still doesn't really address how the menu bar is inactive in Exposé when you want to use these commands. And it also doesn't address the save dialogs and other unexpected window behavior (non-behavior) in apps that don't conform to the HIG.
Exposé is for viewing/observing/exposing and not for manipulating.
technically, you're right.. however, it wouldn't be the first time Apple ignored their own guidelines (see this thread for proof of that).. i believe a minimal undocumented feature such as this wouldn't really hurt anything as far as user friendliness goes, as it would go unnoticed by most users.. it'd only help the "power users" who want to use it.