The future of command launchers

Oct 10, 2022

Past, present and future of application launchers

If we had an event called Productivity Awards, command launchers would get the feature of year award in 2022. It is becoming more common for websites to have a ⌘ Cmd K shortcut to open a command palette for navigating or performing certain actions faster. In the last WWDC, Apple announced new spotlight features giving more power to the native MacOS command launcher. At the same time we have tools like Raycast or Alfred already offering powerful alternatives to it.

With all of this in mind I want to untangle the relationship between all of these launchers and see how the future of command launchers will be, taking into consideration things like AI.

Past

Before diving into the future, let's do a brief and inaccurate history lesson on how command launchers came to be.

“

To be ignorant of what occurred before you were born is to remain always a child

• Sorry, I could not resist the temptation to put an over the top quote
• Keep reading please

The term command launcher is similar to we programmers call command line. Before modern desktop environments came with their fancy windows and workspaces, humans interacted with computers by typing commands into a terminal. They commanded the computer to do things like listing the files inside a folder.

Some years later the internet was integrated into the personal computer, allowing users to browse the web from the comfort of their homes. As comfortable as listening to a few minutes of hellish sounds.

Users still wanted to list files, but this time the files were in someone else's computer in the form of websites. Instead of typing commands into a terminal, users browsed the internet using search engines.

As interfaces became better, some commands became easier to do with gestures and clicks. Instead of having to type a command into a terminal, users could simply click or swipe through the file explorer to find what they were looking for. However, as users accumulated files this approach became slow. In 2004 Apple announced Spotlight, a framework for MacOS that allowed users to search files faster. It started as an extension of the Finder file explorer, but it soon became the globally command launcher we know today. Spotlight continued to evolve giving users the ability to open applications, do simple math and search the internet. Even thought users had simple interfaces the strive for a faster way to interact with computers remained over the years.

If you are interested in a better history lesson about command palettes I will highly encourage you to read this article from Matthew Guay.

Present

To see how things may evolve we need to have a mental model to understand the differences and features of all the modern command launchers.

Global & Local

The first distinction I would like to make is between global and local command launchers.

“

Think globally, act locally

• This is the last quote, I promise
• Thank you

Some command launchers like MacOS Spotlight or Alfred are global since they can be accessed everywhere and are used for high level actions like switching applications. Whereas applications like Figma or Slack have local command launchers that can only be accessed while using each application.

This distinction between local and global launchers will become increasingly important as we move forward through the article since the line between the two could disappear in the future.

Queries & Mutations

Every software can be broken down into two types of commands:

• Queries: Get information from the system.
• Mutations: Modify information of the system.

In every application users go back and forth between getting information and modifying it. This is what humans do after-all, but let's stick to users since I am a software developer not an environmental biologist. With this in mind, we can picture our users going into an endless loop of getting information, changing it and getting it again. Inspired by Nick Milo's knowledge loop, we will call this the command loop.

As we will see later, if we want to be more productive our goal should be to optimize this loop.

• Launch the global command palette by pressing CMD+Space
• Search and open Figma application
• Launch local Figma command palette by pressing CMD+/
• Select the file you need to implement
• Launch the global command palette
• Select and open VSCode application by pressing CMD+K
• Launch the local command palette
• Select the project you are working on
• Start the development server
• Launch the global command palette
• Select Chrome from the list
• Launch the local command palette by pressing CMD+N
• Navigate to the URL you are developing
• Notice that you need to clear the website cache
• Open Chrome developer tools by pressing CMD+SHIFT+I
• Launch the local command palette by pressing CMD+SHIFT+P
• Run the Clear Website Cache command

Some may say that you can automate certain steps, use multiple monitors or have a workspace with everything prepared. I know this is a contrived example, but I am trying to make point. In this article I want to explore if there is a better global solution for all possible workflows.

Future

Being productive means spending less time in what is unimportant. Usually we end up using tools that reduce the friction between what we want to happen and it happening. In physics terms, we want to optimize the path of least resistance. The following sections outline what could be the future of commands launchers and how we may engineer it.

Global vs Local

From the previous example, we can think of local command palettes as transitory states. In other words, by skipping transitory states we will be removing the necessity of local command palettes. With this in mind, the above example will look like this:

• Launch the global command palette
• Open the Figma file you need to implement
• Launch the global command palette
• Start VSCode project and development server
• Launch the global command palette
• Navigate to the URL you are developing
• Notice that you need to clear the website cache
• Launch the global command palette
• Run the Clear Website Cache command

One could argue that local command launchers are a local maxima for what is possible in the global command launcher space. To be clear, I am not making an argument for centralization, as we will see later, this could be achieve with a high degree of decoupling between applications and their respective commands.

Shortcuts

