A wonderful overview of why progressive enhancement and inclusive design go hand-in-hand, and why both are still necessary and deeply useful techniques for modern web development. I particularly liked Matthias' breakdown of why design tools should provide the ability to build/prototype designs progressively as well, so that designers can more easily understand how their work will actually end up deployed:
Because in order to practice progressive enhancement well, every member of the team has to be able to make well-informed decisions. If a designer never sees a design in its most basic form, how can she possibly improve this state of the system?
Dave has been running Netlify Analytics (server-side) and Fathom (client-side) for a few years, and the results are in: data integrity is hard. They offer a solid overview of why neither dataset should be trusted, but why neither is necessarily wrong, either. Still, the big takeaway for me is an old one: do not trust data blindly, and if your data is only coming from one source (and therefore cannot be verified independently), trust it even less 😉
On the differences between the datasets:
The data tells me I get somewhere between 12k and 26k visitors to my site who open anywhere between 18k and 333k pages.
On data integrity (or lack thereof):
My trust in analytics data is at an all-time low. Browser-level privacy improvements, ad blockers, and bot traffic have obliterated the data integrity.
On the perils of basing business decisions on data alone:
If I, or some hypothetical manager, put too much stock into these metrics I could see it causing a firestorm of reprioritization based on bot traffic. We’d be chasing the tail of a health check bot somewhere in Germany.
On what to do about it (and a nice use of the concept of a "sage"):
If your goal is to grow your product, you need a mixture of research (academic and applied), user tests, A/B tests, analytics, performance audits, accessibility audits, and a plethora of other considerations. Even if you have all those processes in place, I still think you need a human — a sage — who can read the tea leaves and interpret the data in a way that the business understands.
A very useful package for getting around the otherwise convoluted steps needed to upgrade npm on Windows. Just open up a PowerShell instance as Admin and use the following three commands (and only the last one if you need to do this again):
Having spent the day affixing all manner of things to our walls, I figured it might be worth jotting down some tips and hard-learned lessons:
Be careful when measuring with a tape measure; it's best to measure from the 10cm line and then just subtract the difference, as the end isn't always that accurate (or better yet, buy a proper ruler!);
It's fine to tap a wall plug into a hole as much as you need to make the screw fit, particularly in plaster (screws don't seem to grip plaster too well, so the last bit isn't really that important);
A reversed drill bit or arbitrary steel rod are useful (plus a hammer) for the above tapping;
Without fail, our wall plugs ask for holes 1mm too large. If it says 7mm, use a 6mm drill bit; if it says 10mm, use 9mm, etc.
Screw thickness does more for strength than length; length helps it grip more, though, and a combination of both is always preferable;
If a screw is twisting at the end of insertion, it probably means the wall plug is too small; try the next size up;
Screw holes being too long isn't much of an issue, really.
Probably nothing too spectacularly novel here, but potentially useful nonetheless.
I use emoji quite a lot on this site, which means I'm already aware of some of the more unusual browser/OS quirks. Don't ever use flag emoji (except pirate 🏴☠️) because Microsoft refuses to weigh in politically on the fact that Taiwan is a legitimate, autonomous country (there, see, is it really that hard?), avoid anything that isn't at least 2-3 releases old, and use an emoji font set for the very oldest glyphs, like 😊, if you really don't want them to appear as 2D, black and white equivalents.
Nolan digs a little deeper, providing some useful insight into extra quirks (Chrome on Linux doesn't deal with emoji well at all; "emoji" actually includes a lot of graphical representations of non-emoticon glyphs, like numbers and punctuation, so don't set emoji fonts for text blocks; etc.) and some pointers on how to improve cross-browser support.
At a time when web browsers have gained a staggering array of new capabilities – including Bluetooth, USB, and access to the filesystem – it’s still a struggle to render a smiley face. It feels a bit odd to argue in 2022 that “the web should have emoji support,” and yet here I stand, cap in hand, making my case
On the emoji characters you don't think about:
As it turns out, characters like the asterisk (*), octothorpe (#), trademark (™), and even the numbers 0-9 are technically emoji.
On how to deal with emoji:
Well, first you need a way to detect broken emoji. This is actually much harder than it sounds, and basically boils down to rendering the emoji to a <canvas>, testing that it has an actual color, and also testing that it doesn’t render as two separate characters.
On Mozilla's hidden Firefox trick:
Interestingly, this problem is actually solvable in Firefox, since they ship their own “Mozilla Twemoji” font
An in-depth guide to SVG filters, including colour manipulation, contrast, brightness, sharpening, blur, blend modes, and distortion. Very useful when trying to work out which combination of filters might be useful to achieve a certain effect.
A fascinating series looking into how to turn a modern React eCommerce front end into as fast a page as possible. The conclusions are not what I had expected.
In particular, the concept of streamed HTML using "chunked Transfer-Encoding" is a neat one. It basically chunks the page up and delivers bits as they are made available (similar to rehydration, but on the server), giving you a much more meaningful page load where non-dynamic data appears almost instantly, and dynamic data is loaded as the API calls are completed (including with skeleton or loading states, if necessary).
Showing pieces of a page as data sources finish is useful for almost any dynamic site.
Taylor points that this is a very old, extremely well supported technique, that almost no one uses, mainly because the native APIs are clunky and no dev tooling really exists. Well, none except Marko, which looks incredibly interesting:
And [Marko] only uses client-side JS for stateful components? You don’t say.
It has an <await> component that enables this exact "chunked" page/asynchronous HTML effect. Very cool!
The articles also take a critical look at heavy UI patterns, like carousels and dropdowns.
On carousels versus tiles:
Think about what code the carousel needs that tiles don’t:
Next/previous swiping vs. buttons, and switching between them
Position indicator
Pause/Play (required for accessibility)
(prefers-reduced-motion) check and mitigation
Accessibly hiding offscreen slides
Autoforwarding
Animation timing
Repositioning slides to the left when wrapping
Tab ↹ handling
No matter how efficiently those features are implemented, they’re still code users must download. (If users actually liked carousels that could be worth it, but, uh…)
On why problematic UI patterns are so common:
But if these UI patterns are annoying, not very accessible, and costly, why do so many sites use them?
I think they’re easier to design, since they don’t have to care about the underlying page.
I suspect analytics falsely report increased “engagement” because they need more interaction than less intrusive designs. Even if said interaction is, say, users trying to get the damn carousel to hold still.
Sometimes, they can be the best solution for a problem — but as soon as you have that component, it’s tempting to reuse it for other, less-suited problems.
Just to save time in the future, this search string for Windows Explorer can be used on the root Amazon Drive folder to find all non-image files:
NOT *.raw AND NOT *.jpeg AND NOT *.CR2 AND NOT *.jpg AND NOT *.dng AND NOT *.tiff AND NOT *.png AND NOT *.CR3 AND NOT folder AND NOT *.tif AND NOT *.xmp
(remove AND NOT *.xmp for the correct value, but those tend to be tiny)
I've been fascinated by the Quagga Project since I was a kid, back when they were (rumoured) to be keeping a small herd of the creatures at the University of Cape Town, visible on drives around the foot of Table Mountain when visiting family. From the back seat, I would desperately scan the treelines and fields for the < 1 minute their "paddock" was supposedly in view, but never saw anything.
I'm glad that the project is still ongoing and getting some pretty positive results. I hadn't realised that genetic evidence has shown that the Quagga is just a subspecies; I actually thought the "de-extinct" population was more of a hybridisation project rather than purely selective breeding, but that actually sits a lot better in terms of the bioethics involved:
With the quagga only a subspecies of the diverse plains zebra, those visual characteristics could still be out there in the existent population, scattered among herds roaming anywhere from Etosha to Zululand.
Also a fan that they're immediately distinguishing it as an effective new subspecies, Rau's quagga:
Firstly, it is important to note that this is not a traditional quagga, but a Rau’s quagga, named after Reinhold Rau because of its different genetic routeIt
I do wonder what becomes of them once the project is "complete". They mention that the next step is focusing on the brown colouration, but that they could see this achieved in 1-2 generations, at which point the plan is to let the herd into the wild. But where? The quagga was originally a Cape/fynbos species with a spread up into Namibia and across towards KwaZulu Natal, so the logical reintroduction regions would be the West Cape, Karoo, Garden Route, and Cape Point. However, all of these are strongholds for the endangered Cape Mountain Zebra, and I wonder how much the two species might compete. If you were to drop the herd off in Kruger or somewhere further north, where there are Plain's Zebra, I'd imagine the two subspecies would just intermingle and the coat pelage of the quagga would again become lost. It will be interesting to see how they balance the two concerns, but I'm hopeful that they find a way. I'd love to be able to visit somewhere like Camdeboo National Park in 20 or 30 years and find myself staring at a scene like this:
They are a remarkably good likeness to historical quagga already; an incredibly beautiful creature indeed! Photo from the Quagga Project website.
How do you make your writing as accessible as possible? Plain text – a system of simplifying the words and phrases used to reduce overall complexity – is an "easy" solution, and I've never seen a better explanation and overview of the practice than this article.
There's a huge amount of useful information here, from the history of plain text, the reasoning behind it, and the methods that experts use to translate technical or lofty literature into it, to the existing attempts at automating or ranking text in terms of accessibility (seemingly tied to education level, with a focus on the US "grade" system). Spoiler: those models aren't particularly useful – who'd have thunk!
But best of all, the entire article is written in both plain text and the original "natural" language (non-plain text?). You can choose which you prefer via a top-level setting, or toggle each paragraph between the two, to see what the difference is directly. That's a really clever feature and I found the comparisons fascinating. Here's a quick example:
It's not a fancy animation, but the added context for the article is brilliant and massively helped my understanding of the subject matter.
In plenty of places, I was interested to see that the information conveyed subtly differed. In some paragraphs, useful context (often causal inference) had been wholesale removed from the plain text version, whilst in others, the plain text provided additional details that made an explanation either more accurate or more specific. I also found some parts of the plain text surprisingly difficult to parse; my brain just isn't used to seeing fragmented sentences like this, I guess.
Here's an example translation, with the plain text second:
Additionally, there is a tendency to censor content for these audiences rather than explain it, which can contribute to continued disparities, like the higher rate at which people with ID experience sexual violence than nondisabled people.
Writers will censor writing for these groups. To censor something means to take out information the writer thinks is not appropriate. Taking out information can make some problems worse.
For example, people with ID experience sexual violence more than nondisabled people. But some writers think people with ID should not read about sex or sexual violence. So, readers don’t have all the information they need.
To me, it seems fairly clear that the plain text version does a much better job of explaining what the text is inferring, chiefly here that the removal of information about sex or sexual violence leaves people with ID (intellectual disabilities) at greater risk of sexual violence themselves. They are denied access to the information that might allow them to understand what is and isn't "normal" or even legal, so may not realise that their treatment is unusual or problematic. However, I also find that plain text harder to read; it forces me to read the first paragraph several times to understand what it's saying.
Regardless, the article is a treasure trove of useful information and provides a huge amount of useful context to the discussion about making writing as accessible as possible 👏👏
On what plain text is and why it is important:
Writing text that can be understood by as many people as possible seems like an obvious best practice. But from news media to legal guidance to academic research, the way we write often creates barriers to who can read it. Plain language—a style of writing that uses simplified sentences, everyday vocabulary, and clear structure—aims to remove those barriers.
On the Flesch-Kincaid formula, a model for measuring the simplicity of language in a given text:
The Flesch-Kincaid formula measures two things:
How long words are.
How many words are in a sentence.
The formula says the shorter the words and sentence, the easier it is to read.
On the Dale-Chall formula:
Dale-Chall is another readability score. It measures two things:
How long each sentence is.
The number of easy or hard words.
Dale-Chall uses a list of 3,000 easy words. Dale-Chall says these are words most 4th graders know. Any other word is a hard word.
On the issues of word lists and gaming the Dale-Chall system:
The original Dale-Chall list of “familiar words” was compiled in 1948 through a survey of U.S. fourth-graders, and even the most recent update to the list in 1995 retains obsolete words like “Negro” and “homely” while omitting “computer.”
We can lower the Dale–Chall readability score even further by adding a second sentence (“Yes!”) that has just one word. This reduces the average sentence length, and so reduces the overall score.
On the Lexile Framework and the issues of proprietary models:
Unfortunately for us, the Lexile Framework is the intellectual property of MetaMetrics, the private company that created it, so we can only guess at the secret recipe...
On the risk of automated "translations" and statistical models:
Technology alone isn’t the answer. Even the most thoughtful algorithms and robust data sets lack context. Ultimately, the effectiveness of plain language translations comes down to engagement with your audience.
Desmond has written a great overview of the current state of "post types" within the IndieWeb community, but the takeaway that struck me as most interesting/valuable is their distinction between original content and derivative content. The former encapsulates most "traditional" blog content: articles, notes, photos, reviews, even check-ins. The latter contains anything that needs additional context: likes, shares, bookmarks (to a degree), comments. That feels like a clear and logical division worth remembering 👏
On the scheme they settled with:
With that in mind, I came up with the following scheme:
Posts. This is my original content, and includes my notes, photos, and articles.
Blog. This is a separate feed of just my articles, so that my original blog can live on. I could make an argument that some people may just want to read my essays, but really this is all about nostalgia, pure and simple.
Links. These are my bookmarks. This feed is mostly for me, since I tend to use bookmarks as a "read later" pile.
Everything. This is a feed of every single post. It's currently the only feed where you can find my likes, reposts, and replies, but they're mixed in with everything else, and I'm making a bet that this is acceptable.
There's something so utterly weightless about this image which I love 😍
I first saw Samantha's work in a small café near Topsham, Devon. I love the way motion is captured by breaking the animals out of their frames. Plus, the combination of watercolour and line drawing is precisely my style, just executed well beyond what I could manage. I'd love to pick something up by them at some point, or even give a similar idea a go myself 😊
