Alt+Tab: show all window previews

[donadigo]

While the current presentation of windows in trunk's Alt+Tab got better I think we should consider redesigning the Alt+Tab behaviour further. The main problem with the current behaviour:

Windows are covered by themselves: this leaves user without knowledge what windows he has opened and how do they look like. If he wants to know, he has to cycle through all of them. Currently we have a dock-like clone on the bottom that shows the current applications open but this solves issue only partially, there could be multiple windows attached to the application. This also:

• forces the user to drastically shift the focus from the center from the center to the bottom of the screen
• is one of the issues why we can't expose a setting to change dock's position to left or right position of the screen
• you cannot choose a window with a mouse when alt+tabbing, because the windows are covered

It is significantly faster and easier (at least for me) to switch to a desired window when I see it immediately after pressing Alt+Tab. You can easily see how much time it takes for you to recognize the window you want to switch to: just compare the current Super+A (expose all windows) behaviour with the Alt+Tab one. Please discuss in the comments.

[Philip-Scott]

One way that could probably speed up Alt+Tab would be to allow scrolling across the opened apps, just like you can scroll across workspaces in the overview

[peteruithoven]

It's a bit hard to talk about this without a visual.
Shouldn't a user just use expose if he likes that specific behavior more?
( "the current presentation of windows in trunk's Alt+Tab" not been released to non daily users yet. )

[donadigo]

It's a bit hard to talk about this without a visual.

That's why there's "needs design" label.

Shouldn't a user just use expose if he likes that specific behavior more?

Expose is not alt+tab. You can't cycle through all the windows quickly with keyboard (although we could take that into consideration).

[alexbhandari]

I've been looking into this and I stumbled across this video: https://www.youtube.com/watch?v=TJDepv2ftU4 which seems to address what is discussed here (and provides a visual). Did gala ever function like this where all windows were visible during alt-tab?

For reference the current behavior in gala that I have is like this: https://www.youtube.com/watch?v=l9tcsOjUgK0 which makes it hard to put the focused window in context with the rest of the windows because all other windows disappear during alt-tab.

[matzipan]

I like what Ubuntu has done in Gnome: https://didrocks.fr/2017/09/14/ubuntu-gnome-shell-in-artful-day-12/

[Godje]

I think for the better scroll/view of the windows there is a Super+T shortcut, which literally is named Show All Windows. If a user of the OS is introduced to such a handy shortcut, he/she might as well have a choice between a quick Alt+Tab, or complete view of Super+T

[Nine-H]

@alexbhandari there's a vestigial gsettings key at org.pantheon.desktop.gala.appearance alt-tab-window-opacity that controls how visible background windows are during alt tab. it doesn't really help with windows occluding each other, and it's a little janky when depth order changes.

[alexbhandari]

@Nine-H thanks! I find that with the increased opacity alt-tab is more intuitive, but I see what you mean in terms of it being a little janky in some instances

[donadigo]

I've pushed an experimental, prototype branch here if anyone wants to test it out: https://github.com/donadigo/gala-alt-tab-window-preview

[mahajanudit]

I used @donadigo and I like the concept better than the original. But I found few issues with it (may be better call them quirks)

1. Thumbnail size difference looks just not right. Off course different apps will have different windows size but to make things look consistent we can have a dimension (preferably height) as same and scale the windows of the thumbnail to make windows look more consistent in the switcher.
2. Too many thumbnails cause the switcher to over flow out of the screen. We should have a limit to the number of windows shown in the screen of the switcher and if that exceeds, it should auto scroll. Off course there should be no scrollbar, the scrolling should be intuitive so as to make sure currently focused windows on the switcher remains somehow at the center of the screen.

But this is a really good start

[donadigo]

@mahajanudit the repo I linked above is an experimental branch, it doesn't get everything right, but it should act more as a mockup.

[mahajanudit]

Agreed, looks really good.

[Blast-City]

What if the windows would be grouped by application, but unlike other switchers the windows of same apps would be stacked like cards. Like this

Alt+Tab/Alt+Shift+Tab or left/right would select an app and Alt+Key above tab or up/down would select a window in a stack by bringing it forward.

Fast Alt+Tab wouldn't show the window switcher, but would switch to the next window.

I still think that it would be better to have a simpler window switcher like gnome or mac. merge all the overviews (selected workspace windows/all windows/workspace overview) and add keyboard shortcuts with a good visual indicator when an app is selected.

[attila123]

Hi, sorry, did not read all messages, just tried Pantheon and the Alt + Tab experience is stopping me for switching to that. I have a laptop with 2 external monitors and it's very difficult to see which application would activate. I would like a behavior similar to Cinnamon (at least how it is set up for me now): when pressing the Alt + Tab in Cinnamon, the window list appears in that monitor where the mouse is. This is very user friendly and it is a must for me! Uploading a screenshot how it looks like.

[Godje]

@attila123 it is a must for you, but not necessarily for everyone. People use what they want here in Linux. Whatever works for you, use it. So if you like it the way you have it, why bother switching to Elementary, if you got what you need. Just install Plank, and configure your bar to have similar layout to Elementary.

[Blast-City]

Not really - switching between more workspaces would require holding Super and pressing Tab, which would probably trigger the overview (I assume). This is a slowdown for me (not to mention getting dizzy from all the zooming of all windows), unless I misunderstand how you mean it.

The idea would be to press fast when you wanted to go to the last window selected. If an user needed to go to another window (press more than two times), it would give a visual cue (overview). The zooming argument is interesting. I didn't thought of that. You're probably right.

One thing I'm sure is that it would still be cool to have the ability to use Alt+Tab and Super+Tab on the multitasking view.

[janxkoci]

The idea would be to press fast when you wanted to go to the last window selected. If an user needed to go to another window (press more than two times), it would give a visual cue (overview).

But that's what I meant - sometimes I skip multiple workspaces with Super+Tab, because it's very fast and I can do it with one hand. If it opened overview, that would be slower and quite distracting, imho.

One thing I'm sure is that it would still be cool to have the ability to use Alt+Tab and Super+Tab on the multitasking view.

I agree, I miss Super+Tab in overview a lot.

[scottjenson]

Just for context the two most common alt-tab switchers are Mac and Window. I'm not advocating we copy them, only that they each provide a example we can use to discuss and critique.

Windows:

• Shows all windows of all apps
• Layout is in a horizontal row
• Clear highlighting as you move through each one
• Can also go backwards, use mouse, quit apps (with mouse click)

Mac

• Shows only App icons (sub windows not shown) (This is much faster)
• Layout is also in a horizontal row
• Clear highlighting as you move through each app
• Can also go backwards, use the mouse, and even quit apps (with keyboard)

Elementary Today

• No abstract layout of apps or windows. it's more of a "highlighting" of the next app in the chain.
• you move from windows to window in one direction

The differences when laid out like this are pretty clear: elementary is more of a "1-at-a-time switcher" while Win/Mac offer more of an "Overview Picker". Here is what I heard above that people would like to see:

• Show all windows (not just apps) in the current workspace
• Not icons but scaled down images of each window (but will this slow things down?)
• Arrange in a more horizontal layout (there could be overlapping, needs to be explored)
• All windows w/in a single app could be grouped/tiled together
• Clearly highlight (or even zoom slightly) as you move from window to window
• Still maintain the 'quick switch' behavior of Alt-Tab so you can toggle between two apps repeatedly.

I'm happy to mock up a range of visuals (not a single solution) to be discussed further. But it's clear there are a lot of constraints. Anything I missed?

[janxkoci]

Nice overview :)

All windows w/in a single app could be grouped/tiled together

