Andy has built a career considering the impact of note-taking and ways to maximise it as a way to gain deeper insights and develop general knowledge. This notes microsite is one of their related experiments: a fluid UI that maps out navigation through interlinked notes. It's clever, with some nice touches, but I do find it a little clunky. Still, plenty here to take note of, if you'll excuse the pun.
A surface-level look at the world of note-taking apps, what the impact of "AI" may be, and why the much-lauded benefits of these tools never really seem to materialise. Ironically, I found the article as it's currently the most-read recent piece on Readwise, a tool explicitly designed as a note-taking app, which may not be the best indication of the benefits its users are feeling (or not feeling, as this would indicate 😅).
I agree with Casey's experience around note-taking, in that simply building a database of neatly back-linked and tagged information does not make for improved recall or understanding, but I find it funny that the single most successful tool for that very endeavour is rarely discussed in these circles: wikis. Wikipedia has managed to curate and interlink a vast amount of humanity's knowledge, and it is used by researchers and the general public all over the world for learning purposes. Personal wikis have similar capabilities (yes I am aware of the obvious bias as I write this on my personal wiki). Yet they rarely get a mention alongside tools such as Obsidian or Roam which, whilst incredible in their own way, maybe shouldn't be the final resting place for that very reason. A wiki encourages a certain level of self-curation and expansion. Though, I suppose, there is also nothing stopping people from using Obsidian like that, either.
Still, I definitely think the points here about AI are valid: if there is one area AI will come to dominate it is information retrieval and summarisation.
On the pros and cons of having all of human history and creative output at your fingertips:
Collectively, this material offers me an abundance of riches — far more to work with than any beat reporter had such easy access to even 15 years ago.
And yet most days I find myself with the same problem as the farmer: I have so much information at hand that I feel paralyzed.
On one of the few real benefits I feel AI will serve – recall:
An AI-powered link database has a perfect memory; all it’s missing is a usable chat interface. If it had one, it might be a perfect research assistant.
On the power of AI as a tool for bubbling ideas up from an archive:
But if I could chat in natural language with a massive archive, built from hand-picked trustworthy sources? That seems powerful to me, at least in the abstract.
On the problem with hallucinations and lack of citations:
A significant problem with using AI tools to summarize things is that you can’t trust the summary unless you read all the relevant documents yourself — defeating the point of asking for a summary in the first place.
On the issue with most note-taking software, how it abstracts away the central purpose (questioning your own knowledge); and also just really like "transient strings of text" bit:
I’ll admit to having forgotten those questions over the past couple years as I kept filling up documents with transient strings of text inside expensive software.as the farmer: I have so much information at hand that I feel paralyzed.
I'm a sucker for a personal collection displayed on the web, and I really love the simplicity of Jamie's design for his digital bookshelf. An easy rating system; simple (and fast) filters; and a very refined UI that is made visually appealing by the use of the actual book covers and some nice whitespace application.
💀 NOTE: The original site no longer appears to be online; the source has been replaced with an Internet Archive link.
Need to self-host your front end away from the "modern" services like Netlify or Vercel? As both continue to get a little sketchier with time, it's definitely something I'm having to consider. Deploying a static site to an old-school host (like my favourite: Krystal) is easy enough, but you lose that wonderful "rebuild on Git push" that we've all become accustomed to. Or do you?
Whenever I push an update in my websites master branch in GitHub, it notifies my server through something called a webhook. My server pulls the latest version of my site from GitHub, runs a Hugo build, and moves the built files into my live site directory.
Chris has written up how to achieve similar functionality on Digital Ocean. I'm not sure how well this would translate to other services, but the toolchain seems generic enough. You need:
And that seems to be about it.
The steps look like this:
git clone git@github.com:<YOUR_USERNAME>/<YOUR_RESPOSITORY>.gitdeploy.php and the code below;htaccess file);theadhocracy.co.uk/deploy.php;Here's the code (note Chris' version may be more up to date, just saving here in case that post disappears):
<?php
/**
* Automated deploy from GitHub
*
* https://developer.github.com/webhooks/
* Template from ServerPilot (https://serverpilot.io/community/articles/how-to-automatically-deploy-a-git-repo-from-bitbucket.html)
* Hash validation from Craig Blanchette (http://isometriks.com/verify-github-webhooks-with-php)
*/
// Variables
$secret = getenv('GH_DEPLOY_SECRET');
$repo_dir = '/srv/users/serverpilot/apps/<YOUR_APP>/build';
$web_root_dir = '/srv/users/serverpilot/apps/<YOUR_APP>/public';
$rendered_dir = '/public';
$hugo_path = '/usr/local/bin/hugo';
// Validate hook secret
if ($secret !== NULL) {
// Get signature
$hub_signature = $_SERVER['HTTP_X_HUB_SIGNATURE'];
// Make sure signature is provided
if (!isset($hub_signature)) {
file_put_contents('deploy.log', date('m/d/Y h:i:s a') . ' Error: HTTP header "X-Hub-Signature" is missing.' . "\n", FILE_APPEND);
die('HTTP header "X-Hub-Signature" is missing.');
} elseif (!extension_loaded('hash')) {
file_put_contents('deploy.log', date('m/d/Y h:i:s a') . ' Error: Missing "hash" extension to check the secret code validity.' . "\n", FILE_APPEND);
die('Missing "hash" extension to check the secret code validity.');
}
// Split signature into algorithm and hash
list($algo, $hash) = explode('=', $hub_signature, 2);
// Get payload
$payload = file_get_contents('php://input');
// Calculate hash based on payload and the secret
$payload_hash = hash_hmac($algo, $payload, $secret);
// Check if hashes are equivalent
if (!hash_equals($hash, $payload_hash)) {
// Kill the script or do something else here.
file_put_contents('deploy.log', date('m/d/Y h:i:s a') . ' Error: Bad Secret' . "\n", FILE_APPEND);
die('Bad secret');
}
};
// Parse data from GitHub hook payload
$data = json_decode($_POST['payload']);
$commit_message;
if (empty($data->commits)){
// When merging and pushing to GitHub, the commits array will be empty.
// In this case there is no way to know what branch was pushed to, so we will do an update.
$commit_message .= 'true';
} else {
foreach ($data->commits as $commit) {
$commit_message .= $commit->message;
}
}
if (!empty($commit_message)) {
// Do a git checkout, run Hugo, and copy files to public directory
exec('cd ' . $repo_dir . ' && git fetch --all && git reset --hard origin/master');
exec('cd ' . $repo_dir . ' && ' . $hugo_path);
exec('cd ' . $repo_dir . ' && cp -r ' . $repo_dir . $rendered_dir . '/. ' . $web_root_dir);
// Log the deployment
file_put_contents('deploy.log', date('m/d/Y h:i:s a') . " Deployed branch: " . $branch . " Commit: " . $commit_message . "\n", FILE_APPEND);
} An excellent overview of the European Accessibility Act, how it overlaps with existing regulations, and the impact it might have. Doesn't get too technical, but does do a good job of explaining the high-level concepts and addressing a few tangential questions, like the result of Brexit on the UK's position.
(Can you tell I'm currently researching the EAA for work?)
On the WAD and where it applies:
It only applies to you if you're a public sector body in Europe, including the UK, as it was implemented in 2016 before Brexit.
On the UK equivalent of the WAD:
The Public Sector Bodies Accessibility Regulations 2018 are, as the name suggests, aimed at public sector bodies also. But, the important difference here is that this is UK specific law.
Because they are harmonised, if you meet the Public Sector Bodies Accessibility Regulations, you will also meet the EU Accessibility Directive. Cool huh?
On the standard behind these laws, EN 301 549:
However, in short, EN 301 549 is a technical standard that lays down the accessibility requirements for ICT (information and communications technology) products and services.
It is essentially just a set of guidelines which tells organisations how to make products accessible, rather than all the legalities which explains what happens to them if they do not!
On the EAA in general:
The European Accessibility Act, on the other hand, is focused on private sector organisations selling products or services to customers that live in EU member states.
And, it's the first time that, whether you provide public services to people in the EU, or you sell products or services to customers in the EU, you will all need to meet the same standard of accessibility.
It's a significant step towards making the digital world more inclusive for everyone and I couldn't be more excited for it to arrive!
Simply put, if you're in the private sector and you operate within the EU, you'll have to make sure your products and services meet the EAA's accessibility requirements. That means more than just making your website accessible.
On the "increased market reach"(I hate these kinds of business-focussed accessibility arguments, but the stat is a good one to have up your sleeve) :
With more than 80 million people in the EU living with disabilities, making your digital offerings accessible can significantly expand your customer base.
On how Craig feels the same way 😅:
Again, I realise I’m making this about money, but we are talking about the private sector here, and unfortunately in private sector, money makes the world go round!
On the impact of the EAA in a post-Brexit Britain:
As we just mentioned, the EAA affects organisations selling to customers in EU member states. So if thats your organisaion, then put simply, you need to comply!
In the UK, private sector companies are also still bound to the Equality Act 2010, which makes it illegal to discriminate against people with protected characteristics, of which one is disability. This means private sector organisations have been expected to make reasonable adjustments for people with disabilities for over a decade anyway.
On the way UK companies could find themselves outcompeted by European, accessible ones:
Even if you only ever plan on selling to people in the UK, your product is going to appear far inferior to your EU competitors if you don’t adopt the same standards. Trust me, there is no competitive advantage in having an ableist product or service in 2023!
Accessibility is not just about ticking boxes; it's about inclusivity. Implementing these standards shows that your business values all customers, regardless of their physical abilities.
The EAA's Article 32 is the one that people get a bit angry about, particularly in accessibility circles. In brief, it gives companies with existing contracts or customers an additional five years to make their stuff accessible (i.e. until June 2030). Bizarrely, that caveat is even longer for physical self-service machines, which get a whopping twenty years additional grace period. As Craig points out, that feels excessive, particularly given how slow to upgrade those services are in the first place (i.e. they probably need to be upgraded sooner than most digital services).
Still, whilst it's an annoying caveat that will certainly be abused by some companies to kick the can down the line – particularly with internal tooling – it doesn't really offer that large of a loophole. Any new sales, customers, or contracts must be accessible from 2025, so if you're updating your software and hardware anyway, why wouldn't you push that out to all customers?
I guess it gives legacy codebases a pass (the kind where one stubborn client refuses to upgrade for a decade, because they prefer one small feature or have been grandfathered into a sweetheart payment scheme or something), so companies have a five-year runway to sunset them, but considering we've already had a five-year runway it does feel a little unnecessary. Still, as Craig says, they might get some extra leeway, but...
But, come 2030, we'll all be here to nail them to the floor!
Tick-tock.
Tick-tock.
On what Article 32 actually says:
The first part of Article 32 sets up a transitional period that ends on 28 June 2030.
It's a grace period for service providers to continue using products they were already using before the 28 June 2025 cut-off date.
Any new stuff purchased will need to be accessible immediately once that 28 June 2025 deadline passes.
Service contracts that were agreed before 28 June 2025 can keep going without any changes until they expire, but only for a maximum of five years from that date.
Article 32 basically says, if they were lawfully used before 28 June 2025, they can still be used until they're no longer 'economically useful', or up to a maximum of 20 years.
On the annoying 20-year grace period for self-service machines:
This bit is probably the part that sucks the most, because most self-service terminals are already about 20 years out of date! Lets be honest, ticket machines for subway trains and super-market self-checkouts aren't exactly what we think of when we give examples of 'cutting edge technology'!
I have used Tailwind on various projects. I think for prototyping and quick proof of concepts, for one-off projects that never need to be updated, it has some advantages. But for code that you want to last; code that needs to be maintained; code that should have thought applied to it, Tailwind has issues. Jeff has done a great job of outlining what those issues are, pointing out that CSS is currently undergoing a CSS3-level reinvention that solves almost all of the issues Tailwind purportedly solves, but better, and offering some additional thoughts around the edges of why Tailwind seems to have been adopted so rapidly.
On how Tailwind causes long-term debugging headaches, particularly for those of us who build/debug in the browser (read: front-end specialists):
Yeah, you might have auto-completion in your editor, but the browser inspector is utterly neutered. You can't use the applied styles checkbox, because you'll wind up disabling a style for every usage of that tailwind class.
Due to the tailwind compiler, which was a solution to the "shipping massive amounts of CSS" problem, you don't have a guarantee that the class you're trying to poke into the inspector view will actually exist.
On the needless repetition of writing CSS via Tailwind (or any utility-class-only system):
You can't chain selectors. If you want your hover, focus, and active classes to be the same, you have to write them all.
On the issues with declaring "specificity is the devil" or "the cascade is too complex to scale" and refusing to use the language as designed:
Tailwind, and other utility frameworks, throw out the best and most often misunderstood aspects of CSS. CSS was explicitly designed with certain features, that, while complicated, are immensely useful once you can master them. The cascade, selector chaining (see above), and specificity are all very powerful tools. If you misunderstand them, yeah you can cut yourself. Just like if you don't use a saw properly you can cut yourself.
Selector chaining, particularly with the advent of new CSS selectors likeisandwhere, allows very clean reuse of common bits of CSS. You get to separate the properties that affect how something looks from what is being affected. It's obvious, but in tailwind, you don't get that.
And on how Tailwind still has specificity even if proponents like to argue it doesn't (a breed of specificity with no clear method to work around, no less, which often causes bigger headaches than the native cascade would have in the first place):
And it's a lie to say you don't have to worry about specificity in tailwind; tailwind has its own specificity. Classes are read left-to-right by the browser, and so if you dob-1 bg-blue b-2, guess what? Your element gets bothb-1andb-2, and the browser will probably chooseb-2as your border, and throw awayb-1.
On @apply:
@apply is a gigantic code-smell, it goes against everything tailwind supposedly stands for, and doesn't make writing your CSS any easier.On who advocates the loudest for Tailwind:
The people I've seen who are most excited over tailwind are generally those that would view frontend as something they have to do, not something they want to do.
On how Tailwind's time (if it ever truly existed) may be coming to an end:
I've seen other engineers, of all levels, stuck in a mire of bad CSS, and so to them maybe Tailwind seems like a lifesaver. But CSS is better now. It's not perfect, but it's better than its ever been, and it's better than tailwind. Give it another try.
An open-source fork of the Firefox web browsers, with a strong(er) focus on privacy and security. Basically disables all telemetry and most of the slightly questionable decisions that Mozilla have made over the years, either by stripping them out completely or relegating them to user-controlled settings (such as session restore). Also comes bundled with an ad-blocker and a few privacy settings enabled by default. Claims to keep up-to-date with the latest Firefox release, with a 1-3 day lag to ensure nothing slips through.
Not worth the switch right now (it obviously also disables features like Firefox Sync) but useful to remember in case Mozilla goes off the deep end 😉
A useful piece of research diving into the continued fragmentation of viewport and screen sizes across the web. I was actually one of the data points, as I saw the original call to arms (a clever microsite that did nothing but log out the current viewport dimensions, which were saved to a back end somewhere), and had been wondering what would come of the experiment, so it's nice to see it written up in such an interesting and creative way.
The results are not overly surprising, but I particularly like the comparison between common design tool "breakpoint templates" and how often those values were actually recorded. Spoiler: it isn't very often 😉
On the size of the dataset:
We gathered over 120,000 datapoints with over 2,300 unique viewport sizes.
On how fragmented even a supposedly locked-down web experience is, where an iOS browsing session may take place in Safari, an in-app browser, or even the new 3D preview:
Even on one iOS device, there's a minimum of 3 environments a website could find itself in, based on operating system states.
On how breakpoint-based design results in a worse overall UX:
If however, you tend to build with very specific breakpoints and hard values for typography, sizing and spacing, you might find that even with the best intentions, you’re not providing the optimal user experience.
Instead of making design decisions on strict, limited breakpoints, keep in mind the sheer amount of fragmentation there is in viewports.
There's been a lot of hyperbole – in both directions – around Apple's much-anticipated first-steps into VR. I feel this write-up from MartianCraft does a fairly good job of weighing up some of the immediate pros and cons, but largely I just really liked this sentiment:
No one should be writing the Vision Pro’s epitaph — no one knows how the market will respond to a new category. (For the same reason, no one should be proclaiming it as the next iPhone.) But many seem to be seeing the Apple Vision Pro and visionOS with blinders on (see what I did there?).
There definitely does seem to be a hint of "haven't we been here before?" around the doomerism to do with the new product. And as someone who is distinctly not an Apple fanboy, I feel like the Vision Pro may well be the next big hit. But then I just really want it to be. XR is so obviously a solution to many computing problems that I've believed in it since the Google Glass days.
(I'll caveat this by saying the rest of the article is good but I don't agree with many of the takeaways. I don't think people will ultimately care that much about the isolationism of the device, nor do I think that will be much of a talking point outside of certain tech circles. And I also don't think many of the much-lauded applications will ever come to fruition. People seem to forget that most of us already have capable XR devices in our pockets, but you don't see fancy apps letting plumbers X-ray building schematics onto walls or helping chefs get real-time updates on customer allergies. Those applications are already possible, they just rely on infrastructure which would be incredibly costly and far too restrictive to ever make sense, and a fancy new VR headset won't change that. But immersive gaming, home cinemas, and Zoom calls? Yeah, this'll do those things pretty darn well, hopefully as well or better than existing solutions. Because that's where I see the real benefit of these devices: the ability to replace dozens of existing hardware decisions around your home. No more TVs, no more multi-monitors, no more iPad, no more home automation hub. That's the future I want.)
I've been doing quite a bit of research into European accessibility legislation, so this write-up from Bogdan on the subtle differences in the WAD between Norway and the EU was very useful.
The basic gist is: Norway has only implemented parts of the upcoming EAA, specifically those covering the web, mobile applications, and digital documents, but those parts are already live (as of 2021). This simplifies conformance in that it means you only have to worry about WCAG 2.1 AA criteria, with a few exceptions:
In fact, technically, private sector businesses only need to meet WCAG 2.0 AA (another departure from the broader EU rules), and internal or business tools are not covered, including commercial tools such as CMSes and CRMs:
Professional systems that you only have access to as employee of the business are not covered.
On how the exceptions don't really matter; 2.1 AA is still the target:
In my experience with organizations from both sectors WCAG 2.1 on A and AA levels is the actual target already now.
Sure, I can analyse it in hindsight and identify what causes this unintended behaviour, but that sounds an awful lot like excusing it. In the end, it doesn’t matter what my intentions were or what the circumstances were. It’s my actions that matter. More specifically, it’s the effect of my actions on other people that matter.