WordPress.com, and user testing, by phone

Recently, I’ve been helping someone use WordPress.com remotely, over the phone, which has been more difficult than necessary because WordPress.com has two interfaces.

As a combination they’re a little confusing to use at times. There’s the original “WP Admin” and the newer, “improved”, Editor. Here are a couple of screenshots:

WordPress Admin - Edit Post The original “WP Admin”

WordPress Editor - Edit Post The new WordPress Editor

Both interfaces have pros and cons for different people and different situations, and I’m not going to discuss each in detail. I can see why there was a need to create the second, new, Editor — over the years the original WP Admin has become bigger and more complex, and increasingly daunting. And I can see why they don’t want to get rid of the original WP Admin — radically changing the interface that thousands or millions of people use every day would be a customer support nightmare.

But, if we make the assumption that the only current option is to have both interfaces operational, for different people or uses, here are a couple of things that create confusion:

  • When looking at the new Editor (which I think is the default), there’s a link in the left-hand menu to the old WP Admin. But there’s no obvious way to get back again, from the old WP Admin to the new Editor. And that link to the old WP Admin opens in a new browser window or tab. It’s very easy to end up with multiple tabs open without realising it, all containing different versions of Posts, Pages, etc.

  • When editing a Post in the old WP Admin there’s a banner suggesting you “Switch to the improved editor.” This changes the view to the new Editor (in the same tab/window this time), but there’s no way to switch back to the old WP Admin (other than your browser Back button). The left-hand menu does have a “BACK” link, but this doesn’t take you back… it takes you to the list of Posts, still in the new Editor.

While each interface gives you a sense of where you are within it, switching between the two makes me feel lost. I have no sense of where I am in the system as a whole, or the two interfaces’ relation to each other. I’m not sure what the new Editor is even called (I’ve named it “the new Editor” consistently here to try and avoid some confusion).

I think I want more of a sense that I’m switching between two parallel interfaces, and that I can switch back and forth between equivalent screens. Personally, I’d like an always-visible form of navigation that names the two interfaces consistently, so I can always go directly from one to the other.

You might say “well, don’t switch between them then!” But there are, I think, some things which can only be done in the old WP Admin. And also, if you’re finding your way around, it’s very easy to switch from one to the other and have no idea how to return to the slightly more familiar version.

Remote support

All of these confusions are amplified when trying to help someone use WordPress.com over the phone. It’s difficult enough to help someone use software when you can’t see what they’re seeing, but when you don’t even know which interface they’re using it’s even worse.

Is it blue and white? Or does it have a black menu on the left-hand side? Unless you’ve changed the colour scheme under “Users” and then “Personal Settings” in which case the menu could be any colour… OK, what shade of blue is it?

Without any sense of where you are, or which interface you’re using, and with new browser tabs sometimes opening as you switch between them, it only makes helping someone more difficult.

I’ve seen other friends recently talk about the difficulties of remote support, including Dan Hon in a recent newsletter. It makes me wonder if anyone who does user testing for websites (as it’s websites I’m most interested in) tests for the ease of remote support.

I mean, usually when doing user testing, you might give someone a task and sit them in front of your website and watch how they do. Perhaps, as well, you could give someone a task and sit them in front of your website, but they have to talk a second person through how to complete the task. The second person is in another room, on the phone, and is using a different web browser, with a different monitor resolution, and is starting from a different web page. I’m sure this set-up could be improved and made more rigorous — I’m not a user testing expert — but you get the idea. I suspect it would highlight things which are inconsistent or hard to describe.

In Web Development on 6 June 2016. Permalink

Folklore universe

In 2001 a friend shared a link to this paper, ‘Folk Computing: Revisiting Oral Tradition as a Scaffold for Co-Present Communities’. There’s one part of it that really struck me then and I’ve thought about many times since (and it’s more interesting than the academic title sounds).

The paper’s authors created some devices which they gave to 350 children and staff at a “K-8 school”. Here’s a summary of the device and software:

The name “i-ball” is short for “ball of information.” I-balls are simple software folk objects that have some toy- and game-like qualities. People can design their own i-balls and then share with other members of community. In our prototype, i-balls exist on key-chain-sized video game devices made by SEGA and sold as part of their DreamCast video game system, as shown in Figure 1. We wrote our own software for this commercial device, and renamed it the “i-socket,” to distinguish its capabilities from those of the original SEGA “Visual Memory Unit (VMU)”– designed to let kids store and recall their state in a particular DreamCast game.

i-ball and PC software

People design their i-balls on a PC using a prototype graphical programming tool we developed. The most basic form of i-ball consists of a single “animation” programming block. This block allows kids to “decorate” their i-ball by composing an animation out of 128 different letters and icons in a simple “flip-book” style animation editor. Figure 2 [above] shows the first frame of an animation a child created that depicts a face that blinks and says “hi”. I-balls created on a PC can then be downloaded to an i-socket via a small “docking station”.

Like the play objects they are named after, i-balls can be passed between people. Participants can give a copy of one of their i-balls to someone else, or, using “jump” blocks and “rule” blocks in authoring environment, i-balls can be programmed to “bounce” from one person’s i-socket to another’s, based on user-defined rules.

There’s a lot more stuff about the kinds of things that were created and how they were shared. They authors, and kids, could look at how the i-balls spread around the school. And this is my favourite bit:

One of the most interesting “ahas” came after a third grade class viewed a visualization of how one of their favorite i-balls had spread. Someone in the class had made an i-ball version of the class mascot: a bunny named Shadow. They felt this i-ball was very popular and asked several times for a poster-sized printout of how it traveled through the school. When we brought it to their class, however, they were disappointed.

The visualization revealed that while most of the third-grade had gotten a copy of the Shadow i-ball, it had not spread much beyond that. After a long discussion, it became increasingly clear that the third grade had come to believe that because everyone in the class had seen Shadow, many in the school probably had as well. This led to some interesting conversation about the limits of generalizing what is true about your close-knit group to what is true about the larger population.

Ordinarily, of course, the mistaken beliefs of the third graders are self-sealing. People’s folklore universe is determined by whom they interact with, and there is no way of getting outside this universe to test the limits of it. Phenomena like insularity are notoriously hard to see from the inside.

When I first read this I’d already read a fair bit about social networks and the diffusion of ideas through them, but this bit was my own “aha” moment — I don’t think I’d seen such a clear example of a group of people assuming their entire “universe” thought like they did. When everyone in your social group is aware of many of the same things it’s really hard to see the broader world objectively. You assume what’s common knowledge for your peers is common knowledge for everyone.

I’ve thought of that class so many times over the years because we see similar behaviour over and over again: People being surprised at how the wider world doesn’t know what they know, and often laughing at someone in the wider world for their apparent lack of “common” knowledge.

In Misc on 23 April 2016. Permalink

On spending too long setting up one webserver

Over the past couple of months I’ve spent most of my free time setting up a webserver. One webserver. One. This is ridiculous and has made me question my profession and my sanity. This is my attempt to justify myself.

First, let’s step back a bit.

After running The Diary of Samuel Pepys for ten years I had the bright idea of rewriting the site and doing it again. So in 2013 the new version, written using Django, appeared. The website was hosted on Heroku, one of whose benefits is simplifying the task of running a webserver. It can become expensive but for my simple needs it cost US$9 per month (for a database).

Last year Heroku re-jigged their pricing, understandably, and so I’d now have to pay for not only the database but also serving the site itself. The monthly cost would rise to $16 per month. It’s not a huge amount but it was a nudge and I wondered about alternatives.

As a comparison all of my other self-hosted sites are hosted on a Webfaction “shared hosting” account for a total of $10 per month. I could probably have moved Pepys there but this seemed like a good chance to learn something new.

I decided to try setting up a virtual server at DigitalOcean. This is a bit more like a “real” webserver, without Heroku hiding the grubby bits beneath the hood. Consequently it requires more work to get going. But it’s cheaper: the smallest option at DigitalOcean only costs $5 per month. It’s more time consuming and there’s more scope for things to go wrong. But this was a chance to learn more about part of the “full stack” of web development that I’ve usually avoided.

