We currently always display the video button if we have accompanied video content to a slide set. However, often it is the case that one adds an additional slide here and there without recording a complete new video to go along. Use-cases, e.g., think addition of quizzes, literature, home work like reading etc. in existing slide sets. In these cases the button is still shown but will restart the video from the very start, which is a severe usability problem since the users reading the slides are then lost and have to navigate back to the slide they were before pressing the video button. This navigation is possible using our internal menu if they know the title/ID of there last read, which might be tricky, and - depending on our yaml settings - the browser's back button doesn't do the trick since it might throw users to the index page. Hence, there a four general options in case of late content additions imho:
Disable the button if the slide ID is missing in the *-times.json
Add an additional entry in the *-times.json pointing to the slide just after the new on
Add an additional entry in the *-times.json pointing to the slide just before the new on
Add an additional entry in the *-times.json pointing to a new video content just showing this slide and sliced into the existing one for 10 seconds so.
Option 1. is straight forward and possibly the quick way to go. Specifically option 4 also has its benefits but needs a lot of new logic behind, e.g., updating the *-times.json from the point of entry and including the 10s offset for all slides to come and creating an artificial video using, e.g., ffmpeg (maybe with some generic audio stating the missing explanation). While 1. looks straight forward, it - as with options 2. and 3. - comes with the problem in the use-case that students work through the content first by watching the videos. Here, we might have students miss these new slides completely (bad in any case but specifically if these new slides define homework). In that use-case, I guess only option 4. does the trick kind of completely. However, that is up to decide on the severeness of the stated problem and the costs for implementing 4.
monofon
commented
1 year ago
We currently always display the video button if we have accompanied video content to a slide set. However, often it is the case that one adds an additional slide here and there without recording a complete new video to go along. Use-cases, e.g., think addition of quizzes, literature, home work like reading etc. in existing slide sets. In these cases the button is still shown but will restart the video from the very start, which is a severe usability problem since the users reading the slides are then lost and have to navigate back to the slide they were before pressing the video button. This navigation is possible using our internal menu if they know the title/ID of there last read, which might be tricky, and - depending on our yaml settings - the browser's back button doesn't do the trick since it might throw users to the index page. Hence, there a four general options in case of late content additions imho:
Option 1. is straight forward and possibly the quick way to go. Specifically option 4 also has its benefits but needs a lot of new logic behind, e.g., updating the *-times.json from the point of entry and including the 10s offset for all slides to come and creating an artificial video using, e.g.,
ffmpeg(maybe with some generic audio stating the missing explanation). While 1. looks straight forward, it - as with options 2. and 3. - comes with the problem in the use-case that students work through the content first by watching the videos. Here, we might have students miss these new slides completely (bad in any case but specifically if these new slides define homework). In that use-case, I guess only option 4. does the trick kind of completely. However, that is up to decide on the severeness of the stated problem and the costs for implementing 4.