Archive: April, 2019

99

sparkline
                    5th                     10th                     15th                     20th                     25th                     30th
12am    
4am    
8am                                
12pm                                                
4pm                
8pm          

Tuesday, April 30th, 2019

Progressive Font Enrichment: reinventing web font performance | Responsive Web Typography

Jason describes the next big thing in web typography: streaming fonts!

…to enable the ability for only the required part of the font be downloaded on any given page, and for subsequent requests for that font to dynamically ‘patch’ the original download with additional sets of glyphs as required on successive page views—even if they occur on separate sites.

A poem about Silicon Valley, assembled from Quora questions about Silicon Valley

What makes a startup ecosystem thrive?
What do people plan to do once they’re over 35?
Is an income of $160K enough to survive?
What kind of car does Mark Zuckerberg drive?

Pork chop with balsamic glaze.

Pork chop with balsamic glaze.

Monday, April 29th, 2019

Plotting my revenge on my (now unfollowed) USA “friends” who posted their spoilery takes on Game Of Thrones as soon as it aired there.

Well, I’ll spoil the last thing I watched!

Just wait until they find out how Barry Lyndon ends.

Sitting in a deckchair, reading a good book, eating a fish sandwich. Summer is coming.

Sitting in a deckchair, reading a good book, eating a fish sandwich.

Summer is coming.

Naming things to improve accessibility

Some good advice from Hidde, based on his recent talk Six ways to make your site more accessible.

Sunday, April 28th, 2019

Norbert Wiener’s Human Use of Human Beings is more relevant than ever.

What would Wiener think of the current human use of human beings? He would be amazed by the power of computers and the internet. He would be happy that the early neural nets in which he played a role have spawned powerful deep-learning systems that exhibit the perceptual ability he demanded of them—although he might not be impressed that one of the most prominent examples of such computerized Gestalt is the ability to recognize photos of kittens on the World Wide Web.

Bream on samphire with sauce grenobloise.

Bream on samphire with sauce grenobloise.

Saturday, April 27th, 2019

Reading Mr. Penumbra’s 24-Hour Bookstore by Robin Sloan.

Friday, April 26th, 2019

Today’s oyster.

Today’s oyster.

How I failed the <a>

I think the situation that Remy outlines here is quite common (in client-rehydrated server-rendered pages), but what’s less common is Remy’s questioning and iteration.

So I now have a simple rule of thumb: if there’s an onClick, there’s got to be an anchor around the component.

Thursday, April 25th, 2019

Not long ’till Homebrew Website Club Brighton: 6pm-7:30pm this evening in the @Clearleft studio.

https://indieweb.org/HomebrewWebsiteClub#Brighton

Wednesday, April 24th, 2019

Preload, prefetch and other link tags: what they do and when to use them · PerfPerfPerf

Following on from Harry’s slides, here’s another round-up of thoserel attribute values that begin with pre.

More Than You Ever Wanted to Know About Resource Hints - Speaker Deck

Slides from Harry’s deep dive into rel values: preconnect, prefetch, and preload.

Untold History of AI - IEEE Spectrum

A terrific six-part series of short articles looking at the people behind the history of Artificial Intelligence, from Babbage to Turing to JCR Licklider.

  1. When Charles Babbage Played Chess With the Original Mechanical Turk
  2. Invisible Women Programmed America’s First Electronic Computer
  3. Why Alan Turing Wanted AI Agents to Make Mistakes
  4. The DARPA Dreamer Who Aimed for Cyborg Intelligence
  5. Algorithmic Bias Was Born in the 1980s
  6. How Amazon’s Mechanical Turkers Got Squeezed Inside the Machine

The history of AI is often told as the story of machines getting smarter over time. What’s lost is the human element in the narrative, how intelligent machines are designed, trained, and powered by human minds and bodies.

Who Are Design Systems For? | CSS-Tricks

Chris ponders the motivations behind companies sharing their design systems publicly. Personally, I’ve always seen it as a nice way of sharing work and saying “here’s what worked for us” without necessarily saying that anyone else should use the same system.

That said, I think Chris makes a good poin here:

My parting advice is actually to the makers of public design systems: clearly identify who this design system is for and what they are able to do with it.

Interview with Kyle Simpson (O’Reilly Fluent Conference 2016) - YouTube

I missed this when it was first posted three years ago, but now I think I’ll be revisiting this 12 minute interview every few months.

Everything that Kyle says here is spot on, nuanced, and thoughtful. He talks about abstraction, maintainability, learning, and complexity.

I want a transcript of the whole thing.

Front-end Developer Handbook 2019 - Learn the entire JavaScript, CSS and HTML development practice!

The 2019 edition of Cody Lindley’s book is a good jumping-off point with lots of links to handy resources.

Earth day at Clearleft

Isn’t this just lovely?

Cassie made a visualisation of the power we’re getting from the solar panels we installed on the roof of the Clearleft building.

I highly recommend reading her blog post about the process too. She does such a great job of explaining how she made API calls, created SVGs, and calculated animations.

Home Page — Doug Block

There’s a new reissue of the twenty year old documentary on Justin Hall’s links.net and the early days of the web.

Tuesday, April 23rd, 2019

Looking at the schedule for @ParisWeb this October, I think I’m in the René Descartes room, therefore I am in the René Descartes room.

https://www.paris-web.fr/2019/conferences/going-offline.php

Monday, April 22nd, 2019

Checked in at Zum Brandanfang. Matjes 🐟 — with Jessica map

Checked in at Zum Brandanfang. Matjes 🐟 — with Jessica