Thankfully, there are lots of instructions for doing this kind of thing, and I was able to follow these to set up a server and get my Django site working. It took about a day of carefully following along and making notes but, almost uniquely in my experience, the process worked.

I was amazed. I’d learned useful new things. I’d saved $11 per month. Imagine the celebrations.


While I had a new, live, production website, I also needed to write new code on a different version of the site. Django makes it easy to run a local version of your code for development, which is fine but not ideal — my Mac is a different environment to a DigitalOcean virtual server. It’d probably be OK for my own decreasingly popular personal projects but I like to do things “properly”.

Them: You have an interesting CV, Phil. Now then, what’s your biggest weakness?

Me: Well… I like to do things properly.

I always like to try and find the very best, the most “proper” way to do something.

When I’m doing work for clients this tendency meets its natural enemy: deadlines. Working out how to do a new thing the best way can take a while. And while I, of course, like to do client work well, the pressures of time always mean balancing “properly” with “good enough”. This is the real world and the reason anything gets done.

When I’m doing work for myself I am not in the real world. I rarely have set deadlines — I’ll never finish all of my personal projects anyway, so I may as well take the time to find the best way to do things. I may as well try and do things properly!

This is satisfying, and involves learning a lot more, but it takes longer and the end, visible, result is often little different to a “good enough”, “it seems to work” solution.

For a development version of Pepys I, of course, wanted to do things properly — I wanted to mimic the live server as closely as possible. I’d used Vagrant before — it lets you run virtual computers on your own computer — so I just needed to use it to set up a copy of my live server. Which would mean manually going through the same instructions that took a day to set up the live server. And I’d have to repeat this every time I needed a new server for the same or a different project. That seemed like it could be a lot of boring, repetitive days.

Of course, people write code to avoid boring, repetitive days, and there are many ways to automate the setting up of servers. Chef, Puppet, Ansible, SaltStack… all with their own metaphors. I liked the sound of Ansible — it didn’t sound too complicated, and I liked that you run its scripts on one server (such as your laptop) to configure a remote server.

I decided to try using Ansible to set up a Vagrant server, for local development, and to replace the new live server with a new one set up using the same script. I could even make a staging server on DigitalOcean too. Soon, with a single command I could set up as many identical servers as I liked!

Well, not that soon.

I like to do things properly.

Although DigitalOcean isn’t terribly expensive, it seemed like a waste to have an entire virtual server for Pepys. It rarely uses more than 10% of the CPU. And I imagined I might build Django sites in the future that would be smaller and even less worth their own server.

Ansible, and its ilk, are usually used to set up a single website spread over several different servers (to handle the load of a lot of traffic). I wanted to go the other way — set up several websites on a single server. This can’t be that hard, I thought. This must be possible.

I can confirm that it’s possible, and my new DigitalOcean server is live, and I have a matching Vagrant virtual machine. It’s easy to create new ones. It’s great! But, somehow, it’s now the end of March and this is almost all I’ve achieved so far this year.

This is “doing things properly”.

If I’d wanted to use Ansible to set up a server with a single Django app, that’s been done. I would, being me, have built up my own version, copying bits from existing solutions, which would have taken a while, but not too long. It would have been closer to the “it’ll probably take a couple of weeks to get to grips with Ansible” scenario that I initially imagined.

This has taken me far, far too long. Simply to replicate one webserver. If it was going to take me a whole day to manually create each new server I could have done that for many future servers and still saved time. I’ve spent several weeks inching forward, getting despondent, producing nothing visible. But, now, if I make a new Django app it can go on the same server as Pepys. So long as it’s not really popular. By spending weeks typing and swearing I’ve saved myself a hypothetical $5 per month in the future! More celebrations!

Here is my Ansible playbook which I don’t really expect anyone else to use. It has a lot of documentation because I quickly forget how to do things, so always write it down in detail.

Why was this so difficult?

Part of the problem was that I’m not that familiar with servers. So I was learning how to automate something that I know little about. I’d end up spending a lot of time puzzling over basic server administration issues. I am, now, a bit more familiar with this stuff, so that’s good.

