The User Experience of Language Design

Designing a Coding Language

In my career I‘ve designed a wide range of things from software to catheters to robots but — until I joined the audacious and brilliant crew at Jut — I never imagined being part of the design of a computer language.

I vaguely knew, if I thought about it, that computer languages were created by some person. And I’d paid enough attention over the years to the evolving specifications for javascript, html and css to grasp that language development was iterative like any creative process. However, I had never thought about the creation of a computer language truly as ‘design’ and certainly never imagined that the process involved attention to the user experience in ways that were directly analogous to the way I approached the design of software interfaces and interactions.

Designing a coding language is a user experience problem.

Being personally involved in developing the Juttle language completely changed my perspective. Designing a coding language is definitely a user experience problem. In retrospect, I think the source of my blind spot was the medium. I mean, computer languages are all about code and where is the user experience in that? As it turns out, everywhere! The process of coming to this epiphany was both a fascinating affirmation of the universality of the design process and a chance to broaden my appreciation of some of the fundamental pieces of user experience: aesthetics and antecedents.

Aesthetics

Before I actually became involved in the Juttle language design itself I was working on the UX/UI for the interface in which one would write and run Juttle. As we started sharing prototypes of this design with prospective customers I was frustrated to find that the feedback was all to do with what I considered rather picky details around the Juttle language. Here are some examples:

Why do you have a semi-colon there?”
“I wouldn’t use a square bracket like that”
“Functions look like JS and sinks are more like bash”

Initially I didn’t take these comments seriously, hearing them almost as small talk before we got to the ‘real’ feedback about the UI I was designing. But suddenly in the magical way that user research has of making you see your own blindspots, I realized that these comments were the real feedback! We were showing these folks a new computer language and they were giving us detailed reactions to that language in terms of the specific arrangement of symbols and whitespace that Juttle uses to encode meaning.

But suddenly in the magical way that user research has of making you see your own blindspots, I realized that these comments were the real feedback!

The humbling epiphany here was that they were evaluating the symbolic representations in terms of an aesthetic that I was blind to, what the Juttle team called ‘optics.’ This was a shock because — as a designer working in a world of technical people — part of my self identity was wrapped up in the idea that I was the one with the aesthetic vision! Even if the developers didn’t get it, I could see that adding 3 more pixels of padding mattered or how lining up or offsetting objects was critical for communicating hierarchy or that, yes, a small difference in color saturation had a big impact on legibility. But suddenly, I was the one who didn’t get it, who didn’t understand the implications of {} versus [], why :: was a better way to set off moments than : or why, in a particular case, “slashes don’t grok.”

The issue was that in the context of code, text was being evaluated at an entirely new level for me: as an arrangement of symbols that encoded meaning. I hadn’t consciously thought about text in this way since I had learned to read! Uncomfortably, my go-to toolset for thinking about text aesthetics — font, kerning, and leading — were irrelevant for making user experience decisions regarding the interpretation of symbols within the context of an inflexible grid of lines and fixed-width characters. Fortunately, the initial intimidation I felt at this epiphany dissipated as soon as I saw that I could begin to add value to the syntax discussions by playing with symbolic arrangements in my familiar design-test-iterate process.

Antecedents

As I became more involved into the syntax debate, I came to realize there was also another important context in play in the evaluation of the Juttle syntax: other programming languages!

Because my programming experience was limited to html, css, javascript and a small amount of UNIX shell syntax I had no concept of computer language design in terms of historical precedent and standard patterns. My discovery, obvious in retrospect, was that the Juttle team was using the historical context to make two kinds of design decisions, and in both cases there was a direct analogy to the way I used precedent in making visual and interactive design decisions.

The first use of precedent was to create a consistent tone and feel. What I came to understand was that the Juttle team had determined to create a coding experience that felt like a novel blending of a declarative dataflow language with a general-purpose logic execution syntax. They were therefore proposing or evaluating syntax in terms of how it contributed to this desired feel for our target audience. This design process was completely analogous to how I might, in visual design mode, decide upfront I wanted a particular emotional tone for a piece and then carefully insert whatever constructivist references, hints of a Blue Note album cover art or images in Bruce Weber style I needed to achieve that feel.

The second way the Juttle team was making design decisions in terms of historical precedent was by utilizing certain patterns to make the creation and parsing of syntax intuitive. Once I began to understand the references I could see that this was exactly the same way of using precedent (aka standards) as I might make in deciding to copy an interaction model from Amazon, or Apple or Google because I knew that my users would immediately recognize the pattern and thus understand how to use the interface.

An example that brings together both of these issues comes from our design debate about how to enable a Juttle programmer to assign a particular color to a series in a chart. This needed to be possible within the context of the unix-based pattern for parameterization we’d adopted for Juttle that used a dash like this:

-name value

In order to support the complex parameterization required by charts, we’d also decided to support dot separators so the simple solution for the custom color requirement would be

-seriesName.color ‘red’

However, the problem was that seriesName itself might be dot separated such as

cpu.load

This meant we might get passed a parameter string

-cpu.load.color ‘red’
 // can’t parse this unambiguously
 // is .color part of the series name, or is it a reference to our color object?

My suggestion was that we adopt the Javascript pattern for string literals so we’d support this:

-[‘cpu.load’].color ‘red’

The problem with this, however, was that this turned the text immediately after the dash into a kind of expression and that felt wrong from the perspective of the original unix pattern where the text after the dash must be just the name of an object.

The solution? A more verbose but unambiguously precedent-friendly use of array syntax:

-series [{name:’cpu.load’, color:’red’}]

Whew.

While my initial reaction to this debate as it was happening was that it was ridiculously arcane, as I came to understand what was at stake I had to admit to myself that this syntax debate was exactly the same in form (and in degree of pickiness) as any number of UX discussions I’ve been involved with that turned on how to maintain consistency between the implementation of a particular design system and more general user experience standards.

Design is Design

The biggest takeaway for me from the small part I’ve played in the development of Juttle is the affirmation of the universality of the design process. Every kind of human creative endeavor has a context for making user experience design decisions based on its own entirely consistent aesthetic principles and rich history of patterns and precedent. Any time you begin to doubt that, or think that the terms of a particular debate are looking like code to you, well, you are just not looking hard enough.