Suggestion to make "make glossary" less obtrusive

[tobifjellner]

The new ​https://wordpress.org/plugins/wporg-glossary/ is a good idea.
However, if a page on make has many matches against the glossary, it may become hard to handle the page: whenever you move the pointer over the page you almost always happen to pass over some explained term (that you almost always know very well...) and ... poff a popup blows up and you have to wait a bit before you can continue what you were doing.

Suggestion: Make the popups trigger on click and not on hover.

I've suggested the same in ​https://wordpress.org/support/topic/could-it-be-a-bit-less-obtrusive/ I just don't know where is the best place for this.

[garrett-eclipse]

Thought: If hover is too fast and click isn't desired there's always hover-intent.

[dd32]

We had considered using click, in combination with a few other things for accessibility, but ultimately had ruled out using click for a few different reasons that I'm not going to go into right now.

Using hoverintent style approach however makes a lot of sense here, and will mostly avoid unintentional expansions.

If there's any pages which are showing the glossary definitions particularly badly, I'd appreciate it being linked here for reference so it can be taken into account. Some glossary items have been removed if they're not as useful as could be.

[tobifjellner]

If there's any pages which are showing the glossary definitions particularly badly,
I'd appreciate it being linked here for reference so it can be taken into account.
Some glossary items have been removed if they're not as useful as could be.

@dd32 The pre-existing Polyglots glossary has some quite long "explanations", if several of them happen to match a in page, then there may be several dangerous spots in a post, where I need to, say, mark some checkboxes... See, for instance, ​https://make.wordpress.org/polyglots/2019/06/11/clpte-request-woobewoo-plugins/

[garrett-eclipse]

One other thing to note with the post @tobifjellner pointed out, along with the quick to popup it takes a long time to go away so you either need to click away or wait to read the content that gets hidden behind the post. When a user desires to read the content they usually stay on the word or in the tooltip so leaving the hover area might be improved by dismissing a little faster.

[tellyworth]

@talldanwp suggested ​https://github.com/tristen/hoverintent as a possible candidate for implementing this.

[SergeyBiryukov]

Replying to tellyworth:

@talldanwp suggested ​https://github.com/tristen/hoverintent as a possible candidate for implementing this.

Since Make blogs appear to include jQuery, can't we just use core's bundled hoverIntent.js?

[tellyworth]

hoverIntent is a little tricky to hook into tippyjs. As a compromise for now I've tweaked the delay parameter, to add a delay before hovering and decrease the delay before hiding. It's not ideal but seems an improvement.

[garrett-eclipse]

Patch for the wporg-glossary plugin to switch tippy to click and use hoverintent to trigger the click

[garrett-eclipse]

Thanks @tellyworth

Playing around with this via inspect I found switching tippy to click and then triggering the click action on hoverIntent works nicely. I didn't find the code in meta SVN so pulled the plugin SVN to make the 4508.diff patch, not sure if that's the right approach?

I also dropped the delay as hoverIntent basically has it's own delay.

Please give it a test and let me know how you feel.

[tellyworth]

I couldn't say for sure it's the best way, but it's definitely better than what we had, thanks!

Committed in ​https://plugins.trac.wordpress.org/changeset/2267928 and deployed.

Is the solution good enough that we can close this ticket?

[garrett-eclipse]

Thanks @tellyworth that's working very well, thanks for committing. Going to close as I think that's the best solution we're going to get. Cheers

[ocean90]

In ​https://plugins.trac.wordpress.org/changeset/2267928, hoverIntent wasn't added as a script dependency causing now a Uncaught TypeError: $(...).hoverIntent is not a function error which currently breaks the tooltips. hoverIntent should be added as dependency, or better, make it work with hoverintent-js.

Related: ​[WP46872]

[ocean90]

#5219 was marked as a duplicate.

[dd32]

Added the jQuery hoverIntent requirement: ​https://plugins.trac.wordpress.org/changeset/2307616

Ditched the jQuery hoverIntent for the JS-only variant: ​https://plugins.trac.wordpress.org/changeset/2307628
That allows for selecting text within the glossary item again (Previously, hoverIntent was hiding the item as soon as the mouse left the anchor)

Bumped version and WP requirement to 5.3.1: ​https://plugins.trac.wordpress.org/changeset/2307629

Deployed, everything seems to be working to me.