Hi there, I already commented on this on a GitLab issue. Because the GitLab issue has been closed, I thought I’d post a shortened version of my comment here for better visibility.
@aday wrote:
The reason for switching from vertical to horizontal, as described in the blog post, is to allow us to use the vertical axis for travel into and out of the overview, both in terms of the spatial model for the system, and specifically to have a coherent set of gestures and shortcuts for navigation.
As part of the design process, we did attempt to retain the vertical workspaces and use the horizontal axis for travel in to and out of the overview, but it never looked good or behaved well.
As far as I can think, it completely doesn’t matter for a touchpad or a touchscreen if the gestures are performed horizontally or vertically. If we can use a left-right-swipe to switch workspaces, we can also use a left-right-swipe to switch the view. Except if horizontal swipes are for whatever reason worse than vertical swipes, but why should view changes be first class citizens and workspace changes second class citizens then, and not the other way around?
As I think regarding touch devices input, the scrolling direction is irrelevant, I don’t think it actually is, but for other resasons.
Conventions
For decades of digital user interfaces, scrolling through things that don’t fit on the screen has been vertical. Unlike other UI conventions, this has been applied nearly everywhere: From mobile phones to PDAs to bank terminals to desktop UIs. You can even see Douglas Engelbart in his 1968 presentation of his graphical user interface scroll vertically.
But why is that so? Why has this convention been so widely adopted?
The reason lies in a much older convention, the convention of western writing. In western languages, letters are arranged horizontally, but then grouped in arrays of vertical lines. Having these lines not go for too long and break at a certain point is crucial for a good reading experience. That’s why nearly all books written for non-infants are printed in a portrait format. And this is also why all modern websites that are made with 16:9 screens in mind have max-widths for their text containers. And it’s why we’re used to scroll vertically.
So it looks like having both an app grid and a workspace overview that scroll horizontally does not only break the conventions within Gnome apps (I haven’t seen any plans to make Nautilus scroll horizontally) and the conventions established by 10 years of the Gnome shell. It breaks with the conventions of the world.
Keyboard and Mouse navigation
In fact, the design goals blog post states the following:
One of the nice things about having a simpler spatial model and directional gestures to navigate the shell is that it also helps keyboard navigation. This is because it allows for directional shortcuts (e.g. Super + PgUp to move to the workspace above) which are more intuitive than non-directional ones (e.g. Super + M to open the notification popover).
And it’s damn right.
Looks like the conventions about vertical scrolling are so wide-spread that they are even baked into our hardware: Keyboards have PgUp and PgDown keys stemming from the good old times, and most mouse wheels only move vertically. One of the coolest things about the current spatial model of the Gnome shell is that it works well with all of these input methods.
However, keyboards and mouses seem to become second-class citizens with the new horizontal design: While it doesn’t matter for touch devices, it’s unclear how the current mouse and keyboard navigation is going to work in the future.
Are Super+PgUp/Super+PgDown going to stop working in Gnome 40, or are they going to awkwardly move the workspace to the left and right?
Screen proportions
Although some people are lucky having a 16:10 screen, most screens today have a 16:9 aspect ratio. That’s why for layouts targeting desktop- or tablet devices, column-based layout are the way to go. You can see that on websites, were the long-awaited Flexbox and CSS Grid enable website creators to display columns on desktop where rows will be displayed on portrait-mode mobiles, forcing designers to maintain two layouts, but they think it’s worth it, because row-based layouts don’t work well on widescreen displays.
You can observe this on MacOS, where the workspace overview slices the already thin screen into three thinner rows, feeling awkward even on a 16:10 screen. In comparison, the current Gnome design does a pretty good job at dividing the aspect ratio into comfortably usable columns. I think it would be a pity if Gnome gave that up for repeating the design mistake Apple made in times of 4:3 screens.
Spatial design
I really like your idea of moving different views into a spatial model instead of having them just being “modes” that appear and disappear. The latter is very unpleasant from a designer’s perspective, and having three views that show different levels of overview expand the current model into something coherent. And I understand that within the perspective of this design of having these views positioned on-top of another, it makes sense to have the workspaces not also on-top of another.
However, I still have one problem with these views being positioned on-top of another vs. workspaces being positioned on-top of another, and it sums up into one question:
Where are my windows?
No, really, where are my windows in your model? Are they in the bottom view, overlapping and floating, or are they in one of the upper views, placed on workspaces?
If we really treat our views like places in our spatial model, these questions need to be answered. Because as of 2020, the nature of quantum mechanics are not very present in most people’s imagination, therefore it does not at all benefit the idea of a spatial model that the same things are placed at multiple places at the same time.
Currently in Gnome, the perspective change is represented as a “view mode change”. This is indeed not optimal for animations and gestures which work best providing a spatial model. But I don’t think we make it better replacing it with a spatial model that does not quite fit.
Conclusion
Finding a spatial model that fits the change of perspective offered by the window/activity overview requires more investigation, and I think it would be a pity if, after all this amazing work being done, doing scientific studies and showing all of these beautiful mockups, it just stopped with this concept that, if implemented in the current form, has consequences which receive some major and rectified criticism.
And there were pretty important things found out by these studies. For example, how much users prefer interfaces that convey spatial models of the views they’re interacting with.
One model that not only works with vertical workspaces, but also represents “where the windows are” would be a 3 dimensional one: As the three layers of the mockup show different perspectives of the same windows and workspaces, having the windows and workspaces getting smaller the more into “bird-perspective” the views get, it made absolute sense IMHO if the screen zoomed in and out between the perspectives that currently are planned to be displayed on-top of another. This could be conveyed by animations as well as touch gestures (pinching). This actually seems to be the spatial model behind Gnome’s current design, although it is not consequently worked out and, for example, leaves out workspaces. This is something that actually could be worked on.
In fact, we don’t need to do some fancy 3D rendering, everything needed to better portray the current spatial image of our workspaces would be shrinking the background image, draw a border around it and move the background image instead having it fixed when switching workspaces.
It is not worth to deploy a new spatial model into the minds of our users, as long as it doesn’t integrate well with their workflows, and most of all, the rest of Gnome’s design. After all, deploying massive changes at once nearly always leads to users blaming the whole concept for little problems with the realisation (which are inevitable). Same thing happened to Windows 8 (which btw. also featured horizontal scrolling on their start screen, which has been one huge target of criticism and been undone in Windows 10).
And this is not what I want to see here, as the concept it good: Showing the Activity view on boot absolutely makes sense, better portraying the workspace in a spatial image also. Good concepts like this deserve an incremental deployment, that doesn’t antagonise users by completely messing with their way of using the computer, and that can take feedback into account that will be targeted at the small implementation details that come up which each version and not a shitstorm that will unfairly be thrown at the whole concept. As much as I love the fact that there were scientific studies made for this, they were made in artificial environments that only portray the individual concept in isolation, and can’t replace actual real-world user feedback.
