An Event Apart Seattle 2017: Let’s Build a Website (and Talk About The Job of Front-End Design and Development) by Chris Coyier

The last session of the conference was what Chris referred to as an “all-day session”. Chris spoke extensively on multiple topics throughout the day, all of which centered around the idea that writing a website today has a lot of complexity.

Truth be told, most of us in the audience know perfectly well how to build a website, at least to the point that we can build something and get it into publication. Some days it seems like everyone and a whole bunch of things (looking at you, frameworks) believe they know how to build a website.

But best practices are harder to identify and codify, especially with the industry moving on so many topics in so many directions at once. The result: this session was a fantastic use of my time, even having been in the industry for over 20 years.

It’s worth nothing that the session was very geared toward front-end development and developers. This was not the session where you were going to learn how to design a website or how to brand or even at the other end how to test. In that sense, it was the most focused session of the conference.

Since it was an all-day session, and since Chris spent a significant amount of that time actively coding, I did my best to capture the highest concepts and did not get every detail. If you’d like ever detail, Chris is teaching another session in Chicago in August.

An Event Apart Seattle 2017 Let’s Build a Website (and Talk About The Job of Front-End Design and Development) by Chris Coyier (pdf)

(which seemed like something I’d need to tell you when referencing later, but really it wasn’t.)\

(Sometimes I feel like the only weirdo doing all her wireframes in Omnigraffle, but I’m fast at it so I’m sticking to it.)

Chris used a good number of these different apps, and different apps for different projects. That’s a great approach because it means you stay fresh with what’s in the market and at the same time don’t get locked in to only way to think about designs and deliverables.

(even that looks kind of clean to me.) (Last year was rough.)

Specs happen when we pave the cowpaths – we codify what the developers are already doing.

As an Information Architect, I approve of this message.

When your selectors are so specific that the CSS rule is so specific it’s as long as this line of text, you’re making your life hard. (Looking at you, Sharepoint. *growl*)

This was aimed at discussing things with your designers. Sometimes they’ll hand over a comp where it looks like the difference between the standard component and an alternate is arbitrary. It might be arbitrary, or it might be intentional. It’s worth the conversation to understand the arbitrary from the unintentional – one fewer thing to test and code.

Note that we’re this far into the session and we’ve written HTML. That’s it. We started with a designed comp and we made sure we knew what we wanted the end result to look like in a prototype. This is an excellent example of building for progressive enhancement. Start with the basics, because they work everywhere, then enhance up. When it’s designed that way you only use the tools you need, you enhance efficiently, and there’s a better chance that your finished product will be accessible.

Chris helped to found Codepen, which is a web-based “playground” application where you can post things you’re working on and others can see the html, css, and javascript. Until seeing it in action, I totally didn’t get it.

I know, because we’ve been trying to use it to lay out forms at the day job. grr.

Amen, Josh.

If you haven’t seen Luke’s work on Mobile First, there are lots of videos to catch up on.

“Tube of content” makes me laugh and simultaneously describes most of my mobile designs.


Eric Portis wrote a good A List Apart article on Responsive Images in Practice that covers scrset.