A lot of my time was spent trying to make things work for multiple Django websites. Lots of tasks that are quite simple to automate with Ansible become trickier when wanting to do it for one or more websites. Little was impossible, but a lot was harder. A lot.

More time was taken up with making the playbook easy to reuse. More of that “doing things properly”. I wanted it to be easy to add a new Django website to the server, simply by adding a few configuration variables. Which it is, mostly. But making things easily reusable — smoothing out rough edges, thinking through how to structure things — takes a while.

A good few days early on were lost to figuring out the differences between setting up a “real” webserver (like on DigitalOcean) versus a Vagrant one. Although Vagrant mostly behaves like an actual server, there are enough differences that some Ansible things that work fine for proper servers don’t work the same, if at all, on Vagrant.

There were probably a few days sunk solely into how best to handle different Python environments. I can’t quite believe this is so difficult, but there we go. I wanted it to be possible for each Django site to have its own version of Python, its own Python modules and its own environment variables. This is not a solved problem.

(To get a little more technical for a couple of paragraphs… I’ve ended up using: pyenv to manage different python versions; virtualenv and pyenv-virtualenv to manage the discrete environments for installing modules; and autoenv for handling environment variables. It works, but it feels like a mess.

Autoenv sets environment variables OK, but doesn’t have a way of unsetting them, which makes me uneasy. I also looked at direnv and python-dotenv which had their own problems. I spent a long time struggling to get virtualenvwrapper and pyenv-virtualenvwrapper working but failed, not helped by confusing documentation. I feel like I’m missing something.)

Whenever I’m learning some new technical thing it’s a case of running blindly from one seemingly insoluble problem to another. This was no exception, probably because it involves so many different moving parts. There’s Ansible, and there’s knowing general UNIX-y stuff. And then there are the wrinkles of every piece of software that’s being installed, configured and used. Git, Nginx, Gunicorn, Supervisor, Postgresql, Memcached, Django, all that Python gubbins… I can’t pretend to have mastered that lot.

My struggles with learning any new development things are chronicled in my desperate questions on StackOverflow. I usually spend a day or so exhausting all my Googling and experimentation before I give in and compose a question in the hope an American will come along overnight and provide the answer. About 50% of the time I end up answering my own questions eventually, as if I’m continually breaking new and exciting ground like a trailblazing scientist, rather than an increasingly despairing web developer. This project has resulted in these “questions”:

There we go. I’ve no idea how much time I’ve actually spent on this. If it was full-time, five-days-a-week it must be over a month. Six weeks? Whatever, it seems ridiculous. It’s been a grind, without even the usual, eventual, reward of being able to say “TA-DA! Look at this beautiful and/or useful thing what I made!” I guess this blog post is the replacement. “TA-DA! Look at what I’ve been through, even if everything looks exactly like it did before!”

On the bright side, I’ve learned a lot! I’ve filled in some gaps in my knowledge and have a bit more idea about how to serve the websites I might build. My sysadmin skills have probably advanced from the “completely useless” level to the “almost knows enough to be dangerous” level. Which is progress.

On the other hand — and I always have a pessimistic third hand ready — I can’t even keep up with front-end development these days, never mind starting to keep up with a completely new part of the stack. I already had spinning plates crashing down around me and now I’ve found a completely new set of crockery wobbling, wobbling, wobbling away.

In Web Development on 23 March 2016. Permalink

A thought on job ads

If I ever post a handful of Tweets on one topic I feel they should have been a blog post. You remember blog posts. So, a thought on job ads.

I occasionally receive emails from recruiters who have “viewed your page on Github”, or “reviewed your LinkedIn profile”, or whatever. The jobs always sound very dull. Most jobs probably are dull. But these supposedly enticing descriptions are unnecessarily dull. They’re always blandly generic.

This is mainly because recruiters anonymise the company they’re recruiting for, withholding any identifying information. Presumably because they don’t want you applying directly to the company and denying the recruiter their percentage. But making something sound as un-special as possible seems a terrible way to sell it.

