Jeremy Keith's Blog, page 20

Creativity

It���s like a little mini conference season here in Brighton. Tomorrow is ffconf, which I���m really looking forward to. Last week was UX Brighton, which was thoroughly enjoyable.

Maybe it���s because the theme this year was all around creativity, but all of the UX Brighton speakers gave entertaining presentations. The topics of innovation and creativity were tackled from all kinds of different angles. I was having flashbacks to the Clearleft podcast episode on innovation���have a listen if you haven���t already.

As the day went on though, something was tickling at the back of my brain. Yes, it���s great to hear about ways to be more creative and unlock more innovation. But maybe there was something being left unsaid: finding novel ways of solving problems and meeting user needs should absolutely be done ���once you���ve got your basics sorted out.

If your current offering is slow, hard to use, or inaccessible, that���s the place to prioritise time and investment. It doesn���t have to be at the expense of new initiatives: this can happen in parallel. But there���s no point spending all your efforts coming up with the most innovate lipstick for a pig.

On that note, I see that more and more companies are issuing breathless announcements about their new ���innovative��� ���AI��� offerings. All the veneer of creativity without any of the substance.

In the margins

John Willshire has been pondering web marginilia AKA stuff you put in your sidebar.

He has a particular fondness for the good ol��� blogroll. I���ve still got my analogue equivalent on my homepage���the bedroll. It���s a list of links to people who���ve stayed over. Maybe I should also have a regular blogroll, but I suspect it would just be a reproduction of feeds I���m subscribed to.

Then there���s marginalia at the level of a blog post, rather than a whole blog. Kevin Marks points out that this is something that Vannevar Bush described his theoretical memex doing���a device I was just talking about. Kevin created a proof of concept showing outbound and inbound links.

Outbound links are annoted versions of the A elements in a blog post. Inbound links are webmentions (which should now include this post of mine).

Kevin has those links in the margins on either side of the blog post. I���ve also got links that go with my blog posts, but they���re displayed linearly:

the post itself,any responses (webmentions),related posts, something I only recently added, andposts from the same day further back in time.

Do they still count as marginalia when they���re presented vertically rather than alongside? For mobile devices, I���m not sure there���s any alternative.

A memex in every web browser

When Mathew Modine���s character first shows up in Christopher Nolan���s Oppenheimer, I figured the rest of the cinema audience wouldn���t have appreciated me shouting out ���VANNEVAR BUSH IN THE HOUSE!��� so I screamed it on the inside.

The Manhattan Project was not his only claim to fame or infamy. When it comes to the world we now live in, Bush���s idea of the memex has been almost equally influential. His article As We May Think became a touchstone for Douglas Engelbart and later Tim Berners-Lee.

But as Matt Thompson points out:

���the device he describes does not resemble the internet or anything I���ve ever found on it.

Then he says:

What Bush was describing sounds to me like what you might get if you turned a browser history ��� the most neglected piece of the software ��� into a robust and fully featured machine of its own. It would help you map the path you charted through a web of knowledge, refine those maps, order them, and share them

Yes! This!! I 100% agree with the description of browser history as ���the most neglected piece of the software.��� While I wouldn���t go as far as Chris when he says web browsers kind of suck, I���m kind of amazed that there hasn���t been more innovation and competition in this space.

If anything we���ve outsourced the management of our browsing history to services like Delicious and Pinboard, or to tools like Obsidian and Roam Research. Heck, the links section of my website is my attempt to manage and annotate my own associative trails.

Imagine if that were baked right into a web browser. Then imagine how beautiful such a rich source of data might look.

Like Matt says:

I don���t think anything like this exists. So Bush���s essay still transfixes me.

Indie Web Camp Nuremberg

After two days at border:none in Nuremberg, it was time for two days at Indie Web Camp, also in Nuremberg.

I hadn���t been to an Indie Web Camp since before The Situation. It felt very good to be back. I had almost forgotten how inspiring and productive they can be.

This one had a good turnout of around twenty people. We had ourselves an excellent first day of thought-provoking sessions. Then on day two it was time to put some of those ideas into action.

A little trick I like to do on the practical day is to have two tasks to attempt: one of them quite simple, and the other more ambitious. That way, as long as I get the simpler task done, I���ll always have at least something to demo at the end of the day.

This time I attempted three bits of home improvement on my website.

Autolinking Mastodon usernames

The first problem I set myself was ostensibly the simple one. But it involved regular expressions, so then I had two problems.

I wanted to automatically link up Mastodon usernames if I mentioned one in my notes. For example, during border:none I mentioned Brian���s mastodon username in a note: @briansuda@lo��f��ll.is.

That turned out to be an excellent test case. Those Icelandic characters made sure I wasn���t making unwarranted assumptions about character sets.

Here���s the regular expression I came up with. It���s not foolproof by any means. Basically it looks for @something@something.something.

Good enough. Ship it.

Related posts

My next task was a bit more ambitious. It involved SQL queries, something I���m slightly better at than regular expressions but that���s a very low bar.

I wanted to show related posts when you get to the end of one of my blog posts.

I���ve been tagging all my blog posts for years so that���s the mechanism I used for finding similar posts. There���s probably a clever SQL statement that could do this, but I ended up brute-forcing it a bit.

I don���t feel too bad about the hacky clunky nature of my solution, because I cache blog post pages. That means only the first person to view the blog post (usually me) will suffer any performance impacts from my clunky database queries. After that everything���s available straight from a cached file.

Let���s say you���re reading a blog post of mine that I���ve tagged with ten different keywords. I make a separate SQL query for each keyword to get all the other posts that use that tag. Then it���s a matter of sorting through all the results.

I loop through the results of each tag and apply a score to the tagged post. If the post shares one tag with the post you���re looking at, it has a score of one. If it shares two tags, it has a score of two, and so on.

I decided that for a post to be considered related, it had to share at least three tags. I also decided to limit the list of related posts to a maximum of five.

It worked out pretty well. If you scroll down on my recent post about JavaScript, you���ll see links to related posts about JavaScript. If you read through a post on accessibility testing, you���ll find other posts about accessibility testing. If you make it to the end of this post about Mars colonisation you���ll see links to more posts about exploring our solar system.

Right now I���m just doing this for my blog but I���d like to do it for my links too. A job for a future Indie Web Camp.

Link rot

I was very inspired by Remy���s recent post on how he���s tackling link rot on his site. I wanted to do the same for mine.

On the first day at Indie Web Camp I led a session on link rot to gather ideas and alternative approaches. We had a really good discussion, though it���s always worth bearing in mind that there���ll never be a perfect solution. There���ll always be some false positives and some false negatives.

The other Jeremy at Indie Camp Nuremberg blogged about the session. Sebastian Greger was attending remotely and the session inspired him to spend the second day also tackling linkrot.

In the end I decided to stick with Remy���s two-pronged approach:

a client-side script that���as a progressive enhancement���intercepts outbound links and re-routes them toa server-side script that redirects to the Internet Archive if the link is broken.

Here���s the JavaScript I wrote for the first part.

It���s very similar to Remy���s but with one little addition. I check to see if the clicked link is inside an h-entry and if it is, I pass on the date from the post���s dt-published value.

Here���s the PHP I wrote for the server-side redirector. The comments tell the story of what the code is doing:

Check that the request is coming from my site.There also has to be a URL provided in the query string.Make a very quick curl request to get the response headers from the URL. The time limit is set to 1 second.If there was any error (like a time out), give up and go to the URL.Pick the response headers apart to get the HTTP status code.If the response is OK, go to the URL.If the response is a redirect, go around again but this time use the redirect URL.Construct the archive.org search endpoint.If we have a date, provide it. Otherwise ask for the latest snapshot.Ping that archive.org URL. This time there���s no time limit; this might take a while.If there���s an archived copy, redirect to that.There���s no archived copy. Give up and go the URL anyway.

Not perfect by any means, but it works for the most common cases of link rot.

For the demo at the end of the day I went back into my archive of over 10,000 links and plucked out some old posts, like this one from December 2005. It takes a little while to do the rerouting but eventually you get to see the archived version from the same time period as when I linked to it.

Here���s another link from 2005. Here���s another. Those links are broken now, but with a little patience, you���ll still get to read them on the Internet Archive.

The Internet Archive���s wayback machine really is a gift. I can���t imagine how would it be even remotely possible to try to address link rot on my site without archive.org.

I will continue to donate money to the Internet Archive and I encourage you to do the same.

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!