When we write code, we aren't just writing code - we're building an interface. What I mean by that is that a code file is a means of delivering content. Just as a web page delivers content to our users, a code file delivers content to our engineers. As such, all of the thought and calculations that go into designing an enjoyable UI should also go into designing an enjoyable code file.
And, we can't talk about an enjoyable UI without talking about white space. The right amount of white space can make-or-break an experience. To quote Spencer Spinnell, former head of design at Koko Interactive:
"Margins" is just another term for "white space". And, for Spinnell, the appropriate use of white space isn't just good, it's a major factor in great design.
A couple of years ago, I read Refactoring UI by Adam Wathan and Steve Schoger. In their book, Wathan and Schoger also talk about the importance of white space; but, what I love about their approach on the matter is that they advocate for starting with too much white space; and then, dialing it back until things look good:
White space should be removed, not added
When designing for the web, white space is almost always added to a design—if something looks little too cramped, you add a bit of margin or padding until things look better.
The problem with this approach is that elements are only given the minimum amount of breathing room necessary to not look actively bad. To make something actually look great, you usually need more white space.
A better approach is to start by giving something way too much space, then remove it until it you're happy with the result.
You might think you'd end up with too much white space this way, but in practice, what might seem like "a little too much" when focused on an individual element ends up being closer to "just enough" in the context of a complete UI. (Refactoring UI, Pages 67-69)
tab-size CSS property of a
<code> block using a CSS custom property,
--tab-size. The Up/Right arrows will increase the
tab-size and the Down/Left arrows will decrease the
To align with the Refactoring UI book, I'm starting the demo with way too much indentation: 10-spaces. No matter where you fall on the indentation spectrum, I'm confident that we can all agree that 10-spaces delivers a terrible experience. But, by starting with too much and then slowly removing indentation, we can find code that looks great.
In my demo, the code block being rendered contains the code of the demo itself. Essentially, on
load, it grabs:
... which gives us (more or less) the original source of the HTML page. I then jam that markup into the
.textContent property of my
<code> block and call Prism.js on it in order to apply some syntax highlighting:
As you can see, this demo works by grabbing the current
--tab-size property set on the
:root element (
document.documentElement in this case). And then, either incrementing it or decrementing is based on the keyboard event. And, when we open this demo and slowly start decreasing the indentation, we get the following output:
To quote Adam Watham, 2-spaces, in my opinion, is "the minimum amount of breathing room necessary to not look actively bad". But, by starting with too much indentation and then slowly decreasing it until the code looks good, I believe that we see that more indentation leads to a better user experience (UX).
Want to use code from this post? Check out the license.