Auto-Workspaces
Yesterday I posted a bit on how we plan to simplify the overview in Gnome Shell by dropping the tiled view. One thing that wasn’t so fancy about the new workspace panel — it still relied on the user to set up and manage the whole workspace environment .
It would be far more desirable to have Shell take care of most of that management stuff. Heavily inspired by zones from Moblin, here’s the latest proposal:
- There are no empty workspaces (apart from the initial state of not having any windows open whatsoever). If there are no longer any windows on a particular workspace, it gets merged with the adjacent one.
- To launch an application in a new workspace, you drop the launcher on the [X] target thumbnail. Similarly you can launch it onto existing workspace or move windows to a new/existing workspaces.
- In all other aspects it behaves the same as the previous iteration.
In future we might come up with a decent rule of what applications to run in a separate workspace by default (Gimp being one of those potential apps). We need to make sure the concept of workspaces is easily understandable in this case though, as suddenly they move from the realm of optional power-tool into a core functionality. As apps can be launched from outside of the shell overview, we would probably need to make the workspace switching animation much more pronounced. One such transition might zoom out the desktop a bit, slide to the right workspace in stack verticall and then zoom in again. Obviously all this in a fraction of a second.
November 23rd, 2010 at 7:26 pm
Hi!
I like shell but I keep finding it very strange that you guys keep having ‘long distances’ in the UI. For example: the drag from application on the left side to the workspace bar on the right.
Why not have the workspace bar on the bottom, or even top? _much_ less distance: in a multi-screen setup the left-to-right distance is even more relevant. Also, screens are mostly getting wider and not taller, which would indicate a preference for top-bottom placements.
Even in the old UI of shell this was a problem because there the ‘add workspace’ button was placed in the bottom right corner while accessing it required a mouse move into the upper left corner _and_ then a move into the lower right corner; a distance of between 2 and 3 times the screen width, depending on aspect ratio! Placing that button near the upper left corner would have been _much_ better even then.
If possible UIs should keep action targets in the flow of the movement. Reversing direction with the mouse is an annoyance for the brain, more so when the distance is increased.
my 2 cents
November 23rd, 2010 at 8:13 pm
Speaking of moblin zones, here’s an idea I also proposed to the moblin/meego UXer in charge (but we didn’t get around to implement it yet).
What bugs me is that, unlike you use keyboard shortcuts, switching zones is a lot of effort. I think it would be nice if when you moved your mouse pointer to the border of the screen, and then a bit further, you would “push” the current “viewport” over, say 1-2cm, and see a bit of the next workspace. If you clicked on that part of the other workspace, or kept moving the mouse, you would eventually switch over.
Does that make any sense? I might be able to do a mockup if that’s not very clear.
November 23rd, 2010 at 8:15 pm
As someone who worked on Moblin Zones I can’t help but feel very happy about this. Looks awesome, go for it!
November 23rd, 2010 at 8:17 pm
Instead of “There are no empty workspaces” why not go for a model where “There is always *exactly one* empty workspace” ?
Visually, this is the same as removing the “+” button, and making it look like a clean workspace thumbnail. Behaviorally, though, this would allow you to actually switch to a clean workspace if you want to. This is useful when you want to look at your desktop (to show your background to a friend, or to access an icon) and also when you want to get the feeling of “starting with a clean slate”.
November 23rd, 2010 at 8:53 pm
When does this land in trunk – ie replacing the now extinct zoom out with the big left bar.
November 23rd, 2010 at 9:38 pm
Sorry but judging by the latest mockups the direction that the shell is taking is:
Take the current desktop functionality and add another -useless- layer on top
the shell adds steps between the start and the complation of an action (compared to the current desktop)
and thats plainly stupid
the whole point of rethinking the desktop is to make it more efficient
November 23rd, 2010 at 9:39 pm
If this is supposed to work also for small form factor devices, isn’t the top bar to small to use it? (I’m thinking tablet here). Also, isn’t all the drag&drop is inconvenient too for those devices?
November 23rd, 2010 at 9:40 pm
@Ferry: Fair points.
@rob: Before we have the window gestures figured out, I’m affraid we’ll have to punt this.
@nick: You guys did a ton of awesome work on moblin!
@tvst: Not bad at all. And doesn’t make the initial load state a special case. I like!
@Jared: While none of the workspace stuff reached a state I would suggest to go implement, the new layout branch (overview-relayout) should be merged within a week or two.
November 23rd, 2010 at 9:58 pm
You know what I like the most of this mockup? You’re not rearranging the windows on the “background” workspaces. It was a pet peeve of mine.
Also, this is a definitive improvement wrt “single workspace experience”, now you’d only need to address a better way to switch applications: it can be very distracting to see all the windows rearranging themselves every time you switch from an application to the other. My favorite example: you’re writing an email and you need the calculator to insert the result of a few sums. You don’t want the email application to “change” every yime, you want use the calculator and copy the numbers with a minimum of disruptions.
That’s annoying for me, it would drive my mother up the walls. (Please, don’t suggest alt+tab. Most people use the keyboard OR the mouse, not both of them at the same time)
November 23rd, 2010 at 10:00 pm
I am a little intrigued of why do you ditch the tiled-view. Don’t get me wrong, I like the latest mockups, but I have some doubts, since the tiled-view was useful and intuitive for some uses (but of course, it seemed too much to have that each time you go to the overview).
So, some of the doubts are:
- How do I move a window from one workspace to another? If the window is in the current workspace, this is simple enough, but what about if the application is in a different workspace?
Another thing, some time ago Luis Villa talked about the “Panorama” feature of Firefox 4. I really like this idea and I was hoping that the tiled-view could evolve into that, since it allows me to give more area to “more important” workspaces and thus making a sort of hierarchy of workspaces. So what do you think from UX point of view about a “Panorama” view for the Shell? So, maybe you can also point out why tiled-view is bad.
November 23rd, 2010 at 10:53 pm
What is with this obsession that you must force workspaces on people? While I am sure workspaces have their uses not everyone wants them.
And what about the arrogance of suggesting you know better than the user how and where they want their app started? Don’t assume that just because you want Gimp in its own workspace that everyone else does.
November 23rd, 2010 at 11:01 pm
I agree with the first poster – big distances between related actions.
I’ve got a nice big 30″ monitor and to start an application in a new workspace I need to move the pointer to the top left, then bottom right to add a workspace then top left to get application then drag back to near the bottom right to place it on the new workspace.
With a mouse its doable but slow – with laptops with track pads is painful
- doesn’t seem like good interface design to me.
November 24th, 2010 at 12:01 am
I agree with about the increasing width of our displays and suggest moving the workspace strip to the top (below the panel, obviously). That is very similar to how GIMP is handling multiple documents in the dev builds.
Also, ++ for the blank workspace replacing the “+” sign.
November 24th, 2010 at 12:31 am
I like the idea of having a work space selector that is always visible. This speeds up the process of changing workspace, because it allows me to decide what I want to do before I start moving the mouse.
My only worry is that your workspace selector is so big that it will be covered by windows most of the time. Then I have to spend time moving the windows before I can reach the workspace selector that allows me to change workspace. That is a lot of work for a small task.
BTW: How will your workspace selector look if I have less that 3 or more than8 workspaces?
November 24th, 2010 at 1:54 am
How does it work just with keyboard (without touching the rodent)?
November 24th, 2010 at 6:15 am
I have to say, that around six months ago, I wasn’t all too excited about gnome-shell, nor did I really enjoy its interface much, but I’ll be taking another look at this (with an open mind) since I know you’re on the beat, making the UI rock. thanks, and I hope it all turns out super-pro.
November 24th, 2010 at 1:04 pm
@james Very glad to hear that. Taking a break from work and letting folks know what’s happening is just as important as having all the development happening in the open. So I’m glad that you somewhat validate that
@mcepl: “No rodent” navigation will probably benefit from that “one empty workspace” approach tvst suggested. Moving windows around will still be achievable with the window context menu, similar to what we have.
I also have to reiterate that workspaces aren’t the focus of the Shell at all. They will be out of sight if you don’t want to worry about them.
November 24th, 2010 at 2:27 pm
Hej,
I think you should look at xmonad or awesome wm. Learning from tiling window managers means learning how to succeed.
In awesome wm and xmonad it is possible to open applications just with the keyboard. It is possible to define that applications open on workspaces with a specific topic. You can easily move applications with the keyboard from one workspace to another. And so on. Look at those efforts, be inspired and try harder.
Just a tiny advice.
November 24th, 2010 at 3:01 pm
@robsta
@jimmac
And that (the lack of good window gestures) was exactly the reason why we didn’t implement that feature in Moblin. Initially we were very keen to let the user ‘push’ or ‘knock’ the edge of the screen to move windows from one workspace to the other.
The one empty workspace is an interesting one. Is a goal for shell to still have a load of stuff on the desktop?
November 24th, 2010 at 3:36 pm
Regarding the “too much space between sidebars” problem: why not merged the two sidebars? That is, show both apps and workspaces in the left sidebar? Please look at this mockup:
http://i.imgur.com/AoMAb.png
It’s basically the same as Jimmac’s mockup, but with those blue boxes representing workspaces.
- The active workspace is represented by a slightly brighter box. Inactive workspaces are slightly dimmer.
- Some of the applications (in the mockup, Firefox) aren’t inside a box: that means that they are just launchers for favourite applications, which haven’t still been opened.
- When you open an app, its icon moves to the workspace where it has been opened. In the mockup Totem and Banshee were opened in workspace 1, while the rest are in workspace 2.
- You can drag alauncher to another box in order to move its window to another workspace. You can also drag the boxes themselves to reorder the workspaces.
- You can click an app icon in another workspace, and you’ll switch to that workspace and app. You can also click a blue box and you’ll switch to that workspace, focusing on the most recent window.
- The blue box at the bottom represents the empty workspace. You can click it to move to that workspace and then open an app, or drag a launcher to it, and a new empty blue box will appear.
- If you move the cursor all the way to the left edge, the sidebar can thicken to give you some extra space for workspace manipulation (represented in a second mockup: http://i.imgur.com/AGWlX.png
What do you guys think about it?
November 24th, 2010 at 5:32 pm
I’ve made a couple more mockups, complementing the old ones to better convey the idea:
http://i.imgur.com/pb5eb.png shows the initial state of the sidebar. Two apps are “pinned” but none of them is open. There is only one workspace, which is empty at the moment.
http://i.imgur.com/M1DpJ.png shows the sidebar after you open one app (in this case, totem). The first workspace changes size to accomodate totem’s icon, and a second empty one appears.
http://i.imgur.com/CHhU6.png shows the sidebar after you have opened various apps over two workspaces, with a third empty one having appeared.
http://i.imgur.com/phli6.png shows the sidebar after moving the cursor all the way to the left edge.
November 24th, 2010 at 5:43 pm
David: Thanks for looking into this. Anyone else interested in playing around with various concepts, all the assets for these mockups are in the gnome-shell-design module on git.gnome.org. Some concepts live in a branch so check them out.
My initial impression is that this combo-approach might be visually very overwhelming.
Combining launchers with workspaces may pose an issue as app!=window and a single app having multiple windows on multiple workspaces isn’t quite a corner case (people working on multiple projects at the same time, using workspaces for it — office apps, graphic editors, whatever). We might throw a baby out with a bathtub water if we force all app windows to stay within one workspace.
Don’t get me wrong though. It would be a good direction if workspaces were a key concept for shell. The distance to travel when switching workspaces when using only a pointer might sound like a big bummer, but you have to realize both entering the overview and going to the right hand edge can be preformed without any precision (we haven’t got multihead completely sorted but I imagine having some sort of velocity wall/speedbump for the edges).
But again, thank you for looking into it!
November 24th, 2010 at 6:33 pm
Hi Jakub, let me try to elaborate a bit here:
As for my proposal being visually overwhelming. If you are referring to the number of onscreen elements, consider that there is actually less stuff going on in the sidebar because open apps don’t actually have to be highlighted to differentiate them from favourite apps.
As for single apps having multiple windows on multiple workspaces. That’s a case I had already considered. Let’s imagine that you have one firefox window and one totem window in the first workspace, and exactly the same in the second workspace.
If you were on workspace 1 you would see this: http://imgur.com/ZcGyR.png
Whereas if you were on workspace 2 you would see this: http://imgur.com/xPitC.png
In other words: if you have multiple windows on multiple workspaces, the app icon would appear on the current workspace. The other workspace would indicate (for example, with a colour change) that it’s not empty even if it doesn’t have any launchers.
Does this solve the problem you mentioned? Does it raise other concerns?
November 24th, 2010 at 6:49 pm
Jakub, I was showing your mockup to a friend and he asked me what would happen if there were lots of application open, so many that there wouldn’t be place in the sidebar for all of them.
I’m not sure what the intended behaviour is at the moment, but my method could provide a solution for this case: only the icons for apps in the current workspace would be shown, whereas every other workspace would appear minimized, taking a minimal space. The mockups in my previous comment show more or less what these minimized workspace could look like.
November 24th, 2010 at 8:28 pm
I really see this a separate issue from the workspaces. I don’t like combining the two for the reasons I mentioned above.
If a scalability issue arises in future for favorites/running apps on the dash, we might introduce some sort of grouping/shelving like opera11 tab stacking or IOS’ 4.2 folders. But for now, scaling seems to be just fine for the dash as well as the workspace panel. KISS.
November 24th, 2010 at 8:55 pm
Thanks for considering anyway, Jakub! I had a great time giving it a thought!
November 24th, 2010 at 9:02 pm
By the way, there are still a comments of mine that appear as “awaiting moderation”. Please make sure that you at least see them, since they address some of your questions.
Thanks again!
November 24th, 2010 at 10:35 pm
Oops, sorry. Every time there is a link it usually ends up in the queue. All your comments should be visible now.
While I certainly don’t dislike the concept, there are bits that I believe the separate approach is better at – thumbnails work better for identifying a workspace than a group of icons. If you don’t force apps to show windows on a single workspace, I don’t think hiding the non-active workspace icons is a good solution. You get even less overview of what’s open without going workspace by workspace.
The concept does have its strong sides though – not being in the way when you don’t want to use workspaces is probably even better than the hiding as your workspace indicator can be made even more subtle — less opaque fill or outline only (I might want to scale down the ‘running app’ indicator a bit, it is somewhat too prominent I agree).
November 25th, 2010 at 12:32 am
Hey Jakub,
Some interesting points you raised there.
About thumbnails working better for identifying workspaces, I can think of a couple ways to incorporate that in my approach. You remember how I said the sidebar could thicken when you take the cursor to the left edge? Well, this could be done:
http://imgur.com/lLy5w
As you see, a mockup of each workspace would appear for easy identification, but the blue boxes would still be used for workspace switching and managing.
This would also solve the problem about not having an overview, since you would have exactly the save overview as using the original right sidebar. Even more, putting the icons from the active workspace (i.e. the stuff you’re working on) on a separate box makes them easier to find with just a quick look, since you don’t have to mentally separate them from those on other workspaces, which don’t concern you right now.
Please don’t think I’m trying to push this on you, I found your mockup so brilliant it just got me thinking and thinking.
November 25th, 2010 at 4:56 am
I would really like to see some representation of which applications are running on a given workspace – trying to figure out which window is which can be a pain in a preview.
My thought process will be ‘I need to find Eclipse and I forget which space it’s on.’ I don’t want to squint at workspace previews to find it.
I want to click on an Eclipse icon (easy to recognize without thinking) and be taken straight to the workspace containing it. If two Eclipse windows are open, in different workspaces, it would be great to see a preview of both workspaces with the title of each window clearly visible so that I can differentiate between them.
Try using gnome shell with 5 or 6 xterms, 4 or 5 browser windows, 3 or 4 PDF documents and a bunch of spreadsheets open and you’ll see what I mean. Too many similar windows, and I’m looking for a remote terminal that’s connected to host X, or PDF documentation on subject Y.
Please just let me do “Open Evince documents -> Useless whitepaper” or “Terminal windows->root@farawayhost” and get me to the right workspace without squinting at window previews or cycling through spaces.
Maybe click a running-app icon and have all workspaces that don’t contain that app’s windows actually vanish, and also hide all other windows in those spaces that aren’t that app. This gets the cruft out of my way so I can make a decision.
Watching your work with interest. Thanks for doing it.
November 25th, 2010 at 12:16 pm
@david: It’s getting a little complex…
@gabe: The filtering behavior you describe is already in place. When you right click on a launcher on the dash, context sensitive menu pops out _and_ only the app windows are shown.
http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/overview-window-picker-context-menu-pushes-windows-away.png
In addition the search might be matching for open windows too, so quickly getting to a window might be a matter of typing a unique string in the titlebar for example. The thing is, let’s not expect the workspace pager solve all our problems…
November 25th, 2010 at 6:39 pm
http://ubuntuforums.org/showthread.php?t=1608016
http://i.imgur.com/OWGro.png
This concept has been proposed for the Ubuntu Unity Dash and got officially rejected.
Well, IMHO it’s the best solution about dealing with programs and workspaces I’ve ever seen. I don’t think users need to see the content of a window to place it in another/new workspace.
And it’s a blind madness to drag’n'drop a program icon from the launcher on the left to the workspaces bar on the opposite right!
So it should be placed down at the BOTTOM of the screen. Not up: there live the Windows/Application(/recent document?) switches.
And the workspace selector should be ALWAYS VISIBLE, not an item unusefully hidden just waiting for an user interaction.
I don’t know how this gnome shell is moving to improve the window and workspace management from his predecessor.. The overall is a leap forward indeed.
November 25th, 2010 at 11:05 pm
jimmac: are you considering multi-head cases at all in your designs? This does worry me, as all the mockups always seem to be a single head, and the old GNOME Shell in F14 really doesn’t work too elegantly with multi-head – it pretty much just ignores the right-hand monitor. It seems like this is a fairly big use case that should be engineered in from the start and not tacked on as an afterthought later; tacking multi-capability on as an afterthought is how it was done in GNOME 2 and KDE 3, and it didn’t work out that great.
November 29th, 2010 at 9:35 pm
For me we are still missing a “parking space” like described here http://d.imagehost.org/0672/minimize2.png.
For me the questions of workspaces/overview/minimized windows are all related (https://bugzilla.gnome.org/show_bug.cgi?id=604237, https://bugzilla.gnome.org/show_bug.cgi?id=607338).
What do you think ?
December 1st, 2010 at 2:11 am
I was a happy user of gnome-shell and its tile/grid mode, so I miss it very much
.
My usual way of using gnome-shell was creating a grid of 5×5 workspaces. And then I assigned a sort of category of apps to every horizontal line, for example work, study, real time apps, etc. Of course, I used the apps in full screen mode.
I’d like to have some sort of management of groups of workspaces for working in a similar way!
It would be good idea too to save the groups in order to restore my configuration in another session.
December 1st, 2010 at 2:55 am
quick draft for a quick idea for managing groups of workspaces
http://www.flickr.com/photos/jjmarin/5222486176/
December 2nd, 2010 at 5:49 pm
What if workspace preview was placed next to application icons on the left edge of screen. The problem of dragging an icon screen-wide would be gone.
Also it would be nice if middle mouse button would open an application on new workspace, just like you open a page in new tab in web browser. Forgive me if it’s already implemented I haven’t tried gnome-shell for a while now, but I like the direction it’s moving.
+1 for idea of having one empty workspace all the time.
December 12th, 2010 at 4:03 am
Hei Jakub,
I think I’m starting to appreciate your design and I think I have much better opinion than last week.
The solution for my particular use case is just using a workspace for every group of apps. It’s so obvious that I feel shame for not haven’t realised before !. Your design improve the workspace changing mechanism and moving apps to other workspaces.
The only thing I don’t get it is how this proposal works when there are more workspaces for just a column ? (Though I think it’s just a corner case, at least for me)
Keep the really amazing job !
January 6th, 2011 at 8:13 pm
Workspace sidebar represents a meta level of workspaces. That is not very good. I like the lack of taskbar as much as I don’t like the workspace sidebar. In my opinion, zoom out effect was a better idea for managmement of apps/windows on many workspaces.
January 19th, 2011 at 11:53 am
Wouldn’t this approach be a little troublesome with d&d between applications? Let’s say, from file manager to inkscape or from web browser to word processor etc.
February 1st, 2011 at 9:37 pm
Wouldn’t it make more sense to just have a workspace indicator ‘slide out’ from the application dock when hovering over it? The workspaces could be aligned horizontally so that an empty workspace is closest to the application icon (less movement), and the used workspaces are ordered sequentially to the right. Keeps the mouse gestures down and is somewhat elegant.
Example: (A=application, Wb=black workspace, Wn=Workspace ‘n’)
__
A|
A|
A> Wb – W1 – W2 – W3|
A|
–
February 1st, 2011 at 9:39 pm
I’ll also point out that this might make it fairly easy to launch applications to different workspaces via keyboard.
February 6th, 2011 at 2:01 am
@jimmac
Like a couple of others have mentioned, I too like the tiled overview of the workspaces. This was really a big advancement from expo-view in Compiz.
In my opinion the latest design introduces two issues for the daily work in Gnome Shell:
1. Long distance, when having to drag from left edge to the right edge of the screen.
2. No immediate workspace overview when switching to the activities overview.
The former design did not have these drawbacks.
I really hope that you will give the users the option to switch between the tile overview and the new workspace panel at the right.
Other than that, I really like the progress of Gnome Shell
February 16th, 2011 at 4:16 am
hate to add a ‘me too’ tag to @Adam Williamson comment.
The new design looks really nice, but shell has always design issues with dual heads, I’m not sure you could do a single design that work work for single and dual heads. I suspect the only solution is a rather different look for that scenario.
Anyway great work.
March 4th, 2011 at 5:21 pm
I have been a virtual desktop user for a long time so I fell qualified to discuss how I use virtual desktops. One problem I am having with the new Workspace metaphor is how it challenges my spatial view of Virtual Desktops. Even though I have used Enlightenment, I still tend to think of my virtual desktops running horizontally from left to right, numbered 1, 2, 3, and 4. I also have a workflow where my web browser and email is on desktop 1, VirutalBox/Vmware goes on desktop 2, desktop 3 is where something like the gimp would go, but I tend to leave it open, and desktop 4 is for “sluff”.
For the most part I live on desktop 1 with an alt-ctrl-left to 4, then back with alt-ctrl-right. Then a quick alt-ctrl-right to check on desktop 2 and alt-ctrl-left back to 1. I can clearly visualize in my mind where my desktops are and what is on each of them. Much in the same way most users are aware of the spatial location of the icons they have on their desktop. Move their icons around and they are lost. In their mental map they expect certain icons to be in certain locations.
The recent changes in the Gnome 3 shell break that relationship for me. At this point I don’t know if this is good, bad, or just different. It will create a different workflow for me that is sure. In that now I have to think of these desktops in a vertical row, not horizontal. Proof I have to think that way is ctrl-alt-left/right no longer work, now it is crtl-alt-up/down.
I have also noticed that if I have 3 desktops and I move the only window on desktop 1 to desktop 3, desktop 1 goes away, desktop 2 becomes desktop 1 and desktop 3 becomes desktop 2. Often times I have used devilspie to have applications show up on the desktop of my choice. It looks like that will not work here. I am not sure if these desktops are considered “workspaces” by devils pie or not, and what happens to the numbering as they shift, move and are deleted.
With these changes I can no longer think of things “across” my workspaces, but instead must thing of them being “stacked” and I can no longer rely on where things are at. Yes, Gnome Shell is doing all of the heavy lifting for me, much like an automatic transmissions. However, I am used to driving stick and know how to take advantage of driving stick. This change democratizes Virtual Desktops. Users no longer need to learn how to drive stick, they now have an automatic transmission. While empowering those folks, it steals away the power for those that really know how to work a manual transmission.
May 17th, 2011 at 7:02 pm
In conjunction with Fred Warren on Virtual Desktops I am wondering why there are now more movements to access another virtual desktop. For example there are now four movements. 1. Move mouse to top left corner. 2. Move mouse to the right of screen to virtual desktop/Activity of choice. 3. Click on that virtual desktop/Activity. 4. Click on the running program to be able to use it. In the previous Gnome setup it was three not four movements. More is less?
May 17th, 2011 at 9:21 pm
I have to add before anymore comments arrive. Gnome 3 looks great. Yes there are some annoying things, although there are many changes that make the annoyances worth putting up with. I’m adapting and my workflow is starting to flow nicely. A lot of time and effort has gone into Gnome 3.
August 17th, 2011 at 12:14 pm
I have to agree with nova, I actually have to do more to go to another workspace application. It is not friendly, especially if you are a developer and have a lot of applications open and organized on different workspaces.
August 23rd, 2011 at 2:55 pm
Just like Fred Warren, I also have a mental map of where my applications are. I use a 3×3 field of nine desktops, but the basic principle is the same.
Is it such a big issue to add an option to manually manage the virtual desktops? Does it contradict the design principles? (No I have not read them.)
With manual desktop settings I would honestly consider to use Gnome Shell. Automatic desktop management confuses me, as I am used to switch desktops by keyboard. Opening the Dash just to see the desktops and the applications on them before switching desktops is one step too much in my opinion.