Dead Fish ≠ Code Export

This post is a response to a tweet critiquing the “code export” capability of design tools, and a talk called “Stop Drawing Dead Fish” that calls for better tools to allow artists to create visual art without code. Should designers code? Should artists code? It’s a nuanced, interesting topic and I had some thoughts.

, ,
Black and white image of a fish with text 'this is not a fish'

I found myself in a bit of a Twitter hole today, and the one above especially caught my eye. I have dealt with related frustrations and almost hit the retweet button…but then decided not to after my usual internal drama surrounding social media (as discussed in episode 7 of the No You Go podcast – highly recommended).

My hesitation in retweeting this would be that others might translate it to: “code export is bad and people who use code export are bad”, an opinion I do not have. I understood this tweet as a call for design tools more fitting to the medium of the web.

Upon opening the replies, I discovered one from @threepointone linking to a talk called Stop Drawing Dead Fish by Bret Victor. I gave it a watch, and it was so good it inspired a blog post.


Dead Fish, My Summary

Computers are a new medium for visual art that, so far, we have primarily used as a way to emulate other visual art mediums (painting and drawing, animation and television). As with other visual mediums, we run into The Treachery of Images:

Famous painting of a pipe with the text "this is not a pipe" below it
“This is not a pipe”

The above, famous painting by René Magritte pronounces “this is not a pipe” because it is a painting of a pipe, not a pipe. We fall into the same trap with images created on computers. In this talk, Bret uses the example of drawing a fish, or a “dead fish” as it is just an image of a fish and nothing else.

With computers, however, we have the unique ability to define behaviors of art objects that respond to their environments. Computers are best at simulation, and video games are the closest thing to harnessing that power in an artistic sense. The essence of visual art on the computer versus other visual mediums is the ability for a viewer to interact with the art object. Visual art on a computer should be alive and responsive to the viewer by default.

According to Bret, code is an inappropriate way of creating visual art. We can’t directly manipulate the visual aspects of the art in the same way we have been doing since the age of cave paintings. The current assumption is that to create art with behavior, an artist needs to code, but that means manipulating the art object using a language far removed from the object itself which, historically, has never been a prerequisite for creating visual art.

The talk’s overall message is that we need to break the assumption that creating behavior means writing code. Instead, we need to invent ways of creating behavior that make sense in the context of visual art. Artists should be able to create behavior via direct manipulation of the art objects themselves, as they always have. In the talk, Bret demos some software that creates behavior by using geometry to define animation patterns and behavior on a tablet as a potential solution to this problem.

Dead Fish ≠ Code Export

One way to map this message back to the “stop it with the code export” sentiment is to say that designers shouldn’t need to code either; our tools need to get better. I guess this means we are still having the “should designers code” conversation, and the answer is still, probably, “no they don’t need to code, but it wouldn’t hurt”. It also depends greatly on what kind of designer we are talking about, e.g. someone designing for the web should code more than a logo designer.

However, I don’t think the connection between the tweet and the talk is as simple as equating designers and visual artists. What if I said, “designers should code but visual artists shouldn’t code”?

This gets at a much larger debate between the difference between art and design. While there is no official answer to this question (and likely never will be), this Quora thread offers some perspective: Design is Art with constraints or, while Art is expression in its purest form, design exists to solve a problem and does so through defined structural components e.g. typography, layout, and color.

Sure.

Back to “should designers code”. I would argue that, particularly in design for the web, what you make matters less than who is making it with you. Art is generally a solitary undertaking, while design for the web nearly always happens in the context of a team. A (web) designer uses the computer to create visual representations of software that will be implemented and hooked into code logic by others. In this case, I would say designers should code for the sake of communication and time savings.

The thing is…I think that maybe just maybe, for the web, HTML and CSS will evolve to a point where they are the medium. Rather than creating better tools to avoid the need to code, the code will progress in a way that renders the design tools obsolete. That might be far into the future, but I don’t think its a pipe dream.

Anyway…

I’m sure there are many sides to this topic, but that talk is great and you should watch it. I’m excited about the future of CSS and it seems like the amazing development of CSS Grid and the adoption of design systems mean the division between design and front-end code, at least, will become a lot smaller.