Having a single global launcher opens up the possibility to assign shortcuts to global actions whereas in the original example you could only assign local shortcuts to each application.

If you pay attention to the initial example, you will notice that each command palette shortcut and behavior is different. By only using the global command launcher users won't need to learn different shortcut schemas for each application.

Context

Another problem of local command palettes is that only have local context. Which is fine as long as you only use one application. The moment you need to juggle between different applications this becomes an issue.

For example, when I implement the Figma design I want to send a message to Jane in Slack with the URL at the same time that I mark the task as done in Todoist. Again, you could try to automate this, but you can fall into the automation trap, where you spend more time than necessary trying to automate something simple.

Since we spend most of the time getting and modifying information cross-application we can update our command loop diagram.

Having this global command launcher prevents context switching by having a single entry point for performing actions. In other words, no more CMD+Tab madness.

Suggestions

When you automate a workflow you make improvements harder, because the cost of modifying the automation usually is too high. Also, the fact that you are blind to the process prevents you from making connections to find a better solution. Here is where I think AI can help us the most. Let's imagine how the command palette could behave after I implement the website design:

• Implement the website design
• Launch the global command palette
• Run the Publish Website command
• Launch the global command palette
• A command named Send URL to Jane gets suggested to you
• Another command named Share on Twitter gets suggested

A few interesting commands appeared to let's explain them:

• Publish Website: Since we have a global context the command launcher knows that we've finished implementing the website so the launcher suggests us to publish the website. This requires for the command launcher to know what actions has the user taken in the application in order to learn from past user actions. How this is achieved technically will the explain in the engineering section
• Send URL to Jane: Same idea here but with the extra benefit of our global command launcher having contextual/application-specific information to deal with. This command is dynamic. In a sense we are automating automation.
• Share on Twitter: By contrast this not a common workflow, but this a way to discovered unknown connections between the tools we use daily. Thus making our workflow dynamic, fast and personal. Here we are automating creativity.

NLP (Natural Language Processing)

Now that we opened the AI elephant in the room lets go deep. What if we don't need commands at all? This is a crazy idea but its worth exploring. What if instead of having a set of commands I could just ask the computer for what I want. To be clear I will do something like this:

• Launch the global command palette
• Type What is the meaning of life?

• What?
• Sorry, I meant to say:

• Launch the global command palette
• Type Implement Figma design X in web project Y in the browser
• Notice that you need to clear the website cache (even AI does not know how to manage caches)
• Type Clear current website cache

I guess this could become tiresome of writing each time, but maybe if we combine it with suggestion this could shape the future of how we interact with computers.

Social

The same way we work with multiple applications, we work with multiple humans, which perform queries and mutations in same systems we do.

By having a global context, command launchers could make suggestions based on other users actions. For example, Jane may open her command launcher and see a suggestion with the following command: Review Victor's published website. Some launchers like Raycast are paving the way forward by offering team shared features like private commands or text snippets.

Engineering

For making all the above possible one of the following scenarios should happen:

• We will need to know externally, from the global command launcher perspective, what actions can and are being performed by the user. In some sense we will need an open specification where applications define what queries and mutations can be done, so the global application launcher can interact with all of them. Currently, Apple has some APIs that are similar to what would be required like home screen quick actions or Siri event suggestions.
• At the moment application launchers like Raycast rely on community made plugins for integrating with application using the API the tools provide. In fact many companies are creating tools in Raycast for their applications. In a sense Raycast is the open specification.

Both scenarios have their pros and cons. I am a big fan and contributor of Raycast and I recommend it to everyone I can. However, I am unsure about the coupling it has with the tools it provides, if Raycast goes broke all your workflows would change drastically. Both solutions are not incompatible thought, applications could define their collection of commands and the different command launchers could compete to see which has better UX. On another note the fact that you can create your own extension in Raycast seems really promising, in other words, we don't want to tie every command to a specific application as we've seen.

Caveats

I feel there are some objections that could be posed to what I presented here as the future of command launchers. I wouldn't feel comfortable if I didn't mention them so here you have:

• Local launchers are closer both in cognitive and technological terms. In other words it is more natural for users to open command launchers in the application itself instead of having to install an extension (if any) to their global command launcher. Also, the application specific engineers can create their command launcher to perfectly fit the need for their app which could make the global command launcher feel like the second best option.
• The web could take over the application paradigm. Some exciting new web browsers like Arc or SigmaOS are being released and they have pretty cool command launchers built-in. This does not go in opposite to what I presented in this article but it could mean that launchers like Raycast may become obsolete if they don't find a way to properly interact with websites. On the flip side, maybe the web is a great place to create that open specification I mentioned before, we'll see.

I think command launchers will be a primary way we interact with computers in the future. Or maybe the singularity happens and there is nothing to be productive about besides pondering about the meaning of life.