GNOME Bugzilla – Bug 653868
The transition to the overview can be overwhelming and difficult to follow
Last modified: 2012-10-31 01:25:07 UTC
The transition to the overview works well when there are no maximised windows. It is easy to track each window from its start to its end position, and it is comfortable to do so. Problems start when you introduce maximised windows into the mix, however: * It becomes difficult to track the movement of the windows. I am often unable to figure out which window in the overview is the one that I had focused. * The transition effect becomes too dramatic and involves too much movement. This can create an experience that can be dramatic and disorientating. * The magnitude of the transition effect can also mean that tracking the movement of the windows can be physically uncomfortable (my eyes often feel strained during the transition). The transition to the overview should have a low impact and place a low physical/cognitive burden on the user. It should also be comfortable to use. We should figure out how to make sure that this is always the case. :)
Created attachment 191199 [details] Motion mockup - crossfade then scale when transitioning to the overview One possibility is to cross fade to the overview and then just display the final part of the window scaling animation. This would convey the idea that the windows are shrinking into position but would avoid the severity of the current transition. See the attached mockup for an idea of what I mean. This approach could open up some interesting possibilities regarding the order of the windows in the overview (see bug #613453).
Created attachment 191216 [details] M
Created attachment 191217 [details] Revised motion mockup - crossfade then scale the windows Here's an updated version of the video mockup; it should be a bit easier to follow.
Created attachment 191253 [details] [review] wip: cross fade the window_group and window clones going in/out of the overview
(In reply to comment #4) > Created an attachment (id=191253) [details] [review] > wip: cross fade the window_group and window clones going in/out of the overview This is a proof of concept patch that I came up with after playing around with various transition equations. It's not good enough IMO and doesn't look good when you have only 1 or 2 relatively small windows.
Comment on attachment 191217 [details] Revised motion mockup - crossfade then scale the windows I've got a better version of the motion mockup here. It is too big for an attachment, unfortunately: http://dl.dropbox.com/u/5031519/fade-then-scale.webm This is just one possible approach to addressing the issues I described in the bug report, I might add. I'll try and come up with some alternatives if I have time.
When exactly should this transition be used? (a) always? (b) when at least one window is maximized? (c) when the focus window is maximized?
(In reply to comment #7) > When exactly should this transition be used? Potentially never; I'm just exploring possibilities. Like I said above, I'm still trying to find a good solution to this problem, because it is one that I want to see fixed. > (a) always? > > (b) when at least one window is maximized? > > (c) when the focus window is maximized? The idea is that this particular concept would always use the same transition (a). That could be changed, of course. It could be interesting to treat windows differently according to their size...
(In reply to comment #8) > It could be interesting to treat windows differently according to their size... Not sure on this one ... having different animations for the same thing (going to the overview) does not sound like a good idea.
Allan, is this still alive?
I haven't had the issue in a while, so let's say not.