markhnthoraway

In the part where the claim is made that individual characters matter there's a footnote link that ultimately goes to this PDF thesis[1].

That thesis has a claim itself:

> Creating a well designed, legible typeface is therefore not about creating dissimilar characters; the aim must be to find, amongst other things, an optimal balance between uniformity and differentiation and, through that, to attain legibility

At the end of the related chapter, where the author surveys some studies about letter and word recognition. It seems like the distinctions made in this font may be informed by that kind of perspective - not that increased differentiation of characters is good on its own.

This is just at a glance but it seems there is at least a thread there to follow about evidence and reasoning.

[1] https://core.ac.uk/download/pdf/40037679.pdf

I do think training developers and designers on accessibility is a core part of having them ship professional quality work. Even if product people and designers aren't thinking about it, I think it's reasonable to expect competent front-end developers to understand how to implement designs to some professional standard that doesn't make the page unusable for people with disabilities and expose the company to lawsuits.

On the other hand I don't think the business really knows/cares what HTML you use, they just can reasonably trust people to implement stuff in the "right" way, which 90% of time is identify the correct HTML to represent the nature and structure of the design and build out from there. You'd expect things to "just work" when you are paying for front-end specialists.

I've onboarded juniors and interns remotely at a couple of jobs and it's been fine. It doesn't work well if your onboarding process is osmosis-based & you want them to just pick stuff up by being around others. But if you are invested in the success of a junior and establish good patterns around how to communicate, there's no real risk there, and if anything it's healthier and more repeatable.

> In my case, I found that WFH only was isolating, impacted focus, and cut me off from the information flow of the organization, something electronic means cannot really substitute.

I worried about feeling isolated but found I didn't feel that way. And I think generally WFH has improved my ability to focus. My company is fully remote so there are not many in-person channels for information to flow.

Before the pandemic I would not have taken a remote job, I would have not been sure it would work out for me, but having done it for 3 years now, I'm real happy with it.

I do still like seeing people and will go out to work occasionally or cowork with friends. Traffic where I live is horrible though and avoiding a 30 minute dance with death twice a day is an amazing reduction in stress levels.

I guess it's going to work out that this is just one other thing to consider about a workplace and there's no one right answer where all businesses should do the same thing, people need the options.

> The React site would be functional and performant in 6 weeks, and ship in 10. If it didn't, I would step down and recruit a replacement.

I lost at lot of faith in the author's judgment at this point. I know this thing worked out and it was the right decision to port things over to React (and correct the bad decision to count on the Angular team to deliver SSR on their timelines). But you need to be able to explain things to the business without this sort of nonsense. I would be really concerned if I heard a manager saying something like that. It's not an argument, it's just a "trust me" that raises the stakes and pressure around the project.

Depends on context. There's nothing wrong with slowing down to communicate discrete steps that may happen very quickly under the hood.

- Input was received - Input was processed/stored correctly - Outcome is X

Doing everything in real time can reduce confidence and understanding. If everything takes like 5ms it feels weird, sometimes feels even like nothing happened, so people might submit again or feel the need to call and check or whatever.

It's deceptive in the sense that you are waiting maybe 500ms instead of 5ms. But it can be better UX in terms of communicating what's actually going on and having people feel comfortable with their understanding.

On the other hand, artificially slowing down something like closing an advertising modal - antipattern for sure.

It depends how you read that sentence.

Race doesn't matter if "low-income neighborhoods with higher proportions of Black and Latino residents" is simply stating that all low income neighborhoods have higher proportions of Black and Latino residents. Although it's kind of relevant if all downstream bias in arrests etc, say, goes away when you control for income.

But I read it as "of all low income neighborhoods, ones with higher proportions of Black and Latino residents had more police vehicle images". In which case, the question is:

Why would similar-income neighborhoods (which you theorize should have similar crime levels regardless of race) be policed differently based on the race of the population?

Or if a mono font is too limiting - any font that supports the CSS rule `font-variant-numeric: tabular-nums` can be made to behave like a fixed-width font in this situation.