Open tilsammans opened 8 years ago
Hotspot areas can already have an associated audio file which can either be played via inline player or when the area is clicked. Playing on mousemove should also be possible. On touch devices there would probably need to be a fallback to play on touch. Finally, there would have to be an editor option to activate this behavior for audio hotspots.
Something similar can already now be accomplished by using a hover video. But silly iOS autoplay restrictions prevent it from working on mobile.
What we would really like is to have a Page Link area but with an optional atmo audio, purely for the background. We understand that it won't work on iOS, but for desktop it should be fine. When someone hovers, a small hint of what's to be expected can start playing.
Possible with current software, or easy to add? I would expect there to be a third tab in this editor screen, very much like the existing atmo audio functionality.
Technically that should not be too hard. My main concern is configuration complexity for the user since the page type already now is sort of a swiss knife. So on a conceptual level, there would need to be a proposal that
it takes the different hot spot types into consideration
We would like to add it exclusively to the hotspot type 'page link'. The same options could apply as with a hotspot pagetype where an audio link is added. If there is an atmo audio playing on hover, it can be muted, keep on playing or keep on playing at a lower volume. So that menu could remain the same I figure?
integrates with the existing atmo functionality including the existing options to turn down or pause the atmo when a audio hotspot is playing
Yes, see up
takes the different hover image/video variants into account
In case an atmo audio-file is added to a pagelink hotspot area, then this overrides the audio from the hover or panorama video (like an audio-link in a hotspot page does).
Does this makes sense to you as a proposal? We would love to get it working since in our view it adds significant persuasive suspense and playful anticipation to the story, so the hasty web user actually wants to stay with the production and click on the stories.
That sound's reasonable. So I think the following things would need to be done:
input
for an atmo_audio_file_id
attribute to the EditAreaView
that is only visible when target type is "page"
data-audio-file
attribute can even be reused with an additional attribute indicating play-on-hover
is active.mouseenter
/mouseleave
if the play-on-hover
attribute is present such that the audio players controller can take care of fading to the passed audio file. That way we can use the existing fade-atmo-integration etc.This is a pretty rough outline and maybe I'm missing important issues. But it should at least help to give you some pointers into the code.
Last of all it would be really really great if we could get the (embarrassingly small) test suite to run on Travis. For that I'll need to publish the pageflow-support
gem, which at the moment is linked via path
in the Gemfile
. If you point it to the spec/support
directory of your pageflow
checkout, it should work, though.
We've been working with this awesome plugin. It opens up a ton of possibilities for Pageflow stories.
Is it possible/easy to add an atmo audio for each individual area? In some cases we would like background audio to start playing on hover.
It seems all the building blocks are there in principe, it's just a matter of wiring them together?