Archive: January, 2016

Taking part in the IndieWeb

The slides from Calum’s presentation at Front-end London.

AMBER

This is intriguing—a Pinboard-like service that will create local copies of pages you link to from your site. There are plug-ins for WordPress and Drupal, and modules for Apache and Nginx.

Amber is an open source tool for websites to provide their visitors persistent routes to information. It automatically preserves a snapshot of every page linked to on a website, giving visitors a fallback option if links become inaccessible.

The End of Big Data | Motherboard

A great piece of near-future sci-fi from James.

I enforce from orbit, making sure all the mainframes that used to track and store every detail of our lives are turned off, and stay off. And as the sun comes up over Gloucestershire this morning, there they are, resplendent in the mist-piercing light of RITTER’s multispectral sensors: terabytes of storage laid out around the scalped doughnut of the former GCHQ building. Enough quantum storage to hold decades of the world’s pillow talk. Drums of redundant ethernet cable stacked stories-high. Everything dismantled, disconnected, unshielded. Everything damp with morning dew.

I was pointed to this discussion thread which is talking about how to make podcast episodes findable for services like Huffduffer.

The logic behind Huffduffer’s bookmarklet goes something like this…

1. Find any a elements that have href values ending in “.mp3” or “.m4a”.
2. If there’s just one audio on the page, use that.
3. If there are multiple audio, offer a list to the user and have them choose.

If that doesn’t work…

1. Look for a link element with a rel value of “enclosure”.
2. Look for a meta element property value of “og:audio”.
3. Look for audio elements and grab either the src attribute of the element itself, or the src attribute of any source elements within the audio element.

If that doesn’t work…

1. Try to find a link to an RSS feed (a link that looks like “rss” or “feed” or “atom”).
2. If there is a feed, parse that for enclosure elements and present that list to the user.

That covers 80-90% of use cases. There are still situations where the actual audio file for a podcast episode is heavily obfuscated—either with clickjacking JavaScript “download” links, or links that point to a redirection to the actual file.

If you have a podcast and you want your episodes to be sharable and huffduffable, you have a few options:

Have a link to the audio file for the episode somewhere on the page, something like:

<a href="/path/to/file.mp3">download</a>

That’s the simplest option. If you’re hosting with Soundcloud, this is pretty much impossible to accomplish: they deliberately obfuscate and time-limit the audio file, even if you want it to be downloadable (that “download” link literally only allows a user to download that file in that moment).

If you don’t want a visible link on the page, you could use metadata in the head of your document. Either:

<link rel="enclosure" href="/path/to/file.mp3">

Or:

<meta property="og:audio" content="/path/to/file.mp3">

And if you want to encourage people to huffduff an episode of your podcast, you can also include a “huffduff it” link, like this:

<a href="https://huffduffer.com/add?page=referrer">huffduff it</a>

You can also use ?page=referer—that misspelling has become canonised thanks to HTTP.

There you go, my podcasting friends. However you decide to do it, I hope you’ll make your episodes sharable.

Introducing Soundslice offline mode | The Soundslice Blog

Adrian documents how he’s using Service Workers on Soundslice. I could imagine doing something similar for The Session.

Responsive Image Breakpoints Generator by Cloudinary

A very handy tool for figuring out breakpoints for responsive images.

Upload an image in its largest size, play around with the settings, and then generate the breakpoints, the markup, and the resized images for each breakpoint.

Performance Budget Builder

A nifty tool from Brad to help calculate and allocate performance budgets. Click around and edit the numbers.

EnhanceConf line-up by Simon McManus

This is shaping up to be a great affordable one-day event in London on March 4th. The format will be similar to Responsive Day Out.

I suggest you grab a ticket.

Setting up CloudFront and TLS (HTTPS) with Jekyll – olivermak.es

Remember when I mentioned that you can get free certificates from Amazon now? Well, Oliver has written an in-depth step-by-step description of how he got his static site all set up with HTTPS.

More of this please! Share your experiences with moving to TLS—the more, the better.

The elements of HTML

A complete list of HTML elements, past and present. They’re all hyperlinked to the relevant specs.

Glittering Blue

Earth as seen on one day in 2015 from Himawari-8. Beautiful.

Follow the links | A Working Library

The ability to follow links down and around and through an idea, landing hours later on some random Wikipedia page about fungi you cannot recall how you discovered, is one of the great modes of the web. It is, I’ll go so far to propose, one of the great modes of human thinking.

Developer Fallacies | HeydonWorks

Some of the explanations get a little ranty, but Heydon’s collection of observed fallacies rings true:

• The gospel fallacy
• The Luddite fallacy
• The scale fallacy
• The chocolate fireguard fallacy
• The pull request fallacy
• The ‘made at Facebook’ fallacy
• The Bob the Builder fallacy
• The real world fallacy
• The Daphne and Celeste fallacy

I’ve definitely had the Luddite fallacy and the scale fallacy thrown in my face as QEDs.

The ‘made at Facebook’ fallacy is pretty much identical to what I’ve been calling the fallacy of assumed competency: copying something that large corporation X is doing just because large corporation X is doing it.

edX Pattern Library · The Visual, UI, and Front End styleguide for edX’s applications

A nicely documented pattern library.

Revisiting the Float Label pattern with CSS — That Emil is Emil Björklund

A clever technique by Emil to implement the “float label” pattern using CSS. It all hinges on browsers supporting the :placeholder-shown pseudo-class which, alas, is not universal.

I was hoping that maybe @supports could come to the rescue (so that a better fallback could be crafted), but that tests for properties and values, not selectors. Damn!

For a while now, The Session has had some little on-boarding touches to make sure that new members are eased into the culture of this traditional Irish music community.

First off, new members are encouraged to add a little bit about themselves so that there’s some context when they start making contributions.

Secondly, new members can’t kick off a brand new discussion straight away.

Likewise, they can’t post a comment straight away. They need to wait an hour between signing up and posting their first comment. Instead of seeing a comment form, they see a countdown.

Finally, when they do make their first submission—whether it’s a discussion, an event, a session, or a tune—the interface displays a few extra messages of encouragement and care.

But I realised that all of these custom messages were very one-sided. They were always displayed to the new member. It’s equally important that existing members treat any newcomers with respect.

Now on some discussions, an extra message is displayed to existing members right before the comment form. The logic is straightforward:

1. If this is a discussion added by a new member,
2. who hasn’t yet added any comments anywhere,
3. and this discussion has no responses so far,
4. and anyone other than that member is viewing the page,
5. then display a message asking for help making this new member feel welcome.

