Jim Nielsen’s Blog
Preferences
Theme: This feature requires JavaScript as well as the default site fidelity (see below).
Fidelity:

Controls the level of style and functionality of the site, a lower fidelity meaning less bandwidth, battery, and CPU usage. Learn more.

Reading Notes, July 2020

Article: “The Comeback of Fun in Visual Design”

The cynics will say that the pendulum will swing back to flat in a few years and that it’s all part of the cyclical nature of design trends. I don’t think the pendulum swings all the way back. Sure, there’s an aspect of fashion to design—what’s in vogue today won’t be tomorrow—but I think this is more about the scale balancing out than it is the pendulum swinging back. Fun and “judicious expressiveness” is back to stay—not because fashions have changed but because it has value. It took us losing it to realise that.

Shameless plug: I helped Michael write those particular lines, so is it cheating to cite this here on my blog? Either way, I agree with Michael and am excited about the reintroduction of fun into visual design.

Article: “Ask an expert: Why is CSS...the way it is?”

An interesting perspective from a technical director at the W3C on how and why CSS came to be what it is today. What struck me were the similarities between building platform features for the web and building just about any other piece of software. Read these excerpts and try to tell me they don’t sound exactly like any other piece of software you’ve ever worked on:

Once a feature is in place, it’s easier to slightly improve it than to add a new, better, but completely different feature that does the same thing.

This also explains why the first two improvements to specifying color in CSS—a named-color system and a hue-wheel, polar notation—were adopted over much better, but more complicated, systems proposed at the same time. They were slight improvements, seen as easy to implement.

The idea lost momentum, and we chose the path of least resistance instead.

After a week of mailing list discussion and no suggestions for improvement, the consensus was that my syntax was good enough for now.

Article: “Craft is Culture”

A nice articulate piece on craft and culture.

Linux proved that there is no upper limit to how much value you could extract out of a message board or email list, if you got the social dynamics right. The internet made it easy for craft practitioners to find one another, fraternize and argue over methods and best practices, almost like artists. The fact that none of these people had ever met in person, or had any shared culture or life experience, made zero difference. Their craft was their shared culture.

I suspect that within a few years, we (and others) will go through a complete rethink of how hiring works, that’s re-oriented around craft: how do we celebrate it, how do we communicate the ways that we celebrate it, how do we find people who crave celebration of that very specific thing, and then how do we hire them, wherever they are?

Craft is culture. If you care about craft, you’ve done the hard part.

Article: “Over-engineering is under-engineering”

Honestly, I just really liked this line because it felt very relevant.

from an outsider’s perspective the enterprise/startup web developer job looks...mostly dedicated to re-building things the browser already does, just with a ‘this is our brand’ corporate spin.

Video: “The Wet Codebase” by Dan Abramov

So what happens is that developers learn best practices from the previous generation and they try to follow them. Because there were concrete problems and concrete solutions that were born out of experience. And so the next generation tries to pass them on. But it's hard to explain all this context and all this trade off, so they just get flattened into these ideas of best practices and anti-patterns.

And so they get taught to the new generation. But if the new generation doesn't understand the trade offs and the reasons they came to these conclusions, they don't have the context to decide when it's actually a bad idea and how far can you stretch this. So they run into their own problems from trying to take these best practices and anti-patterns to the extreme. And so they teach the next generation.

So what to do about it?

I think one way to try to break this loop is just when we teach something to the next generation, we shouldn't just be two-dimensional and say here's best practices and anti-patterns. But we should try to explain what is it that you're actually trading away. What are the benefits and what are the costs of this idea?

Article: “Accessibility”

Jeremy’s comments on Open Prioritization, which is an experiment in crowd-funding prioritization of new features in browsers.

when numbers are used as the justification, you’re playing the numbers game from then on.

He is speaking about monetary justification in arguments, but I saw a corollary in data-driven decisions. Once you make a product decision based purely on data, it becomes hard to ever deviate from or change that decision. “But the data said we should...” is the argument. Or “what does the data say?” becomes the leading question on decision making. Data is a cruel master.

He continues:

You’ll probably have to field questions like “Well, how many screen reader users are visiting our site anyway?” (To which the correct answer is “I don’t know and I don’t care”

Sometimes I wish more product decisions were made on principles and values like this more than the crutch of data.

If you tie the justification ... to data, then what happens should the data change? ... If your justification isn’t tied to numbers, then it hardly matters what the numbers say (though it does admitedly feel good to have your stance backed up)...The fundamental purpose of [your product] needs to be shared, not swapped out based on who’s doing the talking.