Yesterday (9/20/2014) we held our first ScriptEd year two session and did the scavenger hunt activity.
I made the following PRs to the curriculum based on our experience, which are pretty straightforward changes:
However, there are also some other issues whose solutions are less straightforward, which I will mention below.
JSBin vs. Cloud9
There was a lot of confusion regarding whether to use JSBin or Cloud9 for the exercises. At first we wanted learners to use Cloud9 so that they could save each exercise in a separate file, which would allow us to easily go back later and review in detail what learners were doing. However, because each clue in a section built upon the clue before it, this naturally made students want to just use the same file for each section--for instance, at the very beginning it's easier to just modify hello.html to get to clue 2 rather than making a new headBody.html file from scratch (or even copying/pasting the text). This was particularly pronounced in the MySite clue, where many students just wanted to reuse their existing code from MyFirstWebsite, and we didn't know whether to tell them to edit MySite in-place, or make a copy of its whole folder structure called MyFirstWebsite. The confusion slowed things down, so being explicit would help.
One possibility may be to make a github repo that contains a bare-bones skeleton of each file/folder, which the learners clone in Cloud9. Some of the files could even be completely empty; their mere existence could help resolve some of the aforementioned ambiguities. We'd also then have quick access to all their forks, which would be nice for later review.
However, another problem we ran into was the JS challenges, which were confusing to do in Cloud9 because of the apparent lack of a console, so we had the students switch to JSBin at that point. (We also weren't very experienced with Cloud9 ourselves, so this may have been due to our own lack of expertise.) Of course, by switching to JSBin, it was then a hassle for the students to share out their work.
roman.js is way too hard
I don't think any students made it through the final clue of the JS Variables challenge, which was to create a program that could convert any integer from 1-1000 into a roman numeral. We agreed to make this a bonus/homework problem that students could work on between now and the next class, which we'll email them about soon.
Incentive structure issues
Because the activity was framed as a race between students, one of the mentors suggested students skip hard problems in favor of easier ones, as a way to maximize point scores (and also do better on godforsaken standardized tests).
The assumption was that we would have time at the end of the competition to go over the problems that many students may have skipped, such as the @media challenge (media selectors were not taught in year 1 ScriptEd so few, if any, students knew them). However, we didn't actually end up reviewing anything at the end of the class, so valuable learning opportunities may have been lost (though we could also potentially review some of these things next class, or asynchronously via email).
It might be useful to make some kind of recommendation for how to deal with this in the curriculum. We also ended up offering points for taking fun breaks (by getting the students to pose in the photobooth).
Finally, we also added some preconditions for receiving points to ensure that both members of a pair programming team were learning: we often asked both students to explain what their code was doing, to ensure that one of them wasn't doing all the work, and we also encouraged them to switch who was at the keyboard often.
Yesterday (9/20/2014) we held our first ScriptEd year two session and did the scavenger hunt activity.
I made the following PRs to the curriculum based on our experience, which are pretty straightforward changes:
However, there are also some other issues whose solutions are less straightforward, which I will mention below.
JSBin vs. Cloud9
There was a lot of confusion regarding whether to use JSBin or Cloud9 for the exercises. At first we wanted learners to use Cloud9 so that they could save each exercise in a separate file, which would allow us to easily go back later and review in detail what learners were doing. However, because each clue in a section built upon the clue before it, this naturally made students want to just use the same file for each section--for instance, at the very beginning it's easier to just modify
hello.htmlto get to clue 2 rather than making a newheadBody.htmlfile from scratch (or even copying/pasting the text). This was particularly pronounced in theMySiteclue, where many students just wanted to reuse their existing code fromMyFirstWebsite, and we didn't know whether to tell them to editMySitein-place, or make a copy of its whole folder structure calledMyFirstWebsite. The confusion slowed things down, so being explicit would help.One possibility may be to make a github repo that contains a bare-bones skeleton of each file/folder, which the learners clone in Cloud9. Some of the files could even be completely empty; their mere existence could help resolve some of the aforementioned ambiguities. We'd also then have quick access to all their forks, which would be nice for later review.
However, another problem we ran into was the JS challenges, which were confusing to do in Cloud9 because of the apparent lack of a console, so we had the students switch to JSBin at that point. (We also weren't very experienced with Cloud9 ourselves, so this may have been due to our own lack of expertise.) Of course, by switching to JSBin, it was then a hassle for the students to share out their work.
roman.js is way too hard
I don't think any students made it through the final clue of the JS Variables challenge, which was to create a program that could convert any integer from 1-1000 into a roman numeral. We agreed to make this a bonus/homework problem that students could work on between now and the next class, which we'll email them about soon.
Incentive structure issues
Because the activity was framed as a race between students, one of the mentors suggested students skip hard problems in favor of easier ones, as a way to maximize point scores (and also do better on godforsaken standardized tests).
The assumption was that we would have time at the end of the competition to go over the problems that many students may have skipped, such as the @media challenge (media selectors were not taught in year 1 ScriptEd so few, if any, students knew them). However, we didn't actually end up reviewing anything at the end of the class, so valuable learning opportunities may have been lost (though we could also potentially review some of these things next class, or asynchronously via email).
It might be useful to make some kind of recommendation for how to deal with this in the curriculum. We also ended up offering points for taking fun breaks (by getting the students to pose in the photobooth).
Finally, we also added some preconditions for receiving points to ensure that both members of a pair programming team were learning: we often asked both students to explain what their code was doing, to ensure that one of them wasn't doing all the work, and we also encouraged them to switch who was at the keyboard often.