Just a neat tip: the autocomplete="one-time-code" attribute/value allows an HTML form to fetch a code used for two-factor authentication directly from the messaging app. Seems to only work for numeric or password input elements, but that should cater to most 2FA use cases. Neat
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:
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.
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:
rel attribute on <a> tags;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);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;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;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:
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.