search

jplayer / jPlayer

jPlayer : HTML5 Audio & Video for jQuery
http://jplayer.org/
Other
4.6k stars 1.47k forks source link

Hover behavior should override jPlayer controls autohide #123

Closed tim-peterson closed 11 years ago

tim-peterson commented 11 years ago

I'd like to raise an issue first mentioned in a Jan 2012 post on jPlayer's Google group.

Users are use to the hover behavior of Youtube, Netflix, Apple, etc. whereby the controls are visible when you hover over them but then fadeOut() when you hover off of them.

Unfortunately, jPlayer has an autohide behavior which doesn't take into account where the mouse is and automatically hides the controls (sets display:none on className .jp-gui) after a period of time specified by the developer.

I suggest the autohide option fadesOut the controls on mouseleave rather on a time interval which doesn't take into account user behavior. This seems to be a simple fix but is hugely important from a UX perspective.

happyworm commented 11 years ago

The problem with using hover is that as the web moves to mobile devices is that there is no hover. I agree that I would need to investigate this a little further but consider the following...

We plan to add the common user control of clicking the video to play it and pause it.

On a tablet device, a user touches the actual GUI to play the video and then touches the full screen button. The video goes full screen, but full screen button still thinks it is being hovered over. You can see this will the CSS highlighting in current skins. The GUI would then remain visible...

To try and hide the GUI, they would touch the video, as it is full screen. This then hides the GUI, but pauses the video through the other mechanism. The user then needs to touch the video again to play it. This touch would cause the GUI to display again and then auto-hide a few seconds afterwards.

Yes there could be options, and yes there could be platform sniffing, but I would have to think long and hard before adding this one.

Thank you for the feedback.

tim-peterson commented 11 years ago

@happyworm thanks for the discussion, yes it seems like a hard problem. Perhaps it could be as simple as having click handling be the default but adding hover handling on top of that if one is not on a mobile device? And then perhaps instead of platform sniffing a simple window.innerWidth<768 could be the cutoff point for adding this hover behavior?

Making sure the controls still have decent behavior on fullScreen mode (which is probably more of a CSS issue) is also something to keep in mind.

Anyway, just some ideas...