Coleman McCormick

Archive of posts with tag 'Design'

March 3, 2025 • #

“Topographic beauties straight from old geography books”, @egeberkina.

✦
✦
✦
✦
✦
July 30, 2024 • #

Diagram of a harpsichord. Arnault de Zwolle, c. 1430.

✦
May 2, 2024 • #

The amazing spillway at KĂĄrahnjĂşkar Hydropower Plant , Iceland.

I can’t see brutalism without thinking of Dune. Upper image looks like Caladan.

✦
March 27, 2024 • #

Oldsmobile Incas concept car, 1986.

Resurrect the 80s concept car design language.

This existed and they used a Ford Taurus in Robocop?

✦
March 24, 2024 • #

Teatro Regio. Turin, Italy.

That lighting.

✦
March 8, 2024 • #

The central control building of a solar farm in KarapÄąnar, Turkey.

Future site of an unnamed science fiction film location shoot.

✦
March 6, 2024 • #

Charts on Design — Christoph Labacher · Interaction Designer →

A collection of chart designs.

✦
March 1, 2024 • #

Set the alarm.

✦
February 26, 2024 • #

We should build more moongates in our gardens and backyards.

From Austin Tennell on X.

✦
February 23, 2024 • #

The Magic City , by Russian artist Artur Skizhali-Veis.

✦
February 20, 2024 • #

Every standard mass-market film poster design is subpar. We can do so much better.

✦
February 19, 2024 • #

Cross-section of Hong Kong’s Kowloon Walled City.

✦
February 18, 2024 • #

Let’s return to conversation pits.

✦
February 10, 2024 • #

The film adaptation of Jeff VanderMeer’s Annihilation took some liberties in the narrative. But Alex Garland’s vision on the world, the twisted melange of organisms, the shroom-trip in the Southern Reach — all spot on.

✦
February 10, 2024 • #

Simplicity on the Other Side of Complexity →

My latest post on Res Extensa:

✦
February 4, 2024 • #

Look back less →

Jason Fried:

A better path is to reflect forward, not backwards. Develop a loose theory while working on what’s next. Appreciate there’s no certainty to be found, and put all your energy into doing better on an upcoming project. But how will you do better next time if you don’t know what went wrong last time? Nothing is guaranteed other than experience. You’ll simply have more time under the curve, and more moments under tension, to perform better moving forward. Internalize as you go, not as you went.

✦
January 31, 2024 • #

Snake Bridge on Macclesfield Canal. Astbury Congleton, England.

Bring back artisanal masonry.

✦
January 24, 2024 • #

The barren highways of Naypyidaw.

Don’t listen to the high modernists. You can’t will cities into existence.

✦
✦
✦

Monthly Reading, August 2023

August 29, 2023 • #

This post appeared in issue #36 of my newsletter, Res Extensa, where I write about the intersection of product design, bottoms-up systems, innovation, and what we can learn from the history of technology. I’d love it if you subscribed.


💡 Good Decision, Bad Decision, Indecision, and Fake Decision

The older I get, the more I appreciate two fundamental skills in every line of work:

  1. A respect for and ability to assess trade-offs, and
  2. Knowing how and when to make decisions

Notice it doesn’t say what decision to make. Effective decision-making means knowing which resources to bring to bear, who to involve, and how to zoom out on the upsides and downsides (number 1). And just as critically, it’s knowing when a decision is necessary. On most things, the faster decision is better. Whether we acknowledge it or not, most decisions are two-way doors: we can recover from the downsides. But surprisingly often it’s about knowing when we don’t really need a decision right now. Not deciding is itself a decision.

Decisions

Austin Yang says it this way:

What most people aren’t aware of is that indecision in itself is a decision. You are essentially choosing to stick with the status quo for the time being.

A key factor to how we think about a decision is what action follows. “Indecision” only feels bad if we keep harping on the subject, if we continue deliberating even after we decided to stick with the status quo.

He raises another all-too-common problem where the follow-on action makes the decision problematic: the “fake decision”:

There is one type of decision that doesn’t get talked about enough. These are decisions that get made, but never acted on. I call them “fake decisions.” Technically speaking, they cannot be called decisions at all. They are simply feel-good exercises to fool yourself into thinking that something has changed.


🐄 Age of Invention: Cash Cows

Economic historian Anton Howes writes a newsletter devoted to the topic: what gave rise to the “improving mentality”? For some reason — a combination of timing, the weird semi-isolated, evolved culture of England, access to natural resources, political freedom — the British Isles was a petri dish of innovation in the 18th and 19th centuries.

Anton tells the story of Robert Bakewell, a cattle farmer that set out, through experimentation, trial and error, to improve his cattle herd.

Bakewell’s story could have been an unremarkable one. He was born, farmed, and died at Dishley, much like his father before him. But Bakewell, unlike most people, caught the improving mentality, or attitude — the one thing all inventors, both then and now, have in common — which had him viewing everything around him in terms of its capacity for betterment. The improving mentality was a reframing the status quo as a problem to solve. A habit of optimisation. A compulsion to perfect.

Through dozens of adjustments and a constant drive to improve, his cows were special. But it took active effort, experimentation, and drive to improve. He selectively bred his cattle to have larger backs, with the more expensive sirloin and filets, and smaller mid and lower sections, with their cheaper cuts.

Bakewell’s cows and sheep became extraordinarily valuable when sold for meat, though he soon discovered he could make even more money by leasing out the young males of his breeds to other farmers so that they could improve their own — “but never as good as that of Mr Bakewell who has both the male and the female”. Recognising how essential it was that he not lose his competitive advantage, he even set up his own abattoir and sold only dead meat, for fear that an unscrupulous butcher might be tempted to breed from the live animals sent to slaughter.

