Reading Notes, March 2020

Article: “Why is CSS frustrating?”

First up, the difficulty of CSS reminds me of the difficulty of book design... When designing a book we have to treat the InDesign file as a sort of best guess, it’s not until we print the dang thing that we begin to see all the problems...

So the best thing to remember when designing a book is the same as when designing a website: the screen is a lie.

What we’re seeing on screen and what the final product will become are two very different things. We need to constantly remind ourselves that there are invisible edge cases, problems that in this context, on this screen, are made utterly invisible to us.

“the screen is a lie”—I loved this phrase when I read it. Perhaps everything in this article will be apparent to anyone who’s been working on the web for years, but it’s definitely not apparent for people who haven’t (i.e. “stakeholders”). I’ve already found myself trying to distill the essence of this article into my introductory statements to stakeholders before presenting design mocks, like “ok, remember everyone, that what you’re going to see is actually a lie. It does not represent the final product, nor does it represent the finality of the product. There are problems and edge cases that are entirely invisible to us in these mocks. This is just a glimpse of a very particular, targeted solution.”

Oh, and I liked this snippet about the web being messy. Once you embrace the messiness, it’s no longer a pain point. In fact, it’s actually a strength you enjoy capitalizing on.

I think everyone hates CSS for forcing them to be empathetic but also because the web is so messy—despite that being the single best thing about it.

Video: “When We Build” by Wilson Miner

Had this talk sitting in my “To Watch” list for a long time. It’s full of little insights. I really like the speaker’s presentation of this quote from Marshal McLuhan:

All media are extensions of some human faculty, mental or physical. The wheel is an extension of the foot. The book is an extension of the eye. Clothing is an extension of the skin. Electric circuitry is an extension of the central nervous system. The extension of any one sense displaces the other senses and alters the way we think, the way we see the world, and ourselves. When these changes are made, men change.

Article: “Redesign: Perfect Trifecta” by Frank Chimero

Frank talks about his process of selecting a typeface for his blog.

No matter how much one plans, a designer will crawl through their mental rolodex of fonts and see what feels right to their eye. Post-rationalization is an open secret in the design industry, but with personal work, there is no one to impress with rigor. One can go on intuition. The eye knows.

“Post rationalization is an open secret in the design industry.” Love this line. It’s funny because Frank says it’s an open secret but I can’t actually remember ever seeing it written down anywhere.

Article: “Agile: The Once and Future Methodology”

Really I just liked these quotes. They seem so obvious when written down that they’re hardly worth noticing, but I’m not sure how many of us that work in software have truly internalized this truth such that we could articulate it clearly. I want to, which is why I’m writing this down.

there is an intrinsic tension among opposing forces that every engineering project must solve.

There is the desire to reduce costs; opposing that desire is the need to develop a reliable product with all the features and functionality needed to make it a success.

And this:

Build a little, test early and often so that mistakes are caught early and so stakeholders have a chance to see and respond, and so that the inevitable requirement changes are identified and absorbed during the process, not in a terrified rush at an acceptance test.

Article: “How Big Technical Changes Happen at Slack”

This article was making the rounds on the internet. Personally I think there’s lots of good technical advice in there, but also lots of more broad advice about developing anything as a product—including design systems (whatever you define that to be).

When we are trying to drive change, we do so with a customer-centric attitude towards the teams trying to understand and use a new system. Their happiness is the only real barometer of your success. This involves outreach, requirements gathering, feedback, iteration, and purposeful education and skill-sharing.

When in doubt, remember: you’re accountable for your team’s technical success, and your team’s technical success is–in the long run–judged by the people using your stuff.