Tags: tap



Speaking my brains in Boston

I was in Boston last week to give a talk. I ended up giving four.

I was there for An Event Apart which was, as always, excellent. I opened up day two with my talk, The Way Of The Web.

This was my second time giving this talk at An Event Apart—the first time was in Seattle a few months back. It was also my last time giving this talk at An Event Apart—I shan’t be speaking at any of the other AEAs this year, alas. The talk wasn’t recorded either so I’m afraid you kind of had to be there (unless you know of another conference that might like to have me give that talk, in which case, hit me up).

After giving my talk in the morning, I wasn’t quite done. I was on a panel discussion with Rachel about CSS grid. It turned out to be a pretty good format: have one person who’s a complete authority on a topic (Rachel), and another person who’s barely starting out and knows just enough to be dangerous (me). I really enjoyed it, and the questions from the audience prompted some ideas to form in my head that I should really note down in a blog post before they evaporate.

The next day, I went over to MIT to speak at Design 4 Drupal. So, y’know, technically I’ve lectured at MIT now.

I wasn’t going to do the same talk as I gave at An Event Apart, obviously. Instead, I reprised the talk I gave earlier this at Webstock: Taking Back The Web. I thought it was fitting given how much Drupal’s glorious leader, Dries, has been thinking about, writing about, and building with the indie web.

I really enjoyed giving this talk. The audience were great, and they had lots of good questions afterwards. There’s a video, which is basically my voice dubbed over the slides, followed by a good half of questions afterwards.

When I was done there, after a brief excursion to the MIT bookstore, I went back across the river from Cambridge to Boston just in time for that evening’s Boston CSS meetup.

Lea had been in touch to ask if I would speak at this meet-up, and I was only too happy to oblige. I tried doing something I’ve never done before: a book reading!

No, not reading from Going Offline, my current book which I should encouraging people to buy. Instead I read from Resilient Web Design, the free online book that people literally couldn’t buy if they wanted to. But I figured reading the philosophical ramblings in Resilient Web Design would go over better than trying to do an oral version of the service worker code in Going Offline.

I read from chapters two (Materials), three (Visions), and five (Layers) and I really, really liked doing it! People seemed to enjoy it too—we had questions throughout.

And with that, my time in Boston was at an end. I was up at the crack of dawn the next morning to get the plane back to England where Ampersand awaited. I wasn’t speaking there though. I thoroughly enjoyed being an attendee and absorbing the knowledge bombs from the brilliant speakers that Rich assembled.

The next place I’m speaking will much closer to home than Boston: I’ll be giving a short talk at Oxford Geek Nights on Wednesday. Come on by if you’re in the neighbourhood.

Name That Script! by Trent Walton

Trent is about to pop his AEA cherry and give a talk at An Event Apart in Boston. I’m going to attempt to liveblog this:

How many third-party scripts are loading on our web pages these days? How can we objectively measure the value of these (advertising, a/b testing, analytics, etc.) scripts—considering their impact on web performance, user experience, and business goals? We’ve learned to scrutinize content hierarchy, browser support, and page speed as part of the design and development process. Similarly, Trent will share recent experiences and explore ways to evaluate and discuss the inclusion of 3rd-party scripts.

Trent is going to speak about third-party scripts, which is funny, because a year ago, he never would’ve thought he’d be talking about this. But he realised he needed to pay more attention to:

any request made to an external URL.

Or how about this:

A resource included with a web page that the site owner doesn’t explicitly control.

When you include a third-party script, the third party can change the contents of that script.

Here are some uses:

  • advertising,
  • A/B testing,
  • analytics,
  • social media,
  • content delivery networks,
  • customer interaction,
  • comments,
  • tag managers,
  • fonts.

You get data from things like analytics and A/B testing. You get income from ads. You get content from CDNs.

But Trent has concerns. First and foremost, the user experience effects of poor performance. Also, there are the privacy implications.

Why does Trent—a designer—care about third party scripts? Well, over the years, the areas that Trent pays attention to has expanded. He’s progressed from image comps to frontend to performance to accessibility to design systems to the command line and now to third parties. But Trent has no impact on those third-party scripts. That’s very different to all those other areas.

Trent mostly builds prototypes. Those then get handed over for integration. Sometimes that means hooking it up to a CMS. Sometimes it means adding in analytics and ads. It gets really complex when you throw in third-party comments, payment systems, and A/B testing tools. Oftentimes, those third-party scripts can outweigh all the gains made beforehand. It happens with no discussion. And yet we spent half a meeting discussing a border radius value.

Delivering a performant, accessible, responsive, scalable website isn’t enough: I also need to consider the impact of third-party scripts.

Trent has spent the last few months learning about third parties so he can be better equiped to discuss them.

UX, performance and privacy impact

We feel the UX impact every day we browse the web (if we turn off our content blockers). The Food Network site has an intersitial asking you to disable your ad blocker. They promise they won’t spawn any pop-up windows. Trent turned his ad blocker off—the page was now 15 megabytes in size. And to top it off …he got a pop up.

Privacy can harder to perceive. We brush aside cookie notifications. What if the wording was “accept trackers” instead of “accept cookies”?

Remarketing is that experience when you’re browsing for a spatula and then every website you visit serves you ads for spatula. That might seem harmless but allowing access to our browsing history has serious privacy implications.

Web builders are on the front lines. It’s up to us to advocate for data protection and privacy like we do for web standards. Don’t wait to be told.

Categories of third parties

Ghostery categories third-party providers: advertising, comments, customer interaction, essential, site analytics, social media. You can dive into each layer and see the specific third-party services on the page you’re viewing.

Analyse and itemise third-party scripts

We have “view source” for learning web development. For third parties, you need some tool to export the data. HAR files (HTTP ARchive) are JSON files that you can create from most browsers’ network request panel in dev tools. But what do you do with a .har file? The site har.tech has plenty of resources for you. That’s where Trent found the Mac app, Charles. It can open .har files. Best of all, you can export to CSV so you can share spreadsheets of the data.

You can visualise third-party requests with Simon Hearne’s excellent Request Map. It’s quite impactful for delivering a visceral reaction in a meeting—so much more effective than just saying “hey, we have a lot of third parties.” Request Map can also export to CSV.

Know industry averages

Trent wanted to know what was “normal.” He decided to analyse HAR files for Alexa’s top 50 US websites. The result was a massive spreadsheet of third-party providers. There were 213 third-party domains (which is not even the same as the number of requests). There was an average of 22 unique third-party domains per site. The usual suspects were everywhere—Google, Amazon, Facebook, Adobe—but there were many others. You can find an alphabetical index on better.fyi/trackers. Often the lesser-known domains turn out to be owned by the bigger domains.

News sites and shopping sites have the most third-party scripts, unsurprisingly.

Understand benefits

Trent realised he needed to listen and understand why third-party scripts are being included. He found out what tag managers do. They’re funnels that allow you to cram even more third-party scripts onto your website. Trent worried that this was a Pandora’s box. The tag manager interface is easy to access and use. But he was told that it’s more like a way of organising your third-party scripts under one dashboard. But still, if you get too focused on the dashboard, you could lose focus of the impact on load times. So don’t blame the tool: it’s all about how it’s used.

Take action

Establish a centre of excellence. Put standards in place—in a cross-discipline way—to define how third-party scripts are evaluated. For example:

  1. Determine the value to the business.
  2. Avoid redundant scripts and services.
  3. Fit within the established performance budget.
  4. Comply with the organistional privacy policy.

Document those decisions, maybe even in your design system.

Also, include third-party scripts within your prototypes to get a more accurate feel for the performance implications.

On a live site, you can regularly audit third-party scripts on a regular basis. Check to see if any are redundant or if they’re exceeding the performance budget. You can monitor performance with tools like Calibre and Speed Curve to cover the time in between audits.

Make your case

Do competitive analysis. Look at other sites in your sector. It’s a compelling way to make a case for change. WPO Stats is very handy for anecdata.

You can gather comparative data with Web Page Test: you can run a full test, and you can run a test with certain third parties blocked. Use the results to kick off a discussion about the impact of those third parties.

Talk it out

