The Rev. Martin Luther King Jr. quoted Theodore Parker: “The arc of the moral universe is long, but it bends towards justice.”

But it’s not bending itself. And it’s not waiting for someone from away to bend it either.

It’s on us. Even when it doesn’t work (yet). Even when it’s difficult. Even when it’s inconvenient.

Jonas has put together a useful overview of why the "new" Context API in React is probably a better option than Redux for many simple use cases, as well as step-by-step instructions on how to set up a Redux-like global store using it.

In combination with the useContext and useReducer hooks we can create a global store that manages the entire app’s state and supports convenient ways to update the state throughout the app regardless of how deep the component tree goes.

The only downside to this approach appears to be scalability, but honestly very few sites are going to need to track more than 2-3 pieces of global information which this should manage nicely.

I have a tendency to prefer the kind of "inside-out" control that Kent is advocating in this piece, though I've never head it called "inversion of control" before. The idea of giving your users the ability to manipulate the output of a given function/API is a great way to futureproof your work and something I think is generally useful doing earlier rather than later.

The problem comes, as he identifies, when you overdo it:

What if that's all we ever needed filter to do and we never ran into a situation where we needed to filter on anything but null and undefined? In that case, adding inversion of control for a single use case would just make the code more complicated and not provide much value.

So how do you walk that fine line? Like most things, there's a lot of grey in the decision. Personally, I like to do things with no inversion first, sticking to the principle of "doing one thing well". Then, if I (or others) find that they need to extend that functionality, I begin adding overrides. Overrides are great for maintaining existing code and allowing for an inversion of control. For example, in the pseudo-array-filter example Kent uses, I would cede control of the filter options to a prop/variable (as he does), but then add a line that populates that variable with the original null and undefined checks if it's blank. That way existing implementations still work, nothing breaks, and moving forward the code is much more flexible (and, crucially, avoids the multiple-extension spaghetti that we're trying to avoid).

Sure, occasionally someone might inadvertently duplicate that setup, by re-specifying the default behaviour in the function call, but that's fine. If you didn't set the default behaviour every call would have to do that anyway, so it still saves time in the long run, and you avoid pre-extending code that never needs the flexibility in the first place.

I don’t think we have any clue about how disruptive this shift is going to be.

There are people and organizations that are racing to break the fabric of community that we all depend on. Either to make a short-term profit or to atomize/vaporize widespread trust to hide from accountability and to slow change...

In the meantime, it’s worth confirming the source before you believe what you see.

The GOV.UK UX and design team are fascinating. Every time I've had to use the website I've found it a breeze, which is an enormous achievement on their behalf. Better yet, they're incredibly transparent and make a lot of their research and reasoning available.

Recently, they changed all numeric input fields (dates, phone numbers, age etc.) across the entire GOV.UK design system to use `<input type=”text” inputmode=”numeric” pattern="[0-9]*">` instead of `<input type="number">`. That almost sounds counter intuitive, given that their goal is to trigger the (very useful) numeric keypad on mobile devices, but their reasoning is pretty bulletproof.

• Number inputs don't have great support across various screen readers and other accessibility software (which does seem a little odd to me but facts are facts);
• Some browsers attempt to round large numbers, potentially into exponential notation (e.g. 1429327e+18) or just to the nearest 10;
• Old version of Safari have, well, irritating traits like adding commas to numbers over a certain size; particularly unhelpful for credit card fields!
• Scrolling can accidentally change numbers, which is an issue (I've felt that one personally).

Their proposed solution of using a `text` version with the numeric keypad specified solves pretty much all of these issues, and the `pattern` attribute polyfills in for older iOS devices and some other old browsers which may not understand `inputmode` that well. Neat.

Original source: Reddit

Senongo Akpem’s Cross-Cultural Design has been on my radar a lot lately; I probably should pick it up. In the meantime, A List Apart have released a little subsection with some interesting insights:

• Stereotypography is the stereotyping of a culture, region, or other group via a specific font style or typeface. Example used is Neuland, which to me is the Jurassic Park font but apparently has a long historical association with Western ideas of the "Dark Continent" version of Africa i.e. racism. Advice is to avoid any type that attempts to "invoke" a culture, particularly if it has been designed apart from that culture. Makes sense, but worth being reminded of.
• Google Fonts is banned in China, so use of their free web fonts is non-global without workarounds.
• Different alphabets have different "visual density" expectations. Asian alphabets such as Japanese are information dense, so readers are used to less white-space but need larger glyphs than in traditional Western alphabets like Latin. I'd never considered that white-space would be a culturally defined construct, not to that basal a level at least.

I don't work with localisation at all, but it's clear that if you do, there's a lot more to consider.

When you love a website design, you look into how it was made, right? That's what I did with Robb Owen's recent redesign. Amazingly, his incredibly smooth scroll and cursor tracking is achieved via his own JS library... way to make the rest of us feel entirely inadequate 😂

Tornis looks like a really interesting package for site animations. I definitely want to give it a go with some projects I'm working on. Even simple elements like the rotating lighthouse stamp are just very cleanly/smoothly animated. Impressive.

It's not often that I see a website and just want to explore it, but that's what Robb Owen has achieved. I've literally gone back multiple times just to refresh my memory of it. There's something incredibly elegant in both the motion design and the colour palette. Plus, I'm a sucker for fast rendering cursor tracking animations 😅

I wish there wasn't an initial loading screen, but otherwise a truly enviable personal website.

An adaptation of Robert C. Martin's book Clean Code for JavaScript (ES6+) full of best practice examples and (probably more importantly) common anti-patterns that they can remove/prevent/avoid. Just a useful resource to check back on from time to time.

A neat little npm package that runs accessibility (a11y) tests on web pages to whatever WCAG or other standard you need. The fact it can be automated at build time should be very useful. There's also a GUI-based version, Koa11y, which looks useful for quick spot checks. I'm a little surprised there isn't a web hosted version or even a browser plugin, but perhaps someone will fork the project in the future.

A good look behind Andy's "microblog", a small website that powers his Twitter feed and link list via a mixture of IFTTT, RSS, Feedbin, Eleventy, and Netlify. Includes step-by-step guide and source code. Would be interesting to see if The Old Reader has anything similar in terms of API integrations or scrapable feeds 🤔

The Jamstack enables me, a designer who codes, to make incredibly cool shit and I am all for it!

What a wonderful project. The folk at Paravel have taken the Sherlock novel A Scandal in Bohemia and recreated it as a bespoke website. Of course, the whole site is beautifully designed, but the real showstopper here is their (light!) usage of animation and sound. There's something engrossing about reading a chapter set on a wet winter's night and hearing the sound of rain on window panels in the background.

That's the kind of interactivity that the web was built for and I love it. (It's also a cracking argument for copyright expiration and public domain art works.)

Discoverd via Trent Walton.