Explore My Notes

Disclaimer: The title link is an affiliate link, which means I get credit if you use it to sign up. Not really why I made this post, but figured why not 🤷‍♂️

Mailbrew is a service I've been meaning to check out for a while. Because it's a paid service (no free tier) I'm not sure it's something I would invest in right now, but I like the idea so I wanted to try it out. Initial thoughts are that it's simple to use and has some really neat design ideas, but dear lord I wish it allowed bulk editing. I just spent 30 minutes inputting about 20 Twitter feeds to one "brew" (their name for an email) because I had to manually edit each one to set it to be "two columns; two tweets". If I could have just saved that template it would have been perfect.

As it is, the system was still very easy to search for accounts on Twitter, find them, and add them to my own little feed. I also through in an RSS to see how that worked and it was just as simple. I've created a brew that contains all the frontend sources I like, but don't want to commit to subscribing too. That's a lot of people on Twitter, as well as huge feeds like CSS Tricks. I used to use Twitter's own suggested/curated feeds feature to keep up with most of these people, but since they destroyed that system and replaced it with one which is overloaded with spam and meaningless nonsense, I've been wanting something to fill the void. Right now I'll get the feed weekly, but it's the kind of thing which could be handy to check daily. If I like it I may even look into spinning up something similar, just for my own use, as email is a fine-enough delivery method but it's not really my preference. We'll see. For now, I've made the brew public: frontend twitterings.

Update 09/06/20: Having used Mailbrew for the allotted trial period, I've just let it lapse. As a result, I don't think the affiliate link is really worthwhile so I've removed the coded part and just left the homepage URL. I liked the service, but ultimately I found it didn't fit in my routine. I don't actually like newsletters; I prefer content feeds. So I never moved anything from RSS there, it was basically just Twitter accounts that I like but don't want to follow. Unfortunately, what I've discovered is that people's most popular tweets are rarely their best. They tend to be humorous or controversial. Neither is particularly useful. What's more, getting the brew daily was way too much; I don't even check my emails once a day, so it would just build up. Once a week was manageable, but made it feel like a chore (even if I invariably enjoyed reading it when I got around to it). I don't need to pay for a service that gives me chores. So yeah, a decent service but not for me.

Whilst archiving an old copy of Digital Photographer I came across a profile of North Devon photographer Ross Hoddinott. His work stood out as just exceptional landscapes from areas I love and he's clearly still going strong. Here are some of my favourites (click to see the high-res originals on Ross' site):

A solid introduction to the Jamstack, including full build tutorials for an initial SSG setup with Eleventy and Netlify, integrations with the News API service and Open Weather, geolocation checks and content localisation, Netlify functions for API requests, and even some mention of SSL on localhost.

A detailed overview of the various methods available to locally store website or web app data. Overall, the recommendation is:

• For critical resources (images, content, scripts etc.) use a service worker, specifically the Cache Storage API;
• For all other data, use IndexedDB (though adding an additional service which allows you to use that API with promises can also be very beneficial).

These processes have wide browser support, are well maintained, and have a low user impact. They're also better at persisting. For example, SessionStorage is locked to that browser tab, LocalStorage is now quite outdated and actively blocks the main thread, and cookies are constantly refreshed so bloat your HTTP request size. Other APIs are either deprecated (WebSQL, Application Cache), lack widespread support (File System API), or require explicit user permission (bad UX – Native File System API) so should be avoided.

You can use the StorageManager API to check how much space you're using and set limits, but most modern browsers now allow such large limits it should never be an issue (the article has an explicit example of how to use that API as well as what to do if you run up against storage quotas).

It can be worth explicitly setting your data to be considered persistent storage so that browsers don't delete it when they need more device space (but obviously use this cautiously and don't abuse it).

I'd be interested to see whether IndexedDB could be used with search blobs from Algolia, even if only on a local instance based on user permission.

Looks like CSS is getting extensibility built-in with a new @property element (works like @media – also looks like we're getting CSS.registerProperty() in JavaScript 🤔).

It'll work as below, and let you extend existing CSS functions with a similar syntax to CSS variables. Not 100% sure about how useful it will be, but it's always nice to see added flexibility and certainly the gradient animation use case provided in the example would have its purposes.

@property --my-property {
    syntax: '<color>';
    initial-value: green;
    inherits: false;
}

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:

• 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: