Interactive video - Add interaction at 1/10 second precision

Hello,

I use interactive video when teaching English learners. These videos contain conversations, and I pause it to ask questions about what was said. When set the interaction display time, we have a precision of seconds, but in order to pause a conversation at the right moment, there is need of 1/10 of a second. For example, set the display time to 23.4 seconds, etc.

Also, it seems that the summary display time cannot be set to zero (I have got an error). It will be usefull to allow to display the summary right at the end of the video.

Thanks,
Oren

Content types: 
0
0
Supporter votes Members of the Supporter Network can vote for feature requests. When the supporter network has generated sufficient funding for the top voted feature request it will normally be implemented and released. More about the H5P Supporter Network
falcon's picture

Thank you for reporting! I've seen this request before, and I've experienced how this may be useful. Hopefully someone in the community will take on this task. If not I might add it to a sprint for the H5P Core team, but they are quite busy at the moment with other great improvements that are coming up :)

I'm looking forward to see the next release!

I noticed that there's a pull request for this very issue from about a year ago: https://github.com/h5p/h5p-interactive-video/pull/12

Any chance this will be integrated into the official IV release any time soon? 

 

stopbit's picture

It's a Shame, our developer worked on this project to improve the accuracy of start/stop timing in the interactive videos.

It was very tricky! and doesn't quite do 1/10 timing, it's more like 1/4 of a second timing. We've sinced moved on due to it not being adopted.

I'm also concerned other work we are putting in may not be accepted either. We are going to start work on improving the social shares feature in Course Presentation next. However if it doesn't get accepted and adopted by the H5P team, there may not be much point in contributing further. We are a business and don't want to waste productivity time.

 

tim's picture

Hi stopbit, 
I understand your frustration. The core team has been quite poor at getting all the pull requests in and some may have slipped through the cracks. 

After this release we are going to try and clear the backlog of all the pull requests we have and merge as many of them in as possible. 

In the meantime, I would recommend that you try to keep in close contact when developing the feature so that it's 'on our radar'. I understand that business time is precious and I hope that you will continue contributing.

Thanks,

Tim

falcon's picture

I'm very sorry about this stopbit. We're working on how to handle feature requests for code maintained by Joubel like Interactive Video. Pull requests are obviously extremely valuable contributions. We want to make the process efficient for both the contributor and us. We're perhaps spending more time testing and reviewing a pull request than the average open source maintainer. We would ideally want a way to pre-qualify them. So qualify two things - (1) is it a feature we want to add and (2) how do we want to add it. If contributors pre-qualify we could for instance promise what release the pull request would go into.

In the fraction of seconds case it was definitively a feature we wanted to add. I did have a look at it when it came and I probably should have left a comment. I was worried that testing would reveal that we needed to rewrite the entire show-hide logic for devices with slow processors and videos with lots of interactions. The current logic is far from ideal. The pull request would use the same logic ten times as often, potentially making matters even worse. We saw it as a time-consuming pull request to handle and it never made the cut for the last ~10 releases :/ We should have communicated this.

It's definitively a shame. Even worse if it makes you not contribute more features.

What if we did this for all feature requests from now of:

  1. Create a pull request routines page on H5P.org stating that in order to "guarantee" that a pull request goes through quickly we urge developers to first raise an issue on GitHub explaining what feature they want to add and how they want to add it both technically, UX wise and accessibility wise, and get it accepted by a maintainer.
  2. When we receive a pull request on an accepted issue we expedite the reviewing of that issue.
  3. When we receive pull requests that isn't pre-qualified we will link to the pull request routines page and inform the contributor instantly whether or not we think the need for the feature is big enough for us to consider it and if the solution looks promising.

The goal is to save time both for maintainers and contributors and make sure that the best pull requests are being handled quickly. What do you think?