Picture 1 Picture 2

Grüße aus Hamburg!

Ostern.

Ostern.

Saturday, April 20th, 2019

Checked in at Jugendbildungsstätte Bahnhof Göhrde. with Jessica map

Checked in at Jugendbildungsstätte Bahnhof Göhrde. with Jessica

Picture 1 Picture 2 Picture 3

Walking in the woods.

Picture 1 Picture 2

Sauerkraut prep.

Friday, April 19th, 2019

Going to Hamburg. brb

Thursday, April 18th, 2019

Fading out siblings on hover in CSS | Trys Mudford

Well, the clever CSS techniques just keep on comin’ from Trys—I’m learning so much from him!

Inlining SVG background images in CSS with custom properties

Here’s a tiny lesson that I picked up from Trys that I’d like to share with you…

I was working on some upcoming changes to the Clearleft site recently. One particular component needed some SVG background images. I decided I’d inline the SVGs in the CSS to avoid extra network requests. It’s pretty straightforward:

.myComponent {
    background-image: url('data:image/svg+xml;utf8,<svg> ... </svg>');
}

You can basically paste your SVG in there, although you need to a little bit of URL encoding: I found that converting # to %23 to was enough for my needs.

But here’s the thing. My component had some variations. One of the variations had multiple background images. There was a second background image in addition to the first. There’s no way in CSS to add an additional background image without writing a whole background-image declaration:

.myComponent--variant {
    background-image: url('data:image/svg+xml;utf8,<svg> ... </svg>'), url('data:image/svg+xml;utf8,<svg> ... </svg>');
}

So now I’ve got the same SVG source inlined in two places. That negates any performance benefits I was getting from inlining in the first place.

That’s where Trys comes in. He shared a nifty technique he uses in this exact situation: put the SVG source into a custom property!

:root {
    --firstSVG: url('data:image/svg+xml;utf8,<svg> ... </svg>');
    --secondSVG: url('data:image/svg+xml;utf8,<svg> ... </svg>');
}

Then you can reference those in your background-image declarations:

.myComponent {
    background-image: var(--firstSVG);
}
.myComponent--variant {
    background-image: var(--firstSVG), var(--secondSVG);
}

Brilliant! Not only does this remove any duplication of the SVG source, it also makes your CSS nice and readable: no more big blobs of SVG source code in the middle of your style sheet.

You might be wondering what will happen in older browsers that don’t support CSS custom properties (that would be Internet Explorer 11). Those browsers won’t get any background image. Which is fine. It’s a background image. Therefore it’s decoration. If it were an important image, it wouldn’t be in the background.

Progressive enhancement, innit?

Hacking and writing at Homebrew Website Club Brighton.

Hacking and writing at Homebrew Website Club Brighton.

It’s Homebrew Website Club Brighton in just a few hours: 6pm-7:30pm at the @Clearleft studio.

https://indieweb.org/HomebrewWebsiteClub#Brighton

Wednesday, April 17th, 2019

Checked in at Jolly Brewer. Tunes! — with Jessica map

Checked in at Jolly Brewer. Tunes! — with Jessica

Limitation Breeds Creativity - Cassie Evans [Bytes Conf 2019] - YouTube

Cassie’s terrific talk from Bytes Conf, featuring some wild CSS experiments.

(Conference organisers—you want Cassie on your stage!)

Tuesday, April 16th, 2019

I am very, very excited to announce three more speakers for Patterns Day on June 28th here in Brighton: @ThatEmil, @CraftUI, and @HeydonWorks!

https://patternsday.com/

Get your ticket today! (if you haven’t already)

Three more Patterns Day speakers

There are 73 days to go until Patterns Day. Do you have your ticket yet?

Perhaps you’ve been holding out for some more information on the line-up. Well, I’m more than happy to share the latest news with you—today there are three new speakers on the bill…

Emil Björklund, the technical director at the Malmö outpost of Swedish agency inUse, is a super-smart person I’ve known for many years. Last year, I saw him on stage in his home town at the Confront conference sharing some of his ideas on design systems. He blew my mind! I told him there and then that he had to come to Brighton and expand on those thoughts some more. This is going to be an unmissable big-picture talk in the style of Paul’s superb talk last year.

Speaking of superb talks from last year, Alla Kholmatova is back! Her closing talk from the first Patterns Day was so fantastic that it I just had to have her come back. Oh, and since then, her brilliant book on Design Systems came out. She’s going to have a lot to share!

The one thing that I felt was missing from the first Patterns Day was a focus on inclusive design. I’m remedying that this time. Heydon Pickering, creator of the Inclusive Components website—and the accompanying book—is speaking at Patterns Day. I’m very excited about this. Given that Heydon has a habit of casually dropping knowledge bombs like the lobotomised owl selector and the flexbox holy albatross, I can’t wait to see what he unleashes on stage in Brighton on June 28th.

Emil Björklund Alla Kholmatova Heydon Pickering
Emil, Alla, and Heydon

Be there or be square.

Tickets for Patterns Day are still available, but you probably don’t want to leave it ‘till the last minute to get yours. Just sayin’.

The current—still incomplete—line-up comprises:

That isn’t even the full roster of speakers, and it’s already an unmissable event!

I very much hope you’ll join me in the beautiful Duke of York’s cinema on June 28th for a great day of design system nerdery.

A Webring Kit | Max Böck - Frontend Web Developer

Inspired by Charlie, here’s a straightforward bit of code for starting or joining your own webring.

Monday, April 15th, 2019

James Bridle / New Ways of Seeing

James has a new four part series on Radio 4. Episodes will be available for huffduffing shortly after broadcast.

New Ways of Seeing considers the impact of digital technologies on the way we see, understand, and interact with the world. Building on John Berger’s seminal Ways of Seeing from 1972, the show explores network infrastructures, digital images, systemic bias, education and the environment, in conversation with a number of contemporary art practitioners.

My brain sometimes confuses the ridiculously talented writer and actor Phoebe Waller Bridge with the ridiculously talented singer and songwriter Phoebe Bridgers.

Sunday, April 14th, 2019

Screening Surveillance

Three short films set in the near future from the suitably ominous-sounding Surveillance Studies Centre. The Black Mirrorlets are:

Pork!

Pork!

Saturday, April 13th, 2019

Checked in at The Parlour. Afternoon tea — with Jessica map

Checked in at The Parlour. Afternoon tea — with Jessica

Offline fallback page with service worker - Modern Web Development: Tales of a Developer Advocate by Paul Kinlan

Paul describes a fairly straightforward service worker recipe: a custom offline page for failed requests.

Goodbye Google Analytics, Hello Fathom - daverupert.com

Dave stops feeding his site’s visitors data to Google. I wish more people (and companies) would join him.

There’s also an empowering #indieweb feeling about owning your analytics too. I pay for the server my analytics collector runs on. It’s on my own subdomain. It’s mine.

Inline an SVG file in HTML, declaratively & asynchronously!

Woah! This is one smart hack!

Scott has figured out a way to get all the benefits of pointing to an external SVG file …that then gets embedded. This means you can get all the styling and scripting benefits that only apply to embedded SVGs (like using fill).

The fallback is very graceful indeed: you still get the SVG (just not embedded).

Now imagine using this technique for chunks of HTML too …transclusion, baby!

Sergey | the little SSG

Trys has made YASSG—Yet Another Static Site Generator. It’s called Sergey (like SSG, see?) and it does just one thing: it allows you to include chunks of markup. It’s Apache Server Side Includes all over again!

Kick the tyres and see what you think.

Webrings | sonniesedge

Charlie muses on ol’ fashioned web rings …and the cultural needs they fulfilled.

We suffer from homogenous dirge in most of our contemporary web presences. Having a personal website has become a rarer and rarer thing in this time of social media profile pages.

However, recent months have seen a surge in personal websites and blogging amongst some members of the web tech community. This is something that we urgently need to encourage!

Friday, April 12th, 2019

Google AMP lowered our page speed, and there’s no choice but to use it - unlike kinds

What happens when you’re AMP pages are slower than your regular pages …but you’re forced to use AMP anyway if you want to appear in the top stories carousel.

AMP isn’t about speed. It’s about control.

The elephant in the room here is pre-rendering: that’s why Google aren’t using page speed alone as a determining factor for what goes in the carousel.

Disenchantment - Tim Novis

I would urge front-end developers to take a step back, breathe, and reassess. Let’s stop over engineering for the sake of it. Let’s think what we can do with the basic tools, progressive enhancement and a simpler approach to building websites. There are absolutely valid usecases for SPAs, React, et al. and I’ll continue to use these tools reguarly and when it’s necessary, I’m just not sure that’s 100% of the time.

Thursday, April 11th, 2019

Accessibility Events | CSS-Tricks

If you’re using Apple’s VoiceOver, both your phone and your computer will broadcast your assumed disability to the entire internet, unless and until you specifically tell it to stop.

Looking forward to fiddling with my website at Homebrew Website Club this evening in the @Clearleft studio from 6pm-7:30pm. Come along and fiddle with your website.

https://indieweb.org/HomebrewWebsiteClub#Brighton

Nothing Fails Like Success – A List Apart

On an individual and small collective basis, the IndieWeb already works. But does an IndieWeb approach scale to the general public? If it doesn’t scale yet, can we, who envision and design and build, create a new generation of tools that will help give birth to a flourishing, independent web? One that is as accessible to ordinary internet users as Twitter and Facebook and Instagram?

Design perception

Last week I wrote a post called Dev perception:

I have a suspicion that there’s a silent majority of developers who are working with “boring” technologies on “boring” products in “boring” industries …you know, healthcare, government, education, and other facets of everyday life that any other industry would value more highly than Uber for dogs.

The sentiment I expressed resonated with a lot of people. Like, a lot of people.

I was talking specifically about web development and technology choices, but I think the broader point applies to other disciplines too.

Last month I had the great pleasure of moderating two panels on design leadership at an event in London (I love moderating panels, and I think I’m pretty darn good at it too). I noticed that the panels comprised representatives from two different kinds of companies.

There were the digital-first companies like Spotify, Deliveroo, and Bulb—companies forged in the fires of start-up culture. Then there were the older companies that had to make the move to digital (transform, if you will). I decided to get a show of hands from the audience to see which kind of company most people were from. The overwhelming majority of attendees were from more old-school companies.

Just as most of the ink spilled in the web development world goes towards the newest frameworks and toolchains, I feel like the majority of coverage in the design world is spent on the latest outputs from digital-first companies like AirBnB, Uber, Slack, etc.

The end result is the same. A typical developer or designer is left feeling that they—and their company—are behind the curve. It’s like they’re only seeing the Instagram version of their industry, all airbrushed and filtered, and they’re comparing that to their day-to-day work. That can’t be healthy.

Personally, I’d love to hear stories from the trenches of more representative, traditional companies. I also think that would help get an important message to people working in similar companies:

You are not alone!

Wednesday, April 10th, 2019

Split

