Teaching web development to design students

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
• Background
  • 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
• HTML
  • Viewing source and the web inspector
  • What HTML tags look like
  • The structure of an HTML5 page
  • Coding together: A portfolio page in HTML
• CSS
  • HTML describes, CSS styles
  • What CSS looks like; selectors, properties and values
  • The display property
  • The box model
  • Colours
  • 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.

Day 3: JavaScript (PDF)

• HTML is content; CSS is presentation; JavaScript is behaviour
• In JS Bin (the first time) or the browser console (the second):
  • Variables
  • Sums
  • Strings and numbers
• Coding together: Favourite food and drinks
  • Arrays and objects
  • Functions
  • For loops
  • Updating the page with jQuery
• Coding together: Artybollocks
  • Forms
  • Events

Day 4: APIs with JavaScript (PDF)

• Overview of getting data via APIs
• HTTP, REST. GET, POST, PUT, DELETE
• XML and JSON
• Coding together: Weather forecast
  • Geocoding a postcode using Google’s Maps Javascript API
  • Displaying a Google map for that location
  • Displaying a seven-day weather forecast using the Dark Sky Forecast API
  • Displaying a random GIF for each day’s weather using Giphy’s API

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:

1. They’d never need any of this stuff again.

2. Having realised they can do the basics, they learn more and do some web design and/or development, straightaway or sometime in the future.

3. Having learned the basics of programming (using JavaScript) they find it easier to learn some non-web-development programming in the future (e.g., Processing, or some hardware-related stuff).

4. 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.

Teaching

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: section, main, article, 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 time field. 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.

Or:

If we want to make this text red then we set the color parameter to #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?

Similarly, I wanted to teach good ways to do things, but not spend all my time hammering home best practices. We sort of built our pages “mobile first” but, as with many of us, pages were mostly viewed in full-size desktop browsers. I tried to teach sensible ways to target CSS, and to structure simple JavaScript, and to write semantic, accessible HTML, but, when time is limited, at some point you have to let go and say, “that’s fine, it seems to work”.

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.

• The first time I started teaching JavaScript basics we used JS Bin to get instant feedback on what we typed. This was fine, but it felt like a bit of an abstraction for beginners, requiring a big change of context when switching to writing JS in a web page. The second time I think we did the basics in the browser console but, again, this seems a bit unnecessary. Next time I think I’d go straight to writing JS in the page and displaying the results or doing 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.

• The current HTML/CSS/JS/APIs structure is fine but you could easily argue that a different mix would make more sense, depending on the type of students and their aims. Learning a back-end language would be more useful in some ways than JavaScript, and give a more rounded view of the full web stack. But it’s harder to get everyone set up with that and people would still want the instant interactivity of JavaScript. Let’s not even start on which back-end language would be best to teach…

• The final day of using JavaScript APIs felt a bit too brain-stretching at times. To go from knowing nothing about web development to fetching, parsing and displaying data from different APIs felt like some huge steps. I knew this but thought it would still be useful for them to get a sense of what’s possible, even if they didn’t fully understand everything we went through. It’s also, as Nat put it, about “using data and the network as your material”. I wouldn’t change this, but it’s worth acknowledging, and going slowly.

• Although I wouldn’t necessarily change the API day drastically, I don’t think I’d use the Google Maps JavaScript API again. I wanted to only use APIs that require a key (I’m not going to try and explain an OAuth dance) which Google’s API satisfies… but it also requires including a bunch of JavaScript and using Google’s own objects and methods, which seems too confusing. It’s hard to explain clearly what’s going on.

• 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.

Commenting is disabled on posts once they’re 30 days old.