Alternatively, we could do something like this for Joubel content types. Other maintainers may have other philosophies. If any pull requests that works are added you make a lot of people happy (but you might end up with a lot of trouble in the long run from technical debt, too many settings etc). Maintainers may also choose to let others in the community test and review pull requests to speed things up (but it means that it is reviewed by people who aren't necessarily well-informed about the system design, architecture and future plans of the content type)

stopbit's picture

Hi Falcon / Tim

I'm pleased to see such speedy responses on the forums from you guys, I appreciate it.

I understand the points you're raising regarding new features, pull request process etc. What you've outlined seems like a good way to implement a control system for changes.

Have you checked the system Moodle use? A member of our team recently created a plugin for Moodle to Export Lessons to PDF & Epub formats - a long over-due feature, which was bizzarely missing from Moodle core given the years of demand for it.

The process was surprisingly easy, in-fact the plugin was accepted and published within 24 hours and updates were made by the maintainer Adam King, immediately upon comment suggestions from moderators and users.

The notification process was first picked-up by a bot, which reported to the new plugins moderator.

Right now I know Adam is looking at H5P Course Presentation code with an aim to include more features for social sharing - Please check here: https://h5p.org/comment/10425 . For the time being, how would you advise in proceeding regarding this particular project, given the situation you describe.

We'll continue to contribute, so long as we feel we're being listened to - But no communication or lack of indications of progress will certainly put off contributers. You guys are great on the forums, I hope you can mirror this in terms of development comms too :-D

Many Thanks!

falcon's picture

Hi stopbit,

The H5P Core Team has had a meeting on this now and decided to go ahead with the suggestion. We've created the following guide for pull requests. Does it seem clear and fair? We've also added more resources to handling future GitHub community activity so prequalification issues will get concrete feedback normally within a day and the pull request itself will get an eta normally within a day after receiving it given that it is prequalified. Might also get handled right away.

Maybe you could try out this procedure with the social sharing features for Course Presentation? Do note that we have considered Facebook sharing, but it was hard to find a way of doing it at that time because of limitations in the Facebook API. The site needed a Facebook App key or something I believe. A technical solution should explain how issues like app keys can be handled in shareable H5P content if Facebook sharing is planned.

Also, do note that you may share H5P content types yourself and apply for developer access. If you do you have your own H5P content type and can update it as much and as often as you want, and you decide how you want to handle feature and pull requests for your content type. You may also create more content types and share them instantly without a second review process. I guess this might be similar to the Moodle process for Export Lessons to PDF & Epub. We'll try to speed up reviews of the applications as well. So far the applications for full developer access have been very rare but hopefully, we'll get a lot more.

stopbit's picture

Hi Falcon,

Thank you for getting back to me. Adam King has finished his work on the social sharing and is just in the middle of tidying up code etc.

I will request Adam runs through the process described, but the features have already been added for Facebook, Twitter and Google sharing for Course Presentation.

I'm sure Adam will describe his methods better than I can. Adam is also wanting an App ID for facebook for H5P use - could we get one, it should take a few mins for your team to setup.

Many Thanks

Hey Falcon,

Following on from that, I can see an existing App ID in the code so I'm not sure how far along you got with the Facebook API implementation although obviously I cannot create an ID for you; I've had to resort to using the slightly obsolete sharer.php provided at https://facebook.com/sharer/sharer.php alongside some querystrings for the parameters. Given an App ID I could bring that part of the modification up to date and begin creating an issue on Github. 

It's a simple addition but leaving sharing exclusively for Twitter seems a little lacking and I'm more than happy to maintain the rest. Strings that I've added to the localization only have English translations at the moment as I don't have accurate access to other languages although I'm optimistic either the core team or the community are able to source these easily as they're short and scarce. 

Thank you for reviewing the pull request process as open-source projects do benefit greatly from community contributions and I look forward to putting it to the test with my two cents!

Many thanks.

falcon's picture

Hi @stopbit,

The process is well underway in this GitHub issue. It seems we might not need a Facebook App ID after all.

stopbit's picture

Hi Falcon,

Yes, it seems Adam discovered an App ID may not be needed and the legacy facebook sharer is likely to continue to be supported by facebook.

Very excited to see this in development, it's looking good so far.

 

otacke's picture

Both thumbs up for your openness!

falcon's picture

This seems to be a duplicate of this issue

roblespar's picture

Increasing the timing precision of videos will have a positive influence on using H5P in video post production. The more one can put digital assets into the code layer on top of the video, the easier it will be to update the video with new overlays, interactions and references. It won't replace the green screen but it will make videos easier for teachers to use in shorter video segments that require precise rapid changes for animations.