Finding the Right (Design) Metaphor

Designers of user interfaces make frequent use of metaphors to guide their designs. This isn’t simply a means to easily come up ideas for how to arrange the interactive parts of a computer program, however. The primary reason to use metaphors is for the benefit of end users of a software application.

The design of a program is heavily influential on the behaviour of a user. Features which are highly exposed and easy to see will be used more often than those which are hidden away, and the selection of accessible features will guide the user in a specific direction. This is why books in left-to-right languages are designed with the first page all the way on the left — it’s much easier to read a book when pages are arranged similarly to how the words on them are read. It is therefore expected that a software application for reading books would arrange virtual pages the same way.

I’ve spent parts of the last several months experimenting with text editing. It’s a core component of any computer work and in my opinion (and, based on the number of editors which exist, the opinion or many others) the current offerings are lacking in some regards. To remedy a problem in managing many files in larger text editing projects, I wrote Cheveret — a minimalistic text editor with a hierarchical file system displayed in a sidebar. Aside from a few hiccups that could easily be fixed, it worked fine. However, I’ve shelved it.

Cheveret was based on the metaphor of a cheveret desk — a small writing desk with a few drawers and shelves. The small writing surface prevents too many loose pages from being spread around, which means less visual clutter. The storage options allow the writer to organize their work, leaving them to focus on the immediate writing task at hand. The design goal of Cheveret was to allow the user to effectively navigate a programming or writing project with files scattered over lots of subfolders, which it did. It made it much easier to split up code into small files where each had only one purpose.

The problem I ran into is that I don’t actually like reading code organized in this way.

It’s painfully frustrating to have to hop from file to file to be able understand what’s going on in a program. In any programming language, execution of code is a very linear affair. Functions are defined one at a time which execute lines one at a time. That isn’t to say that organizing code into multiple files isn’t immensely useful. At some point, a project becomes too big that constraining it to one file would lead it to be very difficult to navigate, but so too is a project consisting of dozens of code files which are only a couple hundred lines long. By falling into this trap, I learned that I was programming in ways that were counterproductive.

That begs the question — what went wrong?

I used the wrong metaphor.

I was looking to write a text editor that’d suit my programming style without providing endless distractions. What I’d come up with was mostly that, except in the form of a desk. The trouble with this metaphor is that I was already using something else that fit the metaphor: the computer itself. Every computer arranges its graphical applications through a metaphor known as the desktop, which I’d needlessly duplicated. Instead of trying to “improve” the facilities provided by my computer’s desktop environment, I should have looked at what was there to see how best to fit it into my text editor. Being able to handle stacks of files is not the superpower I thought it was, and the end result was a workflow that didn’t suit me.

Fixing this issue was a simple matter of adjusting the metaphor to paper. What I seek to replace is the standard issue text editor that comes with my desktop, and why I seek to replace it is that the status quo has too much. It’s graph paper with such overcomplicated grids that I can barely see the paper underneath. It’s an opportunity to simplify and find the core tool buried beneath the cruft.

Pictured: A teaser.

To understand why paper was a good metaphor, see my process on avoiding the wrong superpowers.