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

My 2015

“Better late than never” is sometimes true. Here is some of what I did last year because if you’re reading this I assume you might be interested.


The first three months of 2015 — it seems longer ago — I was at Citizens Advice, part of a team working on an “Alpha” version of new information and services for both the general public and the employees and volunteers in their many bureaux. Lots of HTML, CSS, JavaScript, “UX” (I guess) and more PHP than anticipated, not that that’s a problem.

I left when my contract ended, and it was back to freelancing for the same reason I first went freelance in 2003: I couldn’t think what else to do.

First, I was at the lovely Failbetter Games creating new HTML, CSS and JavaScript templates for one of their games, making things work nicely on both desktop and mobile.

I spent quite a bit of time in the middle of 2015 building a new site for St Paul’s School. The fine-fingered folk at Clearleft had done all the talking and planning and designing, and created some beautiful HTML, CSS and JavaScript templates. I pulled those apart and put them back together with the PHP-based Craft CMS, writing a large amount of custom code along the way. Craft seems nice, and thoughtfully constructed.

As Autumn arrived I joined George Oates of Good, Form & Spectacle and Frankie Roberto to put together a nice new website for the British Museum’s Waddesdon Bequest. A nice exercise in massaging a lot of existing data and creating a means to easily explore it; not as an isolated digital experience, but also representing how the objects are displayed in the gallery itself. HTML, CSS and Javascript with a tiny bit of my rusty Ruby.

2015 was the first time I did some teaching, showing second-year design students at Goldsmiths how to make websites. We rapidly covered HTML, CSS and JavaScript and it was an interesting experience. Hopefully for them as well as me. I plan to write more about this. That might even happen.

As the end of the year approached, I spent a few weeks on a site that’s not live for the interesting thing that is The Sync Project, using the Flask Python framework and, again, of course, HTML, CSS and JavaScript.

And that was the work year, a busy one. I’m fortunate that every project involved learning something new. In some ways, long-term freelancing makes me feel like I’m not progressing: most projects are a similar scale and, while many peers have moved on, I’m still writing code. But, then, I get to dabble with a much wider variety of languages and frameworks and tools than I would in most full-time jobs. It’s an odd combination of variety and sameness.

Not work

The year disappeared before I got round to having a holiday. I didn’t leave England in 2015 — I barely even ventured outside London and Essex — and there were hardly any weeks that didn’t involve at least some work. Not good.

Last year I hoped to read, on average, one fiction and one non-fiction book each month, alongside the usual Sight & Sounds, and the London and New York Reviews of Books. I managed 14.5 fiction and 11 non-fiction, although most of the latter were fairly slim or light.

I went to the cinema 22 times. I’m aiming for 52 in 2016, in an effort to get out a bit more. Even if it’s “getting out” into dark rooms and sitting down. A film, Selective Listening, I acted in a couple of years earlier came out online and on DVD.

I went to seven gigs. Here’s some of the music I listened to most last year:

My Last.fm Albums chart for 2015

Online… @samuelpepys and, to a much lesser extent, Pepys’ Diary continued to use up about a day per month. My Crazy Walls and Our Incredible Journey Tumblrs continued ticking over. I failed to write lots more posts here. For the third, or maybe fourth, time I started work on a Django package to mirror my digital stuff — links, photos, check-ins, Tweets, etc. That’s only the first step in re-writing my website, and completing that seems a long way off, still.

There’s a huge amount I want to write — both code and normal words — but once work has eaten up so much energy there’s a limit to how much time I want to sit at a computer typing.

In Work on 21 January 2016. Permalink

Today’s Guardian is back

A week ago I partly fixed my site Today’s Guardian, but it wasn’t fully repaired. Now it is.

The problem was that the script which creates the site each day scraped the content of a web page to get the list of articles in that day’s edition of the paper, which were then fetched one-by-one from the Guardian’s API. Inevitably that web page changed, my script didn’t understand the new HTML, and it didn’t seem an easy job to fix this fragile part of the process.

When I last did a chunk of work on the site there was no way to recreate an edition of the newspaper solely using the API. Thankfully that’s changed and you can now:

  • Set use-date to newspaper-edition, and from-date and(?) to-date to the YYYY-MM-DD date in question.

  • Set tags to include newspaper-book (a “book” being the section of the printed paper, such as “Main section”, “G2” or “Sport”).

  • Include newspaperPageNumber in the show-fields parameter.

This will fetch all the articles from that day’s paper, each accompanied by a description of which “book” it’s in, and include the page within that book the article is on. For example, here is the kind of query I’m doing, in the Content API explorer.

(There’s another tag, newspaper-book-section which is the section within the newspaper-book, such as “Editorials & reply” or “UK news”. I haven’t done anything with this yet.)

So I’ve now replaced the previous fragile and lengthy process with one which fetches all the articles in a single API request (or two, should there ever be more than 200 articles in one edition). A bit of shuffling of data later and I’ve reconstructed the day’s paper.

Not only does this make the script much faster to run, but it hopefully means the site will be more robust, and the sections of the paper will make more sense — previously there were some strange odds and ends appearing.

There are some oddities — it seems like one or two articles a day have no page number, so I’m currently leaving them out. And yesterday there was an article with no newspaper-book, so I’d also omit that.

And I’m a bit confused by the variety of “sections” an article could be in. For example, an article might have a sectionId of “Business”, while its newspaper-book-section might have a webTitle of “Top stories” and a sectionName of “From the Guardian”. A different article might have “UK news” for all three parameters. For now I’m only showing the first.

