An embarrassment of command prompts

In the past few years, I’ve noticed an increase in text-driven ways to control the software I use. The most prominent example is Spotlight on macOS (or the many 3rd party alternatives, and the similar tools on Windows and Linux systems).

Most of these tools work something like this: you use a keyboard shortcut (cmd+space, cmd+K, etc.) to summon a typing prompt. You can then type a variety of commands to trigger an action, like launch an application, search for a file, or perform a calculation.

I presume the origin of these types of text prompt interfaces are linked to two prominent text-input interfaces types:

  1. Web search – Google in particular has taught us to see a simple text input, and expect to be able find just about anything with it.
  2. Command line interfaces – the text-based terminal interfaces that come along with Linux/Unix systems are less forgiving than the Google search box, but they allow experts powerful capabilities by chaining together simple text-based tools.

These days, most of the systems I use have some incarnation of these command prompts:

  • Terminals (bash, zsh, etc.) – local and remote. In my work as Web designer and developer, I spend lots of time in a terminal either locally on macOS, or remotely on Linux-based Web servers.
  • System-wide search/launcher prompts (Spotlight or equivalent) – a system-wide prompt for quickly launching or searching.
  • Web-application command prompts – applications like Slack and Notion had keyboard shortcuts that trigger and application-level prompts to search or navigate within that app.
  • Text editor command prompts (VS Code, Sublime Text, etc.) – most development-focused text editing tools feature command prompts for performing actions or navigating text files. These are like other application-level command prompts, but seem to be particularly common in the domain of text editing, presumably because it’s already a keyboard-focused activity.

Text-based interfaces tend to be powerful and flexible, but not easily discovered. The issue of discovering capabilities is often addressed with auto-complete suggestions.

Text-based input also happens to be a relatively low-bandwidth model that works well on remote systems across a potentially slow network.

One, or many?

I find myself wanting for more consistency among these different types of commands prompts. Though some conventions are emerging, many applications have different keyboard shortcuts to trigger the prompts, and different syntax and behaviors within the prompts.

I’d like to see all of these systems become interoperable in the way of Unix-style command line tools. On a command line, I can “pipe” the output on one command into the input of another (indefinitely). The command prompts in macOS Spotlight, Slack, Notion, and my text editor live in silos, inaccessible to each other.

Slack and Notion both have concepts of “people” (usually prefixed with an @ symbol) and spaces (“channels” or “pages”). However, I can’t reference a Slack channel from Notion. Slack and Notion don’t know that when I refer to @Kelly in either system, I’m talking about the same person. This type of interoperability requires that: Everything should have a URL (sidenote: I think much of Slack’s effectiveness stems from how they do have a URL for every message, even though it’s a closed system).

There are some advantages to keeping each command prompt isolated in its own domain. This isolation allows each application to tailor the syntax and behavior of its command prompt to best match the type of content in that application. The more broad-reaching a system becomes, the more abstraction you must introduce. This abstraction can be powerful but abstractions can also leak and obfuscate.

Despite the drawbacks of a more universal system of interoperable command prompts, I still find myself wanting for a single universal command prompt that works across my entire system and can reach within each of the applications.

Also happens that voice command systems like Siri, Alexa, and whatever Google calls theirs, are becoming more popular. Infrastructure that makes application-level command prompts more interoperable could also open up more capabilities for voice-based control.

Editing note: This was a draft post I wrote and didn’t complete about two years ago, thinking I would build it into a great article full of images and references. Then, this week I saw much better posts on the topic from Chris Coyier and Maggie Appleton. The lesson: Press Publish.

 

Leave a Reply

Your email address will not be published. Required fields are marked *