As a final step for each skills assignment, students will perform a task while explaining what steps they’re performing and why they’re performing them. Such self-explanation activities have been found to be a beneficial learning technique. Furthermore, performing the target type of task for a third time will further help students gain the benefits of practice effects.
In the video recording, you must do the following:
The video recordings you make must meet the following requirements:
There are two good ways that we know of to produce these videos using software that is freely available to you. Here are some instructions for each:
Additionally, there are non-free options you are welcome to try as well, like Camtasia, but that is up to you.
To submit your explanation video, follow these steps:
Upload to YouTube. Upload your video to YouTube, and set its visibility to “unlisted”. Be aware that YouTube accepts only certain video formats (although they’re generally the most common ones), so you’ll want to make sure your recording has a compatible encoding.
Submit Video URL via Dropbox. Paste the YouTube URL of the video into the appropriate eCourseware dropbox.
Explanation videos are graded as pass/fail. An explanation video may be graded as a fail if any of the following are true.
✖ Task done wrong. There must not be significant errors in the performance of the task, and the steps performed must not deviate significantly from the prescribed way of doing things.
✖ Missing or wrong explanations. There must not be significant errors in what the speaker says, and things must not be under-explained.
✖ Missing or wrong general steps. There must not be any significant omissions or errors in the mentioning of the general steps from the demos as the task is performed.
✖ Over the time limit. A maximum length for each explanation-video assignment will be specified, and you must complete the task in under that time limit. Note that there is no minimum length for videos—that is, they may be shorter than the time limit.
✖ Multiple takes or video edits. The video of your task performance must be done in a single take, without breaks or any sort of editing. If you experience a mistake or interruption that would cause the session to exceed the time limit, you must start the task and the video over.
✖ Poor audio/video quality. The video must be of sufficiently high quality that everything can be seen clearly, and the audio must be clear such that the speaker can be easily understood.
✖ Reading from a script. You must not read directly from notes or a script when talking aloud during the task. At the least, you would have to memorize such a script, but you really should have sufficient mastery of the material that you can simply draw from your own knowledge/understanding as you speak.
✖ Using a Secondary Monitor. Your computer may have multiple monitors, and your recording may only capture one of them. That’s fine, but be sure not to use the monitors not being recorded during the demo. For example, students may be tempted to read from a script on a secondary monitor, while they record the activity on a different monitor. If we suspect something like that is happening, the explanation video will receive failing marks.
Additionally, keep the following in mind as you create your videos:
✔ Limited, deliberate copy/pasting is OK. As you perform the task, some copying and pasting from the demos is allowed; however, any code you paste you must fully explain.
✔ Rough edges are OK. Your performance in the video doesn’t have to be perfect in order to pass. For example, some making and debugging of mistakes is fine. Also, making a small number of minor mistakes in your explanations would likely pass as well.
✔ Some “Test It!” steps may be skipped. Although you should always show that the functionality you create in your video works by running it, you need not perform every “Test It!” step in a demo. That said, the final version of the code definitely must be run and tested, and I strongly recommend some intermediate running and testing of the code as you write it to ensure that you haven’t introduced any bugs along the way.