Journal

Here’s a lovely Design System that interestingly uses Eleventy for its reference website and other generated artefacts:

We use Eleventy for both the static documentation and the dynamically generated parts like component playgrounds and design tokens. We don’t currently use a JavaScript framework on the website, except Duet’s own components.

I find Duet interesting both from the Design System perspective (it contains lots of interesting component techniques and options) but also in terms of how far 11ty can be pushed.

Here are my current go-to resources when building a new site using Eleventy (11ty).

Build an Eleventy site from scratch by Stephanie Eckles. As the name suggests, this is for starting from a blank canvas. It includes a really simple and effective way of setting up a Sass watch-and-build pipeline that runs alongside that of Eleventy, using only package.json scripts rather than a bundler.

Eleventy Base Blog from 11ty. If rather than a blank canvas you want a boilerplate that includes navigation, a blog, an RSS feed and prism CSS for code block styling (among other things) then this is a great option. Of course, you can also just cherry-pick the relevant code you need, as I often do.

Eleventy Navigation Plugin. This allows you to set a page or post as a navigation item. It handily supports ordering and hierarchical nesting (for subnavigation). You can then render out your navigation from a layout in a one-liner or in a custom manner.

Eleventy Cache Assets Plugin. This is really handy for caching fetched data so as not to exceed API limits or do undue work on every build.

11ty Netlify Jumpstart is another from Stephanie Eckles but this time a “quick-start boilerplate” rather than blank canvas. It includes a minimal Sass framework, generated sitemap, RSS feed and social share preview images. The About page it generates contains lots of useful info on its features.

forestry.io settings for 11ty Base Blog and forestry.io settings for Hylia (Andy Bell’s 11ty starter)

Add Netlify CMS to an 11ty-based website

All my posts tagged “11ty”

More to follow…

A while back, Jake Archibald tweeted:

Don't render buttons on the server that require JS to work.

The idea is that user interface elements which depend on JavaScript (such as buttons) should be rendered on the client-side, i.e. with JavaScript.

In the context of a progressive enhancement mindset, this makes perfect sense. Our minimum viable experience should work without JavaScript due to the fragility of a JavaScript-dependent approach so should not include script-triggering buttons which might not work. The JavaScript which applies the enhancements should not only listen for and act upon button events, but should also be responsible for actually rendering the button.

This is how I used to build JavaScript interactions as standard, however sadly due to time constraints and framework conventions I don’t always follow this best practice on all projects.

At work, we use Stimulus. Stimulus has a pretty appealing philosophy:

Stimulus is designed to enhance static or server-rendered HTML—the “HTML you already have”

However in their examples they always render buttons on the server; they always assume the JavaScript-powered experience is the baseline experience. I’ve been pondering whether that could easily be adapted toward better progressive enhancement and it seems it can.

My hunch was that I should use the connect() lifecycle method to render a button into the component (and introduce any other script-dependent markup adjustments) at the earliest opportunity. I wasn’t sure whether creating new DOM elements at this point and fitting them with Stimulus-related attributes such as action and target would make them available via the standard Stimulus APIs like server-rendered elements but was keen to try. I started by checking if anyone was doing anything similar and found a thread where Stimulus contributor Javan suggested that DIY target creation is fine.

I then gave that a try and it worked! Check out my pen Stimulus with true progressive enhancement. It’s a pretty trivial example for now, but proves the concept.

Astro looks very interesting. It’s in part a static site builder (a bit like Eleventy) but it also comes with a modern (revolutionary?) developer experience which lets you author components as web components or in a JS framework of your choice but then renders those to static HTML for optimal performance. Oh, and as far as I can tell theres no build pipeline!

Astro lets you use any framework you want (or none at all). And if most sites only have islands of interactivity, shouldn’t our tools optimize for that?

People have been posting some great thoughts and insights on Astro already, for example:

• Chris Coyier’s review
• Review in CSS-Tricks Newsletter #255 including links to Chris’s Astro demo site
• The web is too damn complex, by Robin Rendle
• Astro’s introductory blog post

(via @css)

The GOV.UK Design System is a nice Design System success story. At 3 years old it’s reporting high traffic, usage and satisfaction ratings. GDS do so much great, thoughtful and inclusive work (which they also share with the community) and it’s inspiring to see it being a success.

There are now more than 900 live cross-government services using the GOV.UK Design System - 75% more than a year ago. It’s being used in more than 2,600 repositories on GitHub and has been forked more than 200 times.

Here’s a handy JS package for “copy to clipboard” functionality that’s lightweight and installable from npm.

It also appears to have good legacy browser support plus a means for checking/confirming support too, which should assist if your approach is to only add a “copy” button to the DOM as a progressive enhancement.

(via @chriscoyier)

@Amy_Hupe recently posed a great question on Twitter regarding inclusive language for buttons:

What's an inclusive way to describe what you do to a (digital) button, given it might be pressed with a mouse click, a screen tap, a key on a keyboard, and so on? I've tended to use "select" but wondering if that's right?

There are a lot of good suggestions and my current feeling is that:

1. it depends. What’s right for one context may not be for another; and
2. there are a few good ones.

My favourites are:

• use;
• “click or tap”; and maybe
• press (which may work as a common abstraction).

I also offerered this alternative/remix:

Could another way to do this / work around the awkwardness be via the pattern “Do thing X by using the Y button”? i.e. describe the action/result, making the button itself less important so you can just use “using” as your verb. So… “Submit the form using the “Submit” button”.

“via” is another word/pattern that’d similarly allow less need to worry about physical stuff. So “Launch a preview via the “Preview” button”. Same idea as “using”.

And I liked Craig Abbot’s observation:

it’s actually a bit weird to describe the physical interactions anyway. It should be intuitive. If a button says continue, it’s pretty obvious you need to interact with it. If you need to explain the UI usually there’s a bigger problem.

I’m not such a fan of these suggestions:

• select; and
• activate

I’ve just finished reading Never Let Me Go by Kazuo Isihiguro.

Afterwards I was also keen to see the film, which I enjoyed. It featured great performances by Carey Mulligan and Andrew Garfield in particular, and a haunting score. Although I enjoyed the book, I found it a little slow-paced and so watching the film helped bring it all together (despite taking a few liberties with the plot).

Lastly, I enjoyed this short interview with the author in which he interestingly remarked that the sci-fi element was just a device to support the primary topic of managing friendship and loving relationships within our short lifetimes.

I should have bookmarked it long before now, but just revisiting the Lightning Design System I’m reminded that is really well organised and executed.

SLDS saves time and energy, freeing designers and developers to focus on larger issues of usability and meaning. Standardized, reusable components support collaboration, reinforce branding, and provide a consistent look and user experience.

Having a nice moment revisiting this amazing 2006 Ai records double-header from @datassette and @plant43_ and remembering pre-lockdown Glasgow life.