> By stashing infrequently-used items in a command bar like this, […] You don’t need to add that extra toolbar or layer of menu items.
I’m concerned, from this description, about people putting features only in a command palette, and rendering features completely undiscoverable.
This is one of the big problems of Windows’ Start Menu ever since Vista. In XP, you could find all your programs easily. Vista kinda hid them, and Windows 8 hid them a little more, and 11 hid them a lot more. They’re still there, but honestly difficult to find.
So please make sure your features are still discoverable.
Also remember that a lot of users are shockingly bad at typing. Command bars are a power user feature.
This is one of the reasons why I’m a super fan of the macOS global menubar.
It’s always present and cannot be hidden by app developers, and so there’s no reason to not populate it, and thus the menubar serves as a consistently available master index of the program’s functions. That alone makes it invaluable.
I’m extremely disappointed Ubuntu gave up on Unity. It had the same basic concept, and menus being searchable was so good. GNOME’s determined direction (Adwaita) is so dumb for anything but small, simple apps. Just hopelessly bad.
Mind you, app-defined command palettes can be better than a global one because they can provide more information and context and augment it with other widgets as appropriate. The best command palettes are not just a searchable version of the menu, they add more.
I think probably app-defined palettes and a global menu is best possible combo.
The app-defined palette enables more rich functionality as you’ve mentioned, while the system-owned global menu provides a consistent way to see everything an app is capable of without hunting and pecking through the palette. The menu also serves as a unified API for assistive and automation technology to interact with software and allows users to choose how the menus are displayed (don’t like a top-aligned menubar? Cool, your desktop can present it as window attached menus, a pie menu, or NeXT style floating menus or anything else you can imagine).
Did you know that macos has had a per application menu that does this for years?
In most apps, press "cmd-shift ?" And you will activate the help search. I know, I know. We don't need help, but the other thing it does is reveal menu items from the native menubar.
It's great for finding fiddly commands in complex native apps.
The problem with this pattern is that command-k was already a commonly used shortcut for creating a link, which meant that products like Slack had to find something new for making a link so they overloaded paste which is super broken as a result.
Too humble to mention that you're the creator :) thank you Ben! In my opinion, Slack is the application that really popularized the command bar/palette in the mainstream.
So I'm right to blame Slack for overloading an already existing shortcut??!? I've always blamed Slack, but I didn't know it actually was Slack that started this madness.
How did these come to be associated with command-k and not command-p, which is the more common association at least for developer tools (chrome, vs code, sublime, figma, obsidian)? Command P makes sense since it is a Palette. Maybe it is just a weird quirk that all developer-facing tools use one binding while tools for the hoi polloi use the other.
Particularly offensive to try to name the whole concept after Slack’s default keybinding.
> By stashing infrequently-used items in a command bar like this, […] You don’t need to add that extra toolbar or layer of menu items.
I’m concerned, from this description, about people putting features only in a command palette, and rendering features completely undiscoverable.
This is one of the big problems of Windows’ Start Menu ever since Vista. In XP, you could find all your programs easily. Vista kinda hid them, and Windows 8 hid them a little more, and 11 hid them a lot more. They’re still there, but honestly difficult to find.
So please make sure your features are still discoverable.
Also remember that a lot of users are shockingly bad at typing. Command bars are a power user feature.
This is one of the reasons why I’m a super fan of the macOS global menubar.
It’s always present and cannot be hidden by app developers, and so there’s no reason to not populate it, and thus the menubar serves as a consistently available master index of the program’s functions. That alone makes it invaluable.
I’m extremely disappointed Ubuntu gave up on Unity. It had the same basic concept, and menus being searchable was so good. GNOME’s determined direction (Adwaita) is so dumb for anything but small, simple apps. Just hopelessly bad.
Mind you, app-defined command palettes can be better than a global one because they can provide more information and context and augment it with other widgets as appropriate. The best command palettes are not just a searchable version of the menu, they add more.
I think probably app-defined palettes and a global menu is best possible combo.
The app-defined palette enables more rich functionality as you’ve mentioned, while the system-owned global menu provides a consistent way to see everything an app is capable of without hunting and pecking through the palette. The menu also serves as a unified API for assistive and automation technology to interact with software and allows users to choose how the menus are displayed (don’t like a top-aligned menubar? Cool, your desktop can present it as window attached menus, a pie menu, or NeXT style floating menus or anything else you can imagine).
Did you know that macos has had a per application menu that does this for years?
In most apps, press "cmd-shift ?" And you will activate the help search. I know, I know. We don't need help, but the other thing it does is reveal menu items from the native menubar.
It's great for finding fiddly commands in complex native apps.
The problem with this pattern is that command-k was already a commonly used shortcut for creating a link, which meant that products like Slack had to find something new for making a link so they overloaded paste which is super broken as a result.
I'll just mention that if you follow the link and read the article, linger a while.
Maggie Appleton's site is delightfully designed and thoughtful written. There are a ton of wonderful articles to enjoy there.
Some fun history on how the cmd-k shortcut came to be:
https://ux.stackexchange.com/a/153937
Too humble to mention that you're the creator :) thank you Ben! In my opinion, Slack is the application that really popularized the command bar/palette in the mainstream.
So I'm right to blame Slack for overloading an already existing shortcut??!? I've always blamed Slack, but I didn't know it actually was Slack that started this madness.
Also, emacs M-x from 1980 or maybe TECO's extended command from 1978 (learned these from Bobbie Chen who wrote https://digitalseams.com/blog/why-do-sublime-text-and-vs-cod...)
How did these come to be associated with command-k and not command-p, which is the more common association at least for developer tools (chrome, vs code, sublime, figma, obsidian)? Command P makes sense since it is a Palette. Maybe it is just a weird quirk that all developer-facing tools use one binding while tools for the hoi polloi use the other.
Particularly offensive to try to name the whole concept after Slack’s default keybinding.
It's so frustrating when websites hijack this shortcut.
PowerToys is the Windows equivalent
I'm glad to see that other software companies had recognized the power of M-x, which had been in Emacs since before GNU Emacs.
Now if only they'd understand the power of immediate, pervasive extensibility in Lisp (Autodesk did!).