Page MenuHomePhabricator

Implement a way to display tooltips (using PopupWidget) on hover/focus rather than on click
Open, NormalPublic

Description

Here are a few examples of where they've been used:

Small ------------------------------------



Large ------------------------------------


Related Objects

Event Timeline

violetto raised the priority of this task from to Needs Triage.
violetto updated the task description. (Show Details)
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 5 2015, 12:15 AM
violetto updated the task description. (Show Details)Feb 5 2015, 12:18 AM
violetto set Security to None.

Hover seems to make sense for things like this as long as we also support click (for touch enabled devices)

How/Is this different from Tipsy? (functionally)

I'm removing F37375 from the description because it is a tipsy.

Tipsy-ies are non-interactive. You cannot move your cursor into the tipsy. It moves where your cursor points. They're used as supporting description / info to an element.

PopupButtonWidget in comparison is interactive. It may contain links that user can interact with.

violetto renamed this task from PopupButtonWidget (frameless, with popup head)‎ shows at hover instead of onClick? to PopupButtonWidget should be shown at hover not on-click. .Mar 7 2015, 3:06 AM
violetto assigned this task to Prtksxna.
violetto updated the task description. (Show Details)

Another aspect to take into account is we support hover to show/hide those is to be careful not to accidentally hide them while the user is moving the cursor to interact with them. That is, make sure to provide a safe channel (active area, delay in time, etc.) between the trigger an the popup that makes sure it does not close when the user moves from one to the other.

@Pginer-WMF do you have a screenshot for example?

@violetto it was a generic concern, similar to the one in the "hover tunnels" section about this article on hover menus.
For example, with Hovercards, if you move your cursor too slow through the red area I added in the mockup below, the card will close before you are able to reach it.

This is not a big concern for hovercards since (a) you don't need to click the card (you can just click the link your cursor was over), and (b) the timer for closing the hover card leaves enough time for you to reach the card (you need to move the cursor really slow).

However, for other uses we may want to consider additional mechanisms such as making the red area I illustrated to be an invisible part of the card so that moving in that area counts as hovering the card and does not hide it.

violetto updated the task description. (Show Details)Mar 10 2015, 5:41 PM
violetto updated the task description. (Show Details)Mar 10 2015, 5:45 PM
Jaredzimmerman-WMF moved this task from Triaged to In Development on the Design board.

To add to what @Pginer-WMF said — even when Hovercards did not have any actions on the Popup itself, people wanted to be able to tweak the delay times. There are two delay times—

  1. After hovering for how long should the popup show up. You don't want to see popups showing and hiding in bursts as you move your mouse across the screen.
  2. After removing the mouse from the link, in how long should the popup disappear. This is the window of time when the user can try to jump the mouse to the card itself (keeping it open).

Deciding these values for everyone is a pain. We tweaked it a couple of times for Hovercards and then ended up letting editors change it themselves from their common.js.

I personally prefer click actions for opening UI elements that I'll need to interact with, like — menus, drop-downs etc; and a hover action for tooltip type things. So, I'd prefer to see a PopupButtonWidget only when I click.

Prtksxna removed Prtksxna as the assignee of this task.May 1 2015, 11:37 AM

Feel free to re-assign once we come to a resolution.

Change 231547 had a related patch set uploaded (by Prtksxna):
PopupButtonWidget: Add hoverAction config to show popup on hover

https://gerrit.wikimedia.org/r/231547


click



hover



this comes after user finishes an action, so it's more like a notification, neither click or hover.


I'm on the fence about this whether this should be hover or on-click. I see this having two options: Either have a slight delay on hover to reveal the popup, or make it so it's on click.

If we make it on hover with a reasonable amount of delay, I'd prefer we use it sparingly, which I don't think has been an issue. I looked around Wikipedia for examples but it was quite hard to find some, with exception of hover cards. For me, the advantages is that this is a small target for a potentially important information.

Just like tooltips, triggered by mouse hover, they carry supporting info that are potentially important. Granted, tooltips' use case is different and so is hovercards. Users get hovercards from in-line links that are littered everywhere within an article. I can understand if it gets frustrating especially when your mouse is wandering across the page.

Here's an example at the top of my head why clicking on each icon is more work for something so small that carry helpful info for users:
https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-echo

Here's a proposal, do you have time to make a prototype? Perhaps with the same execution within Special:Preferences. If you can make me a prototype, I can find the users to try this out. I hear your point, and will be happy to follow what our users think feels best.

I share the same concerns about the small hover tunnels. We can give the illusion of a larger surface area with a bigger tapping space like indicated in yellow in the photo below. Moving the tipsy closer to the text/icon/target wouldn't be a bad idea.

I'm on the fence about this whether this should be hover or on-click.

For now, I am working on making it a config option, so that we can use the same widget for both use cases.

Here's a proposal, do you have time to make a prototype?

I am not sure if the patch will get merged, but testing this with different settings shouldn't be to much of a problem.

Jdforrester-WMF moved this task from Backlog to Doing on the OOUI board.Aug 26 2015, 1:39 AM

For now, I am working on making it a config option, so that we can use the same widget for both use cases.

I think having both is going to be more confusing than picking one as we will end up with inconsistent behaviour between interfaces. I think we should stick with avoiding hover functionality.

Change 231547 abandoned by Prtksxna:
PopupButtonWidget: Add hoverAction config to show popup on hover

Reason:
As per discussion on T88630

https://gerrit.wikimedia.org/r/231547

matmarex renamed this task from PopupButtonWidget should be shown at hover not on-click. to Implement a way to display tooltips (using PopupWidget) on hover/focus rather than on click.Oct 15 2015, 6:14 PM
matmarex removed a project: Patch-For-Review.
matmarex added a subscriber: TheDJ.

This will be useful for T116086, T118709 and similar use cases. Not that this is the only solution. We could have a sub-label that always shows part of the help text.

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptNov 17 2015, 8:41 AM
Jdforrester-WMF triaged this task as Normal priority.Mar 2 2016, 2:02 AM
Jdforrester-WMF moved this task from Doing to Next-up on the OOUI board.
Danny_B moved this task from Unsorted to OOUI on the UI-Standardization board.May 20 2016, 8:59 PM
Volker_E moved this task from In Development to Incoming on the Design board.Jan 5 2017, 5:00 PM
phuedx removed a subscriber: phuedx.Mar 26 2017, 4:52 AM

To add to what @Pginer-WMF said — even when Hovercards did not have any actions on the Popup itself, people wanted to be able to tweak the delay times. There are two delay times—

  1. After hovering for how long should the popup show up. You don't want to see popups showing and hiding in bursts as you move your mouse across the screen.

That's where hoverIntent (vanilla JS version) could come in handy. From my experience it's a great addition to make the interface more easy-going for users.

For now, I am working on making it a config option, so that we can use the same widget for both use cases.

I think having both is going to be more confusing than picking one as we will end up with inconsistent behaviour between interfaces. I think we should stick with avoiding hover functionality.

As @matmarex points out in T117720: Remove use of jquery.tipsy from Wikimedia-maintained code, and @Perhelion in T147243: mw tooltip gadget/widget/plugin is needed, we really do need some way to do this in OOUI. Do you think it'd be better off as a separate widget then?

Krinkle removed a subscriber: Krinkle.Sep 20 2017, 3:15 PM