Tags: interaction



Wednesday, March 7th, 2018

Parallax scrolling with CSS variables | basicScroll

Don’t let the title fool you—this isn’t just for parallax scrolling (thank goodness!)—it’s for triggering any CSS updates based on scroll position. Using CSS custom properties makes a lot of sense. The JavaScript/CSS bridge enabled by custom properties is kind of their superpower. (That’s one of the reasons why I don’t like calling them “CSS variables” which makes them sound like Sass variables—they’re so much more than that!)

Friday, March 2nd, 2018


Heydon keeps on delivering the goods. This time, he looks at making on-screen notification messages accessible using ARIA’s live regions.

As ever, structuring content is paramount, even where it pertains to dynamic events inside realtime web applications.

Thursday, March 1st, 2018

Your Interactive Makes Me Sick - Features - Source: An OpenNews project

Browsers have had consistent scrolling behavior for years, even across vendors and platforms. There’s an established set of physics, and if you muck with the physics, you can assume you’re making some people sick.

Guidelines to consider before adding swooshy parallax effects:

  1. Respect the Physics
  2. Remember that We Call Them “Readers”
  3. Ask for Consent

Given all the work that goes into a powerful piece of journalism—research, interviews, writing, fact-checking, editing, design, coding, testing—is it really in our best interests to end up with a finished product that some people literally can’t bear to scroll through?

Sunday, February 11th, 2018

Seva Zaikov - Single Page Application Is Not a Silver Bullet

Harsh (but fair) assessment of the performance costs of doing everything on the client side.

Wednesday, January 31st, 2018

Stimulus 1.0: A modest JavaScript framework for the HTML you already have

All our applications have server-side rendered HTML at their core, then add sprinkles of JavaScript to make them sparkle.

Yup!—I’m definitely liking the sound of this Stimulus JavaScript framework.

It’s designed to read as a progressive enhancement when you look at the HTML it’s addressing.

Tuesday, January 9th, 2018

The Origin of Stimulus

I really like the look of this markup-driven JavaScript library from the same people who brought us the pjax library Turbolinks.

The philosophy behind these tools matches my own philosophy (which I think is one of the most important factors in choosing a tool that works for you, not against you).

Saturday, December 23rd, 2017

Ubiquity and consistency

I keep thinking about this post from Baldur Bjarnason, Over-engineering is under-engineering. It took me a while to get my head around what he was saying, but now that (I think) I understand it, I find it to be very astute.

Let’s take a single interface element, say, a dropdown menu. This is the example Laura uses in her article for 24 Ways called Accessibility Through Semantic HTML. You’ve got two choices, broadly speaking:

  1. Use the HTML select element.
  2. Create your own dropdown widget using JavaScript (working with divs and spans).

The advantage of the first choice is that it’s lightweight, it works everywhere, and the browser does all the hard work for you.


You don’t get complete control. Because the browser is doing the heavy lifting, you can’t craft the details of the dropdown to look identical on different browser/OS combinations.

That’s where the second option comes in. By scripting your own dropdown, you get complete control over the appearance and behaviour of the widget. The disadvantage is that, because you’re now doing all the work instead of the browser, it’s up to you to do all the work—that means lots of JavaScript, thinking about edge cases, and making the whole thing accessible.

This is the point that Baldur makes: no matter how much you over-engineer your own custom solution, there’ll always be something that falls between the cracks. So, ironically, the over-engineered solution—when compared to the simple under-engineered native browser solution—ends up being under-engineered.

Is it worth it? Rian Rietveld asks:

It is impossible to style select option. But is that really necessary? Is it worth abandoning the native browser behavior for a complete rewrite in JavaScript of the functionality?

The answer, as ever, is it depends. It depends on your priorities. If your priority is having consistent control over the details, then foregoing native browser functionality in favour of scripting everything yourself aligns with your goals.

But I’m reminded of something that Eric often says:

The web does not value consistency. The web values ubiquity.

Ubiquity; universality; accessibility—however you want to label it, it’s what lies at the heart of the World Wide Web. It’s the idea that anyone should be able to access a resource, regardless of technical or personal constraints. It’s an admirable goal, and what’s even more admirable is that the web succeeds in this goal! But sometimes something’s gotta give, and that something is control. Rian again:

The days that a website must be pixel perfect and must look the same in every browser are over. There are so many devices these days, that an identical design for all is not doable. Or we must take a huge effort for custom form elements design.

So far I’ve only been looking at the micro scale of a single interface element, but this tension between ubiquity and consistency plays out at larger scales too. Take page navigations. That’s literally what browsers do. Click on a link, and the browser fetches that URL, displaying progress at it goes. The alternative, as exemplified by single page apps, is to do all of that for yourself using JavaScript: figure out the routing, show some kind of progress, load some JSON, parse it, convert it into HTML, and update the DOM.

Personally, I tend to go for the first option. Partly that’s because I like to apply the rule of least power, but mostly it’s because I’m very lazy (I also have qualms about sending a whole lotta JavaScript down the wire just so the end user gets to do something that their browser would do for them anyway). But I get it. I understand why others might wish for greater control, even if it comes with a price tag of fragility.

I think Jake’s navigation transitions proposal is fascinating. What if there were a browser-native way to get more control over how page navigations happen? I reckon that would cover the justification of 90% of single page apps.

That’s a great way of examining these kinds of decisions and questioning how this tension could be resolved. If people are frustrated by the lack of control in browser-native navigations, let’s figure out a way to give them more control. If people are frustrated by the lack of styling for select elements, maybe we should figure out a way of giving them more control over styling.

Hang on though. I feel like I’ve painted a divisive picture, like you have to make a choice between ubiquity or consistency. But the rather wonderful truth is that, on the web, you can have your cake and eat it. That’s what I was getting at with the three-step approach I describe in Resilient Web Design:

  1. Identify core functionality.
  2. Make that functionality available using the simplest possible technology.
  3. Enhance!

Like, say…

  1. The user needs to select an item from a list of options.
  2. Use a select element.
  3. Use JavaScript to replace that native element with a widget of your own devising.


  1. The user needs to navigate to another page.
  2. Use an a element with an href attribute.
  3. Use JavaScript to intercept that click, add a nice transition, and pull in the content using Ajax.

The pushback I get from people in the control/consistency camp is that this sounds like more work. It kinda is. But honestly, in my experience, it’s not that much more work. Also, and I realise I’m contradicting the part where I said I’m lazy, but that’s why it’s called work. This is our job. It’s not about what we prefer; it’s about serving the needs of the people who use what we build.

Anyway, if I were to rephrase my three-step process in terms of under-engineering and over-engineering, it might look something like this:

  1. Start with user needs.
  2. Build an under-engineered solution—one that might not offer you much control, but that works for everyone.
  3. Layer on a more over-engineered solution—one that might not work for everyone, but that offers you more control.

Ubiquity, then consistency.

Thursday, December 21st, 2017

the bullet hole misconception

The transcript of a terrific talk on the humane use of technology.

Instead of using technology to replace people, we should use it to augment ourselves to do things that were previously impossible, to help us make our lives better. That is the sweet spot of our technology. We have to accept human behaviour the way it is, not the way we would wish it to be.

Explorable Explanations

A collection of interactive lessons—games that teach—featuring the work of Bret Victor, Nicky Case, and more (the site is put together by Nicky Case).

Thursday, December 7th, 2017

The User Experience of Design Systems

When you start a redesign process for a company, it’s very easy to briefly look at all their products (apps, websites, newsletters, etc) and first of all make fun of how bad it all looks, and then design this one single design system for everything. However, once you start diving into why those decisions were made, they often reveal local knowledge that your design system doesn’t solve.

In this talk transcript, Rune Madsen enumerates the reasons for his informed scepticism towards design systems:

  1. The first concern, which is also the main argument of this talk, is that humans – especially designers and engineers – are obsessed with creating systems of order. This is not really driven by a demand from users, so they often tend to benefit the designer, not the user.
  2. My second concern relates to what I believe design systems is doing to our digital experience. We’ve always had trends in graphic design (Swiss design, Flat UI, etc), but I’m getting increasingly concerned that this broad adoption of design systems is creating a design monoculture that really narrows the idea of what digital products can be.
  3. My third concern is that with all this talk about design systems, there’s very little talk about the real problem in digital design, which is processes and tools. Designers love making design manuals, but any design system will completely and utterly fail if it doesn’t help people in the organization produce faster and better products.

Tuesday, November 28th, 2017


Take a break. Build a sandcastle. It’s relaxing.

Thursday, November 23rd, 2017

A Content Slider

Brad always said that carousels were way to stop people beating each other up in meetings. I like the way Heydon puts it:

Carousels (or ‘content sliders’) are like men. They are not literally all bad — some are even helpful and considerate. But I don’t trust anyone unwilling to acknowledge a glaring pattern of awfulness. Also like men, I appreciate that many of you would rather just avoid dealing with carousels, but often don’t have the choice. Hence this article.

Monday, October 2nd, 2017

When the news goes sideways – James Donohue – Medium

The BBC has been experimenting with some alternative layouts for some articles on mobile devices. Read on for the details, but especially for the philosophical musings towards the end—this is gold dust:

Even the subtext of Google’s marketing push around Progressive Web Apps is that mobile websites must aspire to be more like native apps. While I’m as excited about getting access to previously native-only features such as offline support and push notifications as the next web dev, I’m not sure that the mobile web should only try to imitate the kind of user interfaces that we see on native.

Do mobile websites really dream of being native apps, any more than they dreamt of being magazines?

A Personal Computer for Children of All Ages (PDF)

Alan Kay’s initial description of a “Dynabook” written at Xerox PARC in 1972.

Draggable JS – JavaScript drag and drop library

This looks like a very nice little JavaScript library for drag’n’drop. The site works as an example of the functionality in action.

Brought to you by Shopify, the company enabling Breitbart.

Friday, September 22nd, 2017

The First Web Apps: 5 Apps That Shaped the Internet as We Know It

A great bit of web history spelunking in search of the first websites that allowed users to interact with data on a server. Applications, if you will. It’s well written, but I take issue with this:

The world wide web wasn’t supposed to be this fun. Berners-Lee imagined the internet as a place to collaborate around text, somewhere to share research data and thesis papers.

This often gets trotted out (“the web was intended for scientists sharing documents”), but it’s simply not true that Tim Berners-Lee was only thinking of his immediate use-case; he deliberately made the WWW project broad enough to allow all sorts of thitherto unforeseen uses. If he hadn’t …well, the web wouldn’t have been able to accommodate all those later developments. It’s not an accident that the web was later used for all sorts of unexpected things—that was the whole idea.

Anyway, apart from that misstep, the rest of the article is a fun piece, well worth reading.

Friday, September 8th, 2017

UI Sounds: From Zero To Hero | Icons8 Blog

Following on from Ruth’s piece, here are some more thoughts on sound in UI from Roman Zimarev, the creator of icon sounds.

He makes a distinction between notification sounds and interaction sounds, as well as talking about sound identity in branding.

Monday, July 31st, 2017

Tooltips & Toggletips

Another great deep dive by Heydon into a single interface pattern. This time it’s the tooltip, and its cousin, the toggletip.

There’s some great accessibility advice in here.

Tuesday, July 11th, 2017

Designing The Perfect Date And Time Picker – Smashing Magazine

Vitaly’s been bitten with date-picker fever. Here’s his deep, deep, deep dive into one interface element.

Friday, July 7th, 2017

What football will look like in the future

I can’t remember the last time I was genuinely surprised, delighted, and intrigued by an online story like this.