After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 703538 - new alt-tab behaviour breaks user context
new alt-tab behaviour breaks user context
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: app-switcher
3.8.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2013-07-03 12:35 UTC by Ferry Huberts
Modified: 2013-08-18 11:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
appSwitcher: Add option to limit to the current workspace (2.99 KB, patch)
2013-07-04 17:28 UTC, drago01
committed Details | Review

Description Ferry Huberts 2013-07-03 12:35:09 UTC
the new alt-tab behaviour no longer groups the windows of the current workspace first. the 3.6 behaviour was way better

this change breaks the context of the user, which is quite bad.
the user switched to a different workspace for a reason, to access the context in that workspace.
Comment 1 drago01 2013-07-04 16:38:07 UTC
Yeah I have to agree I find myself constantly ending up on the wrong workspace by accident.  I said the same thing when the change got introduced but got overruled.

Setting the ui-rewview keyword but I doubt the designers will change their mind. They seem to use workspaces in a completely different way where this is not an issue.
Comment 2 Ferry Huberts 2013-07-04 16:53:09 UTC
Being overruled, I find that quite odd.

Workspaces are - by definition - distinct contexts.

Contexts actually have boundaries, both physical (a different workspace is on a different screen) and logical (grouping the windows per workspace as in 3.6).

Removing the window grouping breaks the boundaries mental model: physically the contexts are separated (different screens) while logically they are not (alt-tab doesn't group per workspace).

This is quite bad for the user experience.

I now gratuitously move from context to context while before I had to make a conscious choice to do so, as it should be, per the boundary.

I've explained these concepts to the GNOME people on multiple occasions and I find it rather odd that they have not thought about this, or worse, chose to ignore the concepts.

These designers are supposed to known about the concepts, be experts in cognitive ergonomics.

I'm rather disappointed that changes like these made it in.
Comment 3 Ferry Huberts 2013-07-04 16:57:40 UTC
@designers,

If you do want to keep the current behaviour, then the least you could do is provide a setting that allows users to switch on the grouping per workspace.

But I'd rather have the grouping as default because that provides a consistent model, while the current behaviour does not.
Comment 4 drago01 2013-07-04 17:28:08 UTC
Created attachment 248404 [details] [review]
appSwitcher: Add option to limit to the current workspace

Add an option to limit the appSwitcher to the current workspace. For users
that use workspaces for task separation this more convient then current
behviour. While having to add an option is unfortunate there is no way to make
both groups happy as workspaces usage differes between different users / types
of users.
Comment 5 Ferry Huberts 2013-07-04 17:36:54 UTC
Please no limiting to the workspace _only_, just grouping like it was in 3.6

Limiting to the worspace can already be achieved by the AlternateTab extension.
That behaviour is too limiting since it doesn't allow me to make the conscious choice to go to a different workspace.

The workspace boundary was visualised in the 3.6 behaviour. That behaviour was sound.
Comment 6 Florian Müllner 2013-07-04 18:07:20 UTC
(In reply to comment #2)
> Contexts actually have boundaries, both physical (a different workspace is on a
> different screen) and logical (grouping the windows per workspace as in 3.6).

Correct, workspaces are used to group windows. The problem here is that we don't switch windows (by default), but applications - there the grouping by workspace is a whole less clear, given that a single workspace can contain more than one application, just as a single application can have open windows on more than one workspace.

This was not just a theoretical problem, we had quite a number of open bug reports about confusing behavior of the popup (for once, it broke one of the most intuitive alt-tab assumptions: hitting alt-tab twice in a row will bring you back to where you were). Some reports even were from users who use workspaces heavily - it's unavoidable, if you categorize a set of items by multiple criteria that overlap, you end up with tensions (how is an app with windows on multiple windows supposed to behave - like a single app with windows spread across workspaces, or like multiple apps with each having windows on a particular workspace).

So I still stand by our conclusion - grouping windows by workspace is fine, so is grouping them by application. But trying to group them by both at the same time is messy and confusing ...



(In reply to comment #3)
> If you do want to keep the current behaviour, then the least you could do is
> provide a setting that allows users to switch on the grouping per workspace.

No, there won't be such a setting for the app switcher. However we did add a window switcher in 3.8 (which is disabled by default), which already has the option to show windows from all workspaces or just the current one. I wouldn't object to an additional setting to group windows by workspace for those who want it.
Comment 7 Florian Müllner 2013-07-04 18:11:47 UTC
(In reply to comment #4)
> Created an attachment (id=248404) [details] [review]
> appSwitcher: Add option to limit to the current workspace

This doesn't have the problems that the old behavior had, so I'm not principally opposed to adding this. Still, I'd like for the designers to chime in first ...
Comment 8 Florian Müllner 2013-07-04 18:12:40 UTC
Review of attachment 248404 [details] [review]:

Code looks good, pending design review.
Comment 9 drago01 2013-07-04 18:13:50 UTC
(In reply to comment #6)
> (In reply to comment #2)
> > Contexts actually have boundaries, both physical (a different workspace is on a
> > different screen) and logical (grouping the windows per workspace as in 3.6).
> 
> Correct, workspaces are used to group windows. The problem here is that we
> don't switch windows (by default), but applications - there the grouping by
> workspace is a whole less clear, given that a single workspace can contain more
> than one application, just as a single application can have open windows on
> more than one workspace.

And this is what causes problems with current behavior. When I want to switch to firefox I want firefox *on that workspace* not being taken to a completely different workspace.

> This was not just a theoretical problem, we had quite a number of open bug
> reports about confusing behavior of the popup (for once, it broke one of the
> most intuitive alt-tab assumptions: hitting alt-tab twice in a row will bring
> you back to where you were). Some reports even were from users who use
> workspaces heavily - it's unavoidable, if you categorize a set of items by
> multiple criteria that overlap, you end up with tensions (how is an app with
> windows on multiple windows supposed to behave - like a single app with windows
> spread across workspaces, or like multiple apps with each having windows on a
> particular workspace).

While this is true the current solution has its own issues.
Comment 10 Florian Müllner 2013-07-04 18:28:57 UTC
(In reply to comment #9)
> While this is true the current solution has its own issues.

Few things haven't - I was not claiming otherwise, just outlining the reasoning behind the change.

Now, the proposed filtering by workspace (as opposed to grouping) doesn't have the aforementioned problems, so I'm open to that (as well as to grouping by workspace in the window switcher).
Comment 11 Ferry Huberts 2013-07-04 18:56:22 UTC
Please _do_ read reply 2.

As per your own comment:

> Correct, workspaces are used to group windows.

So why _break_ that grouping?
That's completely counter-intuitive.
Even more so when also considering the context situation I explained.

You made a window more important than a context.
That's a mistake:

1. A workspace IS a different context.
2. A workspace groups windows.
ergo: a context is logically (and physically!) more important than a window.

(even the plain language shows you the logic!)

> Correct, workspaces are used to group windows.

ergo: a context is logically (and physically!) more important than a window.

(even the plain language shows you the logic!)
Comment 12 Ferry Huberts 2013-07-04 19:14:13 UTC
(In reply to comment #6)
> (In reply to comment #2)
> > Contexts actually have boundaries, both physical (a different workspace is on a
> > different screen) and logical (grouping the windows per workspace as in 3.6).
> 
> Correct, workspaces are used to group windows. The problem here is that we
> don't switch windows (by default), but applications - there the grouping by
> workspace is a whole less clear, given that a single workspace can contain more
> than one application, just as a single application can have open windows on
> more than one workspace.
> 
> This was not just a theoretical problem, we had quite a number of open bug
> reports about confusing behavior of the popup (for once, it broke one of the
> most intuitive alt-tab assumptions: hitting alt-tab twice in a row will bring
> you back to where you were). Some reports even were from users who use

yes, in your CURRENT context!
NOT in a different context.

So there are some vocal users that don't understand the logic and their flow is made the default?

> workspaces heavily - it's unavoidable, if you categorize a set of items by
> multiple criteria that overlap, you end up with tensions (how is an app with

they don't overlap. you stay in your context unless you explicitly choose not to.

so your popup appears in your current context.

> windows on multiple windows supposed to behave - like a single app with windows
> spread across workspaces, or like multiple apps with each having windows on a
> particular workspace).

ah, that triggered something else:
if I switch to -say- a terminal on my current screen, it's raised to the front.
why the heck are _all_ terminals on _all_ screens raised to the front?! that's not what I asked. I just switched to the terminal on my current screen. don't touch my other screens!

it's inconsistencies everywhere and it's getting worse, not better.

do I really need to re-iterate basic design principles of UIs?
I'll do it anyway:
- consistency
- consistency
- consistency
- consistency
- consistency
- locality
- predictability
- reflect reality
- simplicity


the new behaviour violates (at least) consistency, locality, reflect reality.

> 
> So I still stand by our conclusion - grouping windows by workspace is fine, so
> is grouping them by application. But trying to group them by both at the same
> time is messy and confusing ...
> 
> 
> 
> (In reply to comment #3)
> > If you do want to keep the current behaviour, then the least you could do is
> > provide a setting that allows users to switch on the grouping per workspace.
> 
> No, there won't be such a setting for the app switcher. However we did add a
> window switcher in 3.8 (which is disabled by default), which already has the
> option to show windows from all workspaces or just the current one. I wouldn't
> object to an additional setting to group windows by workspace for those who
> want it.

so you take away something, introduce a major inconsistency, and offer no way to get the thing back that was taken away. way to go.


I'm getting the distinct feeling that I'm fighting an uphill battle here.
I've always believed the name-calling to be undeserved.
I believed engaging with arguments to be the way.
I've tried and actually _want_ to keep trying.

Please re-read your own comments and re-evaluate your own logic; it's unsound.
Comment 13 drago01 2013-07-04 19:28:48 UTC
(In reply to comment #12)
> (In reply to comment #6)
> > (In reply to comment #2)
> > > Contexts actually have boundaries, both physical (a different workspace is on a
> > > different screen) and logical (grouping the windows per workspace as in 3.6).
> > 
> > Correct, workspaces are used to group windows. The problem here is that we
> > don't switch windows (by default), but applications - there the grouping by
> > workspace is a whole less clear, given that a single workspace can contain more
> > than one application, just as a single application can have open windows on
> > more than one workspace.
> > 
> > This was not just a theoretical problem, we had quite a number of open bug
> > reports about confusing behavior of the popup (for once, it broke one of the
> > most intuitive alt-tab assumptions: hitting alt-tab twice in a row will bring
> > you back to where you were). Some reports even were from users who use
> 
> yes, in your CURRENT context!
> NOT in a different context.

He means windows rather then applications. i.e an application can have windows on multiple workspaces.

> So there are some vocal users that don't understand the logic and their flow is
> made the default?

That's not what he said either.

> > workspaces heavily - it's unavoidable, if you categorize a set of items by
> > multiple criteria that overlap, you end up with tensions (how is an app with
> 
> they don't overlap. you stay in your context unless you explicitly choose not
> to.
> 
> so your popup appears in your current context.
> 
> > windows on multiple windows supposed to behave - like a single app with windows
> > spread across workspaces, or like multiple apps with each having windows on a
> > particular workspace).
> 
> ah, that triggered something else:
> if I switch to -say- a terminal on my current screen, it's raised to the front.
> why the heck are _all_ terminals on _all_ screens raised to the front?! that's
> not what I asked. I just switched to the terminal on my current screen. don't
> touch my other screens!
> 
> it's inconsistencies everywhere and it's getting worse, not better.
> 
> do I really need to re-iterate basic design principles of UIs?
> I'll do it anyway:
> - consistency
> - consistency
> - consistency
> - consistency
> - consistency
> - locality
> - predictability
> - reflect reality
> - simplicity
> 
> 
> the new behaviour violates (at least) consistency, locality, reflect reality.

Can you be a bit less dramatic? While my first comment in the bug could have been worded better as well I don't think going down this route is helpful. Can we stay factual and leave emotions out please?
Comment 14 Ferry Huberts 2013-07-04 19:40:40 UTC
> He means windows rather then applications. i.e an application can have windows
> on multiple workspaces.

There is not a clear distinction, it's fuzzy, so there might as well be no distinction at all:
- An application can have multiple instances.
- An application can have multiple windows.
- How do you see the difference? --> Sometimes you do and sometimes you don't.
There is no mechanism in place to enforce a difference.
Therefore there is no (clear) distinction between the two and therefore they are logically the same.


> > ah, that triggered something else:
> > if I switch to -say- a terminal on my current screen, it's raised to the front.
> > why the heck are _all_ terminals on _all_ screens raised to the front?! that's
> > not what I asked. I just switched to the terminal on my current screen. don't
> > touch my other screens!
> > 
> > it's inconsistencies everywhere and it's getting worse, not better.
> > 
> > do I really need to re-iterate basic design principles of UIs?
> > I'll do it anyway:
> > - consistency
> > - consistency
> > - consistency
> > - consistency
> > - consistency
> > - locality
> > - predictability
> > - reflect reality
> > - simplicity
> > 
> > 
> > the new behaviour violates (at least) consistency, locality, reflect reality.
> 
> Can you be a bit less dramatic? While my first comment in the bug could have
> been worded better as well I don't think going down this route is helpful. Can
> we stay factual and leave emotions out please?

factual without emotion does not communicate how important an issue is to the one reporting it.
communication lacking an aspect is incomplete.

as I said,
> I've tried and actually _want_ to keep trying.
Comment 15 Ferry Huberts 2013-07-04 19:54:20 UTC
I've made the window raising behaviour into a new bug: https://bugzilla.gnome.org/show_bug.cgi?id=703630
Comment 16 Florian Müllner 2013-07-04 20:35:50 UTC
(In reply to comment #11)
> Please _do_ read reply 2.
> 
> As per your own comment:
> 
> > Correct, workspaces are used to group windows.
> 
> So why _break_ that grouping?

Because the toplevel objects of the application switcher are applications, not windows. Workspaces don't group applications.


> You made a window more important than a context.

No. We made applications more important than workspaces. Note that I'm saying workspace and not context - by itself, a workspace is just a space to group a set of windows; whether groups are based on context, size or color is really up to the user(*). They are a tool, it's up to users what they make of it. Slightly off-topic: I once witnessed a user arguing that the only correct way to use a web browser is to use one window per site, and only ever use tabs to group pages from the same site.


(In reply to comment #12)
> So there are some vocal users that don't understand the logic and their flow is
> made the default?

Not at all. I'd even go as far as saying that it were some vocal users that lead us to the behavior we had up to 3.6, but admittedly I don't have hard numbers to back this up.


(*) I doubt anyone *actually* groups windows by color, but size is actually not too far-fetched - putting maximized windows that you only need to check on occasionally (mail etc.) on different workspaces is a perfectly valid use case.
Comment 17 Ferry Huberts 2013-07-04 20:56:40 UTC
(In reply to comment #16)
> (In reply to comment #11)
> > Please _do_ read reply 2.
> > 
> > As per your own comment:
> > 
> > > Correct, workspaces are used to group windows.
> > 
> > So why _break_ that grouping?
> 
> Because the toplevel objects of the application switcher are applications, not
> windows. Workspaces don't group applications.
> 

See comment 14:
> Therefore there is no (clear) distinction between the two and therefore they
> are logically the same.


> 
> > You made a window more important than a context.
> 
> No. We made applications more important than workspaces. Note that I'm saying
> workspace and not context - by itself, a workspace is just a space to group a
> set of windows; whether groups are based on context, size or color is really up

and therefore a set of applications

> (*) I doubt anyone *actually* groups windows by color, but size is actually not
> too far-fetched - putting maximized windows that you only need to check on
> occasionally (mail etc.) on different workspaces is a perfectly valid use case.

which is the _perfect_ example of a different context


Let's take webbrowser tabs; these were also invented to have different contexts (a 1-application/window-per-context).
A webbrowser tab is _not_ changed by the browser unless the user has asked for it.
Why would a workspace be changed without the users asking for it?
That would make shell inconsistent with the most dominant application on earth...


Let's also make it a bit more concrete with an example from my daily use:
- Eclipse in one workspace
- git tools in another workspace

I do code development with Eclipse, version control with Git.
Two entirely different contexts and therefore on different workspaces.
When I switch from Eclipse to Git, I'm going to do version control.
I made a choice to do that, I switched context from developing code to doing version control on that code.
An alt-tab now forcibly removes me from that context that I just chose.
Comment 18 Florian Müllner 2013-07-05 01:16:05 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > Because the toplevel objects of the application switcher are applications, not
> > windows. Workspaces don't group applications.
> > 
> 
> See comment 14:
> > Therefore there is no (clear) distinction between the two and therefore they
> > are logically the same.

I didn't want to comment on that earlier, because it didn't make any sense to me (still doesn't) :-)

Our definition of application roughly translates to a .desktop file (see https://wiki.gnome.org/GnomeShell/ApplicationBased for a wordier definition and comparison to GNOME2's window-based approach), not to a single window  or process.

So no, applications and windows are not the same, just as workspaces and windows are not the same (As in: "An application can be associated with zero or more windows, so can a workspace. Therefore they are logically the same").


> > putting maximized windows that you only need to check on
> > occasionally (mail etc.) on different workspaces is a perfectly valid use case.
> 
> which is the _perfect_ example of a different context

Sigh. Let's make the example "e-mail client + music player, both tiled, both only needed occasionally" then. The point is: you *can* use workspace the way you do, to strictly separate tasks (or contexts). You don't *have* to.


> Let's take webbrowser tabs; these were also invented to have different contexts
> (a 1-application/window-per-context).

Uhm, no. They were invented because people started to have too many different pages open at the same time to be still manageable comfortably with one window per page. By all means, split you browser tabs into per-context-windows, but please don't imply that there's anything mandatory about this workflow.


> Why would a workspace be changed without the users asking for it?

I agree, a workspace switch should never just happen. Now, selecting an application in alt-tab *is* a user action (even if it's "get me to application X, wherever it may be" rather than "take me to workspace Y") ...


> Let's also make it a bit more concrete with an example from my daily use:
> - Eclipse in one workspace
> - git tools in another workspace
> [...]
> An alt-tab now forcibly removes me from that context that I just chose.

Just to be clear: I don't mind supporting your workflow better, as long as it doesn't break other workflows. The old behavior only really worked well for users who don't use workspaces at all, it didn't work well for many heavy workspace users (because workspace separation wasn't strict enough) nor casual users (because any workspace separation tended to get in the way). In 3.8, there's no change for users that don't use workspaces, a window switcher that should suit previously unhappy heavy workspace users better, and a changed app switcher to accommodate casual workspace users. The trade-off is that user for whom the old behavior was just right are worse off. If we can improve that without affecting the aforementioned groups, then I'm all ears. But simply going back to the old behavior isn't an option.
Comment 19 Ferry Huberts 2013-07-05 07:33:28 UTC
[snip]

> Our definition of application roughly translates to a .desktop file (see
> https://wiki.gnome.org/GnomeShell/ApplicationBased for a wordier definition and
> comparison to GNOME2's window-based approach), not to a single window  or
> process.
> 
> So no, applications and windows are not the same, just as workspaces and
> windows are not the same (As in: "An application can be associated with zero or
> more windows, so can a workspace. Therefore they are logically the same").

I've read the link and it confirmed what I suspected.

Your difference is a _technical_ difference only, it has no basis in how the user perceives windows and/or applications.
To the user there is no clear difference, and therefore no difference at all, see comment 14.

You made the classical error of confusing technical difference with perceptual difference.

The link also does not talk about a mechanism to make windows and application actually look different.

[snip]

> Just to be clear: I don't mind supporting your workflow better, as long as it
> doesn't break other workflows. The old behavior only really worked well for
> users who don't use workspaces at all, it didn't work well for many heavy
> workspace users (because workspace separation wasn't strict enough) nor casual
> users (because any workspace separation tended to get in the way). In 3.8,
> there's no change for users that don't use workspaces, a window switcher that
> should suit previously unhappy heavy workspace users better, and a changed app
> switcher to accommodate casual workspace users. The trade-off is that user for
> whom the old behavior was just right are worse off. If we can improve that
> without affecting the aforementioned groups, then I'm all ears. But simply
> going back to the old behavior isn't an option.

I'm going to give this a rest.
I've enabled the LaternateTab extension and am now switching on the current workspace only.
I understood that this extension is officially supported by GNOME, please continue doing so and also please update it to actually look the same as the default switcher.
Comment 20 drago01 2013-07-06 17:16:52 UTC
(In reply to comment #8)
> Review of attachment 248404 [details] [review]:
> 
> Code looks good, pending design review.

Do we need that for a not exposed option?
Comment 21 drago01 2013-07-18 12:35:37 UTC
Comment on attachment 248404 [details] [review]
appSwitcher: Add option to limit to the current workspace

Attachment 248404 [details] pushed as d0d9814 - appSwitcher: Add option to limit to the current workspace

Pushed after IRC discussion, leaving the bug open to explore proper solutions that do not require an option.
Comment 22 Allan Day 2013-08-18 11:43:00 UTC
There's been plenty of discussion here, the current design has been explained, and an option has been added.