I don’t understand how “overview levels” that are implemented as different places in a 2D view rather than actual (zooming) overview levels would work at all. The person who made the animations for the mockup apparently didn’t understand it either and animated it as different zoom levels, ignoring the spatial model implied by the gestures.
1 Like
I’m sorry for my last post being a little bit unconstructive. I usually try to avoid these kinds of unconstructive posts, so I just want to say I’m sorry.
@fmuellner You’re referring to the search field covering up the workspaces in my proposal to only apply the visual changes, including the “haptical” workspaces, into the current workspace layout, aren’t you?
This is indeed a problem I didn’t think of, thank you for pointing it out.
I’d propose trying out the following:
- having the search bar aligned to the right or the left (being on the top of a column in the layout) like it was the case in earlier versions of Gnome 3
- having the search field overlap with the workspaces and use the margins between the workspaces to avoid overlapping in the initial view - when scrolling through the workspaces, the search field could disappear (and reappear on text input)
- having the workspaces that are not fully shown anyway fade out into transparency where the search field begins. Fading into transparency is a common pattern for indicating that something is cut off, and I think it would quite fit here
- having a solid bar behind the search field so it does not interfere with workspaces
@allanday pointed out somewhere he tried out some solutions for vertical workspaces in the new layout. Did he try the above solutions and found them not working properly? If yes, I’d finally understand why horizontal workspaces are considered as a solution.
Horizontal? Vertical? Why not both? 
This is going to date me as a living fossil here, but nearly eleven years ago I posted a video showing one of the very first development versions of GNOME Shell, and it had quite a revolutionary workflow… very spatial, very special:
It was, in fact, a ZUI (zooming user interface). Personally I still think it was a very neat idea, and I kinda wish it was still available. I also suspect this type of UI is what @jano would want in practice.
P.s.: my YouTube channel also has some traces of other wonderful UI implementations such as the Fedora “Beefy Miracle” hot-dog mascot boot splash, where “the mustard indicates progress”.
2 Likes
Until recently, I used KDE Plasma, and it implements exactly this. And I really liked it, as it gives a perfect overview about everything and at the same time feels very spatial. However, it works best with a fixed number of workspaces and a fixed number of workspaces per row, and this could become tricky with dynamic workspaces like in Gnome. Also, it has even more issues regarding directional gestures/keyboard shortcuts/mouse wheel than a horizontal layout has.
On KDE, I set Meta+Left/Meta+Right for changing workspaces, as this was what I knew from MacOS, and it always felt a little off when I pressed like Meta+left and the animations sent me all over the place.
I’m really worried about the usability of overview in the new designs. My primary concern is that the workspaces dock is gone from the overview, this has huge implications for navigation and moving windows.
I usually open all my apps and then go into overview to sort them from one workspace into several others using the sidebar. With the new design is there a way to quickly do the same thing?
It seems like I would have to drag every window right over several full screen previews, go back, grab another and do the same thing over again. Managing work-spaces can already get complicated and new overview doesn’t offer a quick way to visualize workspace order or “what’s where”.
Please consider those scenarios when improving on the new designs.
4 Likes
No, the plan is to zoom out workspace when starting the drag, so all workspaces are right at hand.
1 Like
After posting I saw demo of current implementation on baby WOGUE YouTube channel, while I personally would prefer something similar to what elementary OS team is doing that still seems like a good solution. I’m glad someone though of that, the early designs I had in mind when commenting didn’t cover that interaction.
I like the new spatial model as it’s been presented so far. I think I understand where the design team is coming from when they’re talking about clearly separating the horizontal and vertical axes.
Right now, the pinch gesture used to enter the overview attempts, in a way, to emulate the 3rd dimension (z-axis), which is really awkward to execute on a touchpad. A vertical swipe does seem to be a more natural and ergonomic movement for this purpose (it’s also used in macOS for the same, AFAIK), but in order to use that, you need to make the overall swipe semantics coherent. In particular, you need to free up the vertical axis, which is currently occupied by the workspaces. Hence the new semantics. I think it’s much easier to grasp the whole desktop model with it:
Swipe up for an overview of your current workspace and to launch your favorite apps. Swipe up once more to reveal more apps.
Swipe left or right to switch contexts (i.e. workspaces).
Nice and simple!
That said, I have one suggestion: To me it feels more natural to have the dash panel stay above the app grid when it’s revealed (i.e. during the second vertical swipe). As in, you would literally drag the dash upwards to pull out the full app grid, as opposed to showing the grid above the dash (as in the current mockups). Have you considered that?
I would beg to differ. When reading text (on a web page), you scroll vertically because the text flows in that direction. It usually forms a logical unit (an article, a discussion thread, etc.) which you consume linearly, from top to bottom.
However, to change the context (switch to a different article, website, etc.), you move laterally, by switching tabs in your browser. (Unless you’re using a vertical tab layout such as the TreeStyleTab extension in FF, in which case I’d agree it’s not a good analogy.)
In the same vein, workspace are meant to represent different contexts or tasks that you’re working on in parallel, so I can see how laying them out horizontally just makes more sense (to most people).
I think this stems from the fact that we as Earthlings are conditioned to think about the world in a lateral sense, rather than vertically (think: room arrangement in a flat, paperwork on a desk, etc.)
I’ve looked at this video: https://www.youtube.com/watch?v=0CX137QKegA, and most of the design is just OK, but it seems I need to open app grid to create new workspace between others? I suggest to re-consider this because app grid is hardly used at least for me, instead we can put more workspace thumbnails here (to let them fill the screen in table instead of just a row).
Showing all workspaces is important, and I don’t think it should be connected with app grid, it’s not wise to bind a high frequency operation with a low frequency operation…
1 Like
Hi,
This new design sounds almost all good to me. Very exciting. My only concern is about the mouse travelling between the top left corner (“Activities”) and the favorites bar. I am wondering what you have considered for that issue. It’s not a problem when you use the Super Key, but this workflow has low discoverability.
I have the following concerns about the new design:
-
Horizontal scrolling: I’m honestly not a fan of horizontal scrolling on the desktop. “The shell scrolls horizontally but apps scroll vertically” feels very inconsistent to me. I also expect the “horizontal workspace scrolling on the landscape screen” will create a bigger, uncomfortable transition. Isn’t this contrary to GNOME’s distraction-free UX philosophy?
-
Hidden workspaces: In the new design, all workspaces are not visible by default. This would be fine for people who use 1 or 3 workspaces. However, for people who use 4 or more workspaces (including me), I think this will be a big drawback of usability. Personally I want to see all the workspaces in the overview by default.
-
Smaller windows in the picker: Since the new design uses much more spaces, windows in the window picker will appear to be much smaller. How does this look like if there are 10 windows open in a workspace? Do you say “opening many windows in one workspace is unsupported”?
I have posted a solution here to address these my concerns.
1 Like
Please make the vertical or horizontal layout togglable, so that people using dual monitor setups can still use Gnome.
1 Like
This is not really something that can be controlled with an option without literally shipping two separate layouts.
2 Likes
Maybe two layouts is the way to go!
1 Like
You’re now asking other people to maintain two very different behaviours, plus a system to switch between them without breaking. You just tripled the maintenance burden on the Shell developers.
This is not going to happen.
2 Likes
The thing is that we had something really solid until then. And now we’ll be going backward to the horizontal workspace layout of Gnome 2, that will make using multiple monitors impossible again.
At least, this should be made pluggable for extension authors to provide alternative layouts.
1 Like
At least three apps that I use, IntelliJ Idea, Darktable and DaVinci Resolve, have multiple-screens window layouts that will be unusable with the new horizontal layout.
Okay I’ll bite: Why is it unusable
…Maybe it shouldn’t be changed then? As has been stated and explained numerous times in this thread, the current design is superior and has numerous practical advantages. If it’s too much work to make the new layout accommodating for people, then why not leave it as it is now?
1 Like