Progress shouldn’t be taken for granted! It takes optimism and effort to make it happen.


📚 Andy Matuschak — Self-Teaching, Spaced Repetition, Why Books Don’t Work

From Dwarkesh Patel’s excellent podcast, this is a masterclass in how learning works. I love how Andy is always essentially thinking out loud, as he’s in conversation, about the topic. Even a guy with his pedigree realizes that a subject like this is a confoundingly complex, with no “best” way of understanding it.

One of the biggest learnings from Andy is how to be purposeful when you read. You should ask questions of the text! I know this technique and still too often I read something knowing — sometimes consciously, usually subconciously — that I don’t truly understand what I just read. Just take a look at this session where Andy reads and makes notes on a paper in real-time, and you’ll see this in action.


🏃‍♂️ Speed matters: Why working quickly is more important than it seems

From James Somers:

The obvious benefit to working quickly is that you’ll finish more stuff per unit time. But there’s more to it than that. If you work quickly, the cost of doing something new will seem lower in your mind. So you’ll be inclined to do more.

The converse is true, too. If every time you write a blog post it takes you six months, and you’re sitting around your apartment on a Sunday afternoon thinking of stuff to do, you’re probably not going to think of starting a blog post, because it’ll feel too expensive.

Also at work, the better you get, the better you better get:

It is a truism, too, in workplaces, that faster employees get assigned more work. Of course they do. Humans are lazy. They want to preserve calories. And it’s exhausting merely thinking about giving work to someone slow. When you’re thinking about giving work to someone slow, you run through the likely quagmire in your head; you visualize days of halting progress. You imagine a resource—this slow person—tied up for awhile. It’s wearisome, even in the thinking. Whereas the fast teammate—well, their time feels cheap, in the sense that you can give them something and know they’ll be available again soon. You aren’t “using them up” by giving them work. So you route as much as you can through the fast people. It’s ironic: your company’s most valuable resources—because they finish things quickly—are the easiest to consume.

Feedback loops, both positive and negative, are a helluva thing.


🧱 The Pattern Language of Project Xanadu

Architect Christopher Alexander articulated the notion of “pattern languages” in his 1977 book of the same name. You devise a library of rules of thumb for designing (in his case, living spaces — neighborhoods, buildings, rooms) that work well together. Rather than rigid top-down design with hard specs, a well-thought-out pattern language gives the designer room to be creative while still working from thoughtful, functional constraints. An effective pattern language is a hierarchical scheme of composable building blocks: in Alexander’s original language, “Cozy Half-Enclosed Corner” works well with “Light on Two Sides”, or with “Seat Spots in Light and Dark”.

Pattern languages are meant to be sets of general principles. No neighborhood conforms to “The Pattern Language” as a standard.

In the world of software, Ted Nelson’s Project Xanadu is both an epic failure and wild success. It started as a proposal in 1960, and still doesn’t exist.

But as Maggie Appleton points out here, many of the project’s proposed “patterns” have been embraced and implemented in the distributed ecosystem of Internet specifications and software features over the past few decades:

People are building Xanadu without knowing what Xanadu is. Which is the essence of a good pattern language; true patterns evolve naturally within systems, and are found rather than crafted.

We should think of Xanadu as a successful pattern language, rather than a failed software project.


🛕 Anachronistic History

The past couple weeks I’ve been experimenting tons with ChatGPT and Midjourney, figuring out how to make practical use of this new wave of products.

Tinkering around, I asked ChatGPT:

Write about some creative anachronistic historical events.

'Viking Age Space Telescopes', according to Midjourney
'Viking Age Space Telescopes', according to Midjourney

And here’s a brief sampling of what I got:

Aztec Airborne Armada (1400s): The Aztecs develop an array of helium-filled airships, forming an airborne armada to defend their empire and launch surprise attacks on neighboring civilizations.

Socrates’ Philosophical Podcast (399 BCE): Instead of written dialogues, Socrates engages in thought-provoking discussions through an ancient form of podcasting, spreading his philosophical ideas through the airwaves of Athens.

Marco Polo’s Transcontinental Railroad (1271-1295): Marco Polo’s extensive travels result in a collaborative effort among the nations he encountered to construct a massive transcontinental railroad network connecting Europe, Asia, and Africa centuries ahead of its time.

See the full post for more.

🥪 Nibble and Your Appetite Will Grow

From Stephen Ango:

There’s a French expression I like:

L’appétit vient en mangeant

Appetite comes when you eat. Nibble and your appetite will grow.

Appetite can be the hunger for any kind of thing, not just food. Some days I wish I had the appetite to write, to read, to exercise, or even go outside.

Procrastination is the state of waiting for motivation to come. Paradoxically, the most reliable way to create motivation is to start doing the thing.

✦
✦

37signals Live Design Review

March 22, 2023 • #

This is an interesting look into how an effective team works through the weeds of a product design review. I love how it shows the warts and complexities of even seemingly-simple flow of sending a batch email in an email client. So many little forking paths and specific details need direct thinking to shape a product that works well.

✦
✦
✦

Miter Spline Jig Design

October 7, 2022 • #

On my to-build list, I want to make some simple floating picture frames for a few canvasses we have in the house. Those are simple enough to build, but I also want to add reinforcement splines to the mitered corners, for both the structural support and as a design detail.

Using a few examples I found (especially this one from Woodcraft by Suman), I drew up this design that’ll allow it to be reusable, support using hold-down clamps, and stop blocks for batching out cuts. Jigs like this can make somewhat complex cuts dead simple and repeatable. They’re also fun to build since you can often build them from scraps around the shop.

I’ll post back with some results after I get it built and can run it through its paces.

✦

Architecture from Every Country

September 12, 2022 • #

