You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So, you'll have a terminal icon in your panel with a circled "3" indicating there are 3 windows.
When you move the mouse cursor over it (roll-over), three miniature windows will show up for the three windows, so you click on any of them to focus a given terminal window.
So far so good.
However, rollover-based interaction is implemented poorly here.
Let me make a small digression. And let's leave completely aside the fact that rollover-based interaction is probably a bad idea to begin with, given that it requires a completely different paradigm for touch screens. I don't have a touch screen desktop device with ubuntu to test on, so I'll assume that Cinnamon's interface for selecting one of multiple windows from the Panel on a touch screen works perfectly. So let's focus on the traditional screen+mouse case.
Whenever you have a piece of interface activated by a roll-over event, some problems arise. The solutions to those problems have already been invented, and decent user interfaces usually implement those properly. Cinnamon doesn't in this case.
When a roll-over event causes a piece of UI to appear (such as a dropdown menu or submenu; a tootip; or in this case the miniatures of multiple windows for selecting one of them), and that is a piece of UI you are supposed to interact with, the first problem that arises is this:
In order to interact with the newly-appeared piece of UI, you need to move the mouse cursor from your current position (on the "parent" element that caused the "child" UI to show up) to the area within the thing that has just popped up. Let's call them parent and child, so you need to move the mouse from the parent to the child. Obviously these have to be adjecent, otherwise on the trajectory you would at some point be on the empty space between parent and child causing the child element to disappear. But the fact is, even if they are adjacent, it is pretty common that a trajectory from parent to child that never falls off of both is pretty narrow. That is, it's easy, when moving the cursor from parent to child, to accidentally fall off of both, causing the child to disappear (roll-out event).
In decent UIs, this is usually solved in two ways that are not mutually exclusively but are usually both used together:
the "rollout" event causing the child UI to disappear is not triggered immediately but with a delay. So, if in your trajectory, you leave the parent for a short time before reaching the child, the child will not disappear.
A CLICK on the parent usually "locks" the child in the visible state.
So, you can click on the parent element, and the child will not disappear on rollout, and you can take as clumsy, inaccurate and deviated a trajectory as you want to move the cursor from parent to child, without fear of the child disappearing.
Cinnamon, with the panel icon and multiple-window miniatures, doesn't implement either of these.
I am particularly used to the click trick. I ALWAYS click on the parent thing. In some cases (well-designed UIs) that has the above-mentioned effect of locking the enabled state of the child, allowing me to move to it without having to be particularly careful about the path taken. But even when it doesn't (less brilliant but still decent UIs), it just has no effect. So I move the cursor on the parent element, the child element appears, I instinctly click on the parent element which has no effect whatsoever, and then I can interact with the child element (whether or not clicking on the parent made it easier for me or not).
Now, on cinnamon, the following happens:
Observed behavior
I move the mouse over the Terminal icon in the Panel
the three miniatures of the existing open terminal windows show up just above it
I click on the main icon
The click causes either one of the 3 terminal windows to be focused, or to be unfocused if it already had focus. Either way, it makes the 3 popup miniatures disappear immediately
So I am unable to select one of the windows, which is the very thing that I need to do and what I clicked for.
Even worse: every time I do this, I get confused and disoriented, and instinctively I click on the icon again, but this only toggles focus back and forth on the default-chosen window, but never causes the popup miniatures to show up again. The only way to have them to show up again is to move out of the icon and back onto it (rollout-rollover).
Expected behavior
Accepting the overall design, the fact that the miniature windows for selection show up on rollover, and accepting the fact that a click on the parent icon causes one of them (the last focused one) to be given or taken away focus...
Accepting all that, the bare minimum that should happen is:
clicking on the main icon must NOT cause the popup miniature windows to hide.
On the very contrary, ideally it should cause them to stick, and not disappear on rollout but only when you click on something else. But even if you don't want to do that, at the very least, the click should have no effect at all.
This is aggravated by the fact that, on other Desktop environments, you actually have to click on the main icon to have the miniatures show up (they don't show up on rollover), so one has an additional reason to be used to clicking on the icon.
The text was updated successfully, but these errors were encountered:
Let's say you have 3 terminal windows open.
So, you'll have a terminal icon in your panel with a circled "3" indicating there are 3 windows.
When you move the mouse cursor over it (roll-over), three miniature windows will show up for the three windows, so you click on any of them to focus a given terminal window.
So far so good.
However, rollover-based interaction is implemented poorly here.
Let me make a small digression. And let's leave completely aside the fact that rollover-based interaction is probably a bad idea to begin with, given that it requires a completely different paradigm for touch screens. I don't have a touch screen desktop device with ubuntu to test on, so I'll assume that Cinnamon's interface for selecting one of multiple windows from the Panel on a touch screen works perfectly. So let's focus on the traditional screen+mouse case.
Whenever you have a piece of interface activated by a roll-over event, some problems arise. The solutions to those problems have already been invented, and decent user interfaces usually implement those properly. Cinnamon doesn't in this case.
When a roll-over event causes a piece of UI to appear (such as a dropdown menu or submenu; a tootip; or in this case the miniatures of multiple windows for selecting one of them), and that is a piece of UI you are supposed to interact with, the first problem that arises is this:
In order to interact with the newly-appeared piece of UI, you need to move the mouse cursor from your current position (on the "parent" element that caused the "child" UI to show up) to the area within the thing that has just popped up. Let's call them parent and child, so you need to move the mouse from the parent to the child. Obviously these have to be adjecent, otherwise on the trajectory you would at some point be on the empty space between parent and child causing the child element to disappear. But the fact is, even if they are adjacent, it is pretty common that a trajectory from parent to child that never falls off of both is pretty narrow. That is, it's easy, when moving the cursor from parent to child, to accidentally fall off of both, causing the child to disappear (roll-out event).
In decent UIs, this is usually solved in two ways that are not mutually exclusively but are usually both used together:
So, you can click on the parent element, and the child will not disappear on rollout, and you can take as clumsy, inaccurate and deviated a trajectory as you want to move the cursor from parent to child, without fear of the child disappearing.
Cinnamon, with the panel icon and multiple-window miniatures, doesn't implement either of these.
I am particularly used to the click trick. I ALWAYS click on the parent thing. In some cases (well-designed UIs) that has the above-mentioned effect of locking the enabled state of the child, allowing me to move to it without having to be particularly careful about the path taken. But even when it doesn't (less brilliant but still decent UIs), it just has no effect. So I move the cursor on the parent element, the child element appears, I instinctly click on the parent element which has no effect whatsoever, and then I can interact with the child element (whether or not clicking on the parent made it easier for me or not).
Now, on cinnamon, the following happens:
Observed behavior
Even worse: every time I do this, I get confused and disoriented, and instinctively I click on the icon again, but this only toggles focus back and forth on the default-chosen window, but never causes the popup miniatures to show up again. The only way to have them to show up again is to move out of the icon and back onto it (rollout-rollover).
Expected behavior
Accepting the overall design, the fact that the miniature windows for selection show up on rollover, and accepting the fact that a click on the parent icon causes one of them (the last focused one) to be given or taken away focus...
Accepting all that, the bare minimum that should happen is:
On the very contrary, ideally it should cause them to stick, and not disappear on rollout but only when you click on something else. But even if you don't want to do that, at the very least, the click should have no effect at all.
This is aggravated by the fact that, on other Desktop environments, you actually have to click on the main icon to have the miniatures show up (they don't show up on rollover), so one has an additional reason to be used to clicking on the icon.
The text was updated successfully, but these errors were encountered: