If you want to understand why command palettes are popping up in apps everywhere right now (instead of five years ago), check out this post.
There’s a feature that users really seem to like
What is a command palette / command k / command bar? Let’s take a look at why this humble, little feature emerged and why it’s becoming a building block in modern software.
To start, let’s talk about a feature that is already ubiquitous: search. Searching the internet has somehow become boring, because everyone does it all the time.
Consider a question like "what is the population of Switzerland?". You probably don't know the answer, but it's very easy to figure out the answer. Just punch “population switzerland” into Google, and boom, done, now you know. This was not an interesting thing to do. You already knew how to do this.
As long as the results are good, search is an extremely efficient information retrieval pattern. To retrieve the right information, you didn't have to:
Without search, finding information is hard. Imagine Google was down and you needed to refine your understanding of central European geography before dinner with your Swiss inlaws. Go to https://wikipedia.org, then select "English," click on "Contents," click on "Geography," scroll down the list to "Europe," click on "Switzerland," and scroll to "Population."
This method works, but it (a) requires you to remember or learn Wikipedia's hierarchy and (b) requires you to transform your query ("population switzerland") into Wikipedia's vocabulary. That transformation requires effort. You had to read through each page to find the right anchor to the next place. Try doing this now.
The Wikipedia path may seem crazy and very 1990s, but you actually do the same thing many times a day when using software.
Instead of trying to retrieve some information about Switzerland, let's do something more fun: imagine you’re doing your taxes and need to create a new Google sheet. Let's try to get rid of the little gray lines that wrap each cell to make our sheet a little sleeker.
How do you do it?
You could try navigating the menus at the top of the site. To figure this out, you need to first decide what the little lines are called, and where the ability to hide them might live. Compare this to the Wikipedia example. In both cases, you have to understand a hierarchy to get the outcome you wanted. The Wikipedia graph was pages; the Google Sheets graph is buttons and menus. This is friction – a gap between intent (what you’re trying to do) and action (the software doing that thing).
If that sounds annoying or you can’t find the option, you can always use Google (search! yay!). "How to remove borders in google sheets" will help. But again, this is friction. As a user, being jettisoned out of the app I’m in to find the answer to a seemingly basic question doesn’t make me feel loved, and, worse, risks me getting distracted.
Thankfully, Google Sheets has a handy feature they call "Search the menus." You can access it by clicking "Help" or using the shortcut “option” + “/.” If you search for "grid," BOOM, you see an option to "hide gridlines." Nice job.
This feature is a command bar. It lets you take action in Google Sheets without needing to know where the action lives in the menus. Just search. (You'll notice it could be a lot better by being more forgiving in its vocabulary; if you search for "lines," for example, you don't see any results.) It’s also really fast. If you’re someone who creates a lot of sheets, it’s so nice to be able to take this action in a few keystrokes without having to remember anything about where it lives in the UI.
Just like information on the web can be represented as a graph where edges are hyperlinks, actions within software (this case, Google Sheets) can be represented as a graph where nodes are actions and edges represent actions that uncover other actions. One way to execute this action was to go from your sheet ➝ Show ➝ View ➝ Show Gridlines.
A command bar is just search that lets you query across the action graph, eliminating friction. As a user, you don't need to know anything about the graph; you just need to describe what you're trying to do in words.
We’ve been talking about software from an end user’s perspective, but now let’s think about how command bars can help software builders.
As you saw in the tweets, command bars go by many names. Command palette. Command menu. Action bar. Command k (which refers to the shortcut that's often used to invoke it).
They each look like a search bar because fundamentally that’s what a command bar is. There’s a space for the user to query, and there’s a space to show results. More advanced versions will also show default actions (before the user has started typing).
Here's a couple examples. You can see the same basic anatomy in each:
When you search, the user sees relevant results. What happens when a user selects an action?
There are two possibilities:
Once you think about this concept of action search, you'll start to see it elsewhere.
For example, it turns out iOS search is kind of a command bar.
Here, you can see examples of both command types: “Alarm” at the top will just teleport you to the Alarm app, but “Turn alarm 7:00 on” will actually set an alarm without you having to do anything else. You can go from intent (setting an alarm) to action (the alarm being set) without having to navigate the Clock app at all.
Voice assistants are in some ways a form of command menu. “Hey Siri, set an alarm” → “OK, for what time” → “seven AM” is like an action command with one input.
There are so many types of software that it can be hard to generalize without thinking about some universal principles that relate to any type of software. Jeff Bezos famously said that in the retail business, users would always want lower prices and faster delivery. The software equivalent of that Bezos-ism is that users always want software that is (a) easier to use and (b) faster. No user will want to spend more time reading a manual or help center to understand how to use an app. Similarly, most of the time, no user would prefer to take the scenic route to accomplish something in a tool when they could do it in less time.
Here are some symptoms of software that could especially benefit from a command bar:
Let’s take each one of these.
New users have a hard time finding important features
New users are especially bad at navigating action graphs because their prior knowledge of the graph is zero. They might not know what actions are possible or how they are described. With a command bar, users need much less prior knowledge.
You get a lot of "How do I do X" support requests
This means your action graph is hard to understand because the relationship between the nodes is unclear. A command bar solves this problem because it turns the support request into a query. If there’s an action that satisfies the query, the command bar will show it.
You can't figure out where to put the new feature you just built
UI bloat is incredibly common, especially as an app grows and adds more features. Adding buttons for every new feature risks making the app confusing and cramped, and sometimes there isn’t a logical place for a feature. A nice property of a command bar is that it scales infinitely.
Users find certain actions slow
Slowness in software is like fatigue in the human body — it’s a common symptom with many different underlying causes. A command bar can help with a few types of slowness.
You'd think with all these benefits and all this user love that every app would have a command bar. Why aren’t they everywhere already?
We believe that part of the reason is that it’s hard to build a command bar well. For the pattern to work, your command palette has to meet several criteria.
Easy to extend
If users can’t find an action in a command bar, they’ll probably ignore it. This is one of the strongest findings we saw in our user research when we were starting CommandBar. If users try out a command bar and it doesn’t contain the action they’re looking for, it’s unlikely they’ll try it again. If they fail 3 times, that probably drops closer to 0. Conversely, you don’t want stale or broken commands lying around.
CommandBar solves this problem with the CommandBar Editor – a configuration tool that makes it possible to add and edit commands without code – and a simple, composable SDK.
Allow natural language input
Don’t force users to use specific words; let them express their intent in the way that is most natural and fast to them as possible. That means accepting synonyms and being typo tolerant. Doing this well is critical to adoption and avoiding a scenario where a command exists in your bar but a user can’t find it because they spelled something wrong or used the wrong synonym. Even for users who are using a command bar regularly, you don’t want to require that they memorize commands like they would need to in a traditional CLI interface.
CommandBar solves this problem with out-of-the-box typo-tolerance and by making it possible to add synonyms to commands based on previous user searches.
Be super fast
Speed is kinda the point of a command bar. Everything about it needs to be fast. It needs to load fast, respond to user input fast, and take action fast. It should probably also support keyboard shortcuts for extra speed. Users should think of it as the fasttrack in your app.
Everything we ship at CommandBar adheres to the principle that if it isn’t fast, users won’t use it. We even let users define their own shortcuts through CommandBar.
Work for any user
If your command bar doesn’t work for all of your users, it isn’t fulfilling its potential: the portal to your app that every user — not just power users — can rely on to quickly go from intent to action. If you don’t do this, you’ll enter a sad cycle where only a subset of users will use the feature, and then you’ll start to optimize for those users, ignoring commands or use cases relevant to the rest.
The entire CommandBar interface accommodates different types of users: users who prefer or depend on the mouse, users who prefer and depend on the keyboard.
Be customized for every user
Showing users relevant actions before the search can turbocharge the entire pattern, and make a command bar a place a user turns to figure out what they should be searching for. Like Clippy, but not annoying.
CommandBar makes it possible to create custom defaults for different users based on who they are and what they’ve done in your app, utilizing patterns from previous users.
Your command bar can be another access point for your product’s entire range of features. Maintaining this additional interface can be a time-consuming engineering task, especially when there are changes in your tech stack.
At CommandBar, our entire focus is making this interface work seamlessly for your company and your end users.
And this is why CommandBar exists. We believe that every software product that cares about its users should have a feature like this, and we want to make it an afternoon project to add a beautiful, performant command bar that all users can rely on.
If you build software, you can try us out at https://commandbar.com.