If they did the exact opposite of this, I think it would look ok. If I was trying to fix this, I would probably just swap the styles of the selected and deselected states. Maybe it’s a miscommunication between designers and implementers, causing the meanings to be swapped?
I don’t think it is that simple. I think that outline is about the “focus”. So if I press enter it will activate that tab, if I press tab it will move the focus to the “Entire Screen” tab.
The UX issue is that there are two concepts of focus in this UI. There is “which tab is active” and “what UI element will pressing enter activate”. These two are not sufficiently differentiated which leads to a confusing experience.
Or maybe there can just be no keyboard focus indicator by default, but that may be annoying for keyboard power users. But this is generally how it works on the web, you have to press tab once to move keyboard focus to the first interactive element.
Right, that makes sense as well. What I was thinking is that the use of the accent colour shows which one is active, though it would probably be less confusing if this wasn’t done with an outline. See the KDE version for example:
Regarding keyboard navigation, I could see this working similarly to radio buttons, where the tab key selects the entire tab group, and tabs need to be navigated using the arrow keys. In this case I think it makes sense to put the focus border around only the selected option, and having the focus border follow the selected option when arrow keys are used. If this is the case, I think swapping the current version does make sense.
If they did the exact opposite of this, I think it would look ok. If I was trying to fix this, I would probably just swap the styles of the selected and deselected states. Maybe it’s a miscommunication between designers and implementers, causing the meanings to be swapped?
I don’t think it is that simple. I think that outline is about the “focus”. So if I press enter it will activate that tab, if I press tab it will move the focus to the “Entire Screen” tab.
The UX issue is that there are two concepts of focus in this UI. There is “which tab is active” and “what UI element will pressing enter activate”. These two are not sufficiently differentiated which leads to a confusing experience.
Or maybe there can just be no keyboard focus indicator by default, but that may be annoying for keyboard power users. But this is generally how it works on the web, you have to press tab once to move keyboard focus to the first interactive element.
Right, that makes sense as well. What I was thinking is that the use of the accent colour shows which one is active, though it would probably be less confusing if this wasn’t done with an outline. See the KDE version for example:
Regarding keyboard navigation, I could see this working similarly to radio buttons, where the tab key selects the entire tab group, and tabs need to be navigated using the arrow keys. In this case I think it makes sense to put the focus border around only the selected option, and having the focus border follow the selected option when arrow keys are used. If this is the case, I think swapping the current version does make sense.
Yeah. I like old school tabs that were clearly attached to the thing that they switched. I definitely prefer the KDE UX here.
Sadly KDE is also trying out the “modern” style tabs in some places too: