A deep dive into the
:focus pseudo-class and why it’s important.
The canonical example in just about every pattern library is documenting button variations. Here, Tyler shows how even this seemingly simple pattern takes a lot of thought.
Accessibility isn’t a checklist …but this checklist is a pretty damn good starting point. I really like that it’s organised by audience: designers, engineers, project managers, QA, and editorial. You can use this list as a starting point for creating your own—tick whichever items you want to include, and a handy copy/paste-able version will be generated for you.
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.
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:
- Respect the Physics
- Remember that We Call Them “Readers”
- 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?
Harsh (but fair) assessment of the performance costs of doing everything on the client side.
A terrific piece by Dan Hon on our collective responsibility. This bit, in particular, resonated with me: it’s something I’ve been thinking about a lot lately:
We are better and stronger when we are together than when we are apart. If you’re a technologist, consider this question: what are the pros and cons of unionizing? As the product of a linked network, consider the question: what is gained and who gains from preventing humans from linking up in this way?
It’s designed to read as a progressive enhancement when you look at the HTML it’s addressing.
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).
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.
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:
- 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.
- 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.
- 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.
Take a break. Build a sandcastle. It’s relaxing.
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.
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?
Alan Kay’s initial description of a “Dynabook” written at Xerox PARC in 1972.
The title is pure clickbait, and the moral panic early in this article repeats the Toyota myth, but then it settles down into a fascinating examination of abstractions in programming. On the one hand, there’s the problem of the not enough abstraction: having to write in code is such a computer-centric way of building things. On the other hand, our world is filled with dangerously abstracted systems:
When your tires are flat, you look at your tires, they are flat. When your software is broken, you look at your software, you see nothing.
So that’s a big problem.
Bret Victor, John Resig and Margaret Hamilton are featured. Doug Engelbart and J.C.R. Licklider aren’t mentioned but their spirits loom large.