Work to maintain an ongoing discussion with the entire team. As Tim Kadlec says:

Everything should have a value, because everything has a cost.

Building More Expressive Products by Val Head

It’s day two of An Event Apart in Boston and Val is giving a new talk about building expressive products:

The products we design today must connect with customers across different screen sizes, contexts, and even voice or chat interfaces. As such, we create emotional expressiveness in our products not only through visual design and language choices, but also through design details such as how interface elements move, or the way they sound. By using every tool at our disposal, including audio and animation, we can create more expressive products that feel cohesive across all of today’s diverse media and social contexts. In this session, Val will show how to harness the design details from different media to build overarching themes—themes that persist across all screen sizes and user and interface contexts, creating a bigger emotional impact and connection with your audience.

I’m going to attempt to live blog her talk. Here goes…

This is about products that intentionally express personality. When you know what your product’s personality is, you can line up your design choices to express that personality intentionally (as opposed to leaving it to chance).

Tunnel Bear has a theme around a giant bear that will product you from all the bad things on the internet. It makes a technical product very friendly—very different from most VPN companies.

Mailchimp have been doing this for years, but with a monkey (ape, actually, Val), not a bear—Freddie. They’ve evolved and changed it over time, but it always has personality.

But you don’t need a cute animal to express personality. Authentic Weather is a sarcastic weather app. It’s quite sweary and that stands out. They use copy, bold colours, and giant type.

Personality can be more subtle, like with Stripe. They use slick animations and clear, concise design.

Being expressive means conveying personality through design. Type, colour, copy, layout, motion, and sound can all express personality. Val is going to focus on the last two: motion and sound.

Expressing personality with motion

Animation can be used to tell your story. We can do that through:

  • Easing choices (ease-in, ease-out, bounce, etc.),
  • Duration values, and offsets,
  • The properties we animate.

Here are four personality types…

Calm, soft, reassuring

You can use opacity, soft blurs, small movements, and easing curves with gradual changes. You can use:

  • fade,
  • scale + fade,
  • blur + fade,
  • blur + scale + fade.

Pro tip for blurs: the end of blurs always looks weird. Fade out with opacity before your blur gets weird.

You can use Penner easing equations to do your easings. See them in action on easings.net. They’re motion graphs plotting animation against time. The flatter the curve, the more linear the motion. They have a lot more range than the defaults you get with CSS keyword values.

For calm, soft, and reassuring, you could use easeInQuad, easeOutQuad, or easeInOutQuad. But that’s like saying “you could use dark blue.” These will get you close, but you need to work on the detail.

Confident, stable, strong

You can use direct movements, straight lines, symmetrical ease-in-outs. You should avoid blurs, bounces, and overshoots. You can use:

  • quick fade,
  • scale + fade,
  • direct start and stops.

You can use Penner equations like easeInCubic, easeOutCubic and easeInOutCubic.

Lively, energetic, friendly

You can use overshoots, anticipation, and “snappy” easing curves. You can use:

  • overshoot,
  • overshoot + scale,
  • anticipation,
  • anticipation + overshoot

To get the sense of overshoots and anticipations you can use easing curves like easeInBack, easeOutBack, and easeInOutBack. Those aren’t the only ones though. Anything that sticks out the bottom of the graph will give you anticipation. Anything that sticks out the top of the graph will give you overshoot.

If cubic bezier curves don’t get you quite what you’re going for, you can add keyframes to your animation. You could have keyframes for: 0%, 90%, and 100% where the 90% point is past the 100% point.

Stripe uses a touch of overshoot on their charts and diagrams; nice and subtle. Slack uses a bit of overshoot to create a sense of friendliness in their loader.

Playful, fun, lighthearted

