Comment by Krssst
11 hours ago
Disabling animations makes everything better no matter the OS.
When executing a sequence of actions, not having to wait 100-300ms for the device to show some random animation before inputing the next action is a time saver and a removes the "why is my computer/phone wasting my time" feeling.
Human reaction time is around 200ms but in a sequence of actions, we don't need visual feedback to move to the next action; it's just muscle memory and we can reach pretty low delay between inputs if the OS and apps do not impede us.
Back to Windows, I'm quite sad that 24H2 removed support for the legacy app switcher (alt-tab). It was very low latency and operated well in many high-load situations. The new one works okay but is not as snappy and can take a bit of time to show up under load. Plus I prefer the old style (smaller box, no need for eye movement to check its content).
I agree there are many bad timer-waster animations. But animations can be a good thing. Take scrolling as an example. Pressing page-down on a text-page or in a text-editor, without animation, it takes me a lot of time and energy to find the place where I left off reading or editing before scrolling. A good animation can save a lot of time here. It's similar with other operations -- and I agree that those operations that we don't do that often tend to be the ones that profit more from animation, while the ones where we already know in advance what will happen can be made worse by animation. I think an animation should never slow down the user, they should not be blocking. An unfinished animation should not prevent the user from typing the next action.
> Pressing page-down on a text-page or in a text-editor, without animation, it takes me a lot of time and energy to find the place where I left off reading or editing before scrolling.
We used to be able to look at the scroll bar to keep track.
Furthermore page down/up used to move a full page consistently. But today it might as well be a random amount specific to the application or content. Making it impossible to train muscle memory.
Have you looked into SimpleWindowSwitcher? https://github.com/sigoden/window-switcher
ExplorerPatcher makes it easy to configure in the settings menu, I'm not aware of any other projects that implement SWS: https://github.com/valinet/ExplorerPatcher
It's very fast and can be configured to set window thumbnail size/area
Thank you, I was not aware of either of those.
SimpleWindowSwitcher looks like a good alternative, unfortunately on my side I think I would prefer switching between all windows of all apps rather than have two different shortcuts for "switch between windows of the current app" and "switch between apps" (but that's just a personal preference).
ExplorerPatcher looks cool too, though patching explorer is probably a no-no in corporate setups.
I also saw https://github.com/kvakulo/Switcheroo which I was curious to try (although it's not an exact replacement either) but never got to it (also seems quite old).
This change annoyed me too, enough to look up a solution, but not enough to actually install anything to work around it. I have this thread bookmarked, where someone implemented it in AHK, so if you're running that already it might be worth a try: https://www.elevenforum.com/t/classic-alt-tab-reincarnation....
I discovered Switcheroo two weeks ago and seeing it abandoned with over 30 forks with relevant commits made me want try to consolidate the forks and add my own flavor to it:
First beta release at
https://github.com/coezbek/switcheroo
Noteable: column design for most frequently used applications and pinned apps shown separately.
Not exactly alt-tab but it’s a ui-less immediate switcher (snappy af, zero latency) to switch between windows of the same app with alt-backtick (next to escape), originally a macOS feature: https://neosmart.net/EasySwitch/
(Backwards navigation with alt-shift-backtick)
Thank you.
Actually the registry entry on 24H2 behaves somewhat similarly: alt-tab still switches windows (of all apps) but the UI is just gone (which is a problem for me because knowing how much time I need to press tab in advance leads to faster switching than "press tab, see if the focused window is what I wanted, and press tab again if it's not" which involves a computer-brain round trip every key press).
Interesting thanks for sharing. I can see how that makes sense for switching apps but imho for switching windows of the same app that benefit is negated since the thumbnail (without intense scrutiny) is generally too similar between windows of the same app.
(As a dev, I often have a dozen browser windows and a dozen or more terminals open, half a dozen IDEs, etc so being able to switch directly between instances if the same app, esp automatically filtering out minimized ones, is much faster than alt-tabbing through then all interleaved, and was my motivation for writing this.)
> Human reaction time is around 200ms
Even if you are talking about the entire loop, that sounds pretty high. Maybe if its moving your hands in reaction to an unexpected stimulus in your feet...
We can tell the difference between 60fps (~16ms per frame) and 120fps (~8ms per frame). Any more than that is a noticeable amount of waiting.
It does get complicated, though. What if the information is presented immediately, then animated? Well, that's where a complete measurement of reaction time would be relevant.
Even so, as you pointed out, we often predict what we will be doing in advance, and can perform a sequence of learned actions much more quickly. If there is a delay imposed before you can perform an action, then you must learn the delay, too. That learning process involves making mistakes (attempting the action before the animation is over), which is extra frustrating, considering how unnecessary it is.
https://humanbenchmark.com/tests/reactiontime
You'll probably see around 200ms. Not saying that's the relevant number in this discussion, but that's probably where the number comes from.
On mobile, I consistently get just under 400ms. I suspect using a mouse would get me closer to 200ms, since I would be resting my finger on the button.
So yes, total reaction time is generally quite long, but most of that time is spent performing "action".
That site would be more interesting if it provided a second interface where you do something predictable, like match a repeating beat.