I took the opportunity to make a few more under-the-hood improvements and one more visible one: any “Opinion” articles that include a URL for the author’s photo now include that photo. Previously, because every article looks so similar in my design, I was always momentarily confused when I started reading something that didn’t feel like “news”. I’d then realise it was a “column” and I could ignore it. So now, the sight of an author portrait will be a sign (for me) that I can swiftly move on.

ScreenshotAbove, looks like everything else. Below, a more obviously ignorable piece of opinion.

There’s still room for improvement. For example, although the articles are sorted by page number, some things still feel slightly out of order. The letters page, for example, contains articles other than letters. While everything from that page will be grouped together, the letters won’t necessarily be consecutive within that group.

But this all seems good enough for the moment and I have other things to fix and update before Christmas. Happy reading!

My thanks to two former Guardian employees, Paul Lloyd and Cantlin Ashrowan, for pointing me towards this solution.

In Projects on 21 December 2015. Permalink

Today’s Guardian fixes

You may remember Today’s Guardian, a site I made in 2010. It’s been running reasonably smoothly for over five years, with only minor fixes, improvements and occasional nudges, which is pleasing. It broke recently but is now back. Almost.

You can read more about the ideas behind the site, but the aim was to replicate the ease of reading the daily newspaper. This was, if you can remember such a primitive age, before simple iPad-based news reading was more common, and before the Guardian’s own daily edition app.

Back then, the only way I could fetch a list of all the articles in a single issue of the newspaper, in roughly the correct order and split into the newspaper’s sections (the main section, Sport, G2, etc), was to scrape an HTML page. (Here’s an archived version.) I used the Guardian’s API to fetch the articles themselves, but this was the only way to replicate the newspaper’s structure.

I often worried that page would disappear or change. It seemed increasingly neglected and, as their website changed, it looked more and more left behind. Recently the URL began redirecting to a new page (and the same for Sunday’s Observer) and so my script broke.

I now have a hasty fix in place although it only lists articles shown on that new page, which is not the full newspaper contents — no sport, no G2, etc. It might also break again; I only know it works today.

In the medium term I’ll try and repair it properly. It would be nice to use only the API, without having to scrape a page, but I’m not sure it’s possible to reconstruct the newspaper’s structure that way. It seems possible to fetch all articles from a single issue (here are the results for today) and the articles have a newspaperPageNumber attribute. But I’m not sure there are any attributes that indicate which newspaper section an article is in, as opposed to the larger number of website sections.

Whether anyone is still using Today’s Guardian or not, I want to keep it running, so hopefully I will find both the time and a method to complete the repairs.

In Projects on 14 December 2015. Permalink

Oh, this is so middle class

It seems a waste to write a long answer on Quora and not post it here too. So, here’s my answer to “What do British people mean when they say, in a derogatory(?) manner, ‘oh, this is so middle class!’?”

It’s interesting to read the answers here because so many of them indicate the class of the person writing them, whether that’s acknowledged or not.

For example, Alec Fane says:

The middle classes however… They try. They try to be posh, and proper, and correct, and jolly good fellows. But most of all, they try to be seen as these things.

Some of them do. Others have a kind of guilt about being middle class and would actually prefer to be seen as being more working class because that gives the impression of being more down-to-earth and “authentic”. One test would be to see how a middle class person behaves when talking to someone who is more working class – maybe a plumber or builder they’ve got round to do some work. I bet a sizeable proportion (including, I admit, me) will try and fit in by talking in a way they wouldn’t usually. It’s also possible this is more of a male middle class thing.

And Tom Alexander, who admits to coming from an upper class background, says:

That type of phrase is basically an example of elitism, where the person is basically saying “oh, this is so common!” in a disparaging manner

I’m sure the phrase can be used in that way, but no one I know (as a middle class person with generally middle class friends) would do so.

So, aside from the point of view of the people writing these answers, you have to bear in mind that there’s no single middle class. To say that a third (or whatever) of the population thinks the same way about something as complex as class, and their place in it, would, of course be over-simplifying.

To talk in terms of newspapers, a middle class person who reads the Times will think differently to one who reads the Daily Mail, who will think very differently to one who reads the Guardian. Partly this is political differences, but it’s not just that.

(For those less familiar… the Times is a right-leaning “quality” newspaper that (in my biased opinion) is less quality/intellectual/worthy than its readers like to think. The Daily Mail is a right-wing tabloid with sensationalist, alarmist headlines that, at best, bend the truth. And the Guardian is a left-leaning “quality” newspaper whose readers are seen as soft, hand-wringing, liberal (in the American sense) intellectuals who don’t live in the real world. (That’s me.))

A (stereotypical) Guardian reader might say something is “so middle class” in a self-deprecating way – “We’ve got this brilliant recipe for spelt loaves for our bread maker… oh god, that sounds so middle class!”

Whereas I can imagine someone who might objectively/demographically be identified as middle class, but is much more “aspirant” and sees themselves as somehow better, might say something is “so middle class” to distance themselves from what they see as a more common behaviour (like Tom Alexander, above).

And someone who is demographically middle class (in terms of income, home, job, etc) but who thinks of themselves as more working class (perhaps because their parents were working class, or because of where they grew up), would say something is “so middle class” to mock a pretentious, trying-too-hard behaviour that they see as ridiculous (whether it’s actually something they’d also be close to doing themselves or not).

As with anything about class, this is a far from clear answer. The short answer to your question is “it depends”!

In Misc on 6 November 2015. Permalink

Recent comments on writing

Writing archives by category