I'm working on the development of some massively on-line education material (whether massively online open courseware is a good thing is a different question, but if it is going to happen, we might as well try to get in early and do it well
). I'm creating content for an entire materials science undergraduate curriculum. The most important part of the content involves computation, visualization, and problem-solving. The students build up a solution by solving a set of sub-problems and then incorporate all of the solutions into something that is meaningful, and hopefully, satisfying to them. Because the solutions to the subproblems are interdependent, I have to provide a mechanism for showing a solution and allow them to proceed to the end of the lesson. If I just provide the solution carte blanche, the student doesn't get the benefit and satisfaction of solving it themselves. Thus, there are two competing factors: 1) force the students to struggle a bit and learn by doing so, 2) provide content that permits them to get to the end and hopefully recognize the beauty of completing a complicated problem.
I've rolled out some of this content in the form of "master classes on materials science problem solving" and have had a chance to observe how students interact with the content. (these are the observations that lead to the monstrosity of code that is posted above
). Here is the crononlogy:
(1) In my first iteration, I asked them to solve a subproblem and then provided the solution in a closed group. Students now are used to being fed immediate content and as soon as the problems became challenging, they would just open the content and accept it as "the solution". The opportunity to teach by doing was a lost.
(2) In my second iteration, I attempted to create some small barrier to "just clicking and not thinking". I ask them to work out a subproblem, and I put my solutions into a separate .m file. Each of the files was encoded---the students had to go find the encryption key to display the solution. Initially, the solutions appeared in the content notebook, but I evolved to having each subproblem's solution appear in a separate notebook. This would allow easy comparison between their solution and mine. Here is what happened, with the entire solution dumped onto the screen and they weren't paying much attention to the content and solution development. They were trying their own solutions, but they weren't getting the full benefit of learning my solutions.
(3) Third iteration: In an attempt to have the students read and follow the logic of a developed solution, I had each substep of the solution appear in a dialog with a button. Clicking the button dumped that substep into a developing notebook. This worked better, but I found a fraction of students would just look for the button and not the solution. I had to find a way to slow them down.
(4) Thus, the fourth iteration is what you see here
. I'll adopt John's solution to put up signposts (think Burma shave). I'll also need to adapt John's previous solution
to this pause technique for material that contains evaluatable expressions.