This was a fantastic thread from The Cultural Tutor — so simple, but had me on an epic Wikipedia / Google Maps rabbit hole.

Some of my favorite examples:

Kind of sad to see so many overbearing modernist structures in here, but some of them are nothing if not impressive, at least.

His newsletter, Areopagus, is full of great tidbits on art, history, classics, architecture, rhetoric. Well worth a subscribe.

✦
✦

Scenes, Pattern Languages,and Nested Systems

August 22, 2022 • #

Last week I picked up Scene and Structure on a recommendation I saw from Nat Eliason. I’ve seen him mention experimenting with writing fiction, which this book is about — the process of narrative structure, staging scenes, the balance between scenes and “sequels” to maintain coherence and tension through writing novels, which is the author’s background. I’ve thought about testing the waters with fiction writing, even if I never publish it anywhere. I think the NaNoWriMo happens in November, so maybe I’ll make a plan to give it a shot during that and see what happens.

Anyway, I’m not necessarily interested in the structure of fiction for myself in learning how to write it. For one I just find it interesting how “formulaic” in a way that all narrative fiction is, from novels, to TV, to films. Once you read Scene and Structure, it’s hard not to notice the mechanical elements playing out. You can watch a TV show and almost narrate yourself the structural elements as they happen. The point of Bickham’s guidance is not to distill every writer into following the same exact formula for everything they write, but rather to see the elemental components of storytelling with clarity, allowing you to see the skeletal framework of fiction. Think about cooking. Yes, it’s about recipes and ingredients, just like stories are plot elements and sentences. But becoming a great cook is more than about knowing lots of recipes and ingredients; great cooks know why particular ingredients show up in recipes together, what each is contributing to a dish, and they can assemble subgroups of ingredients in repeatable, predictable ways. Compelling writing — just like compelling cooking — requires knowledge of a structural hierarchy. A mirepoix of celery, carrot, and onion is a known, functioning collection of aromatics that works well in many many dishes. It’s a building block of building blocks. In narrative, if all you have is action-packed scenes connected one after the other, without a sequel in between for characters to digest what happened and mull over decisions, you leave readers confused and overwhelmed. And there are parallels with systems of all sorts, not just cooking.

One of the things I’m most curious to consider with this book is how well the principles could translate to nonfiction writing. Certainly if you read well written narrative nonfiction — Barbara Tuchman, John McPhee, David McCullough — they’re using many of these similar tactics to establish PoV “characters”, create tension in the narrative, and to find meaning in events, versus just “this happened, then this, then this”, which you could fall into easily writing something like history, which is literally a retelling of events.

I’d also started reading Christopher Alexander’s famous work A Pattern Language, something I’ve had on the shelf a long time and have been looking forward to picking up. I’m probably 50 pages into it so far.

What’s interesting are the similarities between these two books. I hadn’t bought either for the same reasons, but the common threads are certainly there. A Pattern Language is Alexander’s guidebook to cities, neighborhoods, architecture, construction. The idea is that composing these places that people live is an exercise in thinking in building blocks. He lays out dozens of reusable components or themes in architecture, from empirical study of what works and why. Well lit rooms, places to sit, greenery in the right places, putting benches next to gardens. Each on its own seems like an obvious thing, since these are components we see constantly around us. Though I’m not far in yet, and haven’t read any Alexander before, I see the purpose isn’t to tell you that well-lit rooms are a good idea, but to see these components as LEGO blocks for design. If you develop a language of patterns for your own work — even something like software — when faced with what to put where in a new design, you can refer back to your book of patterns and find subcomponents that’ll work well in that situation, based on the goal you have for a particular feature.

Thinking about these systems as “languages” is interesting. A language is hierarchical just like the systems these two books present for fiction writing and architecture. You start with letters, build those into words, then phrases, sentences, paragraphs, and so on. You can’t simply insert new elements into a language from the top without considering how your elements nest together and interact with the surrounding existing elements. This is why top-down “designed” languages have never worked. Even attempts to guide, restrict, or control natural languages have largely failed. The French famously have a government body responsible for maintaining what “real” French looks like. Has that worked? Do French people refer back to a government website to determine to some new vernacular or not?

The similarities between systems like these is fascinating to me. In both cases, fiction and architecture, the systems of patterns are developed over time based on empirical evidence of what works. Writers didn’t invent Bickham’s structure from whole cloth centuries back; the concepts he presents have evolved gradually over time. The way writers wrote even 200 years ago bears little resemblance structurally to what a novel looks like today. Writers over time learned what readers wanted, and innovated around the edges while conforming to norms of structure that were mostly predictable.

In the same way, Alexander refers to “the timeless way of building”. Most of the individual building patterns he presents he did not invent. They’re components for comfortable living that humans developed, in some cases, millennia ago. His mission isn’t to tell you new things, but to present a framework for ordering and assembling the things we know work into a cohesive hierarchy.

✦

Hard Edges, Soft Middle

January 2, 2022 • #

Have you had that feeling of being several weeks into a project, and you find yourself wandering around, struggling to wrangle the scope back to what you thought it was when you started?

It’s an easy trap to fall into. It’s why I’m always thinking about ways to make targets smaller (or closer, if you’re thinking about real physical targets). The bigger and more ambitious you want to be with an objective, the more confidence you need to have that the objective is the right one. What happens often is we decide a project scope — a feature or product prototype we think has legs — but the scope gets bigger than the confidence that we’re right. A few weeks in and there’s hedging, backtracking, redefining. You realize you went down a blind alley that’s hard to double-back on.

I heard an interesting perspective on scopes and approaches to building. Think of the “scope” as the definition of what the project is seeking to do, and the approach as the how.

Hard edges, soft middle

