British Bugs does what it says on the tin, providing a treasure trove of photos and information about all manner of bugs found in the UK.
The Bird Guides forum was an invaluable resource whilst we were failing to see the bearded vulture that made the UK it's home last summer, and I've continued to check in from time-to-time since. In particular, their live sightings map is a brilliant tool for checking whether any rarities have been spotted nearby, or just discovering wild areas with good bird populations.
Niche? Sure 😂 But the Nature Spot website offers some excellent photo identification slides for a lot of species found across the UK. I've found it particularly useful for determining flies and beetles.
Particularly great for invertebrate species, but UK Safari has put together a wide collection of photos on a huge variety of critters found in the British Isles. Particularly great that biomorphs and invasive/introduced species are included.
A brilliant resource from the Mammal Society of Britain: a comprehensive list of all mammal species that occur in or around the British Isles, including identification diagnostics, known ranges, lifestyle habits, and general information.
The surprising thing? In a recent primary in New York, some people had trouble with the new method. It’s not that the method of voting is particularly difficult. The problem is that we’ve trained ourselves to be RIGHT. To have “our candidate” and not be open (or pushed) to even consider that there might be an alternative. And to feel stress when we need to do the hard work of ranking possible outcomes, because that involves, in advance, considering acceptable outcomes that while not our favorite, would be acceptable.
I don't find this surprising. Or actually a problem. As we say in software development: this is a feature, not a bug 😁 Forcing people to consider their actions, to weigh up possibilities, and simultaneously breaking down tribal barriers? Feels like win-win!
Stephen has some interesting views on the Indieweb movement. I'm not sure I agree with many, but it's useful to understand the angle they're coming from and I can, at least, respect their reasoning.
One bit that did spark a thought was his comparison on how the web is often centred around broadcasting, specifically getting content out to as many people/places as possible. I agree that this is probably a problematic model, but found this note on context collapse useful for understanding some of the mess of social media:
The commercial web brought with it context collapse, in which everybody is talking to everybody. This is what creates the need for filters and algorithms and moderation and all the things we said above that the Indieweb is trying to avoid. But when everybody talks to everybody, these are unavoidable. They have to be managed somehow, and sometimes it feels like most Indieweb projects are exercises in different ways of doing this
Relatedly, I thought this was a neat summation on what we should perhaps be aiming towards:
A system based on webs, in other words, and not on stars.
Stephen has also outlined how we might go about doing this, both in terms of ideals to strive for and project constraints that should (in his view) be an MVP for a true "indie web". Here I think I disagree more, but these three ideals definitely ring true as something the web should strive for generally:
- a way for people to store and manage their own data (where 'data' means any digital creation or record, including metadata),
- a way for people to share data with each other without being required to give up their rights or ownership over that data,
- a way for data management and sharing to be independent of the particular platform they are using,
Memex is an interesting looking tool for bookmarking, with more than a feel of second-brain to it. Saving for future organisation binges 😁
A fascinating look at how modern front-end architecture and practices can help solve some of the communities issues; even the ones they initially created! Really neat to see how Brad has been using tools like Storybook and React to drive a clearer delineation of front-of-the-frontend and back-of-the-frontend work. Also helps make design systems seem incredibly powerful in that tech stack.
The gist is that "consumable UI components" create a bridge: front-of-the-frontend devs get to create reusable, beautiful, accessible but dumb components; then back-of-the-frontend devs import them, hook up the business logic, and pass through any dynamic or API-driven or server-determined (etc.) content using simple APIs (in React-land, those APIs are
As I see it, directly consumable UI components serve as a bridge between The Great Divide. It creates a healthy handshake between the front of the frontend and the back of the frontend.
They take these presentational UI components and wrap them in a layer of
smarts that handles business logic, data manipulation, and whatever
else they need to successfully implement the alert component in the real
The workflow for this is fascinating:
- Use Storybook as a front-end source of truth (as he puts it: a "front-end workshop environment"). All components and primitives get built and tested here. Brad also builds out whole page compositions in Storybook so you can see components in context and demonstrate dynamic front-end states more easily;
- Components are built with small APIs that allow dynamic data and business logic to be injected. Sometimes these are very open (allowing whole components or objects, for example) or very strict. They're also used to enforce best practice e.g. restricting colours to pre-approved, WCAG considered combinations or preventing a component with an image from being used without
alttext. Sometimes, a11y or UX is even hard-baked, such as autogenerating form element
- Package the whole design system as a distributable on npm;
- Let back-of-front devs
npm installand use the components they need!
There's a lot going on in this analysis of trust (or lack of it) online. Some parts I agree with, some I don't. It's interesting thinking about the early web in the context of naive communities with integral trust:
Because each of [the groups that built the internet] were high-trust communities, it was easy to conclude that the people they’d be engaging online would be too. And so, as the tools of the internet and then the web were built out, they forgot to build a trust layer.
Also interesting to look at why trust models aren't baked into services online, either:
When a site decides to get big fast, they usually do it by creating a
very easy way to join, and they create few barriers to a drive-by
anonymous experience. And when they make a profit from this behavior,
they do it more. In fact, they amplify it.
And the negative impact that has on numbers versus community:
Because a collection of angry people talking past each other isn’t a community.
But for all I like about Seth's thoughts, I'm not sure I agree with the sentiment here:
...if someone goes into a bank wearing a mask (current pandemic aside) we can assume that they’re not there to make a deposit.
Anonymity still feels like an important aspect of the web, something worth preserving and fighting for. Does it have some issues? Sure, but I don't think it's the root issue that a lot of people portray it as, and it also has a lot of beneficial side effects as well. Seth's focus on community is more meaningful to me; a strong community, a strong sense of place and shared goals, that helps modulate behaviour far more than anonymity ever will (just look at Facebook 😬).
A brilliant overview of all the weird edge-cases that exist with the CSS
margin attribute. Honestly, having used CSS for over a decade I'm not sure I've run into any of them before (maybe parent inheritance a couple of times?) so I'm still unconvinced by the call to abandon
margin in favour of spacer components but I do agree that
gap is a generally more useful attribute to reach for.