(An aside: I’m very picky. There are, of course, many people who will apply for any job that sounds remotely like they have a chance of getting it. And the exact language used in the ad probably isn’t high on their list of priorities. But, while I’ve been sort-of-looking for a proper job for a long time, years of freelancing tells me I can make an interesting living without one. And I can barely imagine working in one company for years any more. So I’m not desperate for any job right now. I’m job-curious.)

Occasionally I go and look through job ads on the web and those that are most appealing are those that appear to be written by someone interested in finding the right person for their own team. They don’t go over the top with buzzwords and making the place sound AMAZING. They sound human. They try to convey a sense of what the company is like as a place to work, and what the role would be like, both initially and in the longer term.

This is important to me because, once past the bullet-points of required and desirable skills, I want to imagine whether I’ll fit in, and whether I’ll like being there and doing the job a couple of years in the future. Does this sound like someone I want to work with/for? Beyond the technologies, does it sound like the kind of work I can do and will want to do every day? Is the company my ideal balance of informal but without the worst excesses of start-up-world? Is it exactly the right place for this special snowflake?

Writing appealing job ads must be difficult. And that’s if you’re part of the company and trying to attract people to you. If you’re a third-party recruiter who’s dashing out loads of these things for clients, and anonymising them, it’s easy to see why the emails aren’t appealing. How can I possibly get a feel for this “innovative Fintech start up” or that “multi award winning agency” when I have nothing specific to go on?

I guess there’s a level of specialised, high-level recruiter that doesn’t work like this. (“Headhunters”? I guess that’s the thing?) And that I shouldn’t be surprised these out-of-the-blue emails are as unappealing as generic spam. But it seems like a waste of everyone’s time.

(This blog post is based on a Twitter conversation with @ClareBurr.)

In Misc on 7 March 2016. Permalink

Planning for closure

When starting work on a new website few of us think about how long the site should last for. I know I don’t. But I think we should.

The lives of many websites have, or will have, an end, but we tend not to think about them in advance. Often, the end is unplanned. Websites sidle slowly into neglect, gradually falling apart. Or they blink out of existence when the domain isn’t renewed or a credit card expires.

How long do you expect your websites to be online for? The answer has implications for your time and, if applicable, your client’s time and budget. Below are four questions I think it’s worth asking before starting work on a new website.

1. How long do I expect this site to stay online for?

This is the basic question that rarely gets asked. We’re so focused on getting the site live that we don’t think about when its death will be. Perhaps more fundamental is to ask “Is this site going to live forever, or will it close at some point?”

Obviously, “forever” is unlikely, but often we aim to keep a site alive for as long as possible. My personal site, for example, has no fixed end date. Quite how to keep a website alive for whatever-forever-means is worthy of another post full of different questions.

Sometimes there is no clear answer. The website for a company is unlikely to last “forever” but also has no specific end date. It will probably last for “a while” until the company outgrows it, or the brand changes, or it looks old-fashioned. But it’s worth at least having a guess. Might that be in six months? Or five years?

The duration of your site’s life has implications for you, your client and their budget, so it’s worth trying to pin down. If you can’t, fair enough — but at least have everyone acknowledge you’re making something whose future is entirely undecided. The remaining questions are still relevant.

2. Under what circumstances will the site close?

If you’ve decided the site has a finite lifespan, when does its life end, and why? If the site is for a particular event maybe you (or your client) have decided there’s not the time or budget to keep it alive when the event’s over. So maybe you choose a date after the event and plan to take the site down then. Or maybe you think your frivolous site will have outlived its life after a year, so perhaps you should plan its death in advance.

The main thing is for everyone to acknowledge what it is you’re making. Is this a site that should last ten years? Or three months? These could be very different things, and cost different amounts of time and money.

If you have a clear “time of death” then perhaps you should set expectations by making this clear on your site. State somewhere that the site will only exist until a certain date. Set in place a clear warning that will appear at a set time before the site’s disappearance. If it’s a site that has user accounts, prepare to contact them well in advance and give them a way to export or transfer their data, if applicable.

3. Do I have the time to keep this site updated?

Unless you’ve decided your site has a short lifespan, and you’re going to wipe it off the web very soon, are you prepared to keep it updated? How much work will that be over 10, 20, 50 years? What is a website like in 2066? Is there a web in 2066?

Over time some or all of these will need tending, fixing, upgrading and improving:

  • Server OS and packages
  • Deployment scripts and tools
  • Database
  • Your back-end code’s language
  • Third-party modules your back-end code uses
  • The site’s framework (Rails, Django, etc) or other fundamental tool (WordPress)
  • Your own back-end code (security fixes, changes required by site growth, etc)
  • Integrations with third-party APIs that will change over time
  • HTML and CSS (for new formats, devices, standards, etc)
  • Your JavaScript (security fixes, device changes, etc)
  • Third-party JavaScript you’ve used.
  • Graphics (new devices, resolutions, etc)

And all of that is assuming an unchanging site, with no new features other than keeping up with the ever-changing tech landscape.

How much time will that take each year? Not a vast amount, but it will take time. The work will seem less and less important over time and become more of a drag when your site is old and little-trafficked.

If your site has users with accounts, who will handle customer support? There will be people who need help with something, people who want to delete things, people who cause trouble, people who break things, people who find bugs, people who want to close their account…

Over the long term there are likely to be occasions when you need to move your site from one server(s) to another. How easy will that be?

Who pays the bills? What happens when the credit card expires? Or the person who put it on their card leaves the company? Which email addresses are the domain, hosting, and accounts on third-party services registered to?

4. What does “closing the site” mean?

If you’ve decided the site has a finite lifespan, what actually happens then? Do you delete the code, shut down the server, and let the domain name lapse? Or does the site have a state between “life” and “non-existent”?

Maybe your site will have an “archived” state. If so, it’s better to plan for it before starting work. Does your code need to work differently for a future archived state? How easy is it to switch to the archived state? Can you turn the site into flat HTML files which will be less work to maintain? Do you have the time and budget to keep even an archived version live for… again, how long?

A couple of examples of putting a closed site into archive mode, even if these weren’t planned from the start (as far as I know):


I don’t think many of us want to ask these questions. I’ve certainly never asked these questions of my own sites.

My knee-jerk reaction is that I want all websites to live “forever”, whatever that means in practicality. But I know that for my personal sites this is increasingly unrealistic. Each one is a little more overhead and, unfortunately, I’m more and more reluctant to start yet another site unless, like a Tumblr, I view it as semi-disposable. If I’d planned sites to be more finite maybe I’d have made more?

I suspect there’s a subset of websites that we can acknowledge in advance aren’t going to last forever, for varying reasons. In those cases we can make this decision clearer from the start, and plan ahead for closure or archiving. If we exceed our expectations — the site’s more popular than expected, we enjoy working on it more than expected, more money comes in — then maybe we can change our plans. But changing plans seems better than having no plans.

And whether we decide the site should live forever or for six months, realising the work that’s involved, even to keep the thing ticking over, is worth doing at the start.

In Web Development on 10 February 2016. Permalink

Teaching web development to design students

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

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.


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.


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.

In Education, Work on 2 February 2016. Permalink

Press play

I’ve started digitising some old cassettes and came across this lovely snippet at the start of what the inlay said was a collection of songs by Madness:

An illustration of why it is (was) important to poke out the tab at the top-left of the cassette so that you didn’t accidentally press play and record when you meant to only press play.

That was probably 1981, so I was about ten and my sister, whose tiny first voice you hear 33 seconds in, was about seven.

I’m surprised how well the cassettes have survived so far — I thought they might break or be somehow unlistenable after 35 years, including a few years sitting on a heated floor by a window. I’ve attached a second-hand Kenwood cassette deck to my MacBook using a Griffin iMic, recording the audio with Amadeus Pro. This seems to work fine, apart from the iMic occasionally getting stuck and playing the same half-second over and over until I unplug it and start again. Technology, eh?

In Personal on 1 February 2016. Permalink

Recent comments on writing

Writing archives by category