In an interview on David Perell’s podcast, Ryan Singer made a comparison between having a hard outer boundary for the work with soft requirements on approach, versus rigid and specific micro-steps, without a solid fence around it, an unclear or amorphous objective. In his words: “hard walls with a soft middle” or “hard middle with a soft wall”:

I’ve had this mental image that I haven’t been able to shake that’s working for me lately, which is what we’re doing in Shape Up. We have a very hard outer wall for the work. And we have a soft middle. So there’s a hard outer boundary perimeter — it’s very fixed, it’s going to be six weeks and we’re doing this, and this is in the project, and this is out of the project, and this is what this solution more or less. Clear hard outer boundaries. But then the middle is totally like “hey, you guys figure it out.” Right now what a lot of companies have is the opposite. They have a hard middle and a soft boundary. So what happens is they commit to this for the first two weeks, we’re going to build this and we’re going to build that, and we’re going to build that all these little things. And these become tickets or issues or very specific things that have to get done. And then what happens the next two weeks you say, okay, now we’re going to do this. You’re specifying exactly what should go in the middle, and it just keeps growing outward because there’s no firm boundary on the outside to contain it. So this is the the hard wall and the soft middle or the hard middle in the soft wall. I think our represent two very, very different approaches.

This requires trust in the product team to choose approach trade-offs wisely. If you encounter a library in use for the feature that’s heavily out of date, but the version update requires sweeping changes throughout the app, you’ll need to pick your battles. A team with fixations on particular steps (the “hard middle”) might decide too early that an adjacent feature needs rework1. Before pulling up to a higher altitude to look at the entire forest, the team’s already hitched to a particular step.

Setting a hard edge with the soft middle sets what the field of play and game plan look like, but doesn’t prescribe for the team what plays to run. The opposite model has a team hung up on specific play calls, with no sense for how far there is to run, or even how large the field is in the first place. When you grant the team the freedom to make the tactical choices, everyone knows there’s some freedom, but it isn’t infinite. The team can explore and experiment to a point, but doesn’t have forever to mess around. If you choose to work in the Shape Up-style 6 week cycle, decision velocity on your approaches has to be pretty high to hit your targets.

Any creative work benefits from boundaries, from having constraints on what can be done. The writer is constrained by a deadline or word count. The artist is constrained by the canvas and medium. A product team should be constrained by a hard goal line in terms of time or objective, or preferably both.

Some of the best work I’ve ever been a part of happened when we chose particular things we weren’t going to do — when we intentionally blocked specific paths for ourselves for some cost/benefit/time balance. Boundaries allow us to focus on fewer possibilities and give greater useful, serious attention to fewer options. We can strongly consider 10 approaches rather than poorly considering 50 (or, even worse, becoming attached to a specific one before we’ve explored any others).

Premature marraige to specific tactics pins you to the ground at the time when you need some space to explore. Because you’ve locked yourself into a particular approach too early, it may require tons of effort and time to navigate from your starting point to the right end point. You may end up having to do gymnastics to make your particular decided-upon solution fit a problem you can find (a solution in search of a problem).

Hard edge, soft middle reminds me of a favorite philosophy from the sage Jeff Bezos, talking about Amazon’s aggressive, experimental, but intentional operating culture:

“Be stubborn on the vision, but flexible on the details.”

  1. What you “need” to do is a dangerous trigger word. Almost always the perceived need is based on a particular understanding of trade-offs that could be misguided. One engineer’s need to recover some technical debt (while noble, of course) might be the opposite for CEO, who might be seeing a bigger picture existential need to the business. A thing is only “more needed” relative to something else. ↩

✦
✦
✦
✦

Weekend Reading: A New Web, Future of Higher Ed, and a Ford Concept Car

August 22, 2020 • #

🔗 A Clean Start for the Web

Tom MacWright with some ideas for cleaning up ever-creeping morass of web technology:

I think this combination would bring speed back, in a huge way. You could get a page on the screen in a fraction of the time of the web. The memory consumption could be tiny. It would be incredibly accessible, by default. You could make great-looking default stylesheets and share alternative user stylesheets. With dramatically limited scope, you could port it to all kinds of devices.

And, maybe most importantly, what would website editing tools look like? They could be way simpler.

🎓 Michael Munger on the Future of Higher Education

Great discussion on this episode of EconTalk with Michael Munger about the possibilities post-COVID of “unbundling” the university a decentralized set of separate services that could combine to give serve the same needs that traditional universities do.

🚗 Ford 021C Concept Car

I saw this through a tweet somewhere, but what a great work of design. Very George Jetson.

✦
✦
✦

A Nomenclature for Low-Code Users

July 7, 2020 • #

The low-code “market” isn’t really a market. Rather, I see it as an attribute of a software product, an implementation factor in how a product works. A product providing low-code capability says nothing about its intended value — it could be a product for sending emails, building automation rules, connecting APIs, or designing mobile forms.

What are termed “LCAP” (low-code application platform) software are often better described as “tools to build your own apps, without having to write all the code yourself.”

This post isn’t really about low-code as a marketplace descriptor, but about refining the nomenclature for how we talk about users we have in mind when designing low-code tools. Who are we building them for? Who needs them the most?

As Aron Korenblit wrote a few months back, low-code as a term isn’t really about code, per se, but often things like process modeling, workflows, data flows, data cleanliness, speed of prototyping, and low cost trial and error:

If what we’re trying communicate is that no-code helps get things done faster, we should elevate that fact in how we name ourselves instead of objecting to code itself.

For many years, all sorts of tools from Mailchimp or Webflow to Fulcrum or Airtable provide layers of capabilities for a continuum of user types, moving from the non-technical through to full developers. The non-tech space wants templates and WYSIWIG tools, the devs want an API, JavaScript customization, and full HTML/CSS editing suites. I think a two-type dichotomy isn’t descriptive enough, though. We need a third “semi-technical” user in the middle.