When I talk about evaluating technology for front-end development, I like to draw a distinction between two categories of technology.

On the one hand, you’ve got the raw materials of the web: HTML, CSS, and JavaScript. This is what users will ultimately interact with.

On the other hand, you’ve got all the tools and technologies that help you produce the HTML, CSS, and JavaScript: pre-processors, post-processors, transpilers, bundlers, and other build tools.

Personally, I’m much more interested and excited by the materials than I am by the tools. But I think it’s right and proper that other developers are excited by the tools. A good balance of both is probably the healthiest mix.

I’m never sure what to call these two categories. Maybe the materials are the “external” technologies, because they’re what users will interact with. Whereas all the other technologies—that mosty live on a developer’s machine—are the “internal” technologies.

Another nice phrase is something I heard during Chris’s talk at An Event Apart in Seattle, when he quoted Brad, who talked about the front of the front end and the back of the front end.

I’m definitely more of a front-of-the-front-end kind of developer. I have opinions on the quality of the materials that get served up to users; the output should be accessible and performant. But I don’t particularly care about the tools that produced those materials on the back of the front end. Use whatever works for you (or whatever works for your team).

As a user-centred developer, my priority is doing what’s best for end users. That’s not to say I don’t value developer convenience. I do. But I prioritise user needs over developer needs. And in any case, those two needs don’t even come into conflict most of the time. Like I said, from a user’s point of view, it’s irrelevant what text editor or version control system you use.

Now, you could make the argument that anything that is good for developer convenience is automatically good for user experience because faster, more efficient development should result in better output. While that’s true in theory, I highly recommend Alex’s post, The “Developer Experience” Bait-and-Switch.

Where it gets interesting is when a technology that’s designed for developer convenience is made out of the very materials being delivered to users. For example, a CSS framework like Bootstrap is made of CSS. That’s different to a tool like Sass which outputs CSS. Whether or not a developer chooses to use Sass is irrelevant to the user—the final output will be CSS either way. But if a developer chooses to use a CSS framework, that decision has a direct impact on the user experience. The user must download the framework in order for the developer to get the benefit.

So whereas Sass sits at the back of the front end—where I don’t care what you use—Bootstrap sits at the front of the front end. For tools like that, I don’t think saying “use whatever works for you” is good enough. It’s got to be weighed against the cost to the user.

Historically, it’s been a similar story with JavaScript libraries. They’re written in JavaScript, and so they’re going to be executed in the browser. If a developer wanted to use jQuery to make their life easier, the user paid the price in downloading the jQuery library.

But I’ve noticed a welcome change with some of the bigger JavaScript frameworks. Whereas the initial messaging around frameworks like React touted the benefits of state management and the virtual DOM, I feel like that’s not as prevalent now. You’re much more likely to hear people—quite rightly—talk about the benefits of modularity and componentisation. If you combine that with the rise of Node—which means that JavaScript is no longer confined to the browser—then these frameworks can move from the front of the front end to the back of the front end.

We’ve certainly seen that at Clearleft. We’ve worked on multiple React projects, but in every case, the output was server-rendered. Developers get the benefit of working with a tool that helps them. Users don’t pay the price.

For me, this question of whether a framework will be used on the client side or the server side is crucial.

Let me tell you about a Clearleft project that sticks in my mind. We were working with a big international client on a product that was going to be rolled out to students and teachers in developing countries. This was right up my alley! We did plenty of research into network conditions and typical device usage. That then informed a tight performance budget. Every design decision—from web fonts to images—was informed by that performance budget. We were producing lean, mean markup, CSS, and JavaScript. But we weren’t the ones implementing the final site. That was being done by the client’s offshore software team, and they insisted on using React. “That’s okay”, I thought. “React can be used server-side so we can still output just what’s needed, right?” Alas, no. These developers did everything client side. When the final site launched, the log-in screen alone required megabytes of JavaScript just to render a form. It was, in my opinion, entirely unfit for purpose. It still pains me when I think about it.

That was a few years ago. I think that these days it has become a lot easier to make the decision to use a framework on the back of the front end. Like I said, that’s certainly been the case on recent Clearleft projects that involved React or Vue.

It surprises me, then, when I see the question of server rendering or client rendering treated almost like an implementation detail. It might be an implementation detail from a developer’s perspective, but it’s a key decision for the user experience. The performance cost of putting your entire tech stack into the browser can be enormous.

Alex Sanders from the development team at The Guardian published a post recently called Revisiting the rendering tier . In it, he describes how they’re moving to React. Now, if this were a move to client-rendered React, that would make a big impact on the user experience. The thing is, I couldn’t tell from the article whether React was going to be used in the browser or on the server. The article talks about “rendering”—which is something that browsers do—and “the DOM”—which is something that only exists in browsers.

So I asked. It turns out that this plan is very much about generating HTML and CSS on the server before sending it to the browser. Excellent!

With that question answered, I’m cool with whatever they choose to use. In this case, they’re choosing to use CSS-in-JS (although, to be pedantic, there’s no C anymore so technically it’s SS-in-JS). As long as the “JS” part is JavaScript on a server, then it makes no difference to the end user, and therefore no difference to me. Not my circus, not my monkeys. For users, the end result is the same whether styling is applied via a selector in an external stylesheet or, for example, via an inline style declaration (and in some situations, a server-rendered CSS-in-JS solution might be better for performance). And so, as a user-centred developer, this is something that I don’t need to care about.

Except…

I have misgivings. But just to be clear, these misgivings have nothing to do with users. My misgivings are entirely to do with another group of people: the people who make websites.

