New 13.0d Persistent hover sample content hidden by scrollbar

[Blama]

Hi Isomorphic,

please see this sample (SNAPSHOT_v13.0d_2020-10-15, Chromium 86) and fix the hover for e.g. "showHeader" by pressing "F2" when it's being shown.
The word "true" of "defaultValue: true" is hidden by the vertical scollbar, I'd expect it to be outside the content, if it's needed at all.

Also, I can't select text inside the window, which users surly want to do to copy&paste.

Best regards
Blama

[Isomorphic]

Thanks for the notification. We've made a change which should address this issue
This fix will be available in 13.0d builds dated October 20 and above

Regards
Isomorphic Software

[Blama]

Hi Isomorphic,

thanks, I can see the new behavior in SNAPSHOT_v13.0d_2020-10-20, which is looking good.

Best regards
Blama

[Vivek_Gungabissoon]

Hi,

For this persistent hover sample, we need to press a key (f2 in the demo) to pin the hover. This extra user interaction is an annoyance for making the hover permanent.

Can this pinning action be done when the user moves the mouse over the hover i.e gives it focus and/or clicks inside the hover area?
This reduces the user interaction from a key press to a minimal mouse gesture.

And then once pinned, the hover could also have a small close button on the top right i.e. a small x to close it as well the current behavior of clicking outside of the hover to dismiss it.

I intend to display a listgrid in the hover with hyperlinked cells (which I believe is already possible) and would like to avoid the f2 keypress for pinning the hover.

Thanks,
Vivek

[Isomorphic]

We implemented persistent hovers that are consistent with persistent hovers found in various popular software, such as Eclipse. Far from being an "annoyance" to have to press a key, this is in fact the whole point of the interface: hovers generally disappear, and this gives an option to keep them.

As far as your concept of a persistent hover that is always persistent, that seems like it would be really annoying, with lots of persistent hovers accidentally appearing, and the end user having to dismiss them constantly like a game of whack-a-mole. Is there any popular software that has this behavior which you can point out?

If not, it's not something we'd want to add special support for, but of course you can just use the hover events to create your own concept of "persistent hover" if you like.

[Blama]

Hi Isomorphic,

actually I agree with Vivek_Gungabissoon.
See this video from hovering in Eclipse 2020-06. As you can see, the hover stays for a short time after you move the mouse away from the element that started the hover.
If you move over the hover in this time, the hover persists automatically without the need for a click or a keypress (although F2 additionally also works). You click then outside the hover to dismiss it.
I also think that this UX is better (and always use the hover method and not the F2 method), as you don't need you hand on the keyboard in order to make the hover persistent. And the click to dismiss is easily done with the device you used to show it.

Perhaps you could even auto-dismiss, if the mouse is moved outside the hover again. This then would neither need a click nor a keypress for full hover interaction.

I personally would like the Eclipse behaviour better, as you then don't need to wait for a timer. You could also add the "x" Vivek_Gungabissoon
suggested, but I personally would say that the full Eclipse way fulfils my expectations, because like you say users are used to this.



Best regards
Blama

[Isomorphic]

This is actually a bug. Setting hoverFocusKey was meant to turn on hover persistence, which you are also supposed to be able to enable separately (without a focus key), but there were missed checkins. We're getting it sorted out and we'll post here when it's corrected.

[Blama]

Hi Isomorphic,

I just noticed that the 13.0d SmartClient docs don't use this feature, yet. Here it would clearly help.

Best regards
Blama

[Vivek_Gungabissoon]

Hi,

Sorry for the delayed response. I will be watching this thread for further developments.

@Blama Thanks for the detailed Eclipse post.

The behavior seen from Eclipse and other apps has become quite common. And my users are all pretty much used to that behaviour.
The "x" is really just a suggestion. The underlying idea is to make the interaction with the user as frictionless as possible with the least amount of clicks.

Thanks,
Vivek

[Blama]

Hi Isomorphic,

this bug in 13.0d is still open. In #7 you said it was just missed checkins, so hopefully the fix is easy?

Best regards
Blama

[Blama]

Hi Isomorphic,

just as FYI: Still happening with FF90/GC91 and SNAPSHOT_v13.0d_2021-07-21.

Best regards
Blama

[Blama]

Hi Isomorphic,

this is still happening with FF95 and v13.0p_2022-01-06.

Best regards
Blama

[Isomorphic]

Sorry about the long wait on this one - we've fixed the originating scrollBar-clipping issue here, and we've added mouseOver hover-persistence with a new attribute Canvas.hoverPersist, which is of new enum-type HoverPersistMode - the values are none, underMouse, clickPin and autoPin (same as clickPin, but on mouseOver rather than click).

These initial modes should provide all the variations covered in this thread, except for a permanent pin (with a close button) - for now, if you really wanted to do that, you'd have to manually disassociate isc.Hover.hoverCanvas (eg, stick it in a Window and set it to null on isc.Hover).

Please retest with a build dated January 15 or later.

[Blama]

Hi Isomorphic,

HoverPersistMode is not in the docs, yet (v13.0p_2022-01-15).

Best regards
Blama

[Isomorphic]

Unfortunately, we spotted some niggles with the implementation, which need fixing in the dev branch before we port to 13.0.

Should be corrected and ported today - we'll update here.