The spectrum of users could look something like this — we analogize these to an Microsoft Excel user equivalent (parenthesized):

Users of low-code software
  • Novice — anything that looks like code is totally opaque to novices. They’re scared off by it and afraid to change anything for fear of breaking something (Can enter data in Excel, and maybe do some sorting, filtering, or data manipulation)
  • Tinkerer — can parse through code examples and pre-existing scripts to roughly understand, uses trial and error and small adjustments to modify or piece together snippets for their own use case; often also can work with data and data tools like database applications and SQL (Can use formulas, pivot tables, lookups, and more with Excel, comfortable slicing and dicing data)
  • Developer — fluent in programming languages; excited about the prospect of writing their own code from scratch, just wants to be pointed to the API docs (Can write VBScripts and macros in Excel, but mostly wants to escape its confines to build their own software)

Of course empowering the Novices is one of the primary goals with low-code approaches, as they’re the least prepared to put together their own solutions. They need turn-key software.

And we can help Developers with low-code, too. If we can bootstrap common patterns and functionality through pre-existing building blocks, they can avoid repetitive work. Much of tool-building involves rebuilding 50-75% of the same parts you built for the last job, so low-code approaches can speed these folks up.

But the largest gap is that middle bunch of Tinkerers. Not only do they stand to gain the most from low-code tools. From my observations, that group is also the fastest-growing category. Every day as more tech-native people enter the workforce, or are compelled to dive into technical tools, people are graduating from Novice to Tinkerer status, realizing that many modern tools are resilient to experimentation and forgiving of user error. The tight feedback loops you can get from low-code affordances provide a cushion to try things, to tweak, modify, and customize gradually until you zero in on something useful. In many cases what a user decides is a “complete” solution is variable — there’s latitude to work with and not an extremely rigid set of hard requirements to be met. By providing building blocks, examples, and snippets, Tinkerers can home in on a solution that works for them.

Those same low-code tactics in user experience also give Novices and Tinkerers the prototyping scaffolds to build partial that can be further refined by a Developer. Sometimes the prototyping stage is plenty to get the job done, but even for more complex endeavors can greatly reduce cost.

✦
✦

Weekend Reading: American Production, On Bikeshedding, and Glyphfinder

May 9, 2020 • #

🏭️ Why America Can Make Semiconductors But Not Swabs

Dan Wang on American industrial production:

Learning to build again will take more than a resurgence of will, as Andreessen would have it. And the U.S. should think of bolder proposals than sensible but long-proposed tweaks to R&D policies, re-training programs and STEM education.

What the U.S. really needs to do is reconstitute its communities of engineering practice. That will require treating manufacturing work, even in low-margin goods, as fundamentally valuable. Technological sophisticates in Silicon Valley would be wise to drop their dismissive attitude towards manufacturing as a “commoditized” activity and treat it as being as valuable as R&D work. And corporate America should start viewing workers not purely as costs to be slashed, but as practitioners keeping alive knowledge essential to the production process.

🚲️ Why We Focus on Trivial Things: The Bikeshed Effect

“Bikeshedding” is a common term in tech circles. When starting on a big new software project, start by asking a design team for opinions on which programming language to use and you’ll get to see it in action. It applies all over; humans love an opportunity to look like they’re contributing meaningfully, especially when they perceive that they should know something about the subject:

Bike-shedding happens because the simpler a topic is, the more people will have an opinion on it and thus more to say about it. When something is outside of our circle of competence, like a nuclear power plant, we don’t even try to articulate an opinion.

But when something is just about comprehensible to us, even if we don’t have anything of genuine value to add, we feel compelled to say something, lest we look stupid. What idiot doesn’t have anything to say about a bike shed? Everyone wants to show that they know about the topic at hand and have something to contribute.

⌘ Glyphfinder

Hat-tip to Julian Lehr’s recent post for the referral to this one. It’s a simple menubar app that gives you a search interface to unicode symbol sets. The speed here is phenomenal; so much faster than the built-in emoji keyboard (plus it has a much larger library).

✦
✦
✦

Weekend Reading: Readwise with Roam, WWI Naval Intelligence, and Interaction Density

April 4, 2020 • #

📖 Readwise2Roam

I’m liking so far the process of manually typing notes in Roam from highlights in my books. Something about it feels more efficient and leaves me with more meaningful, succinct notes. This could come in handy, though, if I want to pull all highlights directly from Readwise (which I’m still loving, use it every day).

⛴ How computational power—or its absence—shaped World War naval battles

How the battlecruiser in the early 20th century gave the British a birds-eye view of their fleet before the days of aerial photography, radar, or satellites:

To achieve his vision of a centrally controlled battlecruiser force, Fisher needed a clear picture of the threats. So he set up a top-secret room in the Admiralty building where intelligence reports and shipping news from all over the world were aggregated onto large maps that showed the positions of every friendly and known enemy ship.

This was known as the Admiralty plot. Unlike the displays you might see in a modern military headquarters (which may be updated every few minutes or seconds), these paper maps had a “refresh rate” of hours or even days. But they were nonetheless revolutionary, because for the first time in history a centralized commander could look at a representation of the world naval situation, with every friendly force and known enemy force tracked all around the world in nearly real time. The British leadership could then issue commands accordingly.

📲 Interaction Density

This is one of the best arguments to describe why “pro” users on multitouch devices have so much frustration trying to achieve the same levels of productivity they can on a desktop. Even with quality applications, for certain types of work, an iPad can feel like you’re handcuffed.

✦

Weekend Reading: Figma's Typography, Xerox Alto, and a Timeline of CoVID

February 29, 2020 • #

⌨️ I Pressed ⌘B, You Wouldn’t Believe What Happened Next

An entertaining talk about the complexity of typography, from Marcin Wichary at Figma’s recent Config conference.

🖥 Restoring Y Combinator’s Xerox Alto

An technical piece on restoring Alan Kay’s Xerox Alto he donated to Y Combinator. Amazing piece of technology history, and inspired so many future developments in computing — graphical user interfaces, WYSIWIG text editing, bitmapped graphics, the mouse, and Ethernet for connectivity.

Xerox built about 2000 Altos for use in Xerox, universities and research labs, but the Alto was never sold as a product. Xerox used the ideas from the Alto in the Xerox Star, which was expensive and only moderately successful. The biggest impact of the Alto was in 1979 when Steve Jobs famously toured Xerox and saw the Alto and other machines. When Jobs saw the advanced graphics of the Alto, he was inspired to base the user interfaces of the Lisa and Macintosh systems on Xerox’s ideas, making the GUI available to the mass market.

🦠 Map and Timeline of CoVID-19 Outbreak

A timeline showing the spread of the coronavirus, with an accompanying map interface.

✦
✦

Weekend Reading: Figma Multiplayer, Rice vs. Wheat, and Tuft Cells

November 23, 2019 • #

🕹 How Figma’s Multiplayer Technology Works

An interesting technical breakdown on how Figma built their multiplayer tech (the collaboration capability where you can see other users’ mouse cursors and highlights in the same document, in real time).

🌾 Large-Scale Psychological Differences Within China Explained by Rice Versus Wheat Agriculture

A fascinating paper. This research suggests the possibility that group-conforming versus individualistic cultures may have roots in diet and agricultural practices. From the abstract:

Cross-cultural psychologists have mostly contrasted East Asia with the West. However, this study shows that there are major psychological differences within China. We propose that a history of farming rice makes cultures more interdependent, whereas farming wheat makes cultures more independent, and these agricultural legacies continue to affect people in the modern world. We tested 1162 Han Chinese participants in six sites and found that rice-growing southern China is more interdependent and holistic-thinking than the wheat-growing north. To control for confounds like climate, we tested people from neighboring counties along the rice-wheat border and found differences that were just as large. We also find that modernization and pathogen prevalence theories do not fit the data.

An interesting thread to follow, but worthy of skepticism given the challenge of aggregating enough concrete data to prove anything definitively. There’s some intuitively sensible argument here as to the fundamental differences with subsistence practices in wheat versus rice farming techniques:

The two biggest differences between farming rice and wheat are irrigation and labor. Because rice paddies need standing water, people in rice regions build elaborate irrigation systems that require farmers to cooperate. In irrigation networks, one family’s water use can affect their neighbors, so rice farmers have to coordinate their water use. Irrigation networks also require many hours each year to build, dredge, and drain—a burden that often falls on villages, not isolated individuals.

🦠 Cells That ‘Taste’ Danger Set Off Immune Responses

I’ve talked before about my astonishment with the immune system’s complexity and power. This piece talks about tuft cells and how they use their chemosensory powers to identify parasites and alert the immune system to respond:

Howitt’s findings were significant because they pointed to a possible role for tuft cells in the body’s defenses — one that would fill a conspicuous hole in immunologists’ understanding. Scientists understood quite a bit about how the immune system detects bacteria and viruses in tissues. But they knew far less about how the body recognizes invasive worms, parasitic protozoa and allergens, all of which trigger so-called type 2 immune responses. Howitt and Garett’s work suggested that tuft cells might act as sentinels, using their abundant chemosensory receptors to sniff out the presence of these intruders. If something seems wrong, the tuft cells could send signals to the immune system and other tissues to help coordinate a response.

Given the massive depth of knowledge about biological processes, anatomy, and medical research, it’s incredible how much we still don’t know about how organisms work. Evolution, selection, and time can create some truly complex systems.

✦
✦

Balancing Power and Usability

November 18, 2019 • #

This is another one from the archives, written for the Fulcrum blog back in 2016.

Engineering is the art of building things within constraints. If you have no constraints, you aren’t really doing engineering. Whether it’s cost, time, attention, tools, or materials, you’ve always got constraints to work within when building things. Here’s an excerpt describing the challenge facing the engineer:

The crucial and unique task of the engineer is to identify, understand, and interpret the constraints on a design in order to produce a successful result. It is usually not enough to build a technically successful product; it must also meet further requirements.

In the development of Fulcrum, we’re always working within tight boundaries. We try to balance power and flexibility with practicality and usability. Working within constraints produces a better finished product — if (by force) you can’t have everything, you think harder about what your product won’t do to fit within the constraints.

Microsoft Office, exemplifying 'feature creep'
Microsoft Office, exemplifying 'feature creep'

The practice of balancing is also relevant to our customers. Fulcrum is used by hundreds of organizations in the context of their own business rules and processes. Instead of engineering a software product, our users are engineering a solution to their problem using the Fulcrum app builder, custom workflow rules, reporting, and analysis, all customizable to fit the goals of the business. When given a box of tools to build yourself a solution to a problem, the temptation is high to try to make it do and solve everything. But with each increase in power or complexity, usability of your system takes a hit in the form of added burden on your end users to understand the complex system — they’re there to use your tool for a task, finish the job, and go home.

This balance between power and usability is related to my last post on treating causes rather than symptoms of pain. Trying too hard to make a tool solve every potential problem in one step can (and almost always does) lead to overcomplicating the result, to the detriment of everyone.

In our case as a product development and design team, a powerful suite of options without extremely tight attention on implementation runs the risk of becoming so complex that the lion’s share of users can’t even figure it out. GitHub’s Ben Balter recently wrote a great piece on the risks of optimizing your product for edge cases1:

No product is going to satisfy 100% of user needs, although it’s sure tempting to try. If a 20%-er requests a feature that isn’t going to be used by the other 80%, there’s no harm in just making it a non-default option, right?

We have a motto at GitHub, part of the GitHub Zen, that “anything added dilutes everything else”. In reality, there is always a non-zero cost to adding that extra option. Most immediately, it’s the time you spend building feature A, instead of building feature B. A bit beyond that, it’s the cognitive burden you’ve just added to each user’s onboarding experience as they try to grok how to use the thing you’ve added (and if they should). In the long run, it’s much more than maintenance. Complexity begets complexity, meaning each edge case you account for today, creates many more edge cases down the line.

This is relevant to anyone building something to solve a problem, not just software products. Put this in the context of a Fulcrum data collection workflow. The steps might look something like this:

  1. Analyze your requirements to figure out what data is required at what stage in the process.
  2. Build an app in Fulcrum around those needs.
  3. Deploy to field teams.
  4. Collect data.
  5. Run reports or analysis.

What we notice a surprising amount of the time is an enormous investment in step 2, sometimes to the exclusion of much effort on the other stages of the workflow. With each added field on a survey, requirement for data entry, overly-specific validation, you add potential hang-ups for end users responsible for actually collecting data. With each new requirement, usability suffers. People do this for good reason — they’re trying to accommodate those edge cases, the occasions where you do need to collect this one additional piece of info, or validate something against a specific requirement. Do this enough times, however, and your implementation is all about addressing the edge problems, not the core problem.

When you’re building a tool to solve a problem, think about how you may be impacting the core solution when you add knobs and settings for the edge cases. Best-fit solutions require testing your product against the complete ideal life cycle of usage. Start with something simple and gradually add complexity as needed, rather than the reverse.

  1. Ben’s blog is an excellent read if you’re into software and the relationship to government and enterprise. ↩

✦
✦

Weekend Reading: Signaling, Busyness, and Magic Ink

September 28, 2019 • #

👏🏼 Applause Lights

This is from 2007, but is still a very astute observation in how politicians and activists use rhetoric to signal rather than recommend a real, actionable way forward on issues:

The substance of a democracy is the specific mechanism that resolves policy conflicts. If all groups had the same preferred policies, there would be no need for democracy—we would automatically cooperate. The resolution process can be a direct majority vote, or an elected legislature, or even a voter-sensitive behavior of an artificial intelligence, but it has to be something. What does it mean to call for a “democratic” solution if you don’t have a conflict-resolution mechanism in mind?

I think it means that you have said the word “democracy,” so the audience is supposed to cheer. It’s not so much a propositional statement or belief, as the equivalent of the “Applause” light that tells a studio audience when to clap.

📥 Busyness as a Proxy for Productivity

We’ve all seen this in the workplace — when email, chat, meetings, et cetera transform into signaling channels for looking busy. Cal Newport’s Deep Work (quoted in this post) has a fantastic section on this:

If you send and answer e-mails at all hours, if you schedule and attend meetings constantly, if you weigh in on instant message systems… all of these behaviors make you seem busy in a public manner. If you’re using busyness as a proxy for productivity, then these behaviors can seem crucial for convincing yourself and others that you’re doing your job well.

Knowledge work is not an assembly line, and extracting value from information is an activity that’s often at odds with busyness, not supported by it.

🖋 Magic Ink: Information Software and the Graphical User Interface

One of those fantastic online papers from Bret Victor.

✦

Weekend Reading: Ted Chiang, Renewable Energy, and ColorBox

September 21, 2019 • #

✍🏼 Ted Chiang Uses Science to Illuminate the Human Condition

I enjoyed this interview with author Ted Chiang. It covers his recent short story collection Exhalation: Stories with nice context and background on the ideas behind each one. I just finished the book last week, and would have to say that The Truth of Fact, the Truth of Feeling was my favorite. A story about the fallibility of memory and what it would be like if our memories were recorded with perfect accuracy.

💡 Can Renewable Energy Power the World?

Renewables map US

Analysis from Bloomberg on the state of renewables versus fossil fuels, with nice map graphics demonstrating the distribution of energy facilities by type in the US. The trends look positive in the United States, but the outlook in developing markets is still challenging, as one would expect:

In developing parts of the world, coal still dominates. China is home to the largest capacity of hydro, wind and solar power—and it remains the world’s biggest consumer of coal. Pakistan’s dream of generating 60% of its power from clean energy sources is still decades away. In Indonesia, coal plants are so cheap to run that the Southeast Asian nation is projected to nearly double its coal generation in the next 25 years.

The growing divide underscores a global dilemma: Wealthy nations can afford to turn their backs on coal, but it remains an easy fallback in countries where electricity is scarce, unreliable, or unaffordable.

🎨 ColorBox

A tool from the Lyft design team for creating color ramps and gradients. Check out the blog post.

✦

Weekend Reading: tracejson, Euclid, and Designing at Scale

August 24, 2019 • #

🛰 tracejson

An extension to the GeoJSON format for storing GPS track data, including timestamps. GPX has been long in the tooth for a long time, but it works and is supported by everything. This approach could have some legs if application developers are interested in a new, more efficient, way of doing things. I know I’d like to explore it for Fulcrum’s GPS-based video capability. Right now we do GPX and our own basic JSON format for storing the geo and elapsed time data to match up video frames with location. This could be a better way.

🔷 Byrne’s Euclid

This is a gorgeous web recreation of Oliver Byrne’s take on Euclid’s Elements. A true work of art.

🎨 Design Tooling at Scale

This post from the Dropbox design team dives into how a large team with a complex product created a design system for a consistent language. It goes into how they organize the stack of design elements and structures using Figma for collaboration.

✦

Weekend Reading: Terrain Mesh, Designing on a Deadline, and Bookshelves