There’s a second-order effect. By making React—or even JavaScript in general—a requirement for styling something on a web page, the barrier to entry is raised.

At least, I think that the barrier to entry is raised. I completely acknowledge that this is a subjective judgement. In fact, the reason why a team might decide to make JavaScript a requirement for participation might well be because they believe it makes it easier for people to participate. Let me explain…

It wasn’t that long ago that devs coming from a Computer Science background were deriding CSS for its simplicity, complaining that “it’s broken” and turning their noses up at it. That rhetoric, thankfully, is waning. Nowadays they’re far more likely to acknowledge that CSS might be simple, but it isn’t easy. Concepts like the cascade and specificity are real head-scratchers, and any prior knowledge from imperative programming languages won’t help you in this declarative world—all your hard-won experience and know-how isn’t fungible. Instead, it seems as though all this cascading and specificity is butchering the modularity of your nicely isolated components.

It’s no surprise that programmers with this kind of background would treat CSS as damage and find ways to route around it. The many flavours of CSS-in-JS are testament to this. From a programmer’s point of view, this solution has made things easier. Best of all, as long as it’s being done on the server, there’s no penalty for end users. But now the price is paid in the diversity of your team. In order to participate, a Computer Science programming mindset is now pretty much a requirement. For someone coming from a more declarative background—with really good HTML and CSS skills—everything suddenly seems needlessly complex. And as Tantek observed:

Complexity reinforces privilege.

The result is a form of gatekeeping. I don’t think it’s intentional. I don’t think it’s malicious. It’s being done with the best of intentions, in pursuit of efficiency and productivity. But these code decisions are reflected in hiring practices that exclude people with different but equally valuable skills and perspectives.

Rachel describes HTML, CSS and our vanishing industry entry points:

If we make it so that you have to understand programming to even start, then we take something open and enabling, and place it back in the hands of those who are already privileged.

I think there’s a comparison here with toxic masculinity. Toxic masculinity is obviously terrible for women, but it’s also really shitty for men in the way it stigmatises any male behaviour that doesn’t fit its worldview. Likewise, if the only people your team is interested in hiring are traditional programmers, then those programmers are going to resent having to spend their time dealing with semantic markup, accessibility, styling, and other disciplines that they never trained in. Heydon correctly identifies this as reluctant gatekeeping:

By assuming the role of the Full Stack Developer (which is, in practice, a computer scientist who also writes HTML and CSS), one takes responsibility for all the code, in spite of its radical variance in syntax and purpose, and becomes the gatekeeper of at least some kinds of code one simply doesn’t care about writing well.

This hurts everyone. It’s bad for your team. It’s even worse for the wider development community.

Last year, I was asked “Is there a fear or professional challenge that keeps you up at night?” I responded:

My greatest fear for the web is that it becomes the domain of an elite priesthood of developers. I firmly believe that, as Tim Berners-Lee put it, “this is for everyone.” And I don’t just mean it’s for everyone to use—I believe it’s for everyone to make as well. That’s why I get very worried by anything that raises the barrier to entry to web design and web development.

I’ve described a number of dichotomies here:

  • Materials vs. tools,
  • Front of the front end vs. back of the front end,
  • User experience vs. developer experience,
  • Client-side rendering vs. server-side rendering,
  • Declarative languages vs. imperative languages.

But the split that worries the most is this:

  • The people who make the web vs. the people who are excluded from making the web.

Improving accessibility with accessibility acceptance criteria — Paul Hayes

Wouldn’t it be great if every component in your design system had accessibility acceptance criteria? Paul has some good advice for putting those together:

  • Start with accessibility needs
  • Don’t be too generic
  • Don’t define the solution
  • Iterate criteria

Web Components will replace your frontend framework

I’ve often said that the goal of a good library should be to make itself redundant. jQuery is the poster child for that, and this article points to web components as the way to standardise what’s already happening in JavaScript frameworks:

Remember when document.querySelector first got wide browser support and started to end jQuery’s ubiquity? It finally gave us a way to do natively what jQuery had been providing for years: easy selection of DOM elements. I believe the same is about to happen to frontend frameworks like Angular and React.

The article goes on to give a good technical overview of custom elements, templates, and the Shadow DOM, but I was surprised to see it making reference to the is syntax for extending existing HTML elements—I’m pretty sure that that is, sadly, dead in the water.

The real measure of information is not in the symbols we send—it’s in the symbols we could have sent, but did not.

—A Mind At Play

The Technical Debt Myth

In some cases, it’s entirely valid to explore new products and technologies, but in others, our striving for novelty becomes the driving factor for abandoning perfectly suitable solutions under the umbrella of technical debt.

Just because a technology is a few years old and possibly frustrating in some cases doesn’t mean you’re in technical debt. We need to stop projecting our annoyances as pitfalls of technological or design choices.

Just a reminder that @Shopify is still the largest source of revenue for Breitbart.

I feel bad for people working there who understand what they’re enabling. I wish @Tobi would show some true leadership.

https://adactio.com/journal/12718

Some Unsolicited Blogging Advice - daverupert.com

When you greet a stranger, look at his shoes.

Keep your money in your shoes.

Put your trouble behind.

When you greet a stranger, look at her hands.

Keep your money in your hands.

Put your travel behind.

Tuesday, April 9th, 2019

Defining Productivity — Jeremy Wagner

We have a tendency in our line of work to assume that what benefits us as developers translates to a benefit for those who use what we make. This is an unsafe assumption.

Public Sans

A free and open source neutral sans-serif typeface, released as part of version two of the design system for the US federal government.

