A few weeks ago, Ryan Hoover wrote an interesting post called The Death of HTML in the Classroom. He described his evolving approach to teaching HTML and CSS to undergraduate students in his Information Design class for English Writing Majors. If you didn't see the post, check it out—it's a thought-provoking read.
Ryan's post resonates with my experience in a lot of ways. I teach a course called Introduction to Digital Literacies, and while a "web-based research project" constitutes the final deliverable, information and web design (and even content management) are not necessarily goals for the course. In fact, the course was originally designed primarily with English Education majors in mind; one of the goals of the course, then, was to create a web-based research project that could act as part of a professional teaching portfolio.
Long story short: the course was designed for English majors (though it's now a university core course, meaning we'll get more and more students from across the curriculum—yay!), it's not a web design course by any stretch of the imagination, it's not even part of a broader curriculum supporting work in information architecture or document design (unless students in the course take on the new Minor in Professional Writing), and the students are overwhelmingly English Majors studying Education, Literature, or Creative Writing (that is, not technical or professional communication).
I've said a few words on what it means (to me) to be digitally literate previously. Short version: in order to be digitally literate, students need to not only understand how the tools work, they need to know how the tools (like wysiwyg editors or templates) were made in the first place.
The first time I taught the course (Fall, 2009) I used a template-based approach to making things for the web, an approach that Ryan considers in his post. Interestingly, students requested more work with what we call the "rhetorical infrastructures" of the web in our class. They wanted more hands on work with HTML and CSS in particular.
Many were frustrated by the templates they used. Many were also puzzled by the fact that we spent a lot of time considering rhetorical infrastructures without actually getting our hands dirty poking around in them. It was my first time teaching the course, and my first class at a new university, so I waded in.
The next time I taught the course (Spring, 2010), I included a 5 week unit on exploring and using HTML and CSS in a text editor ("hand-coding," as they say). This did not go over well.
Mainly because I taught HTML and CSS as a 5 week unit.
It was my fault. We tried to cram too much into too short a time-frame. Further, what we were studying during that time was all new to the students. I seriously overestimated their ability to simply jump in and start working with divs, empty tags, external stylesheets, etc.
This semester, I'm teaching two more sections of Intro to Digital Literacies. I'm teaching the same HTML and CSS book, but this time I've integrated it into the entire semester, a little bit at a time.
Almost every week, students have taken on projects hand-coding HTML and CSS in little bits—one file at a time. One week, it might be simply learning how to position text blocks. The next week, working with images. Then in-line CSS. Then internal CSS. Then an external stylesheet. And on and on.
Most of this work culminates in a project called the Code Folder.
The first component of the Code Folder is simple: there are 20 required files that must be submitted, corresponding to work they've been doing in little bits all semester from our HTML/CSS book. These are easy.
The second component is a little more complicated and a lot more interesting, and this is where my approach might be seen as a counterpoint or middle way in relation to Ryan's discussion. Students choose a website and redesign it. The website they redesign? They choose from a couple of simple open source website templates.
So students do work from a template—in this case, an index file with lots of lorum ipsum, an external style sheet, and some dummy images comprising the website template—but they work with the template in a text editor (TextWrangler or Notepad ++ are our preferred options).
This way, they're not burdened with trying to create the world's slickest stylesheet from scratch. They don't start from nothing, but they must display the technical knowhow to significantly redesign what they start with.
Code Folders for both sections of the course were due yesterday, and I've had a look at every student's site. I'm not only blown away by their creativity and ability, I'm really proud of the fact that they did this work by hand—no dream/rapidweaver, and no web-based wysiwyg editor.
Now, I'm certainly not suggesting that this is the best-case scenario, but I think it fits for our situation here at BSU. By going this route, we do miss important work on things like maintaining databases or a robust CMS.
Long term, my goal is to support vertical curricula that fosters student learning of these kinds of things up the line, with an understanding that students taking more advanced courses come in with basic knowledge about rels, linking, file and directory structures, and working with the basic markup of the web.
And hopefully, without a fear of lifting the hood and pulling things apart.
Karl Stolley's excellent recent post discusses why it's a good thing to get your hands dirty.