August 17, 2019 • #

🏔 MARTINI: Real-Time RTIN Terrain Mesh

Some cool work from Vladimir Agafonkin on a library for RTIN mesh generation, with an interactive notebook to experiment with it on Observable:

An RTIN mesh consists of only right-angle triangles, which makes it less precise than Delaunay-based TIN meshes, requiring more triangles to approximate the same surface. But RTIN has two significant advantages:

  1. The algorithm generates a hierarchy of all approximations of varying precisions — after running it once, you can quickly retrieve a mesh for any given level of detail.
  2. It’s very fast, making it viable for client-side meshing from raster terrain tiles. Surprisingly, I haven’t found any prior attempts to do it in the browser.

👨🏽‍🎨 Design on a Deadline: How Notion Pulled Itself Back from the Brink of Failure

This is an interesting piece on the Figma blog about Notion and their design process in getting the v1 off the ground a few years ago. I’ve been using Notion for a while and can attest to the craftsmanship in design and user experience. All the effort put in and iterated on really shows in how fluid the whole app feels.

📚 Patrick Collison’s Bookshelf

I’m always a sucker for a curated list of reading recommendations. This one’s from Stripe founder Patrick Collison, who seems to share a lot my interests and curiosities.

✦

Weekend Reading: Tissot's Indicatrix, National Park Fonts, and Starlink

June 8, 2019 • #

🌐 Tissot’s Indicatrix

This is a neat interactive tool to visualize distortion due to map projection using Tissot’s indicatrix, a mathematical model for calculating the amount of warp at different points:

Nicolas Auguste Tissot published his classic analysis on the distortion on maps in 1859 and 1881. The basic idea is that the intersection of any two lines on the Earth is represented on the flat map with an intersection at the same or a different angle. He proved that at almost every point on the Earth, there’s a right angle intersection of two lines in some direction which are also shown at right angles on the map. All the other intersections at that point will not intersect at the same angle on the map, unless the map is conformal, at least at that point.

🏞 National Park Typeface

A typeface designed to mimic the National Park Service signs that are carved using a router bit.

Perfect timing on finding this one. I’ve been working on a cartography project to simulate a USGS-style topographic map in QGIS, and this could work perfectly in that design. Excellent work from the Design Outside Studio.

SpaceX is developing a space-based broadband internet system of 24 satellites. The design of this hardware looks incredible. I hope it gets traction and sparks a consumerization of this sort of tech. Between projects like this and the work of Planet and others with microsatellites, that industry seems like it’s on the cusp of some big things.

✦
✦

Wireframing with Moqups

May 16, 2019 • #

Wireframing is a critical technique in product development. Most everyone in software does a good bit of it for communicating requirements to development teams and making iterative changes. For me, the process of wireframing is about figuring out what needs to be built as much as how. When we’re discussing new features or enhancements, rather than write specs or BDD stories or something like that, I go straight to a pen and paper or the iPad to sketch out options. You get a sense for how a UI needs to come together, and also for us visual thinkers, the new ideas really start to show up when I see things I can tweak and mold.

We’ve been using Moqups for a while on our product team to do quick visuals of new screens and workflows in our apps. I’ve loved using it so far — its interface is simple and quick to use, it’s got an archive of icons and pre-made blocks to work with, and has enough collaboration features to be useful without being overwhelming.

Moqups wireframe

We’ve spent some time building out “masters” that (like in PowerPoint or Keynote) you can use as baseline starters for screens. It also has a feature called Components where you can build reusable objects — almost like templates for commonly-used UI affordances like menus or form fieldsets.

One of the slickest features is the ability to add interactions between mocks, so you can wire up simulated user flows through a series of steps.

I’ve also used it to do things like architecture diagrams and flowcharts, which it works great for. Check it out if you need a wireframing tool that’s easy to use and all cloud-based.

✦
✦
✦

A Live Experiment in Disassembling a Map

February 7, 2019 • #

This was a cool idea from cartographer Daniel Huffman. He live-streamed a walkthrough taking apart one of his map projects in Illustrator to see how he puts it all together.

I love this idea and am excited to see him do more like this down the road.

✦

The Incredible Inventions of Intuitive AI

January 2, 2019 • #

This talk on “generative AI” was interesting. One bit stuck out to me as really thought-provoking:

Dutch designers have created a system to 3D print functional things in-place, like this bridge concept. Imagine that you can place a machine, give it a feed of raw material input and cut it loose to generate something in physical space. As the presenter mentions at the end of the talk, moving from things that are “constructed” to ones that are “grown”.

✦

Weekend Reading: Railway Logos, Meditation, and the Next Feature Fallacy

December 8, 2018 • #

🔩 The Next Feature Fallacy

The vast majority of features won’t bend the curve. These metrics are terrible, and the Next Feature Fallacy strikes because it’s easy to build new features that don’t target the important parts.

This certainly rings true for me from experience over the years. It turns out that a single feature itself is far from the main problem halting people part way into on-boarding with a product. This falls into the category of focusing on what we know how to do already, rather than what’s important to do. What’s important isn’t necessarily something you’ll know how to approach without hard research and effort.

🧘🏻‍♂️ Why I’m Into Meditation

I’ve been giving Headspace a try to get into a meditation routine over the last couple months. So many people I respect speak highly of building a meditation practice, and it’s pretty easy to do. Focusing for 10 minutes on a single mundane thing (your breathing) is shockingly hard to do. About 40 or 50 10-minute sessions in, I’m finally getting more comfortable with it. I always feel reenergized after.

🚂 Reagan Ray’s Railway Logos

These are all fantastic. I even see my favorite hat represented in there.

✦

A Never-Ending Train

April 25, 2010 • #

An amazing train station design — the trains don’t have to stop.

✦
✦