It’s a small addition, but it makes a difference.

No intricate JavaScript; no smooth animations; just some words on a screen encouraging a human connection.

An invitation to bring back your personal site

I invite you not just to follow along here as I expand into topics beyond design and technology, but to start your own personal blog up again if you’ve been neglecting it for a while. I’m really interested in the things you are passionate about. I want to learn from you.

Words of Wisdom from @adactio - Matt Radford

A larger screen is now a progressive enhancement. Hell, with things like Siri and Google Now and Amazon’s Echo, we’re getting to the point where even a screen is an enhancement.

The Art of Debugging

I was just helping out with some debugging at work and it reminded me of this great talk/post by Remy:

1. Replicate: see the bug
2. Isolate: understand the bug
3. Eliminate: fix the bug

New – AWS Certificate Manager – Deploy SSL/TLS-Based Apps on AWS | AWS Official Blog

If you’re hosting with Amazon, you now get HTTPS for free.

The Facebook-Loving Farmers of Myanmar - The Atlantic

A fascinating slice of ethnographic research in Myanmar by Craig. There’s no mention of the web, which is certainly alarming, but then again, that’s not the focus of the research.

Interestingly, while Facebook is all omnipresent and dominant, nobody is using it the way that Facebook wants: all the accounts are basically “fake”.

What I found fascinating are the ways that people have found to bypass app stores. They’re basically being treated as damage and routed ‘round. So while native apps are universal, app stores would appear to be a first world problem.

Now if there were only some kind of universally accessible distribution channel that didn’t require any kind of installation step …hmmm.

RWD Interview with Jeremy Keith and Trent Walton

Myself and Trent answer some questions on responsive design for Justin’s excellent newsletter.

JavaScript web apps considered valuable · molily

A response to a rant I linked to recently.

The solution for bad JavaScript web apps is not to abandon them altogether, but to make better ones.

I couldn’t agree more. The tools have evolved and we now have frameworks and practices that allow us to render from the server and use the same code to render on the client, progressively enhancing from a solid robust base.

JavaScript is the best technology to build excellent interactivity in the browser. Still, the most important skill of a client-side JavaScript developer is to know when not to solve a problem with client-side JavaScript. It’s always more robust to solve a problem further down in the stack.

The problem is that I don’t see a willingness from developers to embrace this way of thinking. Instead I see it dismissed as being unrealistic or more expensive.

Still, it always takes time for behaviour to change so maybe things will only get better. I certainly hope so.

2015 Year in Review | codebar

Codebar had a very good 2015.

Of the 137 workshops run, “100 of those workshops were organised by our two busiest chapters, London and Brighton”—50 each.

Why I love working with the web

I love this. I really love this. Remy absolutely nails what makes the web so great.

There’s the ubiquity:

If the viewer is using the latest technology beefy desktop computer that’s great. Equally they could view the website from a work computer, something old and locked in using a browser called IE8.

Then there’s the low barrier to entry—yes, even today:

It’s the web’s simplicity. Born out of a need to connect documents. As much as that might have changed with the latest generation of developers who might tell you that it’s hard and complex (and they’re right), at the same time it is not complicated. It’s still beautifully simple.

Anyone can do it. Anyone can publish content to the web, be it as plain text, or simple HTML formed only of <p> tags or something more elaborate and refined. The web is unabashed of it’s content. Everything and anything goes.

I might just print this out and nail it to the wall.

If you sit back for a moment, and think about just how many lives you can touch simply by publishing something, anything, to the web, it’s utterly mind blowing.

I was in London again today. A team from Clearleft have their sprint playbacks every second Tuesday at the client’s offices on The Strand. I tag along for the ride, and to marvel at the quality of the work being produced in each sprint. Then I duck out when it’s time for them to plan the next sprint—I don’t want to be the extra cook that spoils that particular broth.

Usually I would just head straight back to Brighton, nice and early, avoiding the after-work rush. But today was such a beautiful, crisp, clear winter’s day that I tarried a while. Instead of hopping on the tube back to Victoria, I perambulated.

At Trafalgar Square, I marvelled at the fact that the National Gallery is right there, free to the public. I could just walk right in and admire one of the world’s finest collections of art. So I did.

One minute I was on a typical London street, complete with obligatory Pret a Manger and Costa Coffee. The next I was standing in front of a Caravaggio, marvelling once again at his use of light—like Renaissance film noir.

Turner, Van Gogh, Seurat, Cézanne; all there for everybody to enjoy. As I stood in front of the Holbein—stepping between the school children to find just the right spot for the skull’s optical illusion—I remembered a conversation I had with Alla just last week.

We were discussing responsive design. I was making the case that there should be parity between small screens and large when it came to accessing content. “But”, said Alla, “what about the emotional impact?” Is it even possible to get the same “wow” factor on a handheld screen that you can get with a wider canvas? She asked me if I had ever had an emotional response to seeing something in an art gallery. I smiled, because her question made her point perfectly. Then I told her about the first time I ever went to the Louvre.

It was my first time ever being in Paris. I wasn’t even supposed to be there. It was the early nineties and I was hitch-hiking around Europe, trying my best to avoid big cities—they’re less than ideal when you have no place to sleep. But through a series of circumstances that probably involved too much wine, I found myself taking a ride into the capital and getting dropped in the middle of the city.

It all worked out okay though. Through an astronomical coincidence, I met someone I knew who put me up for a few nights.

I was standing in Châtelet metro station in the middle of rush hour. Whatever effect that wine had on me was wearing off, and I was beginning to realise what a terrible mistake I had made in coming to Paris. I was studying a city map on the wall, looking for areas of green where I might unroll a sleeping bag in peace, when I heard someone shout “Jeremy!” It was a girl from back home in Cork that I knew through a mutual friend in art college. She was working at Euro Disney for the summer and having finished her day’s work, she missed her metro stop and was switching trains. She just happened to be there at just the right time to take me in.

But that’s not the story I told Alla. I told Alla about what happened during that time in Paris when I busked up enough money to go the Louvre.

I walked in and saw Géricault’s The Raft Of The Medusa. I felt like somebody had punched me in the chest. I was genuinely winded. It was one thing to see a reproduction in a book, but the sheer scale of the thing …I had no idea.

I’ve never had quite the same physical reaction to a piece of art since, but I sometimes feel echoes of it. I think that’s probably one of the reasons why I stepped into the National Gallery today. I was trying to recapture a fragment of that feeling.

