Jeremy Keith's Blog, page 18

border:none 2023

In 2013, I spoke at the border:none event in Nuremberg. I gave a talk called The Power of Simplicity.

It was a great little event. Most of the talks were, like mine, on technical topics; design, development, the usual conference material.

This year Joschi and Marc decided to have another border:none event ten years on from the first one. They invited back all the original speakers, as well as some new folks. They kept the ticket price the same as ten years ago���just thirty euros.

For us speakers from the previous event, the only brief they gave us was to consider what���s happened in the past decade. I played it pretty safe and talked about the web. I���ll post a transcript of my talk soon.

Some of the other speakers were far more ambitious. They spoke about themselves, the world, the meaning of life ���my presentation was very tame in comparison.

I really, really admire the honesty and vulnerability that those people displayed. Tobias Baldauf in particular took my breath away. He delivered an intensely personal talk on generational trauma that was meticulously researched and took incredible bravery to deliver. It was worth going to Nuremberg just for the privilege of being present for that talk.

Other talks were refreshingly tech-free. There was a talk on cold-water swimming. There was a talk on paragliding. And I don���t mean they were saying ���what designers can learn from cold-water swimming��� or ���how I became a better developer through paragliding.��� The talks were literally about swimming and paragliding.

There was a great variety of speakers this time around, include age ranges from puberty to menopause (quite literally���that was the topic of one of the talks). I had the great pleasure of providing some coaching before the event to fifteen year old Maya who was delivering her first talk in English. She did a fantastic job! And the talk she gave���about how teachers in her school aren���t always trusting of the technology they provide to students���was directly relevant to what we���re seeing in the world of work. Give people autonomy, agency and trust.

There was a lot of trust at border:none. Everyone who bought a ticket did so on trust���they had no idea what to expect. Likewise, Marc and Joschi put their trust in the speakers. They gave the speakers the freedom to talk about whatever they wanted. That trust was repayed.

Florian took some superb pictures of the event. Matthias wrote up his experience. So did Tom. Valisis shared the gist of his excellent talk.

At the end of the event there was some joking about returning in 2033. I love the idea of a conference that happens once every ten years. Count me in!

Decision time

I���ve always associated good design with thoughtfulness. Like, I should be able to point to any element in an interface and the designer should be able to tell me the reasons it���s there. Those reasons may be rooted in user needs or asthetics or some other consideration, but the point is that there���s a justification for it. Justify every pixel!

But I���ve come to realise that this is a bit reductionist. Now when I point at an interface element, I still expect the designer to be able to justify its inclusion, but I���d also like to know the trade-offs that were made.

Suppose there���s a large hero image. I���m sure the designer would have no problem justifying its inclusion on the basis of impact and the emotional heft it delivers. But did they also understand the potential downsides? Were they were aware of the performance implications of including a large image?

I hope the answer to both questions is yes. They understood the costs, but they decided that, on balance, the positives outweighed the negatives.

When it comes to the positives, universal principles of design often apply. Colour theory, typography, proximity, and so on. But the downsides tend to be specific to the medium that the design is delivered in.

Let���s say you���re designing for print. You want to include an extra typeface just for footnotes. No problem. There isn���t really a downside. In print, you can use all the typefaces you want. But if this were for the web, then the calculation would be different. Every extra typeface comes with a performance penalty. A decision that might be justified in one medium might not work in another medium.

It works both ways; on the web you can use all the colours you want, without incurring any penalties, but in print���depending on the process you���re using���you might have to weigh up that decision very differently.

From this perspective, every design decision is like a balance sheet. A good web designer understands the benefits and the costs behind each decision they make.

It���s a similar story when it comes to web development. Heck, we even have the term ���tech debt��� to describe decisions that we know aren���t for the best in the long term.

In fact, I���d say that consideration of the long-term effects is something that should play a bigger part in technical decisions.

When we���re weighing up the pros and cons of using a particular tool, we have a tendency to think in the here and now. How might this help me right now? How might this hinder me right now?

But often a decision that delivers short-term gain may well end up delivering long-term pain.

Alexander Petros describes this succinctly:

Reopen a node repository after 3 months and you���ll find that your project is mired in a flurry of security warnings, backwards-incompatible library ���upgrades,��� and a frontend framework whose cultural peak was the exact moment you started the project and is now widely considered tech debt.

When I wrote about making the Patterns Day website I described my process as doing it ���the long hard stupid way������a term that Frank coined in a talk he gave a few years back. But perhaps my hands-on approach is only long, hard and stupid in the short time. With each passing year, the codebase will retain a degree of readability and accessibility that I would���ve sacrificed had I depended on automated build processes.

Robin Berjon puts this into the historical perspective of Taylorism and Luddism:

Whenever something is automated, you lose some control over it. Sometimes that loss of control improves your life because exerting control is work, and sometimes it worsens your life because it reduces your autonomy.

Or as Marshall McLuhan put it:

Every extension is also an amputation.

���which is fine as long as the benefits of the extension outweigh the costs of the amputation. My worry is that, when it comes to evaluating technology for building on the web, we aren���t considering the longer-term costs.

Maintenance matters. With the passing of time, maintenance matters more and more.

Maybe we avoid thinking about the long-term costs because it would lead to decision paralysis. That���s understandable. But I take comfort from some words of wisdom on the web from the 1990s. Tim Berners-Lee���s style guide for hypertext:

Because hypertext is potentially unconstrained you are a little daunted. Do not be. You can write a document as simply as you like. In many ways, the simpler the better.

Increment by increment

The bedrock of the World Wide Web is solid. Built atop the protocols of the internet (TCP/IP), its fundamental building blocks remain: URLs of HTML files transmitted over HTTP. Baldur Bjarnason writes:

Even today, the web is like living fossil, a preserved relic from a different era. Anybody can put up a website. Anybody can run a business over it. I can build an app or service, send the URL to anybody I like, and most people in the world will be able to run it without asking anybody���s permission.

Still, the web has evolved. In fact, that evolution is something that���s also built into its fundamental design. Rather than try to optimise the World Wide Web for one particular use-case, Tim Berners-Lee realised the power of being flexible. Like the internet, the World Wide Web is deliberately dumb.

(I get very annoyed when people talk about the web as being designed for scientific work at CERN. That was merely the first use-case. The web was designed for everything ���and nothing in particular.)

Robin Berjon compares the web���s evolution to the ship of Theseus:

That’s why it’s been so hard to agree about what the Web is: the Web is architected for resilience which means that it adapts and transforms. That flexibility is the reason why I’m talking about some mythological dude’s boat. Altogether too often, we consider some aspects of the Web as being invariants when they’re potentially just as replaceable as any other part. This isn’t to say that there are no invariants on the Web.

The web can be changed. That���s both a comfort and a warning. There���s plenty that we should change about today���s web. But there���s also plenty���at the root level���that we should fight to preserve.

And if you want change, the worst way to go about it is to promulgate the notion of burning everything down and starting from scratch. As Erin says in the fourth and final part of her devastating series on Meta in Myanmar:

We don���t get a do-over planet. We won���t get a do-over network.

Instead, we have to work with the internet we made and find a way to rebuild and fortify it to support the much larger projects of repair���political, cultural, environmental���that are required for our survival.

Though, as Robin points out, that doesn���t preclude us from sharing a vision:

Proceeding via small, incremental changes can be a laudable approach, but even then it helps to have a sense for what it is that those small steps are supposed to be incrementing towards.

I���m looking forward to reading what Robin puts forward, particularly because he says ���I���m no technosolutionist.���

From a technical perspective, the web has never been better. We have incredible features in HTML, CSS, and JavaScript, all standardised and with amazing interoperability between browsers. The challenges that face the web today are not technical.

That���s one of the reasons why I have no patience for the web3 crowd. Apart from the ridiculous name, they���re focusing on exactly the wrong part of the stack.

Listening to their pitch, they���ll point out that while yes, the fundamental bedrock of the web is indeed decentralised���TCP/IP, HTTP(S)���what���s been constructed on that foundation is increasingly centralised; the power brokers of Google, Meta, Amazon.

And what���s the solution they propose? Replace the underlying infrastructure with something-something-blockchain.

Would that it were so simple.

The problems of today���s web are not technical in nature. The problems of today���s web won���t be solved by technology. If we���re going to solve the problems of today���s web, we���ll need to do it through law, culture, societal norms, and co-operation.