Building accessible websites and apps is a moral obligation | Go Make Things

  • Morality is not always relative.
  • You’re a web professional.
  • The web is accessible out-of-the-box. We break it.
  • It’s not on people with disabilities to tell you how you screwed up.
  • It should be easier. This is our job.

Science and Tech Ads on Flickr

Stylish! Retro! Sciency!

Martin ad

Monday, April 8th, 2019

Picture 1 Picture 2 Picture 3

Had a great time learning fish skills from @LittleFishHove in @BtnKitchen this evening!

The Bureau of Suspended Objects

200 discarded objects from a dump in San Francisco, meticulously catalogued, researched, and documented by Jenny Odell. The result is something more revealing than most pre-planned time capsule projects …although this project may be somewhat short-lived as it’s hosted on Tumblr.

Tellart | Design Nonfiction

An online documentary series featuring interviews with smart people about the changing role of design.

As technology becomes more complex and opaque, how will we as designers understand its potential, do hands-on work, translate it into forms people can understand and use, and lead meaningful conversations with manufacturers and policymakers about its downstream implications? We are entering a new technology landscape shaped by artificial intelligence, advanced robotics and synthetic biology.

So far there’s Kevin Slavin, Molly Wright Steenson, and Alexandra Daisy Ginsberg, with more to come from the likes of Matt Jones, Anab Jain, Dan Hill, and many, many more.

Methods - 18F Methods

A very handy collection of design exercises as used by 18F. There’s a lot of crossover here with the Clearleft toolbox.

A collection of tools to bring human-centered design into your project.

These methods are categorised by:

  1. Discover
  2. Decide
  3. Make
  4. Validate
  5. Fundamentals

Why you should learn vanilla JS first | Go Make Things

Frameworks (arguably) make building complex applications easier, but they make doing simple stuff more complex.

And that’s why I think people should learn vanilla JS first. I’ve had many students who tried to learn frameworks get frustated, quit, and focus on vanilla JS.

Some of them have gone back to frameworks later, and told me that knowing vanilla JS made it a lot easier for them to pick up frameworks afterwards.

User interfaces: hiding stuff should be a last resort by Adam Silver

When we hide content, there’s a greater risk the user won’t see it. There’s a higher reliance on digital literacy and it’s generally more labour intensive for the user.

Worse still, sometimes we kill off essential content.

AddyOsmani.com - Native image lazy-loading for the web!

The loading attribute for images and iframes is coming to Chrome. The best part:

You can also use loading as a progressive enhancement. Browsers that support the attribute can get the new lazy-loading behavior with loading=lazy and those that don’t will still have images load.

Break out of the echo chamber - Andy Bell

So much of my echo chamber is consumed by people, including myself, who have a very dim view of JavaScript frameworks being thrown at everything, arguing with the people who are in the process of throwing JavaScript frameworks at everything. We forget one very important thing, though: we represent the minority of the web community and our arguments probably look very pointless and silly to the majority.

Sunday, April 7th, 2019

Drag’n’drop revisited

I got a message from a screen-reader user of The Session recently, letting me know of a problem they were having. I love getting any kind of feedback around accessibility, so this was like gold dust to me.

They pointed out that the drag’n’drop interface for rearranging the order of tunes in a set was inaccessible.

Drag and drop

Of course! I slapped my forehead. How could I have missed this?

It had been a while since I had implemented that functionality, so before even looking at the existing code, I started to think about how I could improve the situation. Maybe I could capture keystroke events from the arrow keys and announce changes via ARIA values? That sounded a bit heavy-handed though: mess with people’s native keyboard functionality at your peril.

Then I looked at the code. That was when I realised that the fix was going to be much, much easier than I thought.

I documented my process of adding the drag’n’drop functionality back in 2016. Past me had his progressive enhancement hat on:

One of the interfaces needed for this feature was a form to re-order items in a list. So I thought to myself, “what’s the simplest technology to enable this functionality?” I came up with a series of select elements within a form.

Reordering

The problem was in my feature detection:

There’s a little bit of mustard-cutting going on: does the dragula object exist, and does the browser understand querySelector? If so, the select elements are hidden and the drag’n’drop is enabled.

The logic was fine, but the execution was flawed. I was being lazy and hiding the select elements with display: none. That hides them visually, but it also hides them from screen readers. I swapped out that style declaration for one that visually hides the elements, but keeps them accessible and focusable.

It was a very quick fix. I had the odd sensation of wanting to thank Past Me for making things easy for Present Me. But I don’t want to talk about time travel because if we start talking about it then we’re going to be here all day talking about it, making diagrams with straws.

I pushed the fix, told the screen-reader user who originally contacted me, and got a reply back saying that everything was working great now. Success!

Checked in at The Bugle Inn. Fiddles map

Checked in at The Bugle Inn. Fiddles

Saturday, April 6th, 2019

Accessibility for Vestibular Disorders: How My Temporary Disability Changed My Perspective · An A List Apart Article

This is a fascinating insight into what it’s like to use the web if you’ve got vertigo (which is way more common than you might think):

Really, there are no words to describe just how bad a simple parallax effect, scrolljacking, or even background-attachment: fixed would make me feel. I would rather jump on one of those 20-G centrifuges astronauts use than look at a website with parallax scrolling.

Every time I encountered it, I would put the bucket beside me to good use and be forced to lie in bed for hours as I felt the room spinning around me, and no meds could get me out of it. It was THAT bad.

Taking the train from Brighton to London is the perfect opportunity to test the “lie-if” strategy I’ve been experimenting with on my site.

