new alt-tab window switcher feels slow |
||
Issue descriptionVersion 54.0.2840.51 beta (64-bit) Platform 8743.57.0 (Official Build) beta-channel panther Firmware Google_Panther.4920.24.26 Two issues make alt-tab feel slow: 1. The delay before showing the alt-tab window. Looking at the code, this is intentional. I understand this is a migration strategy from the old behavior to the new, but once I started expecting the new alt-tab behavior, I wanted only to use it and was annoyed by the delay. Note that issue 653163 might need to be looked at to make this work better. 2. The sliding focus moves very slowly. I argue that having no animation here is important to keep up with the user. We do not have a slow animation for switching tabs (ctrl-pgdown), yet it is a similar focus task. I rely on the instantaneous selection of the thumbnail to tell me if I've hit my target and can let go of alt.
,
Oct 28 2016
Another point. I just logged into a machine running M53 that hadn't updated yet. The speed/frustration difference was amazing. It takes me much longer to find the window I need with the new switcher. The problem is the thumbnails are unreadable, so I spend many seconds squinting at the switcher trying to see my target. Or I just give up and use overview, but that doesn't work the same way (no predictable alt-tab window stack). The old switcher is incredibly fast because I get a fullscreen preview instantly, and I need only let go of alt to confirm. How about combining the 2 modes more fully? I am ok with the new switcher if the windows also switch behind it, in the old way. Then I could get a little preview of all windows and also see the full window as before. Also, this merging of old and new would enable hitting escape to cancel, which the old switcher did not have.
,
Oct 28 2016
1) The delay is intentional and we have no plans to remove it. It is not done for legacy reasons, it is done because there are two modes of Alt+Tab usage: (A) I want to jump back to my last window and (B) I want to jump to some open window. With (A) showing the overlay is distracting. 2) Animation is important for tracking the focused window since in general the indication is subtle. We do not plan to remove it. 3) There would be way to much happening on screen if we had both the overlay and windows changing.
,
Oct 28 2016
Thanks for the explanation. (Apologies if the below statements are already known) For future reference, these changes significantly increase the time and perceptual effort needed for window switching by experienced users. This comes from the added delays and the reduction of the size of the critical onscreen information (the contents of the windows) needed for the window switching task. A GOMS- or KLM-style analysis is a quick way to predict these kinds of costs without user testing. |
||
►
Sign in to add a comment |
||
Comment 1 by weifangsun@chromium.org
, Oct 11 2016Status: Assigned (was: Untriaged)