open-ui icon indicating copy to clipboard operation
open-ui copied to clipboard

[Invokers] Should interest event include what triggered it?

Open lukewarlow opened this issue 2 years ago • 4 comments
trafficstars

Interest is currently triggered by hover, focus, or long press. Should the InterestEvent include what type the trigger was?

https://github.com/openui/open-ui/issues/838 raises an interesting idea where you might want, focus but not necessarily hover. Including the type in the event would provide one mechanism to solve this.

lukewarlow avatar Sep 18 '23 22:09 lukewarlow

Can you provide a concrete use case for wanting to exclude one of the mechanisms of interest? I read the issue and it describes the problem but it doesn't seem to describe a compelling use case, that I can see.

keithamus avatar Sep 19 '23 09:09 keithamus

I can think of cases like that in the example screenshot, where "hover" isn't neccesarily a strong enough of an interest. But a focus would be. Thinking about it though it might be a case of simply adding a delay when hovered vs focused. Having said that idk if that's currently possible either?

Feel free to close this issue for now and we can discuss in the Open UI CG if we need the additional behaviour.

lukewarlow avatar Sep 19 '23 10:09 lukewarlow

It's possible today to set an animation delay. There is also the proposed popover-show-delay & popover-hide-delay.

In the screenshot case (attached for posterity) I remain unconvinced that it shouldn't show on hover. It's useful information for people who are only using a pointer device that might not want to focus on the element.

a screenshot demonstrating a UI for password "strength". The password field is focused and has a popover showing a progress field - coloured orange - indicating that the password entered does not meet sufficient requirements to be a secure password

I'd like to see a more compelling example that is actually actively undesirable rather than representing an existing pattern which is debatable.

keithamus avatar Sep 19 '23 12:09 keithamus

i would find it highly peculiar to have the instructions on how to fill out a form field display on hover. That's really only necessary to show if someone is actively trying to interact with the field. Too much potential for it to just get in the way for someone who isn't using their mouse, but navigating through the page and oh, now that the page scrolled, their mouse cursor is on top of a field they aren't trying to interact with.

But flipping the idea around, focus is not necessarily a strong indication of interest. particularly since navigating through focusable elements is the primary way for people to navigate web pages via keyboard alone.

Take the UI of just this page for instance, there are LOTS of popups due to the repetition of people's names and avatars (among the other items that result in popups). I do not think it can be assumed that someone is 'intrested' in seeing that information just because they're trying to navigate through the UI to reach what they want to interact with.

maybe the answer is just to add a delay. but maybe there is something better that could be done here as well? visual affordance that an element could invoke an 'interest' popup. give the user control on if that popup shows or not and don't assume hovering/focusing is an actual indicator of interest (which is not me saying that there isn't use cases where showing on hover/focus is exactly what should be done... but maybe if we could standardize a way to display descriptive information (we can consistently dismiss it, but not show it / reshow it after dismissal), and indicate a level of interest so that one can make a decision between immediately show vs provide some sort of cue that there is something to show if a user wants to see it but otherwise stay out of their way.

Which then does tie back to maybe that could be tied to the element that triggered it. or maybe it needs to be more overtly declared.

scottaohara avatar Oct 26 '23 15:10 scottaohara