2014-2015 Year In Review: Web Programming

This was the first year I’ve taught a computer programming course. The class was a broad survey of programming in HTML5. This was the overall sequence:

Semester 1:

1. Hacking a webpage from the browser console
2. HTML tags, structures, and organization
3. CSS – page design, classes and IDs, along with using Bootstrap
4. Javascript – variables, structures, conditionals
5. jQuery – manipulating the page using events and selectors, animations

Semester 2:

6. Mongo Databases & Queries
7. HTML Templates using Blaze
8. Writing Meteor Apps
9. Meteor, Media, and the HTML5 Canvas
10. HTML5 Games using Phaser

I have posted the files and projects I used with students at this repository on Github:
https://github.com/emwdx/webprogramming2014-2015

What did I do?

The class generally began with a warm-up activity that involved students analyzing, writing, or running code that I gave them. This always led into what we were going to explore on a given day’s lesson. I would show the class a few lines of code, ask them to make a prediction of what they thought would happen. This might be a visual request – what will this look like? Will there be an error? Was this error intentional or not?

This was all done while students had their laptops closed and notebooks open. I usually designed a series of tasks for students to complete using some code snippets that were saved in the directory on the school server.

We didn’t use any textbook, so I knew I needed to create a reference that students could refer back to whenever they got stuck. For each class, I took notes either in Microsoft OneNote or the SMART Notebook software and saved the notes in PDF form. I don’t know if students used this or not.

I had three types of assessment:

• Mini-projects, which were fairly straight forward and had unique answers. These were assessed by general completion (4.5/5) with a (5/5) given for effort to creatively make the code their own. I was fairly loose on that final half point, giving it whenever I saw students clearly engaged by the task. You can see an example of this assignment here.
• Projects, which had clear guidelines and requirements to meet the minimum grade that ranged from 80 – 90 percent, and then a series of additional tasks that raised the grade up to 100%. The additional task points weren’t awarded until the basic requirements were met, though that didn’t stop students from trying (see below).
• Blog posts, which were required for every class. The expectations required a summary of what we learned for each class, along with code snippets, questions about what we learned, or confusion about something they wanted to go over in the next class. As the students became more skilled, this turned into questions that started as “How can we…/Is it possible to…”.

Once every two weeks, and usually on a Friday, I had a 20% day during which students could work on anything they wanted related to web programming. Some students worked on previous projects to resubmit them, others experimented with code from the previous class or week. In a couple of cases, students worked on their own pet projects, which included a chat application, a mathematical formula parser, and applying visual design principles to the pages we created in class. I often made suggestions for what students could do at the beginning of the class block, including providing some basic code they could use to experiment.

What worked:

• Based on feedback from the end of the year, students enjoyed the course. They had a lot of positive comments on the ways I ran the class and that they always got help when they needed it.
• Forcing students to write down code helped with retention and building a useful reference for later. I didn’t require them to write down long blocks of code, but for things like HTML tags and Javascript, I wanted there to be some written reinforcement that things were important. I was pretty strict on deciding when I wanted students to write down code (to activate that part of the brain) and when I wanted them to copy it directly into a text editor and run it.
• Forcing students to recreate code (and not copy and paste) led to higher activity and interaction between students while learning to code. I saved some code as images, not text, which required students to go line by line and see what they were doing. This was a decision I made early on because it helped me when learning to code. That extra step of needing to look at the code while I was typing it in led me to take a closer look at what it said, and I wanted to give a similar opportunity to my students.
• The more open ended projects led to much richer questions and interaction between students. I really liked the range of responses I received when I gave open ended projects. Some students were exceptionally creative or went well beyond the requirements to make code that mattered to them.
• Students were constantly helping each other with their code…when they eventually asked for this help. I was called over many times by students calling out the blanket statement “my code doesn’t work” and then handing me their laptop, but over time they learned that I wasn’t going to just fix their code for them. They became careful readers of each other’s code, when they finally made the step to ask someone to help, though this took some time.
• I succeeded in having students do more than listen. I never talked for more than 15 minutes before students were actually writing and experimenting with code. This was exactly what I wanted.
• 20% days were a big hit. Some students wanted this time as extra processing time to complete the mini projects from the rest of the week. Others liked being able to ask me how to do anything, or to find tutorials for HTML elements that they wanted to learn to use. I really liked how well this worked with this group of students and looked forward to it, and not just because it was a reduction in the planning required for class.
• Videos offered an effective and preferred method for learning to write code in this class. I put together a number of screencasts in which I spoke about the code, and in some cases coded it live. Students were able to pause, copy code to the editor, and then run it pretty easily. Some zipped through it, others took longer, but this is nothing new. The time required to do this, as is always a consideration for me, was often more than I could afford. Luckily, there is plenty of material available already out there, so I was able to step back and give another voice and face a chance to teach my students.

What needs work:

• The bonus elements for projects were the first things most students wanted to figure out first. Many students did not put in the time to read and complete the basic requirements for projects, resulting in submitted projects that were sent right back as being incomplete. Some of this was a language issue, as there were many ESOL students in the class, but most of it was what we always encounter when working with adolescents: not reading the directions.
• Students reused a lot of old (and unrelated) code. I emphasized creating simple code from scratch throughout the year, as my expectations were relatively simple. For many students, copying and pasting code was a crutch that led to many more problems than simply writing simple, clean code from the start. I get it – I copy and paste code myself – but I also know how to clean it up. They knew why not to do it (because they all tried it at some point) but some students continued doing it to the end. I need a better plan for helping students not fall into this trap.
• Many students did not pick up on error messages in the console that said precisely where the problem with the code was located. At times, I expected too much from students, because the console is a scary place. That said, I think I could do a better job of emphasizing how to find the line numbers referenced in these errors messages, regardless of what the error message is.

I really enjoyed teaching this class, and not just because of the awesome group of students that took it. It helped me refine my knowledge and get better at some of the HTML, CSS, and Javascript coding skills that I had used, but often had to relearn every time I wanted to use them.

Feedback, as always, is welcome!