| abetts | |
| hein | |
| davidedmundson |
| Plasma |
the 250ms delay before switching tabs on hover makes Kickoff feel slow, and I've actually seen users mistake this for a performance problem (!)
This patch reduces it to 50ms, which is low enough to make switching feel instantaneous, but still high enough to prevent accidental tab switching when moving the mouse diagonally and clipping another button.
Use Kicker and mouse over the tabs. Rejoice that your computer no longer feels like it's walking through molasses!
| No Linters Available |
| No Unit Test Coverage |
Do we have studies from users that did not complain, because they need the delay? I am thinking about touchpad or trackball users, that cannot move as fast a regular mouse.
Since the tabs are immediately below the content area that they affect, I have trouble understanding what possible usability concern would come into play here.
If someone moves their cursor very slowly across tabs and makes the view change multiple times, then... there's no problem at all, just a feeling of lightness and responsiveness.
Can you explain how a user could "need" the delay?
If they accidentally shoot too far, and want to move back without the tabs changing in between.
Why is it a problem if the tabs change when you overshoot the target? Not doing this makes Kickoff feel slow and ponderous.
I didn't say it is a problem. I just asked if we know it isn't a problem for them. There must have been a reason the delay was added in the first place.
It's also worth noting that the way the delay and the animation are currently implemented makes it pretty ugly even in the case of an accidental overshoot. If you do A->B->A in quick succession, the move from B back to A doesn't commence until the animation moving from A to B has finished playing. This can make it feel like Kickoff is running behind and struggling to keep up.
And FWIW, the main reason there's a delay right now is probably as a poor man's implementation of lazy menus. If you're hitting the menu button in the lower-left of the screen and then move the pointer to, say, the third or forth tab, you're likely to graze adjacent tabs in the process. The delay is there to avoid Kickoff switching in that event, to make it feel calmer and more elegant.
The Kicker menu e.g. contains (albeit smarter) code to handle a similar problem. It interprets purely vertical and diagonal mouse pointer moves differently, so that if you move vertically in the menu it will switch categories and open subdialogs immediately, but if you move diagonally into a subdialog there's some delay to avoid grazing adjacent categories switching the subdialog to that category.
I did something similar in Application Dashboard for moves from the filter list to the center grid.
Kickoff needs similar code to distinguish a diagonal move from outside the menu into the menu from horizontal moves inside the window.
I agree with @hein that the reason is probably " a poor man's implementation of lazy menus".
The thing is, it's an inappropriate application of the feature and isn't necessary here. Allow me to put on my Usability Consultant hat and me illustrate why:
Lazy menus are critically important for traditional horizontal menus that have cascading sub-menus. With this pattern, when you move your cursor diagonally to quickly to reach a sub-menu item, it unavoidably has to pass over several other top-level menu items to reach the desired sub-menu item, as illustrated with Kicker and an arrow showing the corsor's path to reach a sub-menu item:
As you can see, without some logic to handle this case, another top-level item would become activated the moment the cursor leaves the current menu area.
But with Kickoff, the user interface is different. Let's look at the same basic task and with an arrow describing the worst-case-scenario cursor movement:
Kickoff does not implement the pattern of horizontal menus with cascading sub-menus. Instead, it has a tabbed UI that renders the "lazy menus" feature inapplicable for the following reasons:
In conclusion, the "lazy menus" pattern only applies to traditional horizontal menus with cascading sub-menus and is inapplicable to Kickoff. Therefore, the long delay that attempts to provide this unneeded feature is itself unneeded.
That second diagram literally has that arrow crossing through the History tab...
I'm not approving something that replaces one bug with a different known bug. Even if it will affect fewer people.
Especially if kicker has some code we can copy paste.
I did once write a generic QML implementation of a triangle menu filter, implementing something like http://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown
https://phabricator.kde.org/P183
The reason I didn't push forward with it was because I found afterwards it didn't solve the bug I was trying to solve, moving the mouse to task manager tooltips, where my mouse is moving outside an area we control. Would cover the kicker/kickoff cases fine. I can revisit that if wanted.
Yes, I drew the arrow that way deliberately to illustrate that it still works okay for the absolute worst case scenario:
Virtually all other use cases will not have the above constraints and the user can be expected to move the cursor straight up.
I just increased the timer to 50ms, and here's a video showing that there isn't a problem:
That said, I agree that a very lenient triangle filter might work better here, so I'm willing to give it a shot.
That sounds like a sane, humane, and re-usable solution!
Nate, you misunderstood my original comment. The problem isn't going from tabs to content, it's going from the panel button to a tab. That's why the delay was likely added (I've never worked much on Kickoff vs. the other menus we ship, but I have vague memories).
Hmm, I'm not sure what the problem is for this case. Why is it a bad thing if the view changes when your mouse moves across the buttons after you open the menu? Isn't that the whole point of making the view change on hover?
I am all for reducing the time but maybe keep some lag to tackle the points already made in the ticket
This patch reduces it to 50ms, which is low enough to make switching feel instantaneous, but still high enough to prevent accidental tab switching when moving the mouse diagonally and clipping another button.
I'm not sure if the patch is working right for me? Contrary to your video, I get this (and I'm sure the pointer speed of regular users is much slower):
@abetts Can you confirm you are okay with how it works in the video above?
@hein I'm a bit surprised that you are accepting the patch then? FWIW, I think the triangle filter should be implemented before this patch, and not the other way round. Optimizing the delay is good, but introducing the usability bug is worse IMO.
Henrik, if you move your cursor that slowly, even a triangle menu filter won't help you. Try such a slow speed with any other sub-menu paradigm. If I move my cursor as slowly as you depict in your video in Kicker or a sub-menu in one of our apps, I get the same effect.
Triangle menu filters are actually accelerators for experts. For decades, I've observed regular users move their cursors in straight horizontal and vertical lines to access sub-menus. They intuitively grasp that they shouldn't pass the cursor over another content area. It's only experts who want to move in quick diagonal lines and whose high-efficiency use cases are enhanced by triangle filters. And it's important to support experts! But we mustn't forget "Simple by default".
FWIW, I'm all for the triangle menu filter, myself. Sadly I lack the technical ability to do it; that kind of back-end algorithmic programming is quite far from my area of expertise. I was kind of hoping that @davidedmindson would revive his old code for it. But for the above-mentioned reasons, I don't think this is a prerequisite.
@ngraham Are you sure the Kicker menu has a triangle filter at all? I don't think it has, making your video a bad example (or am I wrong?). Try comparing with a QWidget based menu, which for me is much easier to operate than Kicker or Kickoff with your patch.
And BTW, I did not deliberately move the mouse slowly. It's a regular speed, and users of trackpoints would move even slower.
I strongly disagree with your notion that "simple by default" means having no filter (or filter-like workaround) for Kickoff. It's exactly the type of user who has trouble in accurate pointing and who is slow who needs the filter most. It's not a feature only for experts. As Kicker does not have the filter, Kickoff is our only option left for those users. If you take that away, they may just drop Plasma.
How about we meet in the middle, and don't hardcode it: https://lxr.kde.org/search?_filestring=&_string=SubMenuPopupDelay
As mentioned in this discussion, both Kicker and Dashboard have triangle filters. Please make sure you review discussions in full before commenting; it doesn't help if comments are made based on wrong assumptions or misinformation. Especially with such a panicky and guilty attitude. It's really frustrating to have put work into making that triangle filter work nice, and then someone with no clue go "it's all bad and users will drop Plasma". Have more respect for your fellow devs.
The use case for a triangle filter in Kicker and Kickoff is also very different. In Kicker it's really needed because if you accidentally graze the wrong category you likely wind up in the wrong subdialog. In Kickoff it's much more likely that the accidental grazing just makes tab switching happen earlier but then the user hits the right tab after and it moves to that.
That's why I mentioned "or am I wrong". At least when comparing Kicker and Kate, it's pretty clear that there's a difference in behaviour, leading to my conclusion. My comment was based on testing what users see, I'm sorry if you misunderstood that as critique on your implementation.
then the user hits the right tab after and it moves to that.
Not sure I understand? My video is about moving from the tab bar to the entries inside the tab, not about moving between tabs.
For the record, here's the triangle filter in Kicker in action:
You can see it both switch immediately on the horizontal move, and not switch as the cursor goes over 4-5 adjacent categories diagonally on the way to K3b.
The values should be roughly similar to QMenu, although the behavior is different (and imho a little bit nicer): In QMenu only the switching of the subdialog is delayed, but the hover effect on the items happens anyway, so it's visually quite busy. You see the blue hover highlight move under your cursor without the dialog changing. The implementation in Kicker simply discards the diagonal events during the move, so not even the hover effect happens (but when the cursor stops during a diagonal move, it will still switch).
Edit: The reason for my strong reaction above is that "argument by guilt" is a big pet peeve of mine. It's impossible to discuss stuff calmly when someone pulls out "if you don't do this, users will stop using Plasma / I will switch to something else". It raises the stakes to panic overdrive mode and/or makes people defensive. Even if you legitimately worry about that, it's there's real value to making sure a dev discussion never reaches that volume level. Something along similar lines is the //Yes, and// way of working ...
Not sure I understand? My video is about moving from the tab bar to the entries inside the tab, not about moving between tabs.
This explains our misunderstanding. The original reason Kickoff had the delay - as also noted in the earlier discussion - is for the move from the panel button to the tab. I didn't realize we had switched topics.
Do you think tab to entry move is a problem in practice? Don't users just move vertically from the tab?
In my experience (observing users working on tasks, and evaluating eyetracking studies) users tend to move towards something they can see, with the intention to click on it later. In the first part of my video the mouse (following the movement of the eyes) moves from the tab to the arrow, and for the second part of the video the mouse moves from the tab to the entry consisting of text and icon.
In particular I'm concerned about the second case.
If it's a problem, then we could hold off on this and I spend some minutes moving Kicker's triangle filter to Kickoff. I suspect David's code may be better and more general, but then he isn't busied up with something this small.
If it's a problem, then we could hold off on this and I spend some minutes moving Kicker's triangle filter to Kickoff.
I suggested exactly that in my original comment. As you seem to know that particular code, I'm sure Nate would appreciate any help.
@ngraham You ok with abandoning this? Then I'll write an alternate patch this week that makes tab switching fast for moves from the panel button or horizontally and more strongly delayed for diagonal moves into the content area.
FWIW, I found the bug report tracking the request that drove this patch, and it was filed by a VDG member:
Could a different approach work here? No change on hover, but just on click? The user controls the entire action.
@abetts This ticket was closed and replaced with a newer patch. Please read up on a discussion before commenting! :)