A proposal for improving Spaces in Leopard
Like a lot of folks, I’m not quite happy with the implementation of Spaces in Leopard. Overall, I think it’s a beautiful solution, but as Dave Dribin points out, Apple is trying to make an advanced feature accessible to the masses, and as a result, it doesn’t work very well for the folks who will likely use it most: power users.
Traditionally, making power user features accessible to regular users has been one of Apple’s fortés, and they’ve usually managed to do so while still maintaining the flexibility that power users require. With Spaces, however they’ve fallen short of that mark. It’s a new feature, so hopefully they’ll improve it with future updates. Here’s one way I think they could improve it dramatically.
The above screenshot shows the Spaces prefpane with one simple addition: a checkbox, selected by default, which reads “Switch Spaces automatically.” With this checkbox on, Spaces would behave as it currently does, automatically switching Spaces when you switch to an app whose frontmost window is hidden in another space. (Perhaps they could smarten it up a bit so it wouldn’t automatically switch if the given app already has a window open in the current space, but I digress.)
With this checkbox off, Spaces would never switch spaces for you. Instead you would stay in the current space until you decide to switch spaces yourself, either by invoking the meta-view and clicking another space, or by using the modifier keys defined in the Spaces prefpane.
So suppose you’re in space 3 and all your currently-open Safari windows are in space 1. If you switch to Safari, it would act as if there were no windows open and open a new one for you. So each space is truely like a new monitor, a new workspace, oblivious of its partners.
Let’s follow this through a bit more. There are certain window types that you’d want to have available in every space. For example, Safari’s Preferences window, or its Downloads window, or Mail’s Activity window. These would be useful to have in every space. But what if Safari’s Downloads window is already open in space 1, and you press Command-Option-L while in space 3? With auto-switching off, invoking any window that is already open in another space would bring it to you in the current space, rather than swooping you over to it. So if you’re in space 3 and you want to look at that Ebay auction item that’s open in some other space, you could choose the window from Safari’s Windows menu, or from Safari’s Dock menu, and it would swoop into view in your current space, keeping you in place, not disrupting your workflow or your context.
I think this simple change would go a long way toward making Spaces work for the power users who are most likely to get the most use out of it, while still keeping it simple and accessible for folks like my dear old Mom.
[Hat tip to @philoye for thinking this through with me.]
Comments
Pascal says: “Developers shouldn’t have to mod their apps in any way for them to work out of the box in Spaces.”
Agreed. But it makes me wonder:
Is it possible for Spaces to make/provide the kind of choices to minimize complex and frustrating usage scenarios without needing app-specific support? During the time I ran CodeTek VirtualDesktop Pro in pre-Tiger days I noticed quite a few changes related to making it behave “correctly” with specific apps. Will Spaces have to go through a similar process and/or will “impatient” apps be modified if Apple won’t do it (fast enough)?
@Pascal: I get the Channel analogy very well, being French myself. Impossible n’est pas français.
Regarding special windows in app, Apple did the best it could do by making Panel-type windows Space-independent. But the developers may have Panel-like windows that are not really Panel, from a programmatic point of view, and for different reasons (NSPanel class vs NSWindow class). Spaces cannot guess that the Documentation window of Xcode should follow the app through different Spaces, instead of triggering the Space dance.
In fact, the Panel vs Window analogy is very relevant. One of the reason the developer may choose a Panel vs a Window is that a Panel will by default be hidden when the app is not frontmost anymore. This is an example of where it is the developer responsibility to decide between different behaviour.
Hence, to some extent, some of the behavior has to rely on the developers’ hands, but here we are just talking about a more refined behaviour, and the app will work out of the box without this refinement.
wickedly good proposal for improving Spaces in Leopard. I love Spaces, but it’s got serious issues. This would be a painless solve for a large […]
Excellent idea. I’m actually pretty happy with Spaces, though I think what you suggest here is too good not to do. I hope Apple hears you – I’ll be suggesting it to them: http://www.apple.com/feedback/macosx.html
Excellent, so true. It would be great if Apple implemented these features/updates. I have also been frustrated by Spaces. Maybe if Apple doesn’t do it, a third party might?
Yesohyesohyes… I would seriously want this feature. It’s the one reason I haven’t upgraded my Macbook to Leopard yet: it’s still running Virtue Desktop, which behaves just like I want 🙂
In an ideal world, what I’d like to see is a standard modifier combination that toggled the behaviour on the fly in all contexts. Call it fn. Then we could have
command-N -> new window in application space
fn-command-N -> new window in current space
click-in-Dock -> switch to app, move to space of frontmost window
fn-click-n-Dock -> switch to app, frontmost window to current space
Dock-select-window -> bring window frontmost, go to that space
fn-Dock-select-window -> bring window frontmost in current space
etc, etc, etc
It’s probably not entirely feasible because so many modifier combinations are already claimed but maybe it can be approximated.
[…] to make me considerably happier with Spaces behaviour. The first one has already been covered by Pascal.com. Include a ’switch spaces automatically’ checkbox, checked by default. Then make the […]
@Pascal:
| Tom von Schwerdtner says: “The [Safari Download] window is just a utility, a notification
| really, why would you ever want to shift desktops just because of it?”
| I don’t! Re-read what I wrote.
I know *you* don’t. My point is, if virtual desktops were around when Safari was first written, it is a question that the the developers would have asked themselves. The Safari developers would have known, had it come up at the time, that shifting people to a different desktop just for the Safari Download window is excessive and perhaps even obnoxious.
Just sayin’, it’s not all up to Spaces, the app developers have work to do too.
Many good ideas 🙂
But I still like Apples way – so like you say it should be a extra option –
Right now Spaces has the good thing that if you have Safari in space 1 and fx. Mail in space 2, then you can “com (apple) click” on a link in a email if you want the new Safari window to open in the same space as Mail – thats nice – the only problem is that it opens in the background 🙂
Mark Barton says: “In an ideal world, what I’d like to see is a standard modifier combination that toggled the behaviour on the fly in all contexts. […] etc, etc, etc”
Tricky handling cases like “app1 opens app2 window (or launches app2) in current/other space in foreground/background with/without app/space switch”. 🙂
I think Spaces handles command-click on a link in a Mail message by opening a browser window in the background without doing an app/space switch. I’d consider that well-behaved, even if you don’t like it. Not sure what it does if the browser’s not running; will its launch cause a space switch if the app is bound to a non-current space? If so, I’d consider that ill-behaved, even if you like it, because it requires thinking about whether or not the browser is currently running to predict what’ll happen. If the expectation is that command-click doesn’t do an app/space switch than a special case where it *does* do an app/space creates inconsistency.
That’s not meant to be an obscure hypothetical example; cases like it are common with intra-app communication and one reason why Spaces’ (et.al) auto-switching can be a nuisance. I’d like a well-defined, consistent way of doing “app1 talks with app2 in the background” actions.
Could be interesting comparing working styles and experience of people who prefer space auto-switching to those who don’t. I wonder if people comfortable with classic Mac OS app/window hiding/switching interaction might be more prone to like auto-switching while those who’ve used other vwm’s to manage apps/windows would rather have explicit switching. I’d get more value from discussions like this with a better understanding of how other people actually used their systems.
Hey michael, you snuck in your post about command-click in Mail while I was still composing mine. 🙂
Your description doesn’t quite match the way it worked for me during brief testing at the Leopard launch, but I’m more interested in how you prefer it to work and I think you made that point.
[…] working as close to what I would have liked but still I would prefer if Apple were to fix Spaces as this post […]
Yes, this would make Spaces useful. As it is, it’s spastic and annoying, despite its great potential and beautiful implementation.
Pascal, let me explain what I mean more thoroughly. I re-read your article closely (though still not all the comments), but I think I was confused by the paragraph starting “Let’s follow this through a bit more …” which seems to undermine the one above. At least it does to me. (I think you’re talking about certain child windows of certain apps, but it would probably be a bit difficult to empower Spaces to control a preference window of a particular app.) I take your point though about opening a new application window in my current space rather than switching which leads me on to say …
Firstly, I think the auto-space switching is an essential feature. To use your example, say I’m in space 3 and I have Safari open in space 2. Though I might want a new Safari window in my current space, aren’t I more likely to want to look at something I’ve already opened in Safari in space 2 where I’ve been browsing? When I select Safari (using Cmd+tab or the Dock icon) the default should be to switch, unless I specifically open a new Safari window in my current space, which I should definitely be able to do.
‘Allow instance in every space’ is different to ‘Every space’ in the following way: ‘Every space’ keeps all windows of a particular app in all spaces. ‘Allow instance in every space’ would let me spread different windows of the same app (multiple Safari windows for example) across different spaces. So, instead of all Safari windows following me to each space I switch to with ‘Every space’ I could have a contextually applicable Safari window in more than one of my spaces. I think this would fix the issues with spaces as they are at the moment.
Overall this is a very interesting issue, as I can see two distinct ways of thinking about Spaces … and I actually operate both at once! One way sees a particular space based on a task. I have Thunderbird always in Space 3 for example. This is a task-oriented uses of spaces. My IM app might sit nicely in this space too if I used one. Looking at the other way, I also keep spaces 1 and 4 for real work where stuff contextual to that work goes on. These are looser, context-oriented spaces where all sorts of apps relevant to what I’m doing can reside. Honouring both these ways of looking at spaces is quite a challenge: the first requires switching spaces, the second not switching spaces. This is further reason why ‘Allow instance in every space’ is a more suitable workaround than retarding the automatic space switching.
Thanks for sparking off this debate. It proves, at least, that more thought needs to go into Spaces and Apples UI people should look at it more closely. That said, Spaces at this stage are still more powerful and pleasant to use than the Linux equivalents that have been around for years.
[repost to fix botched blockquote; where’s comment previewing when you need it?]
Mark said:
If you select “New Window” in Safari’s Dock icon menu does it open in the current space regardless of any preexisting Safari windows in other spaces?
Definitely worth implementing though it won’t fix everyone’s issues. 🙂
…
Part of the trouble seems caused by borrowing pre-Spaces methods of app switching for space switching. For me it’s less confusing to keep them distinct instead of anticipating if invoking an app switch will also cause a space switch, and to which one. The tradeoff is having to remember which space to switch to, or keep switching until its reached.
And the “app switch may create new window” behavior, which some people rely on, doesn’t integrate particularly well with Spaces.
Likely it’s impossible to get consistency in all cases with Spaces, especially without any app-specific support, but certain improvements would definitely get closer to that goal. And with dubious changes it might end up suffering something analogous to Finder’s spacial vs. browser identify crisis and John Siracusa can start writing about that for a change. 🙂
Most Virtual Desktop apps for OS X have had these features for quite a while. CodeTek VirtualDesktop, Desktop Manager, VirtueDesktops and You Control: Desktops. Unfortunately, all of these apps seem to be discontinued with the exception of You Control’s Desktops. At $30, it might be pricey, but it’s worth the price to have control over your workspace.
I’d like to see an option to have a default space for apps to open in if you haven’t configured it to open somewhere specifically.
By and large I’m working in one space with other Spaces configured for particular things. I have iTunes open in one space at full screen. Mail, iChat, Adium etc in another and so on. I want those apps there because having it that way fits my workflow.
If I happen to be in one of those spaces and then decide I want to open some random app to use in my work area I have to move it. This happens regularly. I would like to be able to say that everything will open in space 1 (for example) unless I have either allocated it somewhere else or I perhaps manually override it when opening so that it stays in whichever subspace I’m in.
Currently I find I have bits of apps all over the place and I have to remember to move them back or move to the right place first. I could go through every app and configure it to start by default in a particular place but that’s a pain.
[…] Not to mention that fact that the continued competition will hopefully serve as a prodding to Apple to bring added functionality and configurability to their own Spaces application within OS […]
Having never used a Virtual Desktop program before, I’m finding Spaces excellent.
I agree (with so many others), this option would be great. Even a mere “defaults write”-solution would make me happy (though a setting is much more friendly of course). Reasonably, Spaces would still jump to apps bound to a specific space, but never otherwise (with this checked).
While awaiting any official solution, “Spaces.. Spaces.. Spaces..” at seems promising.
Or, as I currently do, use Ctrl-F4: the shortcut to “Highlight Window (active) or next window behind it” (requires “Full Keyboard Access” to be on — toggled by Ctrl-F1). It cycles differently than Cmd-Tab, but shift reverses direction, so it’s quite ok. The combo itself is awkward though, so I changed it (in “System Preferences -> Keyboard and Mouse”) to alt-a..
I wish I had seen this article when I filed a Spaces bug report last week. Your suggestion is exactly mine. I received a reply saying that it was a “known issue” and that my bug report had been refiled under bug #4621420.
How Apple thought they would “subtly” change the behavior of Spaces from that of every other virtual desktop manager from the last 15 years, and not receive a ton of grief from their users, I do not know.
Keep the bug reports flowing, and let Apple know what we think. There are a lot of us asking for the same thing, and the fix is easily implemented; this bodes well.
This is an ancient post, but I’ll respond anyway. You can now do exactly this by changing a Dock default:
defaults write com.apple.Dock workspaces-auto-swoosh -bool NO