GNOME Bugzilla – Bug 783953
Window picker layout improvements
Last modified: 2019-04-22 20:12:42 UTC
The design team has been pondering some ideas for making the overview more effective: https://www.dropbox.com/s/zz2h9p6yxez67sg/overview-modifications-2.png?dl=0 While the bigger changes will need more evaluation (and may not happen at all), most of the changes in the window picker can be done independently and have value on their own ...
Created attachment 354022 [details] [review] workspaceThumbnails: Reduce maximum thumbnail size The overview's window picker is primarily about windows, and as the previews that represent them are more effective the bigger they are, it makes sense to scale down competing elements; start by reducing the size of workspace thumbnails on the right ...
Created attachment 354023 [details] [review] overview: Don't expand workspace thumbnails by default We currently expand the workspace switcher when workspaces are being used, that is when there are any windows on a non-active workspace. While this helps with the switcher's discoverability, it does eat into the space available for window previews. By now the component should be well established, so we can afford opting for space efficiency and only expand the switcher while the user actually interacts with it.
Created attachment 354024 [details] [review] workspace: Move window captions We consider the window previews the primary way to identify a window, so it makes sense to give them as much space as possible. So in order to not have title captions take up vertical space, overlay them on top of the corresponding previews.
Created attachment 354025 [details] [review] workspace: Reduce spacing between window previews With the window titles no longer being shown as part of the previews grid, we can reduce the spacing to have more space available to the window previews themselves.
Created attachment 354026 [details] [review] workspace: Only reveal title captions on hover While the new title position gives the previews more space, they now overlay the content which may hide valuable information. Address this by only revealing the title as additional information on hover, like we do for other auxiliary elements.
Created attachment 354027 [details] [review] workspace: Don't restrict title width to window preview Now that only one window title is visible at any time, it no longer matters if a title extends into other window previews, so we can always show the full title.
Created attachment 354028 [details] [review] workspace: Allow full-sized window previews Previews are currently limited to at most 70% of the actual window size. This was done to indicate more clearly that the overview is active and the window cannot be interacted with. However since then other indications like the vignette effect have been added, so artificially limiting the preview size doesn't look necessary anymore.
> Only reveal title captions on hover What about touch screens? Reliance on hover breaks touch interaction. Since this bug seems to be part of a general overview improvement drive, can the following things also be considered: * No ability to close windows via touch (close buttons are another hover-reliant element). Touch is clearly a design consideration throughout GNOME with finger-friendly widgets and sizing; it should be considered consistently throughout GNOME otherwise it's just the worst of all worlds - jumbo widgets but inability consistently interact via touch. * Icons overlaid on windows on the overview, so they can be distinguished easily. Many many windows of different applications otherwise look extremely similar (and actually, hiding the titles is going to make this *worse*. Before this idea is rejected, please try using this extension for a week and see what a difference it makes: https://extensions.gnome.org/extension/302/windowoverlay-icons/
(In reply to Stephen from comment #8) > > Only reveal title captions on hover > > What about touch screens? Reliance on hover breaks touch interaction. The behaviour here isn't all that different from what we currently have. I'd imagine that we'd want to show close buttons for all windows in the picker, when there's a touch screen. > Since this bug seems to be part of a general overview improvement drive, can > the following things also be considered: > > * No ability to close windows via touch (close buttons are another > hover-reliant element). Touch is clearly a design consideration throughout > GNOME with finger-friendly widgets and sizing; it should be considered > consistently throughout GNOME otherwise it's just the worst of all worlds - > jumbo widgets but inability consistently interact via touch. > > * Icons overlaid on windows on the overview, so they can be distinguished > easily. Many many windows of different applications otherwise look extremely > similar (and actually, hiding the titles is going to make this *worse*. > Before this idea is rejected, please try using this extension for a week and > see what a difference it makes: > https://extensions.gnome.org/extension/302/windowoverlay-icons/ Those are both issues that we have existing bugs for. Please keep your comments restricted to the patch set that's attached here.
> The behaviour here isn't all that different from what we currently have. Absent conditional behaviour based on the presence of a touch screen, yes it is. Currently, using a touch screen, I can see all the window titles in the overview. With the "titles on hover" patch, that will no longer be true. > Those are both issues that we have existing bugs for. That's true. The former https://bugzilla.gnome.org/show_bug.cgi?id=668490 has been open since 2012, with this in 2013: "After designers saw the patch in action, they deciced that looks too much bloated. So we hold on the change until we find a better solution for touch devices." The latter https://bugzilla.gnome.org/show_bug.cgi?id=634599 was opened in 2010 and WONTFIXed as "bigger thumbnails is enough" essentially (I'd be very interested to see any timed testing of "find the window" with e.g. blank text editor, light terminal, blank web browser that supports that perspective :J) Seeing as this bug stems from an attempt to improve the overview in several respects, I think some of these stagnating overview usability bugs should be looked at at the same time. The two I mentioned are not an exhaustive list of course ;) Given that neither of those bugs were lacking code to implement the features, and in the case of the former it's still open and no-one's comments or code have moved the needle in 5 years, I thought they were worth mentioning (as examples) while there's general activity to improve the overview. It's less a case of "fix my pet bugs", and more a case of "since there's a rework of the overview happening, long-standing overview usability problems generally should get some renewed attention at the same time, since someone's going to be hacking on the overview anyway."
I have one concern related to the new design, more particularly hiding the window title until hovering. The use case this would be troublesome for is when a workspace have many terminal windows open. During overview mode, it may not possible to identify the terminal you want to select by looking at the content, and if you (like me) tend to have 5-10 terminals open with very similar content (e.g. compile logs and what not for different projects). If the title, which contains the path (thus what project the terminal is used for) is only visible when hovering, I'd have to manually "scan" through my terminals to find the one I'm looking for, which is not optimal.
(In reply to Jonas Ådahl from comment #11) > I have one concern related to the new design, more particularly hiding the > window title until hovering. The use case this would be troublesome for is > when a workspace have many terminal windows open. ... It would be helpful if you could try the patches for a while and see if this is an issue in practice.
> It would be helpful if you could try the patches for a while and see if this is an issue in practice. It's the same basic problem raised by various people in the "overlay icons" bug, but in fact exacerbates that problem by removing the last remaining descriptive element unless hovered.
(In reply to Stephen from comment #13) ... > It's the same basic problem raised by various people in the "overlay icons" > bug, but in fact exacerbates that problem by removing the last remaining > descriptive element unless hovered. One of the goals of these changes is to make the window thumbnails larger, which makes it easier to identify each window. It would be interesting to explore other ways of making the thumbnails bigger. One option might be to reduce the maximum size of the dash.
(In reply to Jonas Ådahl from comment #11) > The use case this would be troublesome for is when a workspace have many > terminal windows open. For me, the title for terminals tends to be something like "[screen: fmuellner@priscilla:~/sr..." most of the time currently. So in my case, the drawback of having to hover a preview in exchange of seeing the full title is an improvement.
> It would be interesting to explore other ways of making the thumbnails bigger. One option might be to reduce the maximum size of the dash. Whatever you do, the maximum non-overlapping window size (with 2+ windows) is going to be 25%.
(In reply to Florian Müllner from comment #15) > (In reply to Jonas Ådahl from comment #11) > > The use case this would be troublesome for is when a workspace have many > > terminal windows open. > > For me, the title for terminals tends to be something like "[screen: > fmuellner@priscilla:~/sr..." most of the time currently. So in my case, the > drawback of having to hover a preview in exchange of seeing the full title > is an improvement. When maximized, I see enough of the title to see the project, but for non-maximized terminal windows, I also only see the first irrelevant part. Another example of identical looking windows that I have several open of is gitk (for example, I currently have 3 open on one workspace), where the repository name is the window title prefix. With this said, while it could be a concern, to be honest, 9 out of 10 times I flip through the Alt-` list, so personally I don't know how affected I would be by this change. Maybe them being bigger could help some times, but in general I can't tell the difference until I read the text in the terminal or see the window title. An idea could be to show-by-default if there are, say, 3 or more of the same application.
My two cents: Patches work well and greatly improve the working of the overview. On the mockup it makes perfect sense and parts closely resemble my current workflow. Over time I learned that dash is impractical and I deleted it through an extension and with another I got the workspaces panel to remain hidden. I also usually use the keyboard shortcut "Super + A" to open the application view directly when I need it (rarely) since I usually use the shell search. Frequent application tab is one of the most useless things I find in the shell, so I always thought that being able to customize the first page of the application list would replace the current dash function (I would access directly using "super + A"). The problem with dash is that users use it as a dock and they bother to not get more functionality. Removing the dash will gain more space for the overview. The mockup of the first message makes sense to me. Note: The title at the center of the window would gain a lot if you increase the font size a bit or add an effect that temporarily darkens the selected window to improve the contrast.
Created attachment 355902 [details] [review] workspace: Move decision to show/hide chrome to clone Currently the chrome layer decides itself which events on the window clone should show or hide the chrome, which makes it harder to extent. Instead, move the decision to the window clone by letting it emit show/hide-chrome events when appropriate.
Created attachment 355903 [details] [review] workspace: Show window chrome on long-press Pointer hover and keyboard focus aren't available on touch devices, so add long-press as alternative to reveal preview title and close button.
The last two patches should allow revealing hidden chrome (close button, title) with touch devices, although I don't have the hardward to test ...
Created attachment 355936 [details] [review] workspace: reposition label bottom - putting the label at the bottom doesn't obscure that much content on the hover state
Created attachment 355937 [details] [review] workspace: update window close - match the updated visuals
Created attachment 355938 [details] [review] workspace: update window close - match the updated visuals
Created attachment 355939 [details] [review] workspace: Move window captions Updated patch + commit message for the new position.
Created attachment 355941 [details] [review] workspace: Don't restrict title width to window preview Update for position change.
Attachment 354022 [details] pushed as 56c28fb - workspaceThumbnails: Reduce maximum thumbnail size Attachment 354023 [details] pushed as 2d84975 - overview: Don't expand workspace thumbnails by default Attachment 354025 [details] pushed as 64bbad1 - workspace: Reduce spacing between window previews Attachment 354026 [details] pushed as 4fd5eee - workspace: Only reveal title captions on hover Attachment 354028 [details] pushed as 1218e68 - workspace: Allow full-sized window previews Attachment 355902 [details] pushed as 6816aea - workspace: Move decision to show/hide chrome to clone Attachment 355903 [details] pushed as 6c472d8 - workspace: Show window chrome on long-press Attachment 355938 [details] pushed as 7f2101d - workspace: update window close Attachment 355939 [details] pushed as 8a911cd - workspace: Move window captions Attachment 355941 [details] pushed as b3b30f2 - workspace: Don't restrict title width to window preview
Sorry for saying this now since I didn't see it when the attachment was created, but press and hold to reveal the title and close button is a terrible UX. This will mean closing a window will be a two-step, delayed process on a touch screen, and will be even worse to try and differentiate between 2+ windows by checking their titles. I made a concrete proposal on the related "show close button" bug that would not result in a poor experience for touch screens: > if there is a touchscreen present, and the overview is not launched via the mouse, show all the close buttons for that specific instance (launch of the overview via touch, Super key or hardware "Win" button launch are all legitimate "I might want to use the touchscreen" cases). The above approach could equally be applied to keeping the titles visible when a touch screen is present to avoid the pretty unusable press-hold-read-repeat title mechanism made available via the above press-and-hold patch.
This broke my workflow with IntelliJ IDEA. I always have multiple IDE windows open (one per project/repo), and before this I was able to quickly find the window I want from the overview by the title. Now I have to hover over all the windows until I find the right one, unless I find another way. Same for any other program of which you have multiple windows open. I don't see how only showing them on hover improves anything, so I think they should always be there.
I just wanted to let you know that thanks to @nlpsuge there is now an extension that makes window titles always visible (like it used to be) in the window overlay: https://extensions.gnome.org/extension/1689/always-show-titles-in-overview/ I personally did not notice that the titles disappeared and are only visible on mouse hover, but I guess for some people this may be a must have feature. Like WindowOverlay Icons extension (https://extensions.gnome.org/extension/302/windowoverlay-icons/ ) in my case. :)