(Feel free to substitute ���today���s web��� with ���tomorrow���s climate���.)

event.target.closest

Eric mentioned the JavaScript closest method. I use it all the time.

When I wrote the book DOM Scripting back in 2005, I���d estimate that 90% of the JavaScript I was writing boiled down to:

Find these particular elements in the DOM andWhen the user clicks on one of them, do something.

It wasn���t just me either. I reckon that was 90% of most JavaScript on the web: progressive disclosure widgets, accordions, carousels, and so on.

That���s one of the reasons why jQuery became so popular. That first step (���find these particular elements in the DOM���) used to be a finicky affair involving , getElementById, and other long-winded DOM methods. jQuery came along and allowed us to use CSS selectors.

These days, we don���t need jQuery for that because we���ve got querySelector and querySelectorAll (and we can thank jQuery for their existence).

Let���s say you want to add some behaviour to every button element with a class of special. Or maybe you use a data- attribute instead of the class attribute; the same principle applies. You want something special to happen when the user clicks on one of those buttons.

Use querySelectorAll('button.special') to get a list of all the right elements,Loop through the list, andAttach addEventListener('click') to each element.

That’s fine for a while. But if you’ve got a lot of special buttons, you’ve now got a lot of event listeners. You might be asking the browser to do a lot of work.

There’s another complication. The code you’ve written runs once, when the page loads. Suppose the contents of the page have changed in the meantime. Maybe elements are swapped in and out using Ajax. If a new special button shows up on the page, it won’t have an event handler attached to it.

You can switch things around. Instead of adding lots of event handlers to lots of elements, you can add one event handler to the root element. Then figure out whether the element that just got clicked is special or not.

That’s where closest comes in. It makes this kind of event handling pretty straightforward.

To start with, attach the event listener to the document:

document.addEventListener('click', doSomethingSpecial, false);

That function doSomethingSpecial will be executed whenever the user clicks on anything. Meanwhile, if the contents of the document are updated via Ajax, no problem!

Use the closest method in combination with the target property of the event to figure out whether that click was something you’re interested in:

function doSomethingSpecial(event) { if (event.target.closest('button.special')) { // do something }}

There you go. Like querySelectorAll, the closest method takes a CSS selector���thanks again, jQuery!

Oh, and if you want to reduce the nesting inside that function, you can reverse the logic and return early like this:

function doSomethingSpecial(event) { if (!event.target.closest('button.special')) return; // do something}

There’s a similar method to closest called matches. But that will only work if the user clicks directly on the element you’re interested in. If the element is nested within other elements, matches might not work, but closest will.

Like Eric said:

Very nice.

Making the Patterns Day website

I had a lot of fun making the website for Patterns Day.

If you���re interested in the tech stack, here���s what I used:

HTMLCSS

Actually, technically it���s all HTML because the styles are inside a style element rather than a separate style sheet, but you know what I mean. Also, there is technically some JavaScript but all it does is register a service worker that takes care of caching and going offline.

I didn���t use any build tools. There was no pipeline. There is no node_modules folder filling up my hard drive. Nothing was automated. The website was hand-crafted the long hard stupid way.

I started with the content. I wrote out the words and marked them up with the most appropriate HTML elements.

Time to layer on the presentation.

For the design, I turned to Michelle for help. I gave her a brief, describing the vibe of the conference, and asked her to come up with an appropriate visual language.

Crucially, I asked her not to design a website. Instead I asked her to think about other places where this design language might be used: a poster, social media, anything but a website.

Partly I was doing this for my own benefit. If you give me a pixel-perfect design for a web page and tell me to code it up, either I won���t do it or I won���t enjoy it. I just don���t get any motivation out of that kind of direct one-to-one translation.

But give me guardrails, give me constraints, give me boundary conditions, and off I go!

Michelle was very gracious in dealing with such a finicky client as myself (���Can you try this other direction?���, ���Hmm��� I think I preferred the first one after all!���) She delivered a colour palette, a type scale, typeface choices, and some wonderful tiling patterns ���it is Patterns Day after all!

With just a few extra lines of CSS, the basic typography was in place.

I started layering on the colours. Even though this was a one-page site, I still made liberal use of custom properties in the CSS. It just feels good to be able to update one value and see the results, well ���cascade.

I had a lot of fun with the tiling background images. SVG was the perfect format for these. And because the tiles were so small in file size, I just inlined them straight into the CSS.

By this point, I felt like I was truly designing in the browser. Adjusting spacing, playing around with layout, and all that squishy stuff. Some of the best results came from happy accidents���the way that certain elements behaved at certain screen sizes would lead me into little experiments that yielded interesting results.

I���m not sure it���s possible to engineer that kind of serendipity in Figma. Figma was the perfect tool for exploring ideas around the visual vocabulary, and for handing over design decisions around colour, typography, and texture. But when it comes to how the content is going to behave on the World Wide Web, nothing beats a browser for fidelity.

By this point I was really sweating the details, like getting the logo just right and adjusting the type scale for different screen sizes. Needless to say, Utopia was a godsend for that.

I could���ve kept tinkering but the diminishing returns were a sign that it was time to put this out into the world.

It felt really good to work on a web page like this. It felt like I was getting my hands into the soil of the web. I don���t think it���s an accident that the result turned out to be very performant.

Getting hands-on like this stops me from getting rusty. And honestly, working with CSS these days is a joy. There���s such power to be had from using var() in combination with functions like calc() and clamp(). Layout is a breeze with flexbox and grid. Browser differences are practically non-existent. We���ve never had it so good.

Here���s something I noticed about my relationship to CSS; my brain has finally made the switch to logical properties. Now if I���m looking at some CSS and I see left, right, top, or bottom, it looks like a bug to me. Those directional properties feel loaded with assumptions whereas logical properties feel much more like working with the grain of the web.

Patterns Day is back!

Mark your calendar: Thursday, March 7th, 2024. That���s when Patterns Day will return for its third edition.

Patterns Day is a one-day event focused on design systems. It���s for designers, developers, project managers, writers, and anyone else who���s working with design systems, pattern libraries, style guides, and components. Tickets are on sale now!

Once again, Patterns Day will be in the magnificent Duke of York���s cinema in Brighton, with its historic charm and dangerously comfortable seats.

The first Patterns Day was all the way back in 2017. Then we had the second Patterns Day in 2019. You can watch videos of the talks from both years.

We all know what happened after 2019. Nothing like a global pandemic to stop an event in its tracks.

Now, finally, Patterns Day is returning in 2024.

After all this time, is there still a need for an event focused on design systems?

In my opinion, the answer is ���more than ever!���

When Clearleft first ran Patterns Day, we had been doing design systems work for a while, but other organisations were only at the start of their journey. Many of the attendees were from companies that were dabbling in design systems, or planned to put a design system together.

That situation has changed. Now most organisations either have at least some experience with design systems. Many companies have got design systems up and running.

But the challenges haven���t gone away. They���ve just changed. You might no longer need to convince anyone that a design system is a good idea, but you might well be struggling to convince people to use the design system you���ve got.

It can be lonely work. That���s why Patterns Day is so vital. It���s a chance to get together with other people going through the same struggles. You���ll have an opportunity to learn from their successes and failures. Most of all, you���ll have the reassurance that you are not alone.

I know that makes it sound more like therapy than a conference, but honestly, that���s where the true value lies.

We���ve already got some fantastic speakers lined up, but there are just as many still to come!

Can you tell that I���m very excited about this?

It would be lovely to see there. Tickets will cost ��255, but you can secure your place now at the super early bird price of just ��195. Dither ye not!

Can���t wait to see you in Brighton on March 7th���it���s going to be a day to remember!

Websites in the dock

I updated my Mac to the newest operating system, Sonoma. I did this to try out the new ���add to Dock��� feature in Safari. It���s like the ���add to Homescreen��� action on iOS.

Before I get into what���s good, I have to start by ranting about a big problem on both desktop and mobile: discovery.

First of all, you have to know that a square with an arrow sticking out of it means ���share���.

Okay, I can buy it. It���s no better or worse than the three horizontal lines of a hamburger icon, or the three horizontal dots of a kebab icon. And whereas the hamburger and kebab icons are used as a catch-all cupboard to sweep all your rubbish into, at least this icon has a specific meaning. It means share, right?

Well, it used to. But now it���s also home to ���add to Homescreen��� and ���add to Dock���. Neither of those actions are sharing.

Stretching semantics, I suppose you could say you���re sharing something with yourself.

Anyway, this is the biggest issue with progressive web apps on both iOS and Mac. Regardless of how well they work, there���s not much point if most people don���t know the option exists.

(Update: Jen rightly points out that you can also get to ���add to Dock��� from the file menu. Doh! How did I miss that���)

Discovery aside, I was interested to see how Safari handles web apps on desktop compared to how Chrome does it.

I���ve had one or two web apps in my dock for a while, installed through Chrome. Google Meet is one of them. I use it quite a bit, and honestly it feels no different to using a native desktop app.

One annoyance is that the Chrome browser also automatically launches whenever I launch the Google Meet icon in my dock. This wouldn���t matter if Chrome were my default browser, but I use Firefox. So whenever I���m using the Google Meet web app, there���s a Google Chrome icon hanging around in my dock, saying ���gizza job, I can do that.���

I opened Google Meet in Safari and then selected ���add to Dock��� from the square with an arrow sticking out of it. Then I quit Safari. I was delighted to see that when I launched the Google Meet web app from the dock, it didn���t automatically launch Safari! Excellent!

Even better, links within a Safari-installed web app respect your default browser choice. What I mean is, previously when I had Google Meet installed via Chrome, if I clicked an external link in Google Meet it opened in Chrome. But now with the Google Meet installed via Safari, external links open in Firefox, my browser of choice. Very good!

But the Safari-installed version of Google Meet is, alas, over-zealous with permissions. I have to grant access to my microphone and camera every single time I launch it. Previously���with the version installed via Chrome���it remembered my choice.

Now I don���t know if the behaviour in the Safari-installed version is a deliberate choice made for security reasons, or if it���s a bug. I suspect it���s a bug. After all, on iOS you get access to more permissions if a site is added to the homescreen���it���s the only way to ask for permissions for notifications, for example.

I added a few more sites to my dock: mastodon.social and thesession.org. They both work really well as standalone apps.

Interestingly, if I click a link to thesession.org from within the mastodon.social standalone web app (or the other way around), the link opens in my default browser. So the web apps don���t ���own��� the domains. That���s fine, although I wonder if it violates the principle of least surprise���perhaps the expectation is that the installed web app is the preffered owner of that link.

I also tried adding Google Calendar to my dock. Ironically, I can only do this with Safari. For some reason, Google have chosen not to make their calendar a progressive web app ���which means there���s no option to install it from Google Chrome.

They���re missing a trick there. It���s the perfect candidate for being a standalone app.

Actually, I take that back. Gmail is the perfect candidate for being a standalone app ���and yet it���s not a progressive web app. Very odd!

With Safari, you can add any website to the dock. It doesn���t need to be a progressive web app. But the installation experience works best if there���s a manifest file pointing to some nice icons.

As it turned out, Google Calendar runs like an absolute dog in Safari (and therefore as a Safari-installed web app). Before you cry conspiracy, note that it runs absolutely fine in Firefox. I know because I use it in Firefox every day. But I can���t add it to my dock from Firefox because Mozilla turned their back on progressive web apps a while back. A bad decision.

Google Calendar isn���t the only thing that runs slowly in Safari���s engine. This page on The Session has a very large DOM and a badly-coded in-page search (I know, I know, I need to improve it). It works fine in other browsers but Safari struggles mightily.

Still, aside from a few annoying little things around permissions and performance���and the situation with discovery���it feels great to have websites that act just like other apps. I like that some of the icons in my dock are native, some are web apps, and I mostly don���t notice the difference.

I wonder if there���s much point using wrappers like Electron any more? I feel like they were mostly aiming to get that parity with native apps in having a standalone application launched from the dock.

Now all you need is a website.

Crawlers

A few months back, I wrote about how Google is breaking its social contract with the web, harvesting our content not in order to send search traffic to relevant results, but to feed a large language model that will spew auto-completed sentences instead.

I still think Chris put it best:

I just think it���s fuckin��� rude.

When it comes to the crawlers that are ingesting our words to feed large language models, Neil Clarke describes the situtation:

It should be strictly opt-in. No one should be required to provide their work for free to any person or organization. The online community is under no responsibility to help them create their products. Some will declare that I am ���Anti-AI��� for saying such things, but that would be a misrepresentation. I am not declaring that these systems should be torn down, simply that their developers aren���t entitled to our work. They can still build those systems with purchased or donated data.

Alas, the current situation is opt-out. The onus is on us to update our robots.txt file.

Neil handily provides the current list to add to your file. Pass it on:

User-agent: CCBotDisallow: /User-agent: ChatGPT-UserDisallow: /User-agent: GPTBotDisallow: /User-agent: Google-ExtendedDisallow: /User-agent: OmgilibotDisallow: /User-agent: FacebookBotDisallow: /

In theory you should be able to group those user agents together, but citation needed on whether that���s honoured everywhere:

User-agent: CCBotUser-agent: ChatGPT-UserUser-agent: GPTBotUser-agent: Google-ExtendedUser-agent: OmgilibotUser-agent: FacebookBotDisallow: /

There���s a bigger issue with robots.txt though. It too is a social contract. And as we���ve seen, when it comes to large language models, social contracts are being ripped up by the companies looking to feed their beasts.

As Jim says:

I realized why I hadn���t yet added any rules to my robots.txt: I have zero faith in it.

That realisation was prompted in part by Manuel Moreale���s experiment with blocking crawlers:

So, what’s the takeaway here? I guess that the vast majority of crawlers don’t give a shit about your robots.txt.

Time to up the ante. Neil���s post offers an option if you���re running Apache. Either in .htaccess or in a .conf file, you can block user agents using mod_rewrite:

RewriteEngine OnRewriteCond %{HTTP_USER_AGENT} (CCBot|ChatGPT|GPTBot|Omgilibot| FacebookBot) [NC]RewriteRule ^ ��� [F]

You���ll see that Google-Extended isn���t that list. It isn���t a crawler. Rather it���s the permissions model that Google have implemented for using your site���s content to train large language models: unless you opt out via robots.txt, it���s assumed that you���re totally fine with your content being used to feed their stochastic parrots.

Trabaja remoto

August was a month of travels. You can press play on that month���s map to follow the journey.

But check out the map for September too because the travels continue. This time my adventures are confined to Europe.

I���m in Spain. Jessica and I flew into Madrid on Saturday. The next day we took a train ride across the Extremaduran landscape to C��ceres, our home for the week.

This is like the sequel to our Sicilian trip. We���re both working remotely. We just happen to do be doing it from a beautiful old town with amazing cuisine.

We���re in a nice apartment that���crucially���has good WiFi. It���s right on the main square, but it���s remarkably quiet.

There���s a time difference of one hour with Brighton. Fortunately everything in Spain happens at least an hour later than it does at home. Waking up. Lunch. Dinner. Everything is time-shifted so that I���m on the same schedule as my colleagues.

I swear I���m more productive working this way. Maybe it���s the knowledge that tapas of Iberican ham await me after work, but I���m getting a lot done this week.

And when the working week is done, the fun begins. C��ceres is hosting its annual Irish fleadh this weekend.

I���ve always wanted to go to it, but it���s quite a hassle to get here just for a weekend. Combining it with a week of remote work makes it more doable.

I���m already having a really nice time here and the tunes haven���t even started yet.

Simon’s rule

I got a nice email from someone regarding my recent posts about performance on The Session. They said:

I hope this message finds you well. First and foremost, I want to express how impressed I am with the overall performance of https://thesession.org/. It’s a fantastic resource for music enthusiasts like me.

How nice! I responded, thanking them for the kind words.

They sent a follow-up clarification:

Awesome, anyway there was an issue in my message.

The line ‘It’s a fantastic resource for music enthusiasts like me.’ added by chatGPT and I didn’t notice.

I imagine this is what it feels like when you���re on a phone call with someone and towards the end of the call you hear a distinct flushing sound.

I wrote back and told them about Simon���s rule:

I will not publish anything that takes someone else longer to read than it took me to write.

That just feels so rude!

I think that���s a good rule.