Well, that and the fact that it’s free …which really is quite amazing in a city as expensive as London.

A Flag for No Nations | booktwo.org

This a magnificent piece of writing from James …all about pieces of metal fabric.

A single technology – the vacuum-deposition of metal vapour onto a thin film substrate – makes its consecutive and multiple appearances at times of stress and trial: at the dawn of the space age, in orbit and on other planets, at the scene of athletic feats of endurance, in defence and offence in the mountains of the Hindu Kush, on the beaches of the European archipelago. These are moments of hope as well as failure; moments when, properly utilised, technological progress enables us to achieve something which was beyond our capabilities before. And yet: we are still pulling bodies from the water wrapped in material which was meant to send us into space.

Andy’s been playing Devil’s Advocate again, defending the much-maligned hamburger button. Weirdly though, I think I’ve seen more blog posts, tweets, and presentations defending this supposed underdog than I’ve seen knocking it.

Take this presentation from Smashing Conference. It begins with a stirring call to arms. Designers of the web—cast off your old ways, dismiss your clichés, try new things, and discard lazy solutions! “Yes!”, I thought to myself, “this is a fantastic message.” But then the second half of the talk switches into a defence of the laziest, most clichéd, least thought-through old tropes of interface designs: carousels, parallax scrolling and inevitably, the hamburger icon.

But let’s not get into a binary argument of “good” vs. “bad” when it comes to using the hamburger icon. I think the question is more subtle than that. There are three issues that need to be addressed if we’re going to evaluate the effectiveness of using the hamburger icon:

1. representation,
2. usage, and
3. clarity.

Representation

An icon is a gateway to either some content or a specific action. The icon should provide a clear representation of the content or action that it leads to. Sometimes “clear” doesn’t have to literally mean that it’s representative: we use icons all the time that don’t actually represent the associated content or action (a 3.5 inch diskette for “save”, a house for the home page of a website, etc.). Cultural factors play a large part here. Unless the icon is a very literal pictorial representation, it’s unlikely that any icon can be considered truly universal.

If a hamburger icon is used as the gateway to a list of items, then it’s fairly representative. It’s a bit more abstract than an actual list of menu items stacked one on top of the other, but if you squint just right, you can see how “three stacked horizontal lines” could represent “a number of stacked menu items.”

If, on the other hand, a hamburger icon is used as the gateway to, say, a grid of options, then it isn’t representative at all. A miniaturised grid—looking like a window—would be a more representative option.

So in trying to answer the question “Does the hamburger icon succeed at being representative?”, the answer—as ever—is “it depends.” If it’s used as a scaled-down version of the thing its representing, it works. If it’s used as a catch-all icon to represent “a bunch of stuff” (as is all too common these days), then it works less well.

Which brings us to…

Usage

Much of the criticism of the hamburger icon isn’t actually about the icon itself, it’s about how it’s used. Too many designers are using it as an opportunity to de-clutter their interface by putting everything behind the icon. This succeeds in de-cluttering the interface in the same way that a child putting all their messy crap in the cupboard succeeds in cleaning their room.

It’s a tricky situation though. On small screens especially, there just isn’t room to display all possible actions. But the solution is not to display none instead. The solution is to prioritise. Which actions need to be visible? Which actions can afford to be squirrelled away behind an icon? A designer is supposed to answer those questions (using research, testing, good taste, experience, or whatever other tools are at their disposal).

All too often, the hamburger icon is used as an excuse to shirk that work. It’s treated as a “get out of jail free” card for designing small-screen interfaces.

To be clear: this usage—or misusage—has nothing to do with the actual icon itself. The fact that the icon is three stacked lines is fairly irrelevant on this point. The reason why the three stacked lines are so often used is that there’s a belief that this icon will be commonly understood.

That brings us to last and most important point:

Clarity

By far the most important factor in whether an icon—any icon—will be understood is whether or not it is labelled. A hamburger icon labelled with a word like “menu” or “more” or “options” is going to be far more effective than an unlabelled icon.

@andybudd Adding the word “menu” next to it goes a long way, and would help with teaching aspect to help it become more familiar in time.

— Paul Annett (@PaulAnnett) January 16, 2016

Don’t believe me? Good! Do some testing.

In my experience, 80-90% of the benefit of usability testing is in the area of labelling. And one of the lowest hanging fruit is the realisation that “Oh yeah, we should probably label that icon that we assumed would be universally understood.”

Andy mentions the “play” and “pause” symbols as an example of icons that are so well understood that they can stand by themselves. That’s not necessarily true.

@andybudd FWIW, I know some people in their 60s who couldn’t tell you what the two line pause icon would do on a web video player.

— Paul Annett (@PaulAnnett) January 16, 2016

I think there are two good rules of thumb when it comes to using icons:

1. If in doubt, label it.
2. If not in doubt, you probably should be—test your assumptions.

Results

Now that we’ve established the three criteria for evaluating an icon’s effectiveness, let’s see how the hamburger icon stacks up (if you’ll pardon the pun):

1. Representation: It depends. Is it representing a stacked list of menu items? If so, good. If not, reconsider.
2. Usage: it depends. Is it being used as an excuse to throw literally all your navigation behind it? If so, reconsider. Prioritise. Decide what needs to be visible, and what can be tucked away.
3. Clarity: it depends. Is the icon labelled? If so, good. If not, less good.

So there you go. The answer to the question “Is the hamburger icon good or bad?” is a resounding and clear “It depends.”

Don’t tell me what my browser can’t do! by Christian Heilmann

A great piece by Christian on taking a responsible, customer-focused approach to building on the web.

You don’t have to support old browsers and terrible setups. But you are not allowed to block them out. It is a simple matter of giving a usable interface to end users. A button that does nothing when you click it is not a good experience. Test if the functionality is available, then create or show the button.

Yes, this is an argument for progressive enhancement. No, that does not mean you can’t use JavaScript.

You can absolutely expect JavaScript to be available on your end users computers in 2016. At the same time it is painfully naive to expect it to work under all circumstances.

Why I hate your Single Page App by Stefan Tilkov

A linkbaity title for a ranty post. But it’s justified.

My point is that from an architectural perspective, most single page apps are the result of making the wrong choices and missing important opportunities.

The Heroine’s Journey. - WordRidden

I think I’ve shown great restraint in not linking to loads of think-pieces about Star Wars and The Force Awakens, because believe me, I’ve been reading—and listening to—a lot.

What Jessica has written here is about The Force Awakens. But more than that, it’s about Star Wars. But more than that, it’s about childhood. But more than that…

