Second-Order Controls
The article that you are now reading has no controls. There is nothing for you to input or interact with that can change it. You are a passive reader. Welcome.
An explorable explanation like this one provides controls: buttons, sliders, drag-n-drops, check boxes, and all of those other GUI (graphical user interface) elements that most people can operate effectively without much training. Underneath the controls, like any piece of software, there is code: the lovechild of a cookbook and an algebra textbook. The author of the work wrote code; you the active reader manipulate controls.
But what’s interesting about this particular explorable explanation is that, if you scroll down, you’re provided with a set of checkboxes. Each corresponds to a control in the interactive visualization. The article explains, “we’ve also provided some controls below to enable you tailor the playground to a specific topic or lesson” (emphasis mine). The checkboxes are themselves controls, and they affect other controls. They are second-order controls, and they start to blur the line between author and reader.
Perhaps the most common second order controls are in preferences or permission management tools. For example, you may remove an item from a drop-down menu or icon tray. Or you may restrict which users have access to certain files or projects, thereby limiting the controls they are shown.
A more extreme example comes from the video game Infinifactory (which, by the way, I recommend to anyone who likes building things in Minecraft). In the main game, you fly around a 3D environment placing factory components (e.g. conveyors, sensors, pushers) that assemble a stream of raw materials into a desired product. One selects these components from a visual menu.
Later, players unlock the ability to design and publish their own puzzles (aka a level editor). What’s remarkable is that the level editor works exactly the same way as the game itself: in first person, by placing blocks. The visual menu of factory components now contains the raw materials of whatever product the player will be building. Once the author has placed some of these blocks, they can immediately enter the puzzle as a player, and demonstrate that the puzzle has a solution before publishing. (The author also has access to checkboxes to limit what factory components are available to the player.)
Contrast Portal 2’s level editor, which presents a schematic cartoon. Although the level editor isn’t code, it requires a very different interface and toolset from playing the game itself. Entering the level in first person happens after a noticeable delay. (To be fair, Infinifactory’s construction mechanics lend themselves to a level editor quite well.)
In short, it seems that second-order controls, especially those that do something other than toggle the presence of first-order controls, aren’t very common. Although they can be difficult to implement, I think that many developers and designers are simply not consciously aware of second-order controls and the power they can have.
What do video games and interactive drawings have in common? State. They can be in one of a number of states, and move between them either with time or by human action (i.e. a control). A second-order control affects the state of the state. A button cannot be checked or unchecked if it doesn’t exist. A conveyor cannot have a location and orientation if conveyors are forbidden in this puzzle. The player’s location is affected by the location of the walls and floor. A file can’t have an index in a list of files if it’s not visible to that user. An active reader can adjust a number and see the system react, but the author must first create that number and define its default, maximum, and minimum values. State depending on other state is everywhere.
Therefore, it’s unsurprising that second-order code is quite common. The most familiar example to an office worker would be an Excel spreadsheet with formulae that recalculate based on new input. The Global Forecast System is first-order code, but the code that runs it every six hours is second-order. Many small programs have resource files that contain code that affects how they run. A Makefile is second-order code which controls whatever is being scripted, and if it’s generated by a configure script, then that’s third-order code.
Then there’s the text editor vim. (If you’re not familiar with vim, just skim over this paragraph.) If you consider normal mode commands to be code, then they’re second-order code. dap, delete all paragraph…of code in this file. Therefore the code in my .vimrc is third-order code: it is code that controls code (vim commands) that controls code (in the file). That’s assuming the code I’m editing is the “bottom”; if it’s a configuration or deployment script there may be more layers. And if I use vim to edit my .vimrc then I have a near-loop, with the old version controlling how I edit the new one.
It seems pretty clear that code can control code for as many layers as one likes, at least theoretically if not practically. Having multiple layers of code is frequently advantageous. But so far I’ve only seen controls nested two layers deep. Every example of a second-order control that I know of was itself created with code.
In 1984, Apple introduced the first Macintosh on the premise that computers should learn about people. Now, the Learn to Code movement says that people should learn about computers. I agree that being able to create software is empowering, but it takes a lot of knowledge and effort to get there. Second-order controls don’t offer nearly the power of code, but they are instantly usable by anyone. If coding is like climbing a mountain, second-order controls are like climbing stairs: you won’t get as high, but it’s done by more people, frequently and safely.
I think that software developers can greatly empower the public by providing them with second-order tools rather than expecting everyone to code.
