Progressive summarisation may not be ideally suited for me right now, but it's an idea which stuck with me whilst I was undergoing my own taxonomy building process. It's worth stepping through the setup for the idea logically:

• You want to create a "second brain" that stores all the information you find useful but don't have an immediate need for, so you can reference it later; a "storage and retrieval system" for knowledge;
• That storage system needs a structure, which is where P.A.R.A (Projects, Areas, Resources, Archives) comes in. This system uses these four folders to quickly categorise any piece of information. Projects is for things being actively worked on; areas is for core subjects that you use routinely (hobbies or work-related); resources is broader topic information that you may want in the future (more like a library categorisation system); and archives are for notes that you find interesting but may never need to look at again;
• Sorting information into these buckets of relevance places it on a timeline: projects are for now; archives are potentially for never. The other two fit in the medium- and long-term.

But P.A.R.A doesn't explain how to take notes. There are two approaches: tagging and notebooks (aka categorisation). Tagging sounds cool, because you build an esoteric web of interlinked data over time, but it doesn't fit how most people's brains work so it's bad for memory recall. Notebooks work like our brains, forming "discrete containers", but they kill serendipity (to paraphrase).

Tiago argues for a note-first approach where you focus on simply recording knowledge as notes. It's a universally applicable system, so it works regardless of existing content structures and makes migration simpler, and it prioritises the act of notation which is the most useful in the long run. It mimics atomic design: notes are atoms and can be assembled into elements, molecules etc. in the future.

But that means our notes need to be well designed so they're useful in the future, but they also need to be quick to create (efficient). There's an obvious paradox here; as Tiago puts it:

You cannot compress something without losing some of its context.

He gives some great outlines of this, where notes are too condensed and therefore lose meaning with time, or two contextualised and therefore too long to be an efficient note-taking (or reading) process. The balance point is progressive summarisation, where you take an iterative approach. It's similar to how I used to condense course notes into flashcards into memory. Critically, you do this over time. So step one is done the moment you create the note; step two the first time you return to it, and so on.

1. Makes notes. These will be long.
2. Go through and bold key takeaways or phrases, the bits that really matter.
3. Highlight any passages which you come back to more than once, so that the real gems slowly rise to the surface.
4. Create a tl;dr style summary; use your own words so that it becomes learned knowledge.
5. (this is rare) Remix it. Find the links, the novel new take, whatever spark of creativity you've had on the subject and write that up as a top-level paragraph.

At no point during summarisation do you delete anything; this is pretty much only ever an additive process, it's just that you slowly prioritise the information until what's left is the stuff which is most useful. That means if your use changes in the future, you still have the full context.

It's an interesting take on cataloguing information and I can't help but consider it an ideal methodology for Wiki-style information stores. Unfortunately, I don't want wiki-style stores; I want an information web. I don't see it working quite as well for that in the long term.

I love Heydon's breakdown of why "accessible" =/= "good". To paraphrase: accessibility is about removing barriers that would prevent people from using your site, but if the content is crap or the functionality is confusing then all you're doing is letting more people suffer a bad experience. Inclusive design seeks to remedy that:

Access is important, but inclusion is bigger than access. Inclusive design means making something valuable, not just accessible, to as many people as we can.

He also makes a good point on why inclusion is not the same as "a11y" + "UX":

In short, inclusive design means designing things for people who aren’t you, in your situation. In my experience, mainstream UX isn’t very good at that.

Inclusive design aims to make sure things work for people, not forgetting those with clinically recognized disabilities. A subtle, but not so subtle, difference.

As accessibility experts have been arguing for years, we're not talking about edge cases; inclusive design makes the argument that creating a better experience benefits everybody whilst having the neat side effect of also improving accessibility. It's a reframing of the age-old argument and that is better than simply keeping the old argument because it doesn't appear to be getting anywhere.

For instance, no matter what your cognitive or visual abilities are, small text presented with a stylised font on a low contrast background will be hard to read. Instead, using high contrast ratios with simple typefaces and supporting functionality like pinch-to-zoom makes your site more inclusive and accessible all at once.

Then, finally, there's this neat summary of why we should use semantic HTML:

HTML is a toolkit for inclusion.

Of course I fell down a rabbit hole with Tom Scott videos after the last note, but I had to save this one as well. Not just because it's a perfect example (with incredible simulations to visualise the math) of how a number of design decisions have stacked on top of one another to create a system which actively kills people, but also because I know these crossroads. They're not far from where my Gran lives and I've driven through them plenty of times myself.

Oh, and also because during a five-minute video explaining why so many cyclists are killed at this intersection every year... at least three cars are filmed engaging in precisely the behaviour that causes those deaths 🤦‍♂️

Ever had any questions about copyright and fair use? Chances are this video will answer them (and, depressingly, chances are the answer is "No, that isn't fair use; yes, you need to pay a license fee"). It certainly helped clear up a number of things for me, whilst (as ever with anything Tom does) being clear about what is/isn't a grey area – and why those grey areas maybe don't matter.

I think Tom makes an extremely well-reasoned argument for why the current system is fundamentally broken, how YouTube's Content ID system is a pretty excellent bandaid that cannot and should not be relied on (but also shouldn't be trashed), and what we can do about. Chiefly, reduce copyright to a maximum of 50 years 👍

There is one thread throughout all these examples: under the current system it often doesn't matter who is actually in the right. Even if the answer to "Is it fair use?" is clear, it's actually about whether you can afford to defend a case. You could be 100% sure it's fair use, but unless you're prepared to spend the time and money to actually fight that in court? It. Doesn't. Matter.

A great review of the differences and similarities between universal design, inclusive design, and plain old accessibility, from one of the originators of universal design within the web community (as Matt points out the concept's roots go back to architecture in the 1980s, which I hadn't realised).

Some useful definitions:

Accessibility is the goal to ensure that products support each individual user’s needs and preferences. This is a pretty broad definition, I’ll
admit. Notably, it doesn’t define people with disabilities as the beneficiaries, and that’s on purpose.

Universal design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design.

Matt doesn't explicitly try to define inclusive design, but I like this attempt from OCAD U in Toronto that he highlights:

We have defined Inclusive Design as: design that considers the full range of human diversity with respect to ability, language, culture, gender, age and other forms of human difference.

I also really like this analogy of how you might define climbing a mountain in the context of inclusion:

Inclusive design is the practice of going up the mountain — we can always look for ways to include more people and situations to our designs, even if the result only gets us a few steps up the trail at a time.

Universal design, by contrast, implies that reaching the summit is the true goal. It’s all well and good to talk about inclusion, but if we’re happy enough making it to the first campground up the trail, we’ll never even try to accommodate the effort needed to go all the way.

I'm using InDesign increasingly it seems and overall I really dig it, but I recently ran into a fairly simple problem that doesn't have an official solution: inline code styling. It's pretty much a standard these days to highlight inline code with a background colour, something like this: <strong>. However, InDesign doesn't allow you to set background fill for a single word (or partial string of any kind).

Luckily, there is a workaround, which I found thanks to the user Wolff over on Stack Exchange. You use a ridiculously large underline effect to mimic a background (with non-breaking spaces for additional padding). Just select the word or phrase, go to the Character Style menu and edit the Underline Options like so:

I can never remember what the differences are between noopener, noreferrer, and nofollow, or when best to use them, so here's a handy guide that covers pretty much all of the basics.

Tl;dr:

• All three are values for the rel attribute on <a> tags;
• There's no point using any of them unless you have target="_blank" set (i.e. the link will force a new tab to open), and if you do you should use noopener to reduce cross-site phishing risks (there's no downside);
• Their primary goal is to restrict the access the linked page has to your website/the page linking to it;
• noreferrer blocks analytics tracking, which you probably don't want to do (but I guess is a way to subtweet via the indie web 😂). It also prevents SEO cross-linking scores, so if you really hate a linked website and don't want to boost it in search, then use this value;
• Ditto nofollow, though this is relevant regardless of what the target is; it just stops search engine crawlers from traversing the link, so ideal if you have it go somewhere you don't want associated with your site or search indexed, or if the link is doing fancy stuff (i.e. it should be a button 😉). There's a valid point here that user-generated content (such as comments) can benefit from applying nofollow by default, to reduce spam efficacy;
• Apparently, nofollow is a requirement for sponsored links and ads, so you don't generate clickthrough revenue based on spiders.

(PS: the article's own tl;dr is arguably even more concise and worth a read)

Now here's something I've been looking for: online (non-Flash) versions of popular board games. It feels like this industry should be booming right now! Board Game Arena looks pretty interesting, with a lot of great games, multiplayer options, and a cheap premium track of only $4 a month (guests can play for free). I also hadn't realised that Steam has a decent selection.

An interesting thought experiment from Chris: if a client asked you to build a website that could last a minimum of 10 years, what would you do? Lots of influential people in his answers, but I'm most interested in some of the proposed solutions. Basically:

• Use semantic HTML and CSS; minify JS as much as possible (and obviously no JS frameworks or dependencies);
• No externally hosted resources or data i.e. you can't call out. Either inline, self-host, or remove everything external;
• Clean, minimal design; simple colour palette; good typography (several people recommend system fonts, but I actually feel it would be best to host font files locally and fall back to "classic" system fonts. You never know when Windows might kill Arial, or when a new OS suddenly takes off);
• Consider internationalisation support (who says English is the main language in 10 years?);
• Stick to viewport units wherever possible to adapt to new screen resolutions and sizes; ditto SVG;
  
• Minimal copy – "even words go stale";
• Register the domain and hosting for the full 10 years upfront and set up auto-renewal of stuff like SSL.
  

Based on experience and observation in my time in the industry, I’d say it’s somewhere around 75% of websites are completely gone after 10 years, let alone particular URL’s on those websites being exactly the same (reliable external resources).

In all of these apps, every change you make updates the URL, instantly saving your progress in an easily sharable link. You don’t have to create an account or log in. In fact, you couldn’t if you wanted to because there’s no database! These apps are completely static.

What a fun idea. I've obviously seen (and have used) URLs contain state information in the past, such as user preferences (light/dark mode or animation), but building an entire game using nothing but URL parameters is pretty slick. The tip of encoding into base64 is great, too, as that really maximises what you can do with the space you have, though it does hurt extensibility (and readability) for your users.

Kasey mentioned this blog post in her talk yesterday. I wish I'd checked it out sooner, as it pretty much covers my notes from her (excellent) presentation but with greater clarity 👍 The perfect overview of the main WCAG 2.1 guidelines that all websites should strive to meet.

Oh dear. Tim's put together some actual numbers on the impact that using a frontend framework has on the user. As a proponent of the Jamstack, which pretty much has JavaScript frameworks at its core, these types of articles are always worrying, but they remain absolutely necessary information. So let's rip off the band-aid:

Sites with Angular ship 344% more JavaScript on desktop at the 10th percentile, and 377% more on mobile. Sites with React, the next heaviest, ship 193% more  JavaScript on desktop and 270% more on mobile devices.

Ouch 😢

Vue fares a little better, then comes jQuery (no real surprises there), with "vanilla" websites in the lead (again, not surprising; as Tim puts it, you can't start with JavaScript and expect to ship less). Thread times are similar, though here React is bottom of the pile by a clear margin:

React sites bring up the tail end, spending 248% more time on desktop devices and 658% more time on mobile devices. No, 658% is not a typo. At the 10th percentile, sites with React spend 2.7s on the main thread dealing with all the JavaScript sent down.

In comparison, Angular is rocking 230%-313% at the 10th percentile. This gets "better" as you begin looking at worse sites (i.e. the 90th percentile), but the overall trend persists and the numbers are still terrifying. At the tail-end, React sites are spending 20.8 seconds just parsing the JavaScript! Even more damning for React is that single-framework sites (which should perform better across the board) actually end up performing worse for the bottom 50%. Quite why is debatable, though Tim argues for site migrations meaning that some React sites are still offloading a lot of the work to jQuery, which remains more performant.

Worse still is how badly these framework-based websites perform on mobile.

Even at the 10th percentile, React sites spend 431.5% more time on the main thread on mobile devices as they do on desktop devices.

That's equivalent to over 10 seconds just to load the page properly... Still, whilst these results are even more damning than I would have predicted, there is room for hope. Tim is right in suggesting that vanilla JavaScript is the best alternative, but he also points to other technologies which could be a positive trade-off. More performant frameworks like Svelte and Preact help a lot; SSGs such as Gatsby, NuxtJS, and NextJS also give you massive savings (whew 😊).

He even points out that there are some forks and tools beginning to appear that simply strip all that JS out of the shipped site. For instance, the No JS Gatsby plugin looks pretty great; probably something worth experimenting on for this site.