What I’m saying is: if you only read one thing about the new Star Wars film, read this.

It’s tempting to think of testing with screen-readers as being like testing with browsers. With browser testing, you’re checking to see how a particular piece of software deals with the code you’re throwing at it. A screen reader is a piece of software too, so it makes sense to approach it the same way, right?

I don’t think so. I think it’s really important that if someone is going to test your site with a screen reader, it should be someone who uses a screen reader every day.

Think of it this way: you wouldn’t want a designer or developer to do usability testing by testing the design or code on themselves. That wouldn’t give you any useful data. They’re already familiar with what problems the design is supposed to be solving, and how the interface works. That’s why you need to do usability testing with someone from outside, someone who wasn’t involved in the design or development process.

It’s no different when it comes to users of assistive technology. You’re not trying to test their technology; you’re trying to test how well the thing you’re building works for the person using the technology.

In short:

Don’t think of screen-reader testing as a form of browser testing; think of it as a form of usability testing.

I don’t get up to London all that often—maybe once every few weeks; just long enough for the city’s skyline to have changed again. Yesterday was one of those days out in the big smoke.

I started with a visit to the Royal College of Art to see the work in progress exhibition that’s running until Sunday. Specifically, I wanted to see the project by Monika, who was one third of the immensely talented internship collaboration at Clearleft that produced notice.city. Her current project is called Watching the Watchers, all about undersea cables, surveillance, and audio—right up my alley. I think Ingrid, James, Dan, and Georgina would like it.

After that, I entered a metal tube to be whisked across the city to the Hospital Club, where a room had been booked for a most enjoyable Clearleft event. Anna had organised a second of her roundtable gatherings. This time the theme was “going responsive.”

The idea is to gather people together for one afternoon to share experiences and challenges. Anna invited people from all sorts of organisations, from newspapers to e-commerce and everything in between. Some of them were people we already knew, but most of them had no connection to Clearleft at all.

Everything happened the Chatham House Rule so I can’t tell you the details of who said what, but I can tell you that it was very productive afternoon. Some of the companies represented were in the process of switching to responsive, some had already done it, and some were planning it, so it was a perfect mix.

We began with a variation on the lean coffee technique. Splitting into groups, everyone jotted down some topics that they wanted to discuss. We shared those, grouped them, and voted on which order we would discuss them. Each topic got 5 to 10 minutes of discussion. In my group, we discussed strategy, workflow, tools, and more. We could’ve easily talked for longer. Some outcomes (very badly summarised):

• The vision and strategy for a responsive redesign needs to be communicated (and sold) up the chain to stakeholders as well as to the designers and developers in the trenches.
• “Mobile-first” For The Win! Solve the harder problems first.
• Multi-disciplinary teams For The Win! Works well with Agile too.
• A pattern libraries is probably the best tool you can have. So pattern libraries For The Win too!

After a break, we switched over in to a sort of open space exercise. Anyone who has a burning question they want answered writes that question down on an oversize post-it and slaps it on the wall. Now we’ve got a room with questions written on different parts of the wall. If you want to take a stab at answering any of those questions, you write it down on a post it note and slap it next to the question. Everyone does this for a while, going from question to question and having lots of good discussion. Then, at the end, we go from question to question, with the person who originally posted the question taking ownership of summarising the answers.

Some of the questions were:

• How to help people to stop thinking “desktop first”?
• Should designers code? Should developers design? Or Both?
• How do you start to deploy a responsive version of an existing site?
• How do you do responsive ads?
• What is the best tool to use to create responsive designs?
• Would every project benefit from a design system? Is it always worth the investment?

You get the idea. The format worked really well; it was the first time any of us had tried it. We slightly over-ran the time we had allotted for the afternoon, but that’s mostly because there was so much meaty stuff to discuss.

With that productive afternoon done, I made my way to the Bricklayer’s Arms, where by lucky coincidence, a Pub Standards meet-up was happening. I went along for a pint and a chat while I waited for rush hour to ease off: I wanted to avoid the crush before I started making my way back to Brighton. See you next time, Londinium.

Feature.js

A lightweight alternative to Modernizr. It doesn’t add classes to your markup so it’s up to what you do with the results of any test.

It’s perfect for cutting the mustard on a case-by-case basis.

The web is okay

It’s okay to feel stress in response to this rapid development. It’s natural. I hate change, I hate it so so much. I like things to be consistent and for it to have it’s own place. If it doesn’t, I get stressed and my obsessive compulsive tendencies run riot in a desperate attempt to preserve order. This both benefits and hinders my work.

Chimes very nicely with the latest episode of Ctrl+Click Cast.

Stupid Shit No One Needs & Terrible Ideas Hackathon

A one-day event where participants conceptualize and create projects that have no value whatsoever.

September 13th, 2007:

Jeremy Keith looks a bit like Alan Rickman’s Severus Snape in Harry Potter.

February 25th, 2009:

I have to start off by saying—and maybe this will come as no surprise—but you look a lot to me like the guy who plays Snape on Harry Potter. Do you get that? Do you get that a lot?

January 24th, 2013:

I just figured out who @adactio looks exactly like. Try and guess.

— Amber Weinberg (@amberweinberg)

@amberweinberg Please don’t say Severus Snape.

— Jeremy Keith (@adactio)

@adactio lololol I admit, last night when you were bundled up in a scarf you looked SO like him that’s exactly why I thought

— Amber Weinberg (@amberweinberg)

April 24th, 2013:

Another conference, another person telling me I remind them of Severus Snape. Never Alan Rickman, mind …only ever Alan Rickman as Snape.

— Jeremy Keith (@adactio)

January 14th, 2016:

RIP Alan Rickman :-( I always thought he looked a bit like @adactio

— Ian Devlin (@iandevlin)

I’m at Homebrew Website Club. I figured I’d use this time to document some tweaking I’ve been doing to the back end of my website.

securityheaders.io is a handy site for testing whether your website’s server is sending sensible headers. Think of it like SSL Test for a few nitty-gritty details.

adactio.com was initially scoring very low, but the accompanying guide to hardening your HTTP headers meant I was able to increase my ranking to acceptable level.

My site is running on an Apache server on an Ubuntu virtual machine on Digital Ocean. If you’ve got a similar set-up, this might be useful…

I ssh’d into my server and went to this folder in the Apache directory

cd /etc/apache2/sites-available

There’s a file called default-ssl.conf that I need to edit (my site is being served up over HTTPS; if your site isn’t, you should edit 000-default.conf instead). I type:

nano default-ssl.conf

Depending on your permissions, you might need to type:

sudo nano default-ssl.conf

Now I’m inside nano. It’s like any other text editor you might be used to using, if you imagined what it would be like to remove all the useful features from it.

Within the <Directory /var/www/> block, I add a few new lines:

<IfModule mod_headers.c>
  Header always set X-Xss-Protection "1; mode=block"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set X-Content-Type-Options "nosniff"
</IfModule>

Those are all no-brainers:

• Enable protection against cross-site-scripting.
• Don’t allow your site to be put inside a frame.
• Don’t allow anyone to change the content-type headers of your files after they’ve been sent from the server.

If you’re serving your site over HTTPS, and you’re confident that you don’t have any mixed content (a mixture of HTTPS and HTTP), you can add this line as well:

Header always set Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'"

To really up your paranoia (and let’s face it, that’s what security is all about; justified paranoia), you can throw this in too:

Header unset Server
Header unset X-Powered-By

That means that your server will no longer broadcast its intimate details. Of course, I’ve completely reversed that benefit by revealing to you in this blog post that my site is running on Apache on Ubuntu.

I’ll tell you something else too: it’s powered by PHP. There’s some editing I did there too. But before I get to that, let’s just finish up that .conf file…

Hit ctrl and o, then press enter. That writes out the file you’ve edited. Now you can leave nano: press ctrl and x.

You’ll need to restart Apache for those changes to take effect. Type:

service apache2 restart

Or, if permission is denied:

sudo service apache2 restart

Now, about that PHP thing. Head over to a different directory:

cd /etc/php5/fpm

Time to edit the php.ini file. Type:

nano php.ini

Or, if you need more permissions:

sudo nano php.ini

It’s a long file, but you’re really only interested in one line. A shortcut to finding that line is to hit ctrl and w (for “where is?”), type expose, and hit enter. That will take you to the right paragraph. If you see a line that says:

expose_php = On

Change it to:

expose_php= Off

Save the file (ctrl and o, enter) then exit nano (ctrl and x).

Restart Apache:

service apache2 restart

Again, you might need to preface that with sudo.

Alright, head on back to securityheaders.io and see how your site is doing now. You should be seeing a much better score.

There’s one more thing I should be doing that’s preventing me from getting a perfect score. That’s Public Key Pinning. It sounds a bit too scary for a mere mortal like me to attempt. Or rather, the consequences of getting it wrong (which I probably would), sound too scary.

Delicious Changes | The Official Delicious Blog

The first big change you’ll notice is our transition from the javascript front-end framework that has been powering the content at https://www.delicious.com. The engineers who crafted this version of the site are incredibly talented, and their code is amazing. It’s beautiful and powerful, but it has posed several significant challenges for us. For example, the search engines have a real problem reading our content, hindering users’ efforts to use Google or Bing to find what they’re looking for on Delicious.

securityheaders.io

A quick way of testing for some fairly easy to fix security leakage from your server’s headers.

I say easy to fix, but I find the fix for public key-pins pant-shittingly intimidating.

VerbalExpressions/JSVerbalExpressions

Regular expressions are my kryptonite so I can definitely imagine using the PHP port of this plain English syntax.

When I wrote about mobile Safari adding support for touch-action: manipulation, I finished with this snarky observation:

Anyway, I’m off to update my CSS even though this latest fix probably won’t land in mobile Safari until, oh ….probably next October.

Historically, Apple have tied mobile Safari updates to iOS version number increments, and they happen about once a year. But this time, it looks like my snark was unfounded:

On Safari for iOS, the 350 ms wait time to detect a second tap has been removed to create a “fast-tap” response. This is enabled for pages that declare a viewport with either width=device-width or user-scalable=no. Authors can also opt in to fast-tap behavior on specific elements by using the CSS touch-action property, using the manipulation value.

That’s from the release notes for Safari 9.1—a point release.

I’m very pleased to have been absolutely wrong with my prediction of Apple’s timing.

Day 12: I know Kung Fu – 12 Devs of Xmas

Adam Onishi on teaching and learning:

As web developers, with the constant change in our industry, learning becomes a necessary part of our jobs. However with the right environment I think we can make that learning experience easier and actually a fun part of what we do.

When Charlotte published her end-of-year report, she outlined her plans for 2016, which included “Document my JavaScript learning journey.”

I want to get into the habit of writing one JavaScript post every week to make sure I keep up with learning it. Even if it’s just a few words about some relevant terminology; it can be as long or short as desired or time allows, as long as it happens.

An excellent plan! If you really want to make sure you’ve understood something, write down an explanation of it. There’s nothing quite like writing to really test your grasp of an idea. Even if nobody else ever reads it, it’s still an extremely valuable exercise for yourself.

Charlotte has already started. Here’s a short post on using JavaScript to pick a random an item at random from an array:

Math.round(Math.random() * (array.length - 1))

It might seem like a small thing, but look what you have to understand:

• How Math.round works (pretty straightforward—it rounds a floating point number to the nearest whole number).
• How Math.random works (less straightforward—it gives a random number between zero and one, meaning you have to multiply it to do anything useful with the result).
• How array.length works (seems straightforward—it gives you the total number of items in an array, but then catches you out when you realise there can never be an index with that total value because the indices are counted from zero …which gives rise to an entire class of programming error).

I really like this approach to learning: document each small thing as you go instead of waiting until all those individual pieces click together. That’s the approach Andy took when he was learning CSS and it led to him writing a book on the subject.

When it comes to problem-solving in general (and JavaScript in particular), I have a similar bias towards single-purpose solutions. Rather than creating a monolithic framework that attempts to solve all possible problems, I prefer a collection of smaller scripts that only do one thing, but do it really well; the UNIX philosophy.

Take, for example, Remy’s bind.js. It does two-way data-binding and nothing else. If you only need one-way data-binding, there’s Simulacra.js, which takes a similar minimalist, hands-off approach.

This approach of breaking large problems down into a collection of smaller problems also came up in a completely unrelated discussion at work recently. I floated the idea of starting a book club at Clearleft. Quite a few people are into the idea, but they’re not sure they could commit the time to reading a book on a deadline. Fair enough. Perhaps we could have the book club on a chapter-by-chapter basis? I don’t think that would work all that well for novels, but it did make me think of something related to Charlotte’s stated goal of learning more JavaScript…

Graham has been raving about the You Don’t Know JS book series by the supersmart Kyle Simpson. I suggested to Charlotte that we read through the books at the rate of one chapter a week. The first book is called Up and Going and our first chapter will be Into Programming, starting this week. Then at the end of the week we’ll get together to compare notes.

I’m hoping that by doing this together, there’s more chance that we’ll actually see it through to completion:

Why can I hit deadlines imposed by others, but not those imposed by myself?

WTF Opera Mini?!

The proxy browser Opera Mini is one of the most popular mobile browsers in the world, and rightly so. Ire Aderinokun has put together a handy collection—based on caniuse.com data—of all the features that are unavailable or only partially available in that browser. The point here is not to avoid using these features, but to make sure you’ve got a solid fallback in place:

This isn’t about bashing the problem, but figuring out the solution.

How the Web Works: A Primer for Newcomers to Web Development (or anyone, really) by Preethi Kasireddy

This is a great reminder of the fundamental nuts’n’bolts of the internet and the World Wide Web: clients, servers, URLs, DNS, HTTP, TCP/IP, packet switching, and all the other building blocks we sometimes take for granted.

This is part one of a four-part series:

1. A Primer for Newcomers to Web Development (or anyone, really)
2. Client-Server Model & the Structure of a Web Application
3. HTTP & REST
4. Stay tuned…

Using System Fonts in the Browser

We have some new font keywords that are basically shortcuts to using the system fonts on a device. This article explains the details.

Telegraph

A handy new service from Aaron, for those situations when you need to manually send webmentions.

20 Years Ago Today

A lovely reminiscence from Matt on how he came to fall in love with the World Wide Web.

I really hope he posts this on his own site—it’ll be a shame when this disappears along with everything else being posted to Medium.

Reimagining Single-Page Applications With Progressive Enhancement – Smashing Magazine

Some really great thinking here by Heydon on how to make single page apps but using HTML for the views instead of relying on client-side JavaScript for the rendering. He explains the code he’s using, but what really matters here isn’t the specific solution; it’s the approach. Smart!

You can listen to an audio version of The Force Awakens.

I’d like to talk about The Force Awakens (I mean, really, how can I not?) so there will be inevitable spoilers. Bail now if you haven’t seen the film.

Star Wars was a big part of my childhood. By extension—and because I’ve never really grown up—Star Wars has always been part of my identity, at least in the shallow sense of what I’d list under “hobbies and interests” on a theoretical form. Still, I could relate to Michael’s feelings in the run-up to the new film’s release:

Despite much evidence to the contrary, I don’t hang too many of my wants and needs on Star Wars or its continuing life as a franchise. I’m the fan-equivalent of a deep history archeologist, not a pundit or an evangelist.

While I’ve always been a big fan of Star Wars: The Films, I’ve never cared much about Star Wars: The Franchise. When my local pub quiz for nerds—The Geekest Link—has a Star Wars night, I enter with a prayer of “please no ‘Expanded Universe’, please no ‘Expanded Universe’.”

When I heard that Lucasfilm had been sold to Disney, I was intrigued—this could get interesting! When I heard that J.J. Abrams would be directing Episode VII, I was pretty happy—I like his work, and he’s a safe pair of hands. But I didn’t want to get too excited. Partly that’s because I’ve been burnt before—although I’m something of a prequels apologist in comparison to the hatred they inspired in most people. Mostly though, it’s because I’m aware that when it comes to something that doesn’t yet exist—whether it’s a Star Wars film, a forthcoming album, or an upcoming project at work—the more hope you place on its shoulders, the more unlikely it is to be able to fulfil those over-inflated expectations.

But as The Force Awakens drew closer and closer, despite my best intentions, I couldn’t help but get excited. Jessica and I watched and re-watched the trailers. The day that tickets went on sale, the website for my cinema of choice crashed, so I picked up the phone and waited in a queue to secure seats for the minute-past-midnight first showing (if you know how much I dislike telephonic communication, you’ll appreciate how unusual that action was for me).

I began to literally count down the days. In the final week, Jessica and I re-watched the Star Wars films in Machete Order, which I can highly recommend. That culminated on the evening of December 16th with a gathering ‘round at Andy’s to eat some food, watch Return Of The Jedi, and then head to the cinema before midnight. By the time I was sitting in my seat surrounded by equally enthusiastic fans, I was positively aquiver with excitement.

When the fanfare blasted and the Star Wars logo appeared, I was grinning from ear to ear. Then I experienced something really wonderful: I had no idea what was going to happen next. Going into this film with no knowledge of plot details or twists was the best possible way to experience it.

I didn’t know what the words of the opening crawl would be. I didn’t know who any of the characters were. I didn’t know what anybody was going to say. I know that sounds like a weird thing to fixate on—after all, didn’t we get that with the prequel films too? Well, not really. Because they were all backstory, there were clearly-delineated constraints on what could and couldn’t happen in those films. But with these new films, anything is possible.

I really, really, really enjoyed watching The Force Awakens. But in order to truly evaluate the film on its own merits, I knew I’d have to see it again in more normal circumstances (and who am I kidding? I didn’t need much of an excuse to see it again).

I’ve seen it three times now. I loved it every time. If anything, the things that slightly bothered me on first seeing the film have diminished with subsequent viewings. It stands up to repeat watching, something that isn’t necessarily true of other J.J. Abrams films—I enjoyed Star Trek Into Darkness when I first saw it, but with every time I see it again, it grows a little weaker.

As I said, there were things that slightly bothered me and I’ll get to those, but my overwhelming feelings about this film are very, very positive. I think the world-building is really good. I think the film itself is superbly crafted, as described in this excellent point-by-point analysis by Chris Dickinson. But above all, what I love the most about The Force Awakens are the characters.

Rey. What can I say? She is quite simply a wonderfully-written character brought to life by an astonishingly good performance. And of course I’m going to join in the chorus of people who are glad that we finally get a lead role for a woman in this galaxy. Granted, Star Wars: The Force Awakens isn’t exactly Mad Max: Fury Road, but still, how great is it that 2015 has given us both Rey and Furiousa?

(You know what it is? It’s a good start.)

Likewise with Finn: great character; great performance. Throw in Kylo Ren, Poe Dameron and even BB8 …I’m sold. I’m invested in their stories now. I want to know what happens next. I want to spend time with them.

But The Force Awakens wasn’t just about new heroes and villains. As audacious as it would be to start from an entirely clean slate, it also needed to tie in to the beloved original films. On the whole, I think this film did a good job of balancing the past and the future.

Paul came along to that midnight viewing; a ticket became available at the last minute. But he was prepared not to enjoy it, or even understand it, given that he’s never really watched Star Wars.

“Actually”, I said, “I’d be really interested to find out what you think of it.”

I’m too close to the source material; I can’t objectively judge whether the new film could stand on its own, as opposed to be being the latest episode in an existing saga.

As it turned out, Paul really enjoyed it. Sure, there was stuff he was aware he was missing out on, but interestingly, there was even more stuff that we were all missing out on: the script is filled with references to events that happened in the intervening decades between the old films and the new. I liked that a lot. It helped solidify this as being simultaneously a brand new chapter and also just one sliver of a larger ongoing narrative.

The Force Awakens is very much a bridging piece between the old and the new. The torch was passed on with dignity, and surprisingly, it was Harrison Ford’s Han Solo that made it a convincing handover.

I say “surprisingly” because remember, we had just watched Return Of The Jedi before The Force Awakens and it is so clear that Harrison Ford really didn’t want to be in that film. I know Han Solo is supposed to be somewhat sarcastic, but it was dialled up to 11 for Jedi, and I’m pretty sure it was a very, shall we say, “naturalistic” performance. But here he is over thirty years later, really breathing life into the character.

Through the stewardship of Harrison Ford, we were lovingly taken from the original films that we know so well into a new story. Han Solo picked up the audience like it was a child that had fallen asleep in the car, and he gently tucked us into our familiar childhood room where we can continue to dream. And then, with a tender brush of his hand across the cheek, he left us.

In many ways, Han Solo in The Force Awakens is Ben Kenobi in Star Wars …but with a much more fleshed-out history and a more interesting personal journey. Now he’s the one saying that the Force is real (and he does it in the very spot where he originally ridiculed Kenobi). It’s as if Scully were to slowly come around to Mulder’s worldview and finally intone “I want to believe.”

The biggest gripe that other people have with The Force Awakens is how much the plot resembles that of the original Star Wars. It’s undeniable. The question is how much that matters, and a result, how much it bothers you. It really bothered Khoi. It somewhat bothered Andy. It didn’t bother me much, but it was definitely an aspect that prevented the film from being a complete triumph. But it’s also one of those issues that diminishes with repeated viewing.

Those bothered by the echoes between Star Wars and The Force Awakens are going to be really pissed off when they find out about World War One and World War Two. “Britain and America fight Germany again? Really!?” (Probably best not to even mention any of the Gulf wars).

I get the feeling though that the people who are bothered by the plot are perhaps overplaying the similarities and underplaying the differences.

So yes, in one sense Rey in The Force Awakens is like Luke in Star Wars—a young person on a desert planet far from the action. But then there are the differences: where Luke was whining about his situation, Rey is mastering hers. And of course there’s the fact that he in 1977 is now she in 2015. “That doesn’t make any difference!” you may cry, and you’d be exactly right: it shouldn’t make any difference …so why has it taken us four decades to get to this?

The casting of Rey and Finn is simultaneously unimportant and monumental. It’s unimportant in that it makes no difference to the story whether Rey is a woman or Finn is black. It’s monumental in that they are the main characters in what everyone knew would be the biggest film of the century so far.

One of the other complaints that people have with The Force Awakens is the unclear political background. Here’s Michael again:

The rebels killed the Emperor and won, but now they’re ‘the resistance’? Why? They’re backed by the republic, so why aren’t they just the armed forces of the republic? The First Order strikes against the republic (looked like Coruscant, but apparently wasn’t). How big is the First Order? Big enough to build Starkiller Base, but what does that mean? Do they control systems? Do they have support inside the republic? Is this like a separatists thing? How long have they been around? How are they funded?

This certainly bugged me. It was the kind of issue that could have been fixed with one explanatory scene. Sure enough, it turns out that such a scene was shot but then cut from the film. Mostly that was to keep the film’s running time down, but I suspect that after the dull talkiness of the prequels, there may also have been some overcompensating course-correction away from anything with even a whiff of politics. Alas, that phobia of trade routes and senators resulted in an unclear backstory. It wasn’t until my third viewing that I realised that Hux’s speech is the closest thing to a blackboard scene for the galactic geopolitics: there’s a proxy war between wannabe extremists looking to set up a caliphate (think ISIS) and a resistance (think the Kurds) being funded by the dominant power (think America) …up until The First Order carry out a 9-11/Pearl Harbour/Vulcan scale attack, leaving the balance of power wide open—the next film could take it in any direction.

One of the most impressive achievements of The Force Awakens is that after seeing it, I didn’t want to think about how it tied back to the original films, as I expected I would want to do. Instead, I was entirely preoccupied with questions of what’s going to happen next.

Everyone is talking about Rey. Where is she from? What is her parentage? The most popular theories are currently:

1. She is Luke Skywalker’s daughter.
2. She is Han and Leia’s daughter, the secret sister of Kylo Ren.
3. She is Ben Kenobi’s granddaughter.

Personally, I’d like it if her parentage were unremarkable. Maybe it’s the socialist in me, but I’ve never liked the idea that the Force is based on eugenics; a genetic form of inherited wealth for the lucky 1%. I prefer to think of the Force as something that could potentially be unlocked by anyone who tries hard enough.

But there are too many hints at Rey’s origins for her parentage to go unexplained. All the signs point to her having some kind of connection to existing bloodlines. Unless…

Lawrence Kasdan has been dropping hints about how odd Episode VIII is going to be, mostly because it has Rian Johnson at the helm. He gave us the terrific Looper. One of the most unsettling aspects of that film was the presence of a child with buried potential for destruction through telekinetic powers. For everyone’s safety, the child is kept far from civilisation.

Okay, I know it’s a stretch but what if Rey is on Jakku for similar reasons? Her parents aren’t Skywalkers or Kenobis, they’re just scared by the destructive episodes they’ve experienced with their Force-sensitive infant. With enormous reluctance—but for the greater good—they deposit her on a faraway world.

No?

Okay, well, if you don’t like that theory, you’re going to hate this one:

What if Rey is the daughter of Luke and Leia?

Eww! I know, I know. But, hey, you can’t say the signs weren’t there all along. And the shame of an incestuous union could be the reason for the child’s secret exile.

It’s preposterous of course. Even in a post-Game Of Thrones landscape, that would be going too far, even for Rian Johnson …or would it?

Now I’ve planted the idea in your head. Sorry about that.

Still, how great is it that we we’re all talking about what’s going to happen next?

Some people have asked me where I think The Force Awakens ranks in comparison to the other Star Wars films, and I wasn’t prepared for the question. I honestly haven’t been thinking about it in the context of the original films. Instead I’ve been thinking about the new characters and the new storyline. As Maz Kanata would say:

The belonging you seek is not behind you, it is ahead.

Simply Jonathan: Multiple values for checkboxes

Following on from the post by Aaron that I linked to, more details about sending (and receiving) values from multiple checkboxes with the same name.

12 Little-Known CSS Facts (The Sequel)

I somehow missed this when it was first published last Summer: a collection of twelve obscure CSS knowledge grenades.

You learn something new every day. I just learned twelve somethings.

The Problem with Progressive Enhancement by Alex Lande

I think that “Do we want to support users without JS?” is the wrong question. Progressive enhancement has benefits that reach far beyond that user group.

Specifically:

1. Performance—”Progressively enhanced behaviors like using links that point to real URLs, or server-side form submission handling, allow users to perform important actions before JavaScript loads.”
2. Resilience—”If users can perform critical tasks when your JS breaks, it’s a minor inconvenience instead of a show stopper.”
3. Business, Business, Business.

re:Work - Superpowers at work: OKRs

We’re about to start trying out OKRs (Objectives and Key Results) at Clearleft. It’s a terrible, jargony label, and a lot of the discussion around them is steeped in valleywank, but I think they could be a useful way of helping shared understanding within a company.

I’ll be having a read through the accompanying guide.

Affirming User Choice With Checkboxes, From the Notebook of Aaron Gustafson

Well, this is timely! Just today I was having a really good natter with Charlotte about using checkboxes, specifically sending multiple values to the server:

You’ll notice that the name given to each of these checkbox input elements is the same: “reservation-requested-device[]”. The square brackets (“[]”) at the end of the name are the magic bit that allows the values of each chosen “reservation-requested-device” checkbox to be submitted as the value of “reservation-requested-device”.

See, I wasn’t sure whether that was just a PHP thing (the only server-side input-handling I’ve had much experience of) or whether it was a more general way of sending multiple values.

Update: It seems that the square brackets are indeed a PHP thing. Multiple values will be sent in any case. See this test case.

And that was it really, I knew what I wanted to do, I wanted to build websites

Jake describes the pivotal moment of his web awakening:

I explored the world wide web. I was amazed by the freedom of information, how anyone could publish, anyone could read. Then I found a little button labeled “View source”. That was the moment I fell in love with the web.

It all goes back to having a ZX Spectrum apparently. Pah! Luxury! I had a ZX81—one K of RAM …1K! Tell that to the young people today, and they wouldn’t believe you.

Anyway, this is a lovely little reminiscence by Jake, although I have no idea why he hasn’t published it on his own site.

ScrollReveal

A nice self-contained script for animating items into view as the document scrolls.

I’d like be interested to hear what Graham thinks of this code—he’s my go-to person for smooth scroll-based animations.

(I’m very confused by the tagline for ScrollReveal—”Easy scroll animations for web and mobile browsers”—eh? Mobile browsers are web browsers …”web” is not a synonym for “desktop”.)

What a year! What next? | Charlotte Jackson, Front-end developer

I got a little verklempt reading this.

Content and Display Patterns | Brad Frost

Brad follows up with his thoughts on Dan’s article, emphasising the importance of a developer’s role in not just slavishly recreating what’s in a static comp, but seeing through to the underlying pattern beneath:

It’s so incredibly crucial to treat development as a key part of the design process.

“Content & Display Patterns,” an article by Dan Mall

A really terrific article from Dan on building pattern libraries. In summary:

1. Naming things is hard,
2. Separation of content and presentation is A Good Thing.

There are some really good insights here into getting just the right level of abstraction for a component—not too tightly tied to a specific visual display, but also not too tightly tied to a specific kind of content type:

When thinking about patterns, content strategists are primarily thinking about Content patterns, designers are primarily thinking about Display patterns, and front-end developers are responsible for bringing the two together.

(And it’s great to see Charlotte’s excellent article get a shout-out in the “Related reading” section at the end,)

Installing Letsencrypt on Ubuntu 14.04 and nginx | gablaxian.com

If you’re planning the move to TLS and your server is on Digital Ocean running Nginx, Graham’s here to run you through the (surprisingly simple) process.

Mike Hill - Industrial Design in Entertainment on Vimeo

A terrific analysis of industrial design in film and games …featuring a scene-setting opening that delineates the difference between pleasure and happiness.

Simple inline error message pattern

This is my go-to method for adding validation messages to forms—I think I first heard about it from Derek—so it’s nice to see it corroborated by Steve:

Add the error message as a child of the label element associated with an input.

Will 2016 be the year web advertisers realise we don’t want to be monitored?

Ethan Zuckerman:

This is advertising we’re talking about, the industry founded on the hallucination that people secretly appreciate being tracked, analysed and told what to buy. Advertisers, and the technology companies that cater to them, are responding to ad blocking the only way they know how: doubling down on their fantasy that viewers will suddenly love advertising just as soon as ads are so all-knowing that they anticipate one’s every need and desire.

I usually write a little post at the end of each year, looking back at the previous 365 days. But this time I feel like I’ve already done that. I’ve already written about my year of learning with Charlotte, which describes what I’ve been doing at work for the last twelve months.

Apart from that, there isn’t much more to say about 2015. And that’s a good thing. 2014 was a year tainted by death so I’m not complaining about having just had a year with no momentous events.

The worst that could be said of my 2015 is that Clearleft went through a tough final quarter of the year (some big projects ended up finishing around the same time, which left us floundering for new business—something we should have foreseen), but in the grand scheme of things, that’s not exactly a tragedy.

Mostly when I think back on the year, my memories are pleasant ones. I travelled to interesting places, ate some great food, and spent time with lovely people—Jenn and Sutter’s wedding being a beautiful blend of all three.

So instead of doing a year-end roundup of my own, I’ll just point to some others: James, Alice, Laura, Eliot, Remy, and Brad.

I look forward to reading more posts on their websites in 2016. I hope that you’ll be publishing on your website this year too.

Happy new year!

jordanmoore/Modern-Default-HTML

This is so weird—Jordan Moore’s boilerplate responsive HTML template is exactly the same as mine! What are the odds‽

(I was once asked to contribute a boilerplate starter for

The Website Obesity Crisis

As promised, Maciej has posted the transcript of his excellent Web Directions talk on performance.

So, so good.