You can use bounces, shape morphs, squashes and stretches. This is probably not the personality for a bank. But it could be for a game, or some other playful product. You can use:

  • bounce,
  • elastic,
  • morph,
  • squash and stretch (springs.

You can use easing equations for the first two, but for the others, they’re really hard to pull off with just CSS. You probably need JavaScript.

The easing curve for elastic movement is more complicated Penner equation that can’t be done in CSS. GreenSock will help you visual your elastic easings. For springs, you probably need a dedicated library for spring motions.

Expressing personality with sound

We don’t talk about sound much in web design. There are old angry blog posts about it. And not every website should use sound. But why don’t we even consider it on the web?

We were burnt by those terrible Flash sites with sound on every single button mouseover. And yet the Facebook native app does that today …but in a much more subtle way. The volume is mixed lower, and the sound is flatter; more like a haptic feel. And there’s more variation in the sounds. Just because we did sound badly in the past doesn’t mean we can’t do it well today.

People say they don’t want their computers making sound in an office environment. But isn’t responsive design all about how we don’t just use websites on our desktop computers?

Amber Case has a terrific book about designing products with sound, and she’s all about calm technology. She points out that the larger the display, the less important auditive and tactile feedback becomes. But on smaller screens, the need increases. Maybe that’s why we’re fine with mobile apps making sound but not with our desktop computers doing it?

People say that sound is annoying. That’s like saying siblings are annoying. Sound is annoying when it’s:

  • not appropriate for the situation,
  • played at the wrong time,
  • too loud,
  • lacks user control.

But all of those are design decisions that we can control.

So what can we do with sound?

Sound can enhance what we perceive from animation. The “breathe” mode in the Calm meditation app has some lovely animation, and some great sound to go with it. The animation is just a circle getting smaller and bigger—if you took the sound away, it wouldn’t be very impressive.

Sound can also set a mood. Sirin Labs has an extreme example for the Solarin device with futuristic sounds. It’s quite reminiscent of the Flash days, but now it’s all done with browser technologies.

Sound is a powerful brand differentiator. Val now plays sounds (without visuals) from:

  • Slack,
  • Outlook Calendar.

They have strong associations for us. These are earcons: icons for the ears. They can be designed to provoke specific emotions. There was a great explanation on the Blackberry website, of all places (they had a whole design system around their earcons).

Here are some uses of sounds…

Alerts and notifications

You have a new message. You have new email. Your timer is up. You might not be looking at the screen, waiting for those events.

Navigating space

Apple TV has layers of menus. You go “in” and “out” of the layers. As you travel “in” and “out”, the animation is reinforced with sound—an “in” sound and an “out” sound.

Confirming actions

When you buy with Apple Pay, you get auditory feedback. Twitter uses sound for the “pull to refresh” action. It gives you confirmation in a tactile way.

Marking positive moments

This is a great way of making a positive impact in your user’s minds—celebrate the accomplishments. Clear—by Realmac software—gives lovely rising auditory feedback as you tick things off your to-do list. Compare that to hardware products that only make sounds when something goes wrong—they don’t celebrate your accomplishments.

Here are some best practices for user interface sounds:

  • UI sounds be short, less than 400ms.
  • End on an ascending interval for positive feedback or beginnings.
  • End on a descending interval for negative feedback, ending, or closing.
  • Give the user controls to top or customise the sound.

When it comes to being expressive with sounds, different intervals can evoke different emotions:

  • Consonant intervals feel pleasant and positive.
  • Dissonant intervals feel strong, active, or negative.
  • Large intervals feel powerful.
  • Octaves convey lightheartedness.

People have made sounds for you if you don’t want to design your own. Octave is a free library of UI sounds. You can buy sounds from motionsound.io, targetted specifically at sounds to go with motions.

Let’s wrap up by exploring where to find your product’s personality:

  • What is it trying to help users accomplish?
  • What is it like? (its mood and disposition)

You can workshops to answer these questions. You can also do research with your users. You might have one idea about your product’s personality that’s different to your customer’s. You need to project a believable personality. Talk to your customers.

Designing for Emotion has some great exercises for finding personality. Conversational Design also has some great exercises in it. Once you have the words to describe your personality, it gets easier to design for it.

So have a think about using motion and sound to express your product’s personality. Be intentional about it. It will also make the web a more interesting place.

Why Design Systems Fail by Una Kravets

I’m at An Event Apart Boston where Una is about to talk about design systems, following on from Yesenia’s excellent design systems talk. I’m going to attempt to liveblog it…

Una works at the Bustle Digital Group, which publishes a lot of different properties. She used to work at Watson, at Bluemix and at Digital Ocean. They all have something in common (other than having blue in their logos). They all had design systems that failed.

Design systems are so hot right now. They allow us think in a componentised way, and grow quickly. There are plenty of examples out there, like Polaris from Shopify, the Lightning design sytem from Salesforce, Garden from Zendesk, Gov.uk, and Code For America. Check out Anna’s excellent styleguides.io for more examples.

What exactly is a design system?

It’s a broad term. It can be a styleguide or visual pattern library. It can be design tooling (like a Sketch file). It can be a component library. It can be documentation of design or development usage. It can be voice and tone guidelines.


When Una was in College, she had a print rebranding job—letterheads, stationary, etc. She also had to provide design guidelines. She put this design guide on the web. It had colours, heading levels, type, logo treatments, and so on. It wasn’t for an application, but it was a design system.

Design tooling

Primer by Github is a good example of this. You can download pre-made icons, colours, etc.

Component library

This is where you get the code. Una worked on BUI at Digital Ocean, which described the interaction states of each components and how to customise interactions with JavaScript.

Code usage guidelines

AirBnB has a really good example of this. It’s a consistent code style. You can even include it in your build step with eslint-config-airbnb and stylelint-config-airbnb.

Design usage documentation

Carbon by IBM does a great job of this. It describes the criteria for deciding when to use a pattern. It’s driven by user experience considerations. They also have general guidelines on loading in components—empty states, etc. And they include animation guidelines (separately from Carbon), built on the history of IBM’s magnetic tape machines and typewriters.

Voice and tone guidelines

Of course Mailchimp is the classic example here. They break up voice and tone. Voice is not just what the company is, but what the company is not:

  • Fun but not silly,
  • Confident but not cocky,
  • Smart but not stodgy,
  • and so on.

Voiceandtone.com describes the user’s feelings at different points and how to communicate with them. There are guidelines for app users, and guidelines for readers of the company newsletter, and guidelines for readers of the blog, and so on. They even have examples of when things go wrong. The guidelines provide tips on how to help people effectively.

Why do design systems fail?

Una now asks who in the room has ever started a diet. And who has ever finished a diet? (A lot of hands go down).

Nobody uses it

At Digital Ocean, there was a design system called Buoy version 1. Una helped build a design system called Float. There was also a BUI version 2. Buoy was for product, Float was for the marketing site. Classic example of 927. Nobody was using them.

Una checked the CSS of the final output and the design system code only accounted for 28% of the codebase. Most of the CSS was over-riding the CSS in the design system.

Happy design systems scale good standards, unify component styles and code and reduce code cruft. Why were people adding on instead of using the existing sytem? Because everyone was being judged on different metrics. Some teams were judged on shipping features rather than producing clean code. So the advantages of a happy design systems don’t apply to them.


It’s like going to the gym. Small incremental changes make a big difference over the long term. If you just work out for three months and then stop, you’ll lose all your progress. It’s like that with design systems. They have to stay in sync with the live site. If you don’t keep it up to date, people just won’t use it.

It’s really important to have a solid core. Accessibility needs to be built in from the start. And the design system needs ownership and dedicated commitment. That has to come from the organisation.

You have to start somewhere.


Communication is multidimensional; it’s not one-way. The design system owner (or team) needs to act as a bridge between designers and developers. Nobody likes to be told what to do. People need to be involved, and feel like their needs are being addressed. Make people feel like they have control over the process …even if they don’t; it’s like perceived performance—this is perceived involvement.

Ask. Listen. Make your users feel heard. Incorporate feedback.


Good communication is important for getting buy-in from the people who will use the design system. You also need buy-in from the product owners.

Showing is more powerful than telling. Hackathans are like candy to a budding design system—a chance to demonstrate the benefits of a design system (and get feedback). After a hackathon at Digital Ocean, everyone was talking about the design system. Weeks afterwards, one of the developers replaced Bootstrap with BUI, removing 20,000 lines of code! After seeing the impact of a design system, the developers will tell their co-workers all about it.

Solid architecture

You need to build with composability and change in mind. Primer, by Github, has a core package, and then add-ons for, say, marketing or product. That separation of concerns is great. BUI used a similar module-based approach: a core codebase, separate from iconography and grid.

Semantic versioning is another important part of having a solid architecture for your design system. You want to be able to push out minor updates without worrying about breaking changes.


Use the same convention in your design files, like Sketch.

What about tech stack choice? Every company has different needs, but one thing Una recommends is: don’t wait to namespace! All your components should have some kind of prefix in the class names so they don’t clash with existing CSS.

Una mentions Solid by Buzzfeed, which I personally think is dreadful (count the number of !important declarations—you can call it “immutable” all you want).

AtlasKit by Atlassian goes all in on React. They’re trying to integrate Sketch into it, but design tooling isn’t solved yet (AirBnB are working on this too). We’re still trying to figure out how to merge the worlds of design and code.

Reduce Friction

This is what it’s all about. Using the design system has to be the path of least resistance. If the new design system is harder to use than what people are already doing, they won’t use it.

Provide hooks and tools for the people who will be using the design system. That might be mixins in Sass or it might be a script on a CDN that people can just link to.

Start early, update often. Design systems can be built retrospectively but it’s easier to do it when a new product is being built.

Bugs and cruft always increase over time. You need a mechanism in place to keep on top of it. Not just technical bugs, but visual inconsistencies.

So the five pillars of ensuring a successful design system are:

  1. Investment
  2. Communication
  3. Buy-in
  4. Solid architecture
  5. Reduce friction

When you’re starting, begin with a goal:

We are building a design system because…

Then review what you’ve already got (your existing codebase). For example, if the goal of having a design system is to increase page performance, use Web Page Test to measure how the current site is performing. If the goal is to reduce accessibility problems, use webaim.org to measure the accessibility of your current site (see also: pa11y). If the goal is to reduce the amount of CSS in your codebase, use cssstats.com to test how your current site is doing. Now that you’ve got stats, use them to get buy-in. You can also start by doing an interface inventory. Print out pages and cut them up.

Once you’ve got buy-in and commitment (in writing), then you can make technical decisions.

You can start with your atomic elements. Buttons are like the “Hello world!” of design systems. You’ve colours, type, and different states.

Then you can compose elements by putting the base elements together.

Do you include layout in the system? That’s a challenge, and it depends on your team. If you do include layout, to what extent?

Regardless of layout, you still need to think about space: the space between base elements within a component.

Bake in accessibility: every hover state should have an equal (not opposite) focus state.

Think about states, like loading states.

Then you can start documenting. Then inform the users of the system. Carbon has a dashboard showing which components are new, which components are deprecated, and which components are being updated.

Keep consistent communication. Design and dev communication has to happen. Continuous iteration, support and communication are the most important factors in the success of a design system. Code is only 10% of a sytem.

Also, don’t feel like you need to copy other design systems out there. Your needs are probably very different. As Diana says, comparing your design system to the polished public ones is like comparing your life to someone’s Instagram account. To that end, Una says something potentially contraversial:

You might not need a design sytem.

If you’re the only one at your organisation that cares about the benefits of a design system, you won’t get buy-in, and if you don’t get buy-in, the design system will fail. Maybe there’s something more appropriate for your team? After all, not everyone needs to go to the gym to get fit. There are alternatives.

Find what works for you and keep at it.

Live-blogging An Event Apart Seattle

I tried do some live-blogging at An Event Apart Seattle. I surprised myself by managing to do all six talks on the first day. I even managed one or two after that, but that was the limit of my stamina. Torre, on the other hand, managed to live-blog every single talk—amazing!

Some of the talks don’t necessarily lend themselves to note-taking—ya kinda had to be there. But some of the the live-blogging I did ended up being surprisingly coherent.

Anyway, I figured it would be good to recap all the ones I managed to do here in one handy list.

  1. Beyond Engagement: the Content Performance Quotient by Jeffrey Zeldman. I think I managed to document the essence of what Jeffrey was getting at: for many sites, engagement isn’t the right metric to measure—the idea of a Content Performance Quotient is one alternative.
  2. Digital Marketing Strategies for the Busy “Web Master” by Sarah Parmenter. The structure of Sarah’s talk lent itself well to live-blogging, but I strongly disagreed with one or two of her suggestions (like encouraging people to install the disgusting abomination that is Facebook Pixel).
  3. Scenario-Driven Design Systems by Yesenia Perez-Cruz. This one was hard to live-blog because it was so packed with so many priceless knowledge bombs—an absolutely brilliant presentation, right up my alley!
  4. Graduating to Grid by Rachel Andrew. The afternoon sessions, with their emphasis on CSS, were definitely tricky to capture. I didn’t even try to catch most of the code, but I think I managed to get down most of Rachel’s points about learning new CSS.
  5. Fit For Purpose: Making Sense of the New CSS by Eric Meyer. There was a fair bit of code in this one, and lots of gasp-inducing demos too, so my account probably doesn’t do it justice.
  6. Everything You Know About Web Design Just Changed by Jen Simmons. There was no way I could document the demos, but I think I managed to convey the excitement in Jen’s talk.
  7. Navigating Team Friction by Lara Hogan. I only managed to do two talks on the second day, but I think they came out the best. Lara’s talk was packed full with great advice, but it was so clearly structured that I think I managed to get most of the main points down.
  8. Designing Progressive Web Apps by Jason Grigsby. I had a vested interest in the topic of Jason’s talk so I was scribing like crazy. Apart from a few missing diagrams, I think my notes managed to convey most of Jason’s message.

Of course the one talk I definitely couldn’t live-blog was my own. I’ve documented lists of links relating to the subject matter of my talk, but if you weren’t at An Event Apart Seattle, then the only other chance to see the talk is at An Event Apart Boston in June. That’s the only other time I’m giving it.

I thoroughly enjoyed giving the talk in Seattle, particularly when I treated the audience to a scoop: I announced my new book, Going Offline, during the talk (I had been scheming with Katel at A Book Apart and we co-ordinated the timing to a tee).

Understandable excitement

An Event Apart Seattle just wrapped. It was a three-day special edition and it was really rather good. Lots of the speakers (myself included) were unveiling brand new talks, so there was a real frisson of excitement.

It was interesting to see repeating, overlapping themes. From a purely technical perspective, three technologies that were front and centre were:

  • CSS grid,
  • variable fonts, and
  • service workers.

From listening to other attendees, the overwhelming message received was “These technologies are here—they’ve arrived.” Now, depending on your mindset, that understanding can be expressed as “Oh shit! These technologies are here!” or “Yay! Finally! These technologies are here!”

My reaction is very firmly the latter. That in itself is an interesting data-point, because (as discussed in my talk) my reaction towards new technological advances isn’t always one of excitement—quite often it’s one of apprehension, even fear.

I’ve been trying to self-analyse to figure out which kinds of technologies trigger which kind of reaction. I don’t have any firm answers yet, but it’s interesting to note that the three technologies mentioned above (CSS grid, variable fonts, and service workers) are all additions to the core languages of the web—the materials we use to build the web. Frameworks, libraries, build tools, and other such technologies are more like tools than materials. I tend to get less excited about advances in those areas. Sometimes advances in those areas not only fail to trigger excitement, they make me feel overwhelmed and worried about falling behind.

Since figuring out this split between materials and tools, it has helped me come to terms with my gut emotional reaction to the latest technological advances on the web. I think it’s okay that I don’t get excited about everything. And given the choice, I think maybe it’s healthier to be more excited about advances in the materials—HTML, CSS, and JavaScript APIs—than advances in tooling …although, it is, of course, perfectly possible to get equally excited about both (that’s just not something I seem to be able to do).

Another split I’ve noticed is between technologies that directly benefit users, and technologies that directly benefit developers. I think there was a bit of a meta-thread running through the talks at An Event Apart about CSS grid, variable fonts, and service workers: all of those advances allow us developers to accomplish more with less. They’re good for performance, in other words. I get much more nervous about CSS frameworks and JavaScript libraries that allow us to accomplish more, but require the user to download the framework or library first. It feels different when something is baked into browsers—support for CSS features, or JavaScript APIs. Then it feels like much more of a win-win situation for users and developers. If anything, the onus is on developers to take the time and do the work and get to grips with these browser-native technologies. I’m okay with that.

Anyway, all of this helps me understand my feelings at the end of An Event Apart Seattle. I’m fired up and eager to make something with CSS grid, variable fonts, and—of course—service workers.

Fit For Purpose: Making Sense of the New CSS by Eric Meyer

Time for even more CSS goodness at An Event Apart Seattle (Special Edition). Eric’s talk is called Fit For Purpose: Making Sense of the New CSS. Here are my notes…

Eric isn’t going to dive quite as deeply as Rachel, but he is going to share some patterns he has used.

Feature queries

First up: feature queries! Or @supports, if you prefer. You can ask a browser “do you support this feature?” If you haven’t used feature queries, you might be wondering why you have to say the property and the value. Well, think about it. If you asked a browser “do you support display?”, it’s not very useful. So you have to say “do you support display: grid?”

Here’s a nice pattern from Lea Verou for detecting support for custom properties:

@supports (--css: variables)

Here’s a gotcha:

@supports (clip-path: polygon())

That won’t work because polygon() is invalid. This will work:

@supports (clip-path: polygon(0 0))

So to use feature queries, you need to understand valid values for properties.

You can chain feature queries together, or just pick the least-supported thing you’re testing for and test just for that.

Here’s a pattern Eric used when he only wanted to make text sideways, but only if grid is supported:

@supports (display: grid) {
    @supports (writing-mode: sideways-lr) {

That’s functionally equivalent to:

@supports (display: grid) {
@supports (display:grid) and (writing-mode: sideways-lr) {

Choose whichever pattern makes sense to you. More to the point, choose the pattern that makes sense to your future self when you revisit your code.

Feature queries need to work together with media queries. Sometimes there are effects that you only want to apply on larger viewports. Do you put your feature queries inside your media queries? Or do you put your media queries inside your feature queries?

  • MOSS: Media Outside Support Statements
  • MISO: Media Inside Supports Object

Use MOSS when you have more media switches than support blocks. Use MISO when you only have a few breakpoints but lots of feature queries.

That’s one idea that Eric has. It’ll be interesting to see how this develops.

And remember, CSS is still CSS. Sometimes you don’t need a feature query at all. You could just use hanging-punctuation without testing for it. Browsers that don’t understand it will just ignore it. CSS has implicit feature queries built in. You don’t have to put your grid layout in a feature query, but you might want to put grid-specific margins and widths inside a feature query for display: grid.

Feature queries really help us get from now to the future.


Let’s move on to flexbox. Flexbox is great for things in a line.

On the An Event Apart site, the profile pictures have social media icons lined up at the bottom. Sometimes there are just a few. Sometimes there are a lot more. This is using flexbox. Why? Because it’s cool. Also, because it’s flexbox, you can create rules about how the icons should behave if one of the icons is taller than the others. (It’s gotten to the point that Eric has forgotten that vertically-centring things in CSS is supposed to be hard. The jokes aren’t funny any more.) Also, what if there’s no photo? Using flexbox, you can say “if there’s no photo, change the direction of the icons to be vertical.” Once again, it’s all about writing less CSS.

Also, note that the profile picture is being floated. That’s the right tool for the job. It feels almost transgressive to use float for exactly the purpose for which it was intended.

On the An Event Apart site, the header is currently using absolute positioning to pull the navigation from the bottom of the page source to the top of the viewport. But now you get overlap at some screen sizes. Flexbox would make it much more robust. (Eric uses the flexbox inspector in Firefox Nightly to demonstrate.)

With flexbox, what works horizontally works vertically. Flexbox allows you to align things, as long as you’re aligning in one direction. Flexbox makes things springy. Everything’s related and pushing against each other in a way that makes sense for this medium. It’s intuitive, even though it takes a bit of getting used to …because we’ve picked up some bad habits. To quote Yoda, “You must unlearn what you have learned.” A lot of the barrier is getting over what we’ve internalised. Eric envies the people starting out now. They get to start fresh. It’s like when people who never had to table layouts see code from that time period: it (quite rightly) doesn’t make any sense. That’s what it’s going to be like when people starting out today see the float-based layouts from Bootstrap and the like.


That’s going to happen with grid too. We must unlearn what we have learned from twenty years of floats and positioning. What makes it worth is:

  1. Flexbox and grid are pretty easy to get used to, and
  2. It’s amazing what you can do!

Eric quotes from an article called How We adopted CSS Grid at Scale:

…we agreed to use CSS Grid at the layout level and Flexbox at the component level (arranging child items of components). Although there’s some overlap and in some cases both could be used interchangeably, abiding by this rule helped us avoid any confusion in gray areas.

Don’t be afraid to set these kind of arbitrary limits that aren’t technological, but are necessary for the team to work well together.

Eric hacked his Wordpress admin interface to use grid instead of floats for an activity component (a list of dates and titles). He initially turned each list item into a separate grid. The overall list didn’t look right. What Eric really needed was a subgrid capability, so that the mini grids (the list items) would relate to one another within the larger grid (the list). But subgrid doesn’t exist yet.

In this case, there’s a way to fake it using display: contents. Eric made the list a grid and used display: contents on the list items. It’s as though you’re saying that the contents of the li are really the contents of the ul. That works in this particular case.

The feature queries for that looked like:

@supports (display: grid) {
    @supports (display: contents) {

Eric is also using the grid “ASCII art” (named areas) technique on his personal site. This works independent of source order. For that reason, make sure your source order makes sense.

Using media queries, Eric defines entirely different layouts simply by using different ASCII art. He’s switching templates.

For a proposed redesign of the An Event Apart site, Eric used CSS grid as a prototyping tool. He took a PDF, sliced it up, exported JPGs, and then used grid to lay out those images in a flexible grid. Rapid prototyping! The Firefox grid inspector really helps here. In less than an hour, he had a working layout. He could test whether the layout was sensible and robust. Then he swapped out the sliced images for real content. That took maybe another hour (mostly because it was faster to re-type the text than try to copy and paste from a PDF). CSS makes it that damn easy now!

So even if you’re not going to put things like grid into production, they can still be enormously useful as design tools (and you’re getting to grips with this new stuff).

See also:

Scenario-Driven Design Systems by Yesenia Perez-Cruz

I’m at An Event Apart Seattle (Special Edition) taking notes during the talks. Here are my notes from Yesenia’s presentation…

In the last few years, we’ve seen a lot of change in web design as we have to adapt to so many viewports and platforms. We’ve gravitated towards design systems to manage this. Many people have written about the benefits of design systems, like AirBnB.

But how do you define a design system? You could say it’s a collection of reususable components.

Donella Meadows wrote Thinking in Systems. She said:

A system is an interconnected group of elements coherently organized in a way that achieves something.

A good design system inspires people to work with it. A bad system gets bloated and unusable. Yesenia has seen systems fail when there’s too much focus on the elements, and not enough focus on how they come together. Yesenia has learned that we should start our design systems, not with components, or modules, or legos, but with user scenarios.

Yesenia works at Vox Media. They have eight editorial networks. Two and a half years ago, they started a project to move all of their products to one codebase and one design system. Maintaining and iterating on their websites was getting too cumbersome. They wanted to shift away from maintaining discrete brands to creating a cohesive system. They also wanted to help their editorial teams tell stories faster and better.

It was hard. Each brand has its own visual identity, editorial missions, and content needs. So even though they wanted eight brands to use one design system, there needed to be enough flexibility to allow for unique needs.

There were some early assumptions that didn’t work. There was a hunch that they could take smaller modular components to address inconsistencies in design: layout, colour, and typography. They thought a theming system would work well. They started with layout modules, like three different homepage hero elements, or four different story blocks. They thought they could layer colour and typography over these modules. It didn’t work. They weren’t reflecting critical differences in content, tone, and audience. For example, Curbed and Recode are very different, but the initial design system didn’t reflect those difference.

That brings us back to Donella Meadows:

A system is an interconnected group of elements coherently organized in a way that achieves something.

They weren’t thinking about that last part.

They learned that they couldn’t start with just the individual components or patterns. That’s because they don’t exist in a vacuum. As Alla says:

Start with language, not systems.

They started again, this time thinking about people.

  • What’s the audience goal?
  • Is there a shared audience goal across all brands or are there differences?
  • What’s the editorial workflow?
  • What range of content should this support?

This led to a much better process for creating a design system.

Start with a fast, unified platform. It should load quickly and work across all devices. All patterns should solve a specific problem. But that doesn’t mean creating a one-size-fits-all solution. A design system doesn’t have to stifle creativity …as long as the variants solve a real problem. That means no hypothetical situations.

Identify scenarios. Brad uses a UI inventory for this. Alla talks about a “purpose-directed inventory”. Map core modules to user journeys to see how patterns fit together in the bigger picture. You start to see families of patterns joined together by a shared purpose. Scenarios can help at every level.

The Salesforce design system starts by saying “Know your use-case.” They have examples of different patterns and where to use them. Thinking in user-flows like this matches the way that designers are already thinking.

Shopify’s Polaris system also puts users and user-flows at the centre: the purpose of each pattern is spelled out.

The 18F Design System doesn’t just provide a type system; it provides an explanation of when and where to use which type system.

At Vox, “features” are in-depth pieces. Before having a unified system, each feature looked very custom and were hard to update. They need to unify 18 different systems into one. They started by identifying core workflows. Audience goals were consistent (consume content, find new content), but editorial goals were quite different.

They ended up with quite a few variations of patterns (like page headers, for example), but only if there was a proven content need—no hypothetical situations.

Brand expression for features is all about the details. They started with 18 very different feature templates and ended up with one robust template that works across device types but still allowed for expression.

The “reviews” pieces had a scorecard pattern. Initially there was one unified pattern that they thought would be flexible enough to cover different scenarios. But these scorecards were for very different things: games; restaurants, etc. So people’s needs were very different. In the end, instead of having one scorecard pattern, they created three. Each one highlighted different content according to the user needs.

Homepages were the most challenging to unify. Each one was very distinct. Identifying core workflows took a lot of work.

What’s the value of the homepage? Who is the audience? What are they looking for?

They talked to their users and distilled their findings down into three user goals for homepages:

  • What’s new?
  • What’s important?
  • What’s helpful?

Those needs then translated into patterns. The story feed is there to answer the question “What’s new?”

When it came to variations on the home page, they needed to make sure their design system could stretch enough to allow for distinctly different needs. There’s a newspaper layout, an evergreen layout, a morning recap layout.

Again, Alla’s advice to focus on language was really helpful.

In the process of naming an element, you work out the function as a group and reach agreement.

The last piece was to have a scalable visual design system. Brands need to feel distinct and express an identity. They did this by having foundational elements (type scale, colour system, and white space) with theming applied to them. Thinking of type and colour as systems was key: they need to cascade.

But how do you tell good variation from bad variation? Variation is good if there’s a specific problem that you need a new pattern to solve—there’s a user scenario driving the variation. A bad variation is visual variation on components that do the same thing. Again, the initial design system provided room for “visual fluff and flair” but they were hypothetical. Those variations were removed.

The combination of a scenario-driven system combined with theming allowed for the right balance of consistency and customisation. Previously, the editorial team were hacking together the layouts they wanted, or developers were creating one-off templates. Both of those approaches were very time-consuming. Now, the reporters can focus on telling better stories faster. That was always the goal.

There’s still a lot of work to do. There’s always a pendulum swing between consistency and variation. Sometimes the design system goes too far in one direction or the other and needs to be recalibrated. They want to be able to add more detailed control over typography and spacing.

To wrap up:

  1. Successful design patterns don’t exist in a vacuum.
  2. Successful design systems solve specific problems.
  3. Successful design systems start with content and with people.

See also:

Beyond Engagement: the Content Performance Quotient by Jeffrey Zeldman

I’m at An Event Apart Seattle (Special Edition). Jeffrey is kicking off the show with a presentation called Beyond Engagement: the Content Performance Quotient. I’m going to jot down some notes during this talk…

First, a story. Jeffrey went to college in Bloomington, Indiana. David Frost—the British journalist—came to talk to them. Frost had a busy schedule, and when he showed up, he seemed a little tipsy. He came up to the podium and said, “Good evening, Wilmington.”

Jeffrey remembers this and knows that Seattle and Portland have a bit of a rivalry, and so Jeffrey thought, the first time he spoke in Portland, it would be funny to say “Good morning, Seattle!” …and that was the last time he spoke in Portland.

Anyway …”Good morning, Portland!”

Jeffrey wants to talk about content. He spends a lot of time in meetings with stakeholders. Those stakeholders always want things to be better, and they always talk about “engagement.” It’s the number one stakeholder request. It’s a metric that makes stakeholders feel comfortable. It’s measurable—the more seconds people give us, the better.

But is that really the right metric?

There are some kinds of sites where engagement is definitely the right metric. Instagram, for example. That’s how they make money. You want to distract yourself. Also, if you have a big content site—beautifully art-directed and photographed—then engagement is what you want. You want people to spend a lot of time there. Or if you have a kids site, or a games site, or a reading site for kids, you want them to be engaged and spend time. A List Apart, too. It’s like the opposite of Stack Overflow, where you Google something and grab the piece of code you need and then get out. But for A List Apart or Smashing Magazine, you want people to read and think and spend their time. Engagement is what you want.

But for most sites—insurance, universities—engagement is not what you want. These sites are more like a customer service desk. You want to help the customer as quickly as possible. If a customer spends 30 minutes on our site, was she engaged …or frustrated? Was it the beautiful typography and copy …or because she couldn’t find what they wanted? If someone spends a long time on an ecommerce site, is it because the products are so good …or because search isn’t working well?

What we need is a metric called speed of usefulness. Jeffrey calls this Content Performance Quotient (CPQ) …because business people love three-letter initialisms. It’s a loose measurement: How quickly can you solve the customer’s problem? It’s the shortest distance between the problem and the solution. Put another way, it’s a measurement of your value to the customer. It’s a new way to evaluate success.

From the customer’s point of view, CPQ is the time it takes the customer to get the information she came for. From the organisation’s point of view, it’s the time it takes for a specific customer to find, receive, and absorb your most important content.

We’re all guilty of neglecting the basics on our sites—just what it is it that we do? We need to remember that we’re all making stuff to make people’s live’s easier. Otherwise we end up with what Jeffrey calls “pretty garbage.” It’s aesthetically coherent and visually well-designed …but if the content is wrong and doesn’t help anyone, it’s garbage. Garbage in a delightfully responsive grid is still garbage.

Let’s think of an example of where people really learned to cut back and really pare down their message. Advertising. In the 1950s, when the Leo Burnett agency started the Marlboro campaign, TV spots were 60 seconds long. An off-camera white man in a suit with a soothing voice would tell you all about the product while the visuals showed you what he was talking about. No irony. Marlboro did a commercial where there was no copy at all until the very end. For 60 seconds they showed you cowboys doing their rugged cowboy things. Men in the 1950s wanted to feel rugged, you see. Leo Burnett aimed the Marlboro cigarettes at those men. And at the end of the 60 second montage of rugged cowboys herding steers, they said “Come to where the flavour is. Come to Marlboro Country.” For the billboard, they cut it back even more. Just “Come to Marlboro Country.” In fact, they eventually went to just “Marlboro.” Jeffrey knows that this campaign worked well, because he started smoking Marlboros as a kid.

Leaving aside the ethical implications of selling cigarettes to eight-graders, let’s think about the genius of those advertisers. Slash your architecture and shrink your content. Constantly ask yourself, “Why do we need this?”

As Jared Spool says, design is the rendering of intent. Every design is intentional. There is some intent—like engagement—driving our design. If there’s no intent behind the design, it will fail, even if what you’re doing is very good. If your design isn’t going somewhere, it’s going nowhere. You’ve got to stay ruthlessly focused on what the customer needs and “kill your darlings” as Hemingway said. Luke Wroblewski really brought this to light when he talked about Mobile First.

To paraphrase David Byrne, how did we get here?

Well, we prioritised meetings over meaning. Those meetings can be full of tension; different stakeholders arguing over what should be on the homepage. And we tried to solve this by giving everyone what they want. Having a good meeting doesn’t necessarily mean having a good meeting. We think of good meetings as conflict-free where everyone emerges happy. But maybe there should be a conflict that gets resolved. Maybe there should be winners and losers.

Behold our mighty CMS! Anyone can add content to the website. Anyone can create the information architecture …because we want to make people happy in meetings. It’s easy to give everyone what they want. It’s harder to do the right thing. Harder for us, but better for the customer and the bottom line.

As Gerry McGovern says:

Great UX professionals are like whistleblowers. They are the voice of the user.

We need to stop designing 2001 sites for a 2018 web.

One example of cutting down content was highlighted in A List Apart where web design was compared to chess: The King vs. Pawn Game of UI Design. Don’t start by going through all the rules. Teach them in context. Teach chess by starting with a checkmate move, reduced down to just three pieces on the board. From there, begin building out. Start with the most important information, and build out from there.

When you strip down the game to its core, everything you learn is a universal principle.

Another example is atomic design: focus relentlessly on the individual interaction. We do it for shopping carts. We can do it for content.

Another example on A List Apart is No More FAQs: Create Purposeful Information for a More Effective User Experience. FAQ problems include:

  • duplicate and contradictory information,
  • lack of discernible content order,
  • repetitive grammatical structure,
  • increased cognitive load, and
  • more content than they need.

Users come to any type of content with a particular purpose in mind, ranging from highly specific (task completion) to general learning (increased knowledge).

The important word there is purpose. We need to eliminate distraction. How do we do that?

One way is the waterfall method. Do a massive content inventory. It’s not recommended (unless maybe you’re doing a massive redesign).

Agile and scrum is another way. Constantly iterate on content. Little by little over time, we make the product better. It’s the best bet if you work in-house.

If you work in an agency, a redesign is an opportunity to start fresh. Take everything off the table and start from scratch. Jeffrey’s friend Fred Gates got an assignment to redesign an online gaming platform for kids to teach them reading and management skills. The organisation didn’t have much money so they said, let’s just do the homepage. Fred challenged himself to put the whole thing on the homepage. The homepage tells the whole story. Jeffrey is using this same method on a site for an insurance company, even though the client has a bigger budget and can afford more than just the homepage. The point is, what Fred did was effective.

So this is what Jeffrey is going to be testing and working on: speed of usefulness.

And for those of you who do need to use engagement as the right metric, Jeffrey covered the two kinds of metrics in an article called We need design that is faster and design that is slower.

For example, “scannability” is good for transactions (CPQ), but bad for thoughtful content (engagement). Our news designs need to slow down the user. Bigger type, typographic hierarchy, and more whitespace. Art direction. Shout out to Derek Powazek who designed Fray.com—each piece was designed based on the content. These days, look at what David Sleight and his crew are doing over at Pro Publica.

Who’s doing it right?

The Washington Post, The New York Times, Pro Publica, Slate, Smashing Magazine, and Vox are all doing this well in different ways. They’re bringing content to the fore.

Readability, Medium, and A List Apart are all using big type to encourage thoughtful reading and engagement.

But for other sites …apply the Content Performance Quotient.

See also:

Links from a talk

In two weeks time, I’ll be in Seattle for An Event Apart. I’ll be giving a brand new talk. The title is The Way Of The Web (although perhaps a more accurate title would be The Layers Of The Web).

Here’s the description:

Do you ever get overwhelmed by the ever-changing nature of web design and development? Exhausting, isn’t it? How are you supposed to know which technologies and tools you should invest your time in? Will they stick around or will you just have to relearn everything in another few months? Join Jeremy as he takes a tour of the past, present, and future of working on the web. From the building blocks of HTML, CSS, and JavaScript through to frameworks and libraries right up to the latest and greatest Progressive Web Apps, this talk will examine our collective assumptions with a critical eye. By learning from the past, we can make sensible design decisions today to build the web of tomorrow.

There’s a direct evolution line from my previous talks—Resilence and Evaluating Technology—to this new one. (Spoiler: everything I talk about is in some way related to progressive enhancement …even if I never use the words “progressive" or “enhancement" in the talks.)

I’ve been preparing this new talk for months. It started with a mind map—an A3 sheet of paper with disconnected thoughts, like something from the scene in the crime movie where they enter the lair of the serial killer and find a crazy wall.

Then I set it aside and began procrastinating. But it was the good kind of procrastinating, right? I mean, I had made a start and all those thoughts were now bubbling around in my head.

Eventually I forced myself to put things in some sort of order and started creating slides. That’s the beginning of the horrible process bouncing between thinking “this is pretty good!” and “this is absolute crap!” To be honest, I never actually know if a talk is any good until I give it in front of an audience (practice runs at work are great for getting feedback but they’re not the same as doing the talk for real).

Anyway, I think the talk is ready to roll. If you see me giving this talk and you’re interested in diving deeper into the topics raised, I’ve gathered together some of sources I used.

Further Reading

Related posts on adactio.com

Progressive Web Apps



Styling the Patterns Day site

Once I had a design direction for the Patterns Day site, I started combining my marked-up content with some CSS. Ironically for an event that’s all about maintainability and reusability, I wrote the styles for this one-page site with no mind for future use. I treated the page as a one-shot document. I even used ID selectors—gasp! (the IDs were in the HTML anyway as fragment identifiers).

The truth is I didn’t have much of a plan. I just started hacking away in a style element in the head of the document, playing around with colour, typography, and layout.

I started with the small-screen styles. That wasn’t a conscious decision so much as just the way I do things automatically now. When it came time to add some layout for wider viewports, I used a sprinkling of old-fashioned display: inline-block so that things looked so-so. I knew I wanted to play around with Grid layout so the inline-block styles were there as fallback for non-supporting browsers. Once things looked good enough, the fun really started.

I was building the site while I was in Seattle for An Event Apart. CSS Grid layout was definitely a hot topic there. Best of all, I was surrounded by experts: Jen, Rachel, and Eric. It was the perfect environment for me to dip my toes into the waters of grid.

Jen was very patient in talking me through the concepts, syntax, and tools for using CSS grids. Top tip: open Firefox’s inspector, select the element with the display:grid declaration, and click the “waffle” icon—instant grid overlay!

For the header of the Patterns Day site, I started by using named areas. That’s the ASCII-art approach. I got my head around it and it worked okay, but it didn’t give me quite the precision I wanted. I switched over to using explicit grid-row and grid-column declarations.

It’s definitely a new way of thinking about layout: first you define the grid, then you place the items on it (rather than previous CSS layout systems where each element interacted with the elements before and after). It was fun to move things around and not have to worry about the source order of the elements …as long as they were direct children of the element with display:grid applied.

Without any support for sub-grids, I ended up having to nest two separate grids within one another. The logo is a grid parent, which is inside the header, also a grid parent. I managed to get things to line up okay, but I think this might be a good use case for sub-grids.

The logo grid threw up some interesting challenges. I wanted each letter of the words “Patterns Day” to be styleable, but CSS doesn’t give us any way to target individual letters other than :first-letter. I wrapped each letter in a b element, made sure that they were all wrapped in an element with an aria-hidden attribute (so that the letters wouldn’t be spelled out), and then wrapped that in an element with an aria-label of “Patterns Day.” Now I could target those b elements.

For a while, I also had a br element (between “Patterns” and “Day”). That created some interesting side effects. If a br element becomes a grid item, it starts to behave very oddly: you can apply certain styles but not others. Jen and Eric then started to test other interesting elements, like hr. There was much funkiness and gnashing of specs.

It was a total nerdfest, and I loved every minute of it. This is definitely the most excitement I’ve felt around CSS for a while. It feels like a renaissance of zen gardens and layout reservoirs (kids, ask your parents).

After a couple of days playing around with grid, I had the Patterns Day site looking decent enough to launch. I dabbled with some other fun CSS stuff in there too, like gratuitous clip paths and filters when hovering over the speaker images, and applying shape-outside with an image mask.

Go ahead and view source on the Patterns Day page if you want—I ended up keeping all the CSS in the head of the document. That turned out to be pretty good for performance …for first-time visits anyway. But after launching the site, I couldn’t resist applying some more performance tweaks.

Getting griddy with it

I had the great pleasure of attending An Event Apart Seattle last week. It was, as always, excellent.

It’s always interesting to see themes emerge during an event, especially when those thematic overlaps haven’t been planned in advance. Jen noticed this one:

I remember that being a theme at An Event Apart San Francisco too, when it seemed like every speaker had words to say about ill-judged use of Bootstrap. That theme was certainly in my presentation when I talked about “the fallacy of assumed competency”:

  1. large company X uses technology Y,
  2. company X must know what they are doing because they are large,
  3. therefore technology Y must be good.

Perhaps “the fallacy of assumed suitability” would be a better term. Heydon calls it “the ‘made at Facebook’ fallacy.” But I also made sure to contrast it with the opposite extreme: “Not Invented Here syndrome”.

As well as over-arching themes, it was also interesting to see which technologies were hot topics at An Event Apart. There was one clear winner here—CSS Grid Layout.

Microsoft—a sponsor of the event—used An Event Apart as the place to announce that Grid is officially moving into development for Edge. Jen talked about Grid (of course). Rachel talked about Grid (of course). And while Eric and Una didn’t talk about it on stage, they’ve both been writing about the fun they’ve been having having with Grid. Una wrote about 3 CSS Grid Features That Make My Heart Flutter. Eric is documenting the overall of his site with Grid. So when we were all gathered together, that’s what we were nerding out about.

The CSS Squad.

There are some great resources out there for levelling up in Grid-fu:

With Jen’s help, I’ve been playing with CSS Grid on a little site that I’m planning to launch tomorrow (he said, foreshadowingly). I took me a while to get my head around it, but once it clicked I started to have a lot of fun. “Fun” seems to be the overall feeling around this technology. There’s something infectious about the excitement and enthusiasm that’s returning to the world of layout on the web. And now that the browser support is great pretty much across the board, we can start putting that fun into production.

Research on evaluating technology

I’ve spent the past few months preparing a new talk for An Event Apart San Francisco (and hopefully some more AEAs after that). As always happens, I spent the whole time vacillating between thinking “this is good!” and thinking “this is awful!” I’m still bouncing between those poles. I won’t really know whether the talk is up to snuff until I actually give it to a live audience.

Over the past few years, my presentations have built upon one another. Two years ago, my talk was called Enhance! and it set the groundwork for using a layered approach to web design and development. My 2016 talk, Resilience, follows on with a process and examples for that approach (I also set myself the challenge of delivering a talk about progressive enhancement without ever using the phrase “progressive enhancement”).

My new talk goes a bit meta, but in my mind, it’s very much building on the previous talks. The talk is all about evaluating technology. I haven’t settled on a final title, but I was thinking about something obtuse, like …Evaluating Technology.

Here’s my hastily scribbled description:

We work with technology every day. And every day it seems like there’s more and more technology to understand: graphic design tools, build tools, frameworks and libraries, not to mention new HTML, CSS and JavaScript features landing in browsers. How should we best choose which technologies to invest our time in? When we decide to weigh up the technology choices that confront us, what are the best criteria for doing that? This talk will help you evaluate tools and technologies in a way that best benefits the people who use the websites that we are designing and developing. Let’s take a look at some of the hottest new web technologies like service workers and web components. Together we will dig beneath the hype to find out whether they will really change life on the web for the better.

As ever, I’ll begin and end with a long-zoom pretentious arc of history, but I’ll dive into practical stuff in the middle. That’s become a bit of a cliché for my presentations, but the formula works as a sort of microcosm of a good conference—a mixture of the inspirational and the practical, trying to keep a good balance of both.

For this new talk, the practical focus will be on some web technologies that are riding high on the hype cycle right now: service workers, web components, progressive web apps. I’ll use them as a lens for applying broader questions about how we make decisions about the technologies we embrace, and the technologies we reject.

Technology. Now there’s a big subject. It’s literally the entirety of human history. I had to be careful not to go down too many rabbit holes. I’m still not sure if I’ve succeeded, but I’ve already had to ruthlessly cull some darlings.

One of the nice things that the An Event Apart crew started doing was to provide link lists for each talk to attendees. That gives me an opportunity to touch briefly on a topic in the talk itself, but allow any interested attendees to dive deeper at their leisure.

For this talk on evaluating technology, I’ve put together this list of hyperlinks for further reading, watching, listening, and researching…






Someone at Clearleft asked me a question recently about making bookmarklets. I have a bit of experience in that department. As well as making a bookmarklet for adding links to my own site, there’s the Huffduffer bookmarklet that’s been chugging away since 2008.

I told them that there are basically two approaches:

  1. Have the bookmarklet pop open a new browser window at your service, passing in the URL of the current page. Then do all the heavy lifting on your server.
  2. Have the bookmarklet inject JavaScript to analyse and edit the DOM of the document in the current browser window. All the heavy lifting is done directly in client-side JavaScript.

I favour the first approach. Partly that’s because it makes it easier to update the functionality. As you improve your server-side script, the bookmarklet functionality gets better automatically. But also, if your server-side script doesn’t do its magic, you can always fall back to letting the end user fill in the details.

Here’s an example…

When you click the Huffduffer bookmarklet, it pops open this URL:


…with that page parameter filled in with whatever page you currently have open. Let’s say I’ve got this page currently open in my browser:


If I press the Huffduffer bookmarklet, that will spawn a new window with this URL:


And that’s all it does. Now it’s up to that page on Huffduffer to figure out what to do with the URL it has been given. In this case, it makes a CURL request to figure out what to use as a title, what to use as a description, what audio file to use, etc. If it can’t figure that out, I can always fill in those fields myself by hand.

I could’ve chosen to get at that information by injecting JavaScript directly into the page open in the browser. But that’s somewhat invasive.

Brian Donohue wrote on Ev’s blog a while back about one of the problems with that approach. Sites that—quite correctly—have a strict Content Security Policy will object to having arbitrary JavaScript injected into their documents.

But remember this only applies to some bookmarklets. If a bookmarklet just spawns a new window—like Huffduffer’s—then there’s no problem. That approach to bookmarklets was dismissed with this justification:

The crux of the issue for bookmarklets is that web authors can control the origin of the JavaScript, network calls, and CSS, all of which are necessary for any non-trivial bookmarklet.

Citation needed. I submit that Huffduffer and Instapaper provide very similar services: “listen later” and “read later”. Both use cases could be described as “non-trivial”. But only one of the bookmarklets works on sites with strict CSPs.

Time and time again, I see over-engineered technical solutions that are built with the justification that “this problem is very complex therefore the solution needs to be complex” (yes, I am talking about web thangs that rely on complex JavaScript). In my experience, it’s exactly the opposite way around. The more complex the problem, the more important it is to solve it in the simplest way possible. It’s the only way of making sure the solution is resilient to unexpected scenarios.

The situation with bookmarklets is a perfect example. It’s not just an issue with strict Content Security Policies either. I’ve seen JavaScript-injecting bookmarklets fail because someone has set their browser cookie preferences to only accept cookies from the originating server.

Bookmarklets are not dead. They may, however, be pining for the fjords. Nobody has a figured out a way to get bookmarklets to work on mobile. Now that might well be a death sentence.

Without delay

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.


Mobile browser vendors have faced a dilemma for quite a while. They’ve got this double-tap gesture that allows users to zoom in on part of a page (particularly handy on non-responsive sites). But that means that every time a user makes a single tap, the browser has to wait for just a moment to see if it’s followed by another tap. “Just a moment” in this case works out to be somewhere between 300 and 350 milliseconds. So every time a user is trying to click a link or press a button on a web page, there’s a slight but noticeable delay.

For a while, mobile browsers tried to “solve” the problem by removing the delay if the viewport size had been set to non-scalable using a meta viewport declaration of user-scalable="no". In other words, the browser was rewarding bad behaviour: sites that deliberately broke accessibility by removing the ability to zoom were the ones that felt snappier than their accessible counterparts.

Fortunately Android changed their default behaviour. They decided to remove the tap delay for any site that had a meta viewport declaration of width=device-width (which is pretty much every responsive website). That still left Apple.

I discussed this a couple of years ago with Ted (my go-to guy on the inside of the infinite loop):

He’d prefer a per-element solution rather than a per-document meta element. An attribute? Or maybe a CSS declaration similar to pointer events?

I thought for a minute, and then I spitballed this idea: what if the 300 millisecond delay only applied to non-focusable elements?

After all, the tap delay is only noticeable when you’re trying to tap on a focusable element: links, buttons, form fields. Double tapping tends to happen on text content: divs, paragraphs, sections.

Well, the Webkit team have announced their solution. As well as following Android’s lead and removing the delay for responsive sites, they’ve also provided a way for authors to declare which elements should have the delay removed using the CSS property touch-action:

Putting touch-action: manipulation; on a clickable element makes WebKit consider touches that begin on the element only for the purposes of panning and pinching to zoom. This means WebKit does not consider double-tap gestures on the element, so single taps are dispatched immediately.

So to get the behaviour I was hoping for—no delay on focusable elements—I can add this line to my CSS:

a, button, input, select, textarea, label, summary {
  touch-action: manipulation;

That ought to do it. I suppose I could also throw [tabindex]:not([tabindex="-1"]) into that list of selectors.

It probably goes without saying, but you shouldn’t do:

* { touch-action: manipulation; }


body { touch-action: manipulation; }

That default behaviour of touch-action: auto is still what you want on most elements.

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.

Links from a talk

I’m coming to a rest after a busy period of travelling and speaking. In the last five or six weeks I’ve been to Copenhagen, Freiburg, Prague, Portland, Seattle, and Austin.

The trip to Austin was lovely. It was so nice to be there when it wasn’t South by Southwest (the infrastructure of the whole town creaks under the sheer weight of the event). I wasn’t just there to eat tacos and drink beer in the sunshine. I was there to talk at An Event Apart.

Like I said months before the event:

Everyone in the line up is one of my heroes.

It was, as always, a great event. A personal highlight for me was getting to meet Lara Hogan for the first time. She was kind enough to sign my copy of her fantastic book. She gave an equally fantastic talk at the conference, featuring some of the most deftly-handled Q&A I’ve ever seen.

I spoke at the end of the conference (no pressure!), giving a brand new talk called Resilience—I gave a shortened version at Coldfront and Smashing Conference but this was my first chance to go all out with an hour long talk. It was my chance to go full James Burke.

I assembled some related links for the attendees. Here they are…




Related posts on adactio.com

Here’s a readlist of those links.

Further reading

Here’s a readlist of those links.

See also: other links tagged with “progressive enhancement” on adactio.com

100 words 016

A Dao of Web Design by John Allsopp is a document that stands outside of time. It was a perfectly crafted message for its own era, and amazingly it’s even more relevant now, a full fathom fifteen years later.

We once took on the tropes of print design and tried to apply them to the web. I fear that today we run the risk of treating web development no different to other kinds of software development, ignoring the strengths of the web that John highlighted for us. Flexibility, ubiquity, and uncertainty: don’t fight them as bugs; embrace them as features.

100 words 011

The time had come for Jeremy to leave Brighton. He was being called away to the far shores of the Pacific Northwest. What would have once been a sea voyage and overland trek lasting for weeks and months took him just nine hours in the belly of a flying machine. Having made landfall in Seattle he then had to stand in front of a room full of his peers at An Event Apart and speak to them about progressive enhancement. Jeremy tries to remain humble but as he stepped off that stage, two words went through his mind: “Nailed. It!”

100 words 009

Last year at An Event Apart in Seattle I was giving a talk about long-term thinking on the web, using The Session as a case study. As a cheap gimmick, I played a tune on my mandolin during the talk.

Chris Coyier was also speaking. He plays mandolin too. Barry—one of the conference attendees—also plays mandolin. So we sat outside, passing my mandolin around.

Barry is back this year and he brought his mandolin with him. I showed him an Irish jig. He showed me a bluegrass tune. Together we played a reel that crossed the Atlantic ocean.