I just want to note that, in my view, grouping windows of same app under one icon in switcher will completely break my alt-tabbing workflows and I would have to abandon elementary and look for something else (I don't believe the devs would implement a toggle for this, as the two models are quite different in how they behave). I used to disable grouping wherever it was possible (e.g. GNOME) and really loved the fact it's not present in elementary.

[scottjenson]

Here are my first two attempts. I'm intentionally keeping the animations simple to keep our discussion focused. I've called out additional directions to explore at the end.

Here's the first one: Basic app to app transition:

A few notes:

• Each app is it's own color just to make it easier for you to track
• The title is below each window icon
• This animation is a simple "alt-tab" toggle switch
• If you wanted to go to the final app, you'd just hit alt-tab again

Here's a small addition, showing multiple windows for an app:

What I'm trying to build here is an agreement on how we'd like this new switcher to work. The key things we're getting with this model are:

• A clean, fast animation to get an overview of all windows
• A backward compatible Alt-tab approach to quickly toggling between 2 windows
• A way to extend that to multiple windows/apps
• A future path to allow additional functionality (quitting apps from this view)

For me the critical questions are:

• Are there any performance issues with this approach?
• Does this roughly capture what the community wants?

Once we get agreement on that, we can tackle the important edge cases:

• What happens with odd shaped windows (e.g. mostly vertical or horizontal)
• What happens with lots of windows (go smaller? Wrap to second row?)

[scottjenson]

I appreciate this can't just be visually pleasing, it also has to be efficient and quick. It's not an accident that both Mac and Win have zero animation: it's much faster. I'm hoping we can have style and speed.

Some obvious things to keep the animation but make it faster:

• reduce the animation speed. It's currently 500ms but we could likely make it much faster e.g 250ms.
• Don't animate the window name from CURRENT to TARGET. Just start on TARGET. Only animate the window name if you hit Alt-Tab a second time.
• Short circuit the animation. If you tap and release Alt-Tab quickly, just switch apps with no animation. This more of a power user feature. The Mac does this, Win does not

[cassidyjames]

@scottjenson thanks for tackling this! This looks like a great starting point, and I really appreciate the motion mockups; that makes it so much easier to track and discuss.

My main concern so far is what you've addressed regarding the speed; just tapping Alt+Tab to get to the last-focused app seems to be really common for workflow anecdotally and personally. I think reducing the animation is probably necessary in general, but dropping/significantly speeding it up on release of both Alt and Tab is probably a good in-between while keeping the Alt+Tab+Tab+Tab to switch through multiple windows feeling nice.

As a sort of side-note, we use Material Design inspired values for widget animations in the stylesheet. I am not sure what Material generally says about these sort of larger animations, but I do feel like generally we keep things around or under 300ms to feel snappy. Here are the current constants used in Gala:

gala/lib/Constants.vala

Lines 20 to 33 in 49d1d8f

	public enum AnimationDuration {
	// Duration of the open animation
	OPEN = 350,
	// Duration of the close animation
	CLOSE = 195,
	// Duration of the minimize animation
	MINIMIZE = 200,
	// Duration of the menu mapping animation
	MENU_MAP = 150,
	// Duration of the snap animation as used by maximize/unmaximize
	SNAP = 250,
	// Duration of the workspace switch animation
	WORKSPACE_SWITCH = 300,
	}

My other main concern is around the size of the previews; if I have two large Code windows open, they're gonna look almost identical at that size. I wonder if we should consider larger previews with some overlap like in @danrabbit's previous mockup. I'm pretty open to discussion, though, as that would consequently mean fitting fewer windows on screen at once and obscuring parts of the window previews in the trade-off for larger previews.

Are there any performance issues with this approach?

I think this would be as performant as our other window animations, e.g. the workspace-focused multitasking overview. I don't see any inherent issues with it.

Does this roughly capture what the community wants?

Hard for me to answer personally, but I suspect so. A common complaint I hear is that the order feels unpredictable—I think because people don't see the dock or associate the disconnected app icons strongly with the windows themselves, and our current window previews don't indicate the order at all. This pretty neatly solves it by making the window previews linear. It does also feel more similar to other platforms and like it's not trying to be "clever" by re-using the dock.

A future path to allow additional functionality (quitting apps from this view)

I think that's actually probably the wrong direction specifically… we have the multitasking overview which gives you a complete spread of open windows and allows for quick closing. I think trying to hold Alt+Tab and then perform actions is just going to get overcomplicated. But that's future talk, anyway. :)

