The Typeset of Wall·E (2018)

Made my whole day, fantastic.

A worthwhile read that I thoroughly enjoyed.

I was surprised to see an article about type that didn't involve code editors so heavily upvoted on HN, but as soon as I read the first few paragraphs, I realized why-- it was clearly written by an engineer that has learned a lot about design, and not a designer. There's nothing wrong with that! It's a cool and very well-researched design history deep dive that explores the network of references and roots of the type used, how it was used as a storytelling element, and that sort of thing.

If this was written by a type designer, they'd have been discussing very different things-- why the letterform shapes hit like they do, what design problems they solve, the conceptual and emotional references these shapes make rather than which concrete symbols they relate to, the general rounded square shapes, their negative space, how the lack of stroke contrast makes it hit differently than similar less uniform characters, kerning concerns, etc.

For example, here's Matthew Carter-- one of the more famous type designers-- digging into some of the more unusual type design he's done: https://www.youtube.com/watch?v=RojKQ-w9zn8&t=745s

The person that wrote this article knows a lot more about how this type is used from a modern art perspective, but there's a difference between knowing art history and being able to wield the underlying principles to work with these things as an artist or designer. I think a good example of this is film fans that spend a lot of time on TV Tropes an the like, which are rather like informal film critics. That knowledge is a base requirement for great critical analysis, but if I needed to hire someone to create a film, I'd favor an undergrad film student that was in diapers when the film fan started digging into TV Tropes. Why? It's just a fundamentally different way of reasoning about the same thing. The fan is more concerned with the "whats" and "whens", and the student is more concerned with the "hows", and that gives each of them have a totally different perspective on the "whys". I think creators need to watch out with this. Especially in the nerdier genres, if they're so focused on the film itself that they disregard factors like context and overall story continuity, watching that film is a meaningfully worse experience because they're often more invested in the universe/characters/etc. than they are with the making any give story arc or character pop for a given movie. On the other hand, if we hand too much control to the people primarily interested in the context and story continuity at the expense of any individual film's story and artistic value... well... have you seen the Star Wars prequels?

Back to the article, I could see someone without education in type design reading this article getting the impression that they understand the typographical elements in this film. They definitely understand how the typography was used, but that's a lot different than being able to reason about these things like designers do. A more concrete example would be an in-depth article about the cars in the fast and furious movies, complete with the cultural references of each modification and the purposes they serve. It would be cool and informative, but it wouldn't bring the reader any closer to being an auto designer.

A lot of developers, in particular, get annoyed when I push back against their misconceptions about design. It's not an insult-- it's just not their area of expertise. Usually, they don't know enough about it to realize how little they know about it-- like anybody else with any deep topic they don't know. I've heard designers that have cargo-culted tutorial code into some wordpress plugin spew absolute nonsense about everything from data structures to network architecture with the confidence of someone that just got accepted to a prestigious CS doctoral program. That said, it's easier for non-technical people to see that they don't understand software development because it's easy to see they don't understand the terse error messages, stack traces, code syntax, terminology, etc. It's more difficult in the other direction. Visual design, broadly, is visual communication; for a design to be good, at a bare minimum, it must present cohesive messages or ideas to its intended audience. Many things that look the simplest while still solving all of their goals were the most difficult to make-- you can tell when non-designers copy it because it might look simple, but it probably doesn't effectively communicate everything it needs to-- and that's every bit as true for UI design as it is branding and identity design, and poster design. The complexity in that process is only apparent if you've tried to solve difficult, specific communication problems with a bunch of real-world constraints, grappled with the semiotics, tried to make it stand out, etc. etc. etc. and then had it torn apart by people who've done it a lot longer than you. I can see why someone that doesn't understand what's happening under the hood thinks a designer's main job is making things attractive, like an amateur interior decorator. In reality, that's not even always a requirement-- it often is a natural result of properly communicating your message. What we do is more akin to interior architecture: the functionality comes first. So the next time you see someone suggesting something like allowing custom color themes to your app to "improve UX," maybe consider consulting an experienced UI or UX designer to see what they think. If their suggestions revolve around making it prettier or hiding everything behind menus because functionality is ugly, I conceptually owe you a beer.