Explore My Notes

A sobering look into the history of the UX industry. I think the outlined three "phases of UX" seem pretty on point from my own experience: from idealistic, trusted advisor; to oft-ignored and frequently devalued; to the antithesis of what it set out to be. To mimic the article, it's not that good UX teams and practitioners no longer exist (they definitely do), but that big companies are now more likely to listen to how user psychology can drive short-term profits over long-term satisfaction.

Suddenly the "get rich quick" mentality that had caused the 2008 crash was being adopted by senior leadership at Big Tech firms. Now it was data and algorithms, not UX, that mattered most.

"We're lying to our users," one anguished UX designer told me, explaining that leadership regularly ordered the UX team to create designs that were intentionally misleading. Apparently it helped boost profits.

Increasingly, I think UX doesn't live up to its original meaning of "user experience." Instead, much of the discpline today, as it's practiced in Big Tech firms, is better described by a new name: UX is now "user exploitation."

The mention of how Amazon has become a company famed for its dedication to user experience into one which uses six pages of dark patterns in order to cancel a subscription is, frankly, disheartening.

We're headed into a dangerous time, when our society is run on digital platforms, and UX isn't leading the way to ensure that those tools are usable.

A simple and informative example of how the new CSS clamp property can be used to create fluid layouts (in this case, specifically a fluid type system).

The key is in three CSS variables:

1. --fluid-type-min for the lower bound;
2. --fluid-type-target as the "ideal, fluid setting", using calc() to sidestep accessibility issues when zooming;
3. --fluid-type-max for the upper bound.

With that applied, you can target specific HTML elements and provide meaningful values using the rem unit, e.g:

For the <h1>, we increase the --fluid-type-target to a larger, 5vw. By increasing the viewport unit, we speed up the rate of growth, which will help to maintain its extra large size. To reduce the rate of growth and have less difference between your minimum and maximum sizes: reduce the size of --fluid-type-target.

Here's a snippet of Andy's code:

h1,
h2,
h3,
p {
  font-size: clamp(
    var(--fluid-type-min, 1rem),
    calc(1rem + var(--fluid-type-target, 3vw)),
    var(--fluid-type-max, 1.3rem)
  );
}

For all three custom properties, we are setting the default value as the second parameter.

It’s really important to test that your text gets large enough when you zoom in and small enough when you zoom out—it should be very obviously larger or smaller.

A font designed to make text as legible as possible. Particularly impressive attention to making sure letterforms are still distinctive even when extremely blurred. Best of all: it's completely free to use.

I feel like Max is about two years ahead of me on everything 😁 Here I am thinking about getting Twitter syndication working on Netlify, and he wrote a perfect tutorial back in 2019. Definitely need to give this a spin! The basic concept is to provide a JSON feed of new "tweets" (or thoughts, or notes, or whatever you want to call them) and then use a Netlify "Function" to parse that feed, connect to the Twitter API, and fire off your tweets on build. Very cool!

To trigger our custom function everytime a new version of the site was successfully deployed, we just need to name it deploy-succeeded.js. Netlify will then automatically fire it after each new build, while also making sure it’s not executable from the outside.

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.

Useful write up on using a combination of Actionsflow/GitHub Actions, RSS, and webmentions.app to send webmentions from a static site.

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,