Towards the end of 2015 I taught some second-year design students at Goldsmiths the basics of how to make websites. It was the first time I’d done any teaching and was an interesting experience all round: planning what to include, teaching the classes, and reflecting on what worked and what didn’t.
First though, thanks to Nat Buckley who taught similar workshops before, and whose materials and conversation made the task of preparing for this seem manageable. Like me, now, Nat also reflected on the experience.
Below I’ll summarise what I taught, how I worked out what to teach, how the teaching went, and what I’d change next time.
What I taught
Here’s a rough outline of what I ended up teaching. It’s not detailed, or in exactly the same order, but gives you a rough idea. The “coding together” items are when I’d be typing code on the screen and the students would follow along on their own computers. I’ve linked to PDFs of the slide decks and to examples of the code we wrote.
Day 1: Some background, HTML, CSS (PDF)
- A bit about me
- The “web” is not the “internet”
- A very brief history of the internet
- A very brief history of hypertext
- What happens when we visit a page in a web browser
- Front-end vs back-end
- Viewing source and the web inspector
- What HTML tags look like
- The structure of an HTML5 page
- Coding together: A portfolio page in HTML
- HTML describes, CSS styles
- What CSS looks like; selectors, properties and values
- The box model
- Inheritance and specificity
- Coding together: Styling our portfolio page
Day 2: More HTML & CSS (PDF)
Improving the portfolio sites: continuing with the page we did the day before, students asking how to do anything they wanted to achieve.
- In JS Bin (the first time) or the browser console (the second):
- Strings and numbers
- Coding together: Favourite food and drinks
- Arrays and objects
- For loops
- Updating the page with jQuery
- Coding together: Artybollocks
- Overview of getting data via APIs
- HTTP, REST. GET, POST, PUT, DELETE
- XML and JSON
- Coding together: Weather forecast
A note about the code: these are the results of work in class rather than examples of the very best way to write these things.
Working out what to teach
I’m fortunate that I had Nat’s examples to base these four days on as I wouldn’t have known where to start otherwise. Given I’d never taught anything like this before I stuck with Nat’s basic HTML, CSS, JS and APIs structure. But I still struggled with which details to include and which to leave out. 24 hours of teaching isn’t much when you’re looking back at things you’ve learned over twenty years. I wanted to teach everything. And getting the order correct is tricky: I wanted to teach everything first.
But before getting to code, I wanted to include a bit of history (as did Nat) because I think some context is useful. In part this is about sharing one’s mental models. If you’ve been in an industry, doing a particular kind of work, for a long time you have a very different mental model of it to those coming to it afresh. So I settled on some minimal mental-model sharing
A very brief history of how and when the internet grew, to give a sense of its age and speed of growth.
The difference between the internet and the web, which seems especially important if you’re teaching web development.
The basics of a web page request, including the difference between front- and back-end code.
There’s a lot more that could be included but I didn’t want it to become too much of a social sciences lecture. That took part of the first morning, and the rest of the time was trying to give a basic background to creating websites.
As for the aims of the course, I assumed there’d be four possible outcomes for a student:
They’d never need any of this stuff again.
Having realised they can do the basics, they learn more and do some web design and/or development, straightaway or sometime in the future.
At some point in the future they need to update or change an existing website (e.g., their new employer’s WordPress site) and they’re not scared of tweaking HTML and CSS.
Having never taught before I wasn’t sure what to expect. The first day was a bit of a shock to the system, mainly because students are so very, very quiet. I could ask the class a direct question (“Does that make sense?”, “We’ll do this next; sound OK?”) and there would be silence. No movement, no eye contact. I had no idea if this meant they were hating every minute, if they were completely lost, if they were bored, or… maybe they were just really quiet? I don’t know if the small groups — about 6-8 students — accentuate this.
I had planned to teach HTML on the first day and CSS on the second but, partly because of having no idea how it was going, and partly because I realised there was a limit to how interesting basic HTML was without CSS, I ended up spending most of the first day talking, and I whizzed through both HTML and CSS.
That left the second day entirely unplanned… but, thankfully, it turned out fine. The students seemed happy taking the basic page we’d done the first day and styling it how they wanted, and adding more pages. They’d ask how to do things and I’d share things with the whole class as we went. It seemed to work well enough that the second time I taught the course we, intentionally, did the same thing — cover the basics in day one, then experiment in day two.
That initial hiccup aside it all went pretty well, as far as I know, and was an interesting experience for me. I hope it was useful for the students too. The second time I taught the course I saw a couple of the students from the first time who said they’d done a bit of web stuff since, so that’s not nothing.
Teaching things you know well makes you realise how much you don’t know. There were many things that I’d start explaining and realise I had no idea why I did that; it was just habit. Or it made sense in 2004 and I’ve done it that way ever since. There’s also a lot of stuff I realise I simply don’t know that well. For example, exactly when all the structural HTML5 tags should be used:
aside, etc. I’m not sure there even is a single correct answer.
And then there are things that sound ridiculous when you start explaining them:
We need to know the date this weather forecast is for, so if we look in the data from the API… there’s a
timefield. Yes, it’s just a long number. That’s, er, the number of seconds since 1st January 1970. [laughter] Because, well, that seemed a good idea in the 1970s.
If we want to make this text red then we set the
#FF0000. You might have seen RGB colours in things like Photoshop? So this is RGB, but it’s in hexadecimal, with each pair of characters representing a number from 0 to 255. Because…
Or trying to describe how HTML changes over time and why some things work differently in different web browsers. “There are lots of men arguing on email lists…”
It’s also hard to know which things to teach and which to leave out. For example, those
#FF0000 colours seem a bit complicated, and we could just use
rgb(255,0,0) which makes more sense. But the students are bound to see the former format, so it at least needs mentioning. And, but,
rgb() doesn’t work in Internet Explorer 8… they can probably get away without knowing that, but how much of this hard-won, and progressively useless, legacy knowledge is it worth me sharing? Do they need to know about the weirdness of the box-model when
box-sizing: border-box; will iron out the wrinkles?
Finally, it’s tempting to think students are all technically savvy. They’re young, “digital native”, laptop-toting, app-using millennials! They’ll know more than me! But computing skills vary a lot and it’s easy to take the simplest things for granted; there are some basics I could have been clearer and slower about. For example, organising files and knowing where a file was saved confused some students, leading to duplicates and missing images. But aside from these understandable gaps, the students that stayed (a few left as days went by) were willing to learn and, often, find out how to achieve things they wanted to do under their own steam.
What I’d change next time
Generally, it all went well after that first day. I tweaked a few things for the second time I taught the course, but not a huge amount. There are things I’d do differently next time, or that are worth thinking about:
The second time I tried to explain those hexadecimal colours properly. It seemed a long-shot and I won’t bother again. Even explaining base-16, without expecting anyone to learn it, seemed crazy the moment I started. Just use a decent color-picker.
I should probably understand HTML5’s newer elements better. I feel so old fashioned that this stuff still seems crazy new to me. But whenever I try and learn them more thoroughly it seems like no one can agree how and where to use them correctly and I move on. But this makes it hard to teach them.
console.log(). It’s a bit clunkier — having to refresh to see results — but it feels like a smoother on-ramp to everything else.
It only occurred to me at the end that I should have encouraged the students to try and fix each other’s bugs. If anyone had problems I’d go round and help people and often it’d be a little typo somewhere. Helping each other would acknowledge that this is entirely normal and that a second pair of eyes is often all that’s needed.
My biggest unsolved problem is how to easily, and freely, host the pages the students made. It seems silly to teach them how to make a simple website but have it only exist on their laptops. I asked on Twitter for suggestions and had a lot of answers which I still intend to write up. Most are too complicated for a group with limited time and knowledge. We gave Heroku Dropbox Sync a go, which worked eventually but we spent a lot of time dealing with extremely vague error messages and it doesn’t feel like a “proper” way to do hosting. More on this another time…
That’s all. Hopefully some of the students learned at least as much as I did.