[scottjenson]

After discussing this in the Slack channel we settled on a few next steps:

• Shorten the animation time
• Use the app icon + name at the top
• Have the window below this icon/text area, spaced out on a grid
• Have different sized windows shrink to fit this grid (see how this looks for various sizes)
• Much discussion around many windows: scroll to the right or have multiple rows? (tdb)
• Additional discussion of using Alt-Tab vs Multi-Tasking view, & when to use each one (needs more work)

Action item for me was to use real windows this time and create a 'next step' animation and see how it feels. Rinse, repeat.

[scottjenson]

OK, here is my next version, following a layout suggestion from @danrabbit

Changes from previous version:

• Real window captures
• Jump highlight to NEXT window directly
• More realistic window sizes (but note, not extreme windows sizes yet, that's coming next)
• Each window is held in the same size grid (which takes up more space (but feels more pleasing, uniform)
• MUCH faster animation
• I tried mix of windows with fixed app title and those that with varying titles (e.g. Browser/Terminal)
• Note: the dock animates out of the way while switching, not sure what it's value is?

This feels much faster yet keeps a nice "ElementaryOS" look and style to it (but I'm new here so please give feedback on the visual design) What I will say is that it's fairly LARGE and that feels like the next issue we should discuss. Should the Alt-Tab window be only the last X windows and we optimize for that? Or should this scale to 20 windows? That seems like the next core question for us to answer.

[cassidyjames]

@scottjenson I'm really liking where this is heading. I think I'm confident enough in this direction that we could start prototyping it—@davidmhewitt wants to rework window switching for technical reasons, anyway, so starting here is better than wasting time re-making the current design.

I think we'll want to pay attention to and tweak on thumbnail sizes, animations speeds and curves, etc. But that can be done relatively easily with a working prototype.

Something I do think we should consider is whether all apps should be scaled evenly (i.e. all at 10% of their original size or whatever they show here), or if they should scale to fit within a certain area. I am leaning toward the latter; in your example, see Calculator. To me, it feels awkward that it could be both taller and wider to better fill that space, which would probably help identifying some smaller windows especially. But perhaps that will also come when addressing the extremes.

This may just be an artifact of the prototype, but window labels should all be left-aligned in this layout.

Just as an aside, the OS does have a user-selectable "accent color" we can use in these designs; it's the blue palette by default, but a user can choose between any of the colors here:

If you find yourself needing a color (especially for representing highlighted or active things), this might be a nice place to use a subtle accent to bring that color more into their experience.

[danirabbit]

here's a quick mock showing apps trying to take up the same width instead of scaling at the same rate:

[kmandarin-orange]

I feel some of these mock-ups don't feel quite at-home in elementary. Combining some existing design elements, like Show All Windows layout and current window switcher's shading on unfocused apps might help ground this in the system better. I've got a quick sketch here, I'm not much of a Gimp pro haha.

The main details I think make this fit in well are

• All apps are scaled like @cassidyjames suggested
• Zoom in on focused application, slightly overlapping any applications next to it
• Icons will not zoom but stay on bottom middle of apps
• Selected app has window name in label beneath in same style as system tooltips that shows up in the rest of the system, I think it's called overlay bar?
• Subtle shade on other application windows/icons
• Slightly darker shade on background
• Grid layout similar to Gnome overview/Show All Windows view in eOS
• Like current switcher, clicking on icons/windows in this view will instantly switch to them
• I really like the movement/animation in @scottjenson's mock, though faster may be better
• Dock dodges out of the way like the workspace overview animation does

Something I didn't illustrate right was Wingpanel transparency, which should just take the system default. @danrabbit's mock does this well. Anyway, that's what I have to offer here.

[aral]

Hi all,

I’m coming into this rather late, apologies. I started using elementary OS a few weeks ago and, as I told Daniel on our live stream (https://small-tech.org/events/small-is-beautiful/) I’m absolutely in awe of what you’ve created and hugely hopeful of the direction you’re taking with developing a sustainable open ecosystem that will hopefully one day give developers a viable alternative to the closed silos of Apple, etc.

Now, to the topic at hand: alt + tab.

Unfiltered initial thoughts when I first encountered it:

“What the fuck just happened? Why is everything moving around?”

Basically:

1. Alt + tab is a hidden, productivity gesture (the non-hidden gesture is to use the dock to change apps)
2. As a hidden, productivity gesture, I want it to do what it does with a minimum of fuss and to get out of my way as quickly as possible (the biggest issue I had after switching to elementary OS was losing my trail of thought. I’d think “right I need to look up X in the browser … alt+tab, alt+tab… damn! no! wait… what was I going to look up again?”
3. Icons exist for a reason :)

Within the context of the above three points, I would highly urge you to consider not scaling down the windows but using icons instead.

I know it’s not as fancy-looking but hear me out.

This is what I’ve started using for myself: https://github.com/markstory/gala-alt-tab-plus

If you look at it, you’ll probably think it resembles the macOS switcher and that’s not a bad thing. It’s definitely not perfect (I don’t want to think about where my apps are – i.e., which workspace, etc. ­– when I’m alt + tabbing but currently it is only limited to the current workspace and my current workaround is not to use workspaces.)

So, what I feel this switcher does right:

• It is calm. It does not animate my windows. I don’t want congitive complexity when I’m fast switching between apps. I want to switch between apps. (I would even drop the easing animation of the highlight between apps. In fact, I might just fork it and do that.)
• It uses icons. There is very little cognitive load to recognising an icon. There’s a reason we use icons of applications in menus, etc., instead of tiny thumbnails of them. The same principles apply here. (If we showed windows within an app as well, thumbnails might make more sense there but titles would probably still suffice. Which leads me to…)
• It allows me to tell apart different windows of the same app (simply, by displaying some additional information about each). This could be handled differently if desired and isn’t the most aesthetically-pleasing but functional features below delightful for a reason on the ethical design pyramid (https://2017.ind.ie/ethical-design/). Ideally, of course, I would be able to switch between windows of the same app differently and not have to worry about which workspace or screen my apps are. All these add cognitive load that can make me forget what I am doing.

So, please, please, please, do not cause a full-screen animation every time I press alt + tab. The animation is very pretty but it does not add any semantic value whatsoever and instead adds a huge amount of noise.

Please make alt + tab a calm, quick, gesture with low conginitive load.

If there’s anything I can do to help with this, please let me know.

And thanks again for the amazing work you’re doing. It’s truly inspirational :)

💕️

[danirabbit]

That's interesting and something I hadn't considered was the alt+tab switcher being purely representational and not being a transform at all. Especially since we do have that more full-screen transform multitasking view for jumping non-linearly between windows etc. What do you think about that @scottjenson? And does that more closely resolve your original issues @donadigo?

[aral]

@zspencer I think it would be worthwhile looking into the Pop!_OS task switcher as they’ve layered this functionality well:

1. It switches between all open apps by default so you don’t have to worry about remembering where an app is (why does that matter? With apologies to Steve Krug, don’t make me think!)
2. It layers the gesture to switch to different windows of the same app. You can very easily use the task switcher to switch between apps without worrying about windows. If you do care about the windows, they’re available also via their own shortcut that you can use without interrupting your flow.
3. If you just want to switch to windows of the same app without changing apps, just use the shortcut for window switching.

Given that the elementary team are familiar with the System 76 folks, I’m sure they’re familiar with the switcher.

This might be a case where not reinventing the wheel is a good thing.

I’d highly recommend basing the switcher on a simple model like the one I presented above or on the Pop!_OS one which seems to do everything right.

[donadigo]

@danrabbit being a non-fullscreen action, this solves some of my original issues and @aral's realization that the current transition is too noisy and heavy cognitively is also aligning with my thoughts. As he already pointed out, it should be done with "minimal fuss" so here are my thoughts:

1. fast animation, that is, you should not feel like you're waiting for the animation to happen just for the window switch
2. non-fullscreen: you should not feel like you're leaving the context in which you're working in currently

When it comes to window icons vs. previews, I see how window icons can be less taxing and easier to scan, however there still needs to be a distinction made for multiple windows of the same app. This could be solved in a number of ways, putting the title seems the easiest but I'm unsure if that's really valuable. We could also visualize the window that will be on top live when the user cycles through windows.

[janxkoci]

I use workspaces exactly because I don't want to Alt+Tab through all my windows every time.

I use Alt+Tab mostly to switch between two windows, or to get to a window that is used less frequently (that chat window behind the other 5 work windows). Using Alt+Tab to quickly juggle more than 2 windows gets painfully messy really fast.

This is where I divide my windows to different workspaces, so I mostly have windows for particular task on one workspace and other windows elsewhere. This makes my alt-tabbing much more sane.

So allowing Alt+Tab over all workspaces would obviously completely break this workflow. If I really cannot find my window, there is the dock, or - my favourite - the multitasking view, which has iconic representation of the workspaces and finding the icon there is usually a split-second action.

Those are my two cents.

[ibrahimrahman]

Just want to show support for this proposal. As a regular user, I expect to the alt-tab functionality to be instantaneous, i.e. I focus on the app icon that i want to get to and let go of the buttons the moment it gets highlighted. I would like it to get as out of the way as possible. The animations and full screen view as proposed earlier in this discussion would probably end up being too distracting.

Regarding switching between all apps or just the ones in the current workspace, what could be done is that apps open in separate workspaces are displayed in separate rows, with the row representing the current workspace set to active (only these apps can be cycled through) and all others dimmed/semi transparent or something.

Users could cycle between the rows using for eg. the Q (for down) and W (for up) keys (Since they're right next to Tab) without letting go of the alt key. Pressing Esc would just exit the Alt-Tab switcher and bring the user back to the original window. The rows could also be labeled/numbered which might help in making it even easier to navigate. Just an idea that I wanted to share

[capttrousers]

Joining this convo, as I have a few gripes with the Alt Tab behavior of eOS.

• the list of open windows that I'm tabbing through is at the same position of the dock on the screen but I want it to be in the middle of the screen. This middle of the screen location is standard, and the same as the Gnome and Mac OSX and Windows Alt Tab switchers.
• I can't use arrow or pg down/up keys to manually scroll through the list.

A number of the mocks here look like that's the general direction that eOS is taking the Alt Tab subsystem, putting that list of apps to scroll through in the middle of the display, and allowing keyed scrolling but I cant tell if that's already released or not?

As for people's concerns on the "full screen view", I think they mean that when pressing Alt Tab in these proposed designs, all open windows kind of disappear, or become mostly transparent, with a full screen overlay thing that gets presented which has all the open windows there, and then repeatedly pressing Tab while holding Alt will keep that overlay showing and have some animation affordance that shows your current selection in the context of all the windows, and then releasing Alt will pick that selected window to focus on. For these concerns, can we debounce the animation for 500ms or something, so for power users quickly switching between 2 or 3 apps, they don't have to pay the costs of the animation or all windows view, but if you hold Alt for longer than that period, then the overview is shown?

As for the icons vs actual window contents view question, can we do both? I think that's what Gnome does, you get the window contents scaled down plus the icon at the bottom of that thumbnail.

Also, I tried looking at Aza Raskin's blog post that Dan linked but the server was down, so I googled it, and found this other blog post as a response to Aza's post. This post has a lot of interesting history and behavior of Alt Tab spelled out, across platforms:
https://fjordaan.medium.com/solving-the-real-alt-tab-problem-e9fba18bd0f

[capttrousers]

Well, looks like my main gripe is already fixed :) in the Nov monthly updates.
https://blog.elementary.io/elementary-os-6-odin-updates-november-2021/

There is still the issue of not being able to use arrow keys to go back and forth between the open windows, once you've pressed Alt Tab and continue to hold Alt.

I do think further improvements to this could include prettier "eOS-y" animations and showing scaled thumbnails of each window rather than just the app icon, or in addition to that, but there should be a debounce period so users who are just swapping between 2 or 3 windows dont have to pay any animation/rendering costs.

[scottjenson]

I've away for a while but I've followed this issue so let me reply with how I interpret the work @aral did to clean this up.

1. Thumbnails vs Icons: this design is meant to be icons, it's a quick switch and icons help you quickly identify the app. By using thumbnails, it's that much harder to quickly identify the app. I believe this approach is also an APP switcher and not a WINDOW switcher (please correct if wrong) If so, the app icon is the only solution that works for all windows of that app.
2. Arrow keys while holding Alt: makes sense to me, anything that improves keyboard nav is a win with this
3. Improved animations: Again, seems reasonable, is there someting you'd suggest? Example animation we should be copying?

[capttrousers]

I think Francois Jordaan's blog post I linked above makes a good distinction between 2 different user workflows that are both served by typical Alt Tab behavior across the various OSs and Linux DEs:

1. Quick swapping between 2, at most 3, different windows, using the Most Recently Used sorted list
2. A slower and precise window selection, where Alt is held and the user scrolls through the list either with Tab or arrow keys, the mouse, etc, to select the specific window they want, out of a potentially large list of open windows.

I think most of the recent improvements were around improving scenario # 2, and that the concern about thumbnails and animation is the potential perf impact to scenario # 1. I think it's also fair to argue that scenario 2 is equally served via the all windows overview thing, I think Mac OSX calls it Expose, but I typically prefer using Alt Tab for both scenarios, and I know I'm not alone.

My experience with the new Alt Tab system after upgrading this morning shows it's a WINDOW switcher, not APP switcher, so two windows of Firefox will be shown as two distinct select-able windows in the Alt Tab list, which is now in the middle of the display. (this is definitely the preferred default, Gnome in the past had the default be App switcher, with a sub selector thing for multiple windows for the same app, very frustrating IMO)

The two windows of the same app can only be differentiated with the added window title, which only shows up on the currently selected window in the Alt Tab list. For tabbed apps like browsers, this will be the current open tab for that window.

I found this example of Gnome's Alt Tab list display, from a youtube video. They use a scaled image of the window plus the app icon, although the icon is smaller than I'd like and offset to the bottom right, maybe eOS could do that icon larger and center bottom justified.

So I do think adding scaled thumbnails to the Alt Tab list, in addition to the app icons, is a good balance for that window discoverability problem, with prior art, and if there are perf concerns, adding a debounce for that window w/ icon list could help.

As for animations, I dont know really, there were other designs in this thread that discussed various animation options. That's window dressing to me, but also part of the overall appeal of eOS, so I welcome the future addition of those.

[secondlnl]

What about a switch in settings to switch between the current implementation and this one;

A rough mock-up (made in Akira) that have elements of the current design and some from designs talked about in this thread. (Also from the overview)

The blue highlight is a selection that moves accordingly. The blue could be any accent colour.
The backgrounds for the application are there just because I couldn't find a way to remove them.

[janxkoci]

That looks pretty much like what the comment above you describes in words, i.e. window previews with icons included. There should also be text with a window title, to distinguish different windows of the same app more easily (I often have several PDFs of science papers open and seeing their thumbnail+app icon doesn't help that much, while the title does).