Taking the train from Brighton to London is the perfect opportunity to test the “lie-fi” strategy I’ve been experimenting with on my site.

How Google warped the hyperlink | WIRED UK

Ignore the ludicrously clickbaity title. This is a well-considered look at thirty years of linking on the World Wide Web.

Cool goal

One evening last month, during An Event Apart Seattle, a bunch of the speakers were gathered in the bar in the hotel lobby, shooting the breeze and having a nightcap before the next day’s activities. In a quasi-philosophical mode, the topic of goals came up. Not the sporting variety, but life and career goals.

As I everyone related (confessed?) their goals, I had to really think hard. I don’t think I have any goals. I find it hard enough to think past the next few months, much less form ideas about what I might want to be doing in a decade. But then I remembered that I did once have a goal.

Back in the ’90s, when I was living in Germany and first starting to make websites, there was a website I would check every day for inspiration: Project Cool’s Cool Site Of The Day. I resolved that my life’s goal was to one day have a website I made be the cool site of the day.

About a year later, to my great shock and surprise, I achieved my goal. An early iteration of Jessica’s site—complete with whizzy DHTML animations—was the featured site of the day on Project Cool. I was overjoyed!

I never bothered to come up with a new goal to supercede that one. Maybe I should’ve just retired there and then—I had peaked.

Megan Sapnar Ankerson wrote an article a few years back about How coolness defined the World Wide Web of the 1990s:

The early web was simply teeming with declarations of cool: Cool Sites of the Day, the Night, the Week, the Year; Cool Surf Spots; Cool Picks; Way Cool Websites; Project Cool Sightings. Coolness awards once besieged the web’s virtual landscape like an overgrown trophy collection.

It’s a terrific piece that ponders the changing nature of the web, and the changing nature of that word: cool.

Perhaps the word will continue to fall out of favour. Tim Berners-Lee may have demonstrated excellent foresight when he added this footnote to his classic document, Cool URIs don’t change—still available at its original URL, of course:

Historical note: At the end of the 20th century when this was written, “cool” was an epithet of approval particularly among young, indicating trendiness, quality, or appropriateness.

Friday, April 5th, 2019

Simon Collison | Identity at Dot York 2018

After two decades in tech, I realise phones and social media won’t be going away, so we work with them. My take is that I now need to seek positive digital tools that connect more of us to the non-digital world and really benefit our lives.

Welcoming @jbirdui and @trysmudford to @Clearleft.

Welcoming @jbirdui and @trysmudford to @Clearleft.

Why Computer Programmers Should Stop Calling Themselves Engineers - The Atlantic

This article by Ian Bogost from a few years back touches on one of the themes in the talk I gave at New Adventures:

“Engineer” conjures the image of the hard-hat-topped designer-builder, carefully crafting tomorrow. But such an aspiration is rarely realized by computing. The respectability of engineering, a feature built over many decades of closely controlled, education- and apprenticeship-oriented certification, becomes reinterpreted as a fast-and-loose commitment to craftwork as business.

You probably don’t need that hip web framework - Charged

This is a bit ranty but it resonates with what I’ve been noticing lately:

I’ve discovered how many others have felt similarly, overwhelmed by the choices we have as modern developers, always feeling like there’s something we should be doing better.

Thursday, April 4th, 2019

Your Brighton dance card could be full this evening: Homebrew Website Club in the @Clearleft studio at 6pm, followed by @asyncjs from 7:15pm in @TheSkiff.

After a thoroughly enjoyable time at @FrontendNE, I’m on my way back from Newcastle to Brighton in plenty of time to make it to Homebrew Website Club in the @Clearleft studio from 6pm to 7:30pm this evening.

UX Workshop | Trys Mudford

I’m so, so happy that Trys has joined us at Clearleft!

Here, he recounts his first day, which just happened to coincide with an introductory UX workshop that went really well.

Apple’s new feature a step towards digital apartheid - Axess Lab

I also discussed this accessibility events feature with my friend who is a screen reader user herself. She said it feels like it’s a first step towards a well-meant digital apartheid.

A progressive disclosure component - Andy Bell

This is a really nice write-up of creating an accessible progressive disclosure widget (a show/hide toggle).

Where it gets really interesting is when Andy shows how it could all be encapsulated into a web component with a progressive enhancement mindset

Wednesday, April 3rd, 2019

Getting ready to open the show at @FrontendNE in Newcastle.

Getting ready to open the show at @FrontendNE in Newcastle.

Tuesday, April 2nd, 2019

Yet Another JavaScript Framework | CSS-Tricks

This is such a well-written piece! Jay Hoffman—author of the excellent History Of The Web newsletter—talks us through the JavaScript library battles of the late 2000’s …and the consequences that arose just last year.

The closing line is perfect.

A walk in the country

Spring sprung last weekend. Saturday was an unseasonably nice and sunny day, so Jessica and I decided to make the most of it with a walk in the countryside.

Our route took us from Woodingdean to Lewes. Woodingdean isn’t too far away from where we live, but the walk there would’ve been beside a busy road so we just took the bus for that portion.

Being on the bus means we didn’t stop to take note of an interesting location. Just outside the Nuffield hospital is the unassuming opening of the Woodingdean Water Well. This is the deepest hand-dug well in the world—deeper than the Empire State Building is tall—dug over the course of four years in the mid nineteenth century. I didn’t even know of its existence until Brian told me about it.

From Woodingdean, we walked along Juggs Road. Originally a Roman ridgeway, it was named for the fishwives travelling from Brighton to Lewes with their marine wares. This route took us over Newmarket Hill, the site of many mock battles in the 18th century, for the amusement of the royals on a day out from the Pavilion.

Walking from Woodingdean to Lewes.

Walking through Kingston, we came to the Ashcombe Windmill, where I pet a nice horsey.

Went for a walk in the countryside and made a friend.

Then it was on into Lewes, where we could admire the handsome architecture of Lewes Cathedral …the local wags’ name for Harveys Brewery. Thanks to Ben’s connections, Clearleft managed to get a behind-the-scenes tour of this Victorian marvel a few months ago.

Harveys Brewery.

This time round, there would be no brewery tour, but that’s okay—there’s a shop right outside. We chose an appropriate ale to accompany a picnic of pork pie and apple.

Lewes picnic.

Having walked all the way to Lewes, it would’ve been a shame to return empty-handed, so before getting the bus back to Brighton, we popped into Mays Farm Cart and purchased a magnificent forerib of beef straight from the farm.

‘Twas a most worthwhile day out.

Idiosyncrancies of the HTML parser - The HTML Parser Book

This might just be the most nerdily specific book I’ve read and enjoyed. Even if you’re not planning to build a web browser any time soon, it’s kind of fascinating to see how HTML is parsed—and how much of an achievement the HTML spec is, for specifying consistent error-handling, if nothing else.

The last few chapters are still in progress, but you can read the whole thing online or buy an ePub version.

Dev perception

Chris put together a terrific round-up of posts recently called Simple & Boring. It links off to a number of great articles on the topic of complexity (and simplicity) in web development.

I had linked to quite a few of the articles myself already, but one I hadn’t seen was from David DeSandro who wrote New tech gets chatter:

You don’t hear about TextMate because TextMate is old. What would I tweet? Still using TextMate. Still good.

I think that’s a very good point.

It’s relatively easy to write and speak about new technologies. You’re excited about them, and there’s probably an eager audience who can learn from what you have to say.

It’s trickier to write something insightful about a tried and trusted (perhaps even boring) technology that’s been around for a while. You could maybe write little tips and tricks, but I bet your inner critic would tell you that nobody’s interested in hearing about that old tech. It’s boring.

The result is that what’s being written about is not a reflection of what’s being widely used. And that’s okay …as long as you know that’s the case. But I worry that theres’s a perception problem. Because of the outsize weighting of new and exciting technologies, a typical developer could feel that their skills are out of date and the technologies they’re using are passé …even if those technologies are actually in wide use.

I don’t know about you, but I constantly feel like I’m behind the curve because I’m not currently using TypeScript or GraphQL or React. Those are all interesting technologies, to be sure, but the time to pick any of them up is when they solve a specific problem I’m having. Learning a new technology just to mitigate a fear of missing out isn’t a scalable strategy. It’s reasonable to investigate a technology because you genuinely think it’s exciting; it’s quite another matter to feel like you must investigate a technology in order to survive. That way lies burn-out.

I find it very grounding to talk to Drew and Rachel about the people using their Perch CMS product. These are working developers, but they are far removed from the world of tools and frameworks forged in the startup world.

In a recent (excellent) article comparing the performance of Formula One websites, Jake made this observation at the end:

However, none of the teams used any of the big modern frameworks. They’re mostly Wordpress & Drupal, with a lot of jQuery. It makes me feel like I’ve been in a bubble in terms of the technologies that make up the bulk of the web.

I think this is very astute. I also think it’s completely understandable to form ideas about what matters to developers by looking at what’s being discussed on Twitter, what’s being starred on Github, what’s being spoken about at conferences, and what’s being written about on Ev’s blog. But it worries me when I see browser devrel teams focusing their efforts on what appears to be the needs of typical developers based on the amount of ink spilled and breath expelled.

I have a suspicion that there’s a silent majority of developers who are working with “boring” technologies on “boring” products in “boring” industries …you know, healthcare, government, education, and other facets of everyday life that any other industry would value more highly than Uber for dogs.

Trys wrote a great blog post called City life, where he compares his experience of doing CMS-driven agency work with his experience working at a startup in Shoreditch:

I was chatting to one of the team about my previous role. “I built two websites a month in WordPress”.

They laughed… “WordPress! Who uses that anymore?!”

Nearly a third of the web as it turns out - but maybe not on the Silicon Roundabout.

I’m not necessarily suggesting that there should be more articles and talks about older, more established technologies. Conferences in particular are supposed to give audiences a taste of what’s coming—they can be a great way of quickly finding out what’s exciting in the world of development. But we shouldn’t feel bad if those topics don’t match our day-to-day reality.

Ultimately what matters is building something—a website, a web app, whatever—that best serves end users. If that requires a new and exciting technology, that’s great. But if it requires an old and boring technology, that’s also great. What matters here is appropriateness.

When we’re evaluating technologies for appropriateness, I hope that we will do so through the lens of what’s best for users, not what we feel compelled to use based on a gnawing sense of irrelevancy driven by the perceived popularity of newer technologies.

Going to Newcastle. brb

Thoroughly enjoyed last night’s double bill in the @DukeOfYorks of Cameron and Carpenter.

Just a shame it wasn’t a sing-along.

Aliens: https://www.youtube.com/watch?v=Noe95IxpsiQ

The Thing: https://www.youtube.com/watch?v=8faq5amdK30

Monday, April 1st, 2019

This “feature”—which is enabled in the latest version of iOS by default—is a very bad idea, in my opinion.

This “feature”—which is enabled in the latest version of iOS by default—is a very bad idea, in my opinion.