Even if “App Menu is useless” what will happen with instances? The App Menu is an useful alternative to the default Meta+` to see app’s instances in a Alt+Tab-like layout, not everyone wants to use hotkeys, some prefers hotkeys and some prefers cursor; it’s good to have an alternative for it. Removing it would be bad because you must go to the Dash to see your instances, becoming a waste of time. Besides of Instances question, how you could know which app are you currently focusing in after the animation? On small screens would be easy to figure out, but on a big screen would be a pain, plus with dark backgrounds the window shadow is difficult to see, specially if your focused window doesn’t have sub-level windows and you have a dark background.
And even if you could have a way to see your instances easily without hotkeys, how do you know when a app is launching? The current solution doesn’t solve my doubt so I can’t say that a solution exists, there should be a spinning indicator with the app name currently launching
However, I think the proposed animation + the current App Menu/Window Focus indicator it’s great, you have an animation that let you know which app is currenly focused and you still have the way to easily see your instances without hotkeys and without going to Activities.
I agree with others that the effect is tiring after some time. IMO a permanent indication of the focused window should be done, even if this does not reach all applications that use other gui toolkits. The only common element of all windows is the close button. Changing the color of the close button to a neutral color (light blue?) for the focused window might work. OTOH color as an indicator is not the most accessible.
I just installed the extension and used it to cycle between three windows (two side-by-side, taking up half the screen width each and one taking up almost the entire size of the screen on my 21" monitor). After a couple of switches, I actually felt queasy. And I don’t even have motion sensitivity (or at least never did before).
I don’t think motion is the way to handle focus indication.
It should be a static indicator that is also useful if you were to, for example, look away from your screen and back again after completing some other task.
Instead, how about adding a heavy shadow to the currently-focused window?
Also, I just noticed that the application name is gone from the top bar. This is a regression. The application name is an important landmark. It, combined with the active window indicator (whatever that ends up being) tells you where you are currently. What is the design problem that’s solved by removing it?
If I were making this decision, I would not include either of these changes. Instead, I would keep the current application landmark and make the current window indicator (the darker shadow) much more pronounced so that it is hard to miss.
I’ve been using this the past week, I think it works pretty well.
I’m using a 13" laptop with a 27" external monitor, I would say that the pulse effect feels way better on the bigger display. When using only my laptop display it gets a little obnoxious, especially when tiling more than 2 windows (using pop shell for tiling functionality).
I think that the above problem could be fixed if the pulse scaled down more to the monitor size, so smaller monitors experience a smaller pulse.
I’m going to keep using it as I care about being properly notified about which window is focused (I try not to use mouse and move around only with keyboard) and this is way better than the previous solution.
I tried it a bit and found the animation to be a little too exaggerated and disorienting, one problem that I don’t know if it is fixable by tweaking numbers is that fonts look very bad during the transition as a result of the scaling.
I don’t think this helps identifying the focus very well as the animation only plays once, if you are presented to a desktop with both Element and Discord open side-to-side there is no way to tell where is the focus. I think it would be better if the old indicator remained there (but without an associated menu, that menu is terrible for discoverability and not many apps used it) and the new effect was added but in a much subtler way (maybe using a scale of ~100.5% instead of 101%).
One thing I don’t know, is how will this work in desktops with animations turned off.
If an animation like this is going to be used, it might make sense to scale the window by a fixed number of pixels rather than relative to their size. That’s also what the hover effect for the previews in the overview switched to (before the 40 release, so the initial animation with relative scaling never made it to a stable release). This made this animation much less erratic for larger windows and more noticeable for smaller windows.
about one year ago I tried applying the idea of atmospheric perspective (What is atmospheric perspective?) to unfocused windows for the same purpose.
It should let the user control how much unfocused windows would fade into the background by adjusting the amount of transparency, desaturation, dimming and/or blur.
A subtle blur and transparency worked very well, along with the native shadow from focused window.
Background blur, and not full-window blur (which affects readability), was the tricky part.
Unfortunately my Gjs skills were not that good and I gave up.
I also find the effect disturbing when looking at text, not a deal breaker and I may be focusing too much attention on it.
I’ve disabled the Activities button and removed the window focus animation proposal.
So far, I’ve never felt the need for an additional focus indicator. All windows I’ve tried already have a focus/blur state (stronger shadow, header bar dimming, etc)
So far this is true for: Chromium, all GTK3 apps, all GTK4 apps, all QT apps, Slack Desktop, VSCode (both with or without CSD).
I’m sure you can find some edge cases and Electron apps without a focus/blur state, but it appears to be a very small number.
One aspect that has not been considered is what are the effects on power consumption of animating a window every time the user switches window focus. This is probably very difficult to measure but in an age where everyone is trying to reduce power consumption and improve battery life of portable devices it is something to consider.
For Chromium the distinction is barely visible to me if you use one of the bundled themes (called “Classic” in the appearance settings) instead of the Gtk theme.
Well, now I’ve been using it for over a week and I’ve already changed my perspective.
I thought when you first start using the extension, the animation is really cool, I love that it adds animations to the shell, but when I turned off the extension today, I realized that the App Menu is an important thing, I mean, if they want to remove the menu, that’s fine, but leave the label with the symbolic icon. It is visually better to have this permanent indicator.
We don’t have a dock, in other offices that’s where people usually look to see which app is focused, and in case there isn’t one, the app menu is the best option.
It would even be cool to put the right-click options on it. People in general don’t use the menu application because, in general, it doesn’t have anything that interesting.
One issue I’ve had was with copy/pasting in terminals. I for example use wl-clipboard to share my editor’s clipboard with my system clipboard but since wl-clipboard creates a window each time there’s copy and pastes, the window keeps jumping. I am well aware that it’s just bad design on their end but I’m not aware of any alternative if you use vim or kakoune like myself.
I like the idea of the new focus indication, but I feel like it still doesn’t really draw the user’s attention. The focus indication happens so quickly after the workspace switch and the effect is so subtle that it would probably go unnoticed for most users. It’s miles better than the current focus indicator which I never looked at, but there could be a better, more visible way that still looks as stylish as the current approach.
Thanks for the feedback everyone, this has been very helpful!
After analyzing the responses here and in other places, we feel that the app menu and the window focus issue are perhaps less connected to each other than we previously thought, so we’re now thinking about addressing them separately.
Removing the menu has been largely uncontroversial – the majority of people liked the change or didn’t notice it. This is also consistent with what we’ve seen in previous user research exercises over the years.
The window focus animation, on the other hand, clearly needs more work given that issues like the blurry text being distracting/painful have come up quite a bit. It’s also possible that we’ve been overthinking this and the additional signifier is not really needed in practice, because most apps do have backdrop styling of some kind nowadays, as some people pointed out above.
The current plan is to land the app menu change independently of the animation for now, while continuing to iterate on better ways to indicate focus. We’re unfortunately quite constrained on what we can do (borders, shadows, etc. don’t work for technical reasons as noted above) but there are some new ideas we haven’t tried yet, also thanks to the responses and suggestions here and elsewhere.
Thank you all for your help, and keep an eye out for future experiments
I liked it a lot. The thought “what are they doing here? What is it?” is gone after less than a week. Very useful.
Despite making no sense for most people, a maximised window focus hint for dual (or more) monitors would improve it a lot for, at least, my usage.
And it goes very well together with @CleoMenezesJr Auto Activities.
IMHO, you should ask for users’ opinion on removing app menu without implementing a window focus indication first. I don’t think users will like app menu being removed without an alternate implementationthe indicator for currently focused window/app being removed along with the menu.
It is totally underestimated
