Every RAXXO tool ships with a small, fixed set of keyboard shortcuts chosen for the actions someone repeats dozens of times a session, not for decoration
I cap it at under ten shortcuts per tool and run every candidate through a frequency test before it earns a key, so the list never turns into something a new user has to memorize
Every shortcut gets checked against the browser's own bindings and the operating system's reserved keys before it ships, because a shortcut that silently loses to Chrome is worse than no shortcut at all
A single
?key opens a legend in every tool, so nobody has to guess what is bound or dig through a settings page to find out
Why I Add Keyboard Shortcuts to Something Nobody Asked For
No customer has ever written in asking for keyboard shortcuts. Nobody has ever left a review mentioning them. If I only built what people explicitly asked for, this feature would not exist in a single RAXXO tool. I build it anyway, in every tool, because the people who end up using a tool the most are exactly the people who stop reaching for the mouse.
The pattern shows up the same way every time. Someone tries a RAXXO tool once, likes it, and starts using it daily. A few weeks in, the same five or six actions repeat over and over: open the next item, mark something done, jump back to the list, close the panel. None of that is a decision anymore. It is muscle memory waiting for a shortcut to attach itself to. Without one, the person clicks the same small button in the same corner of the screen a hundred times a week and never notices the friction, because it never rises to the level of a complaint. It just quietly costs them time.
Why every RAXXO tool skips the loading spinner covers a similar idea from a different angle: speed a user does not consciously register still shapes whether a tool feels good to use every day. Keyboard shortcuts are the same trade, aimed at a different kind of friction. A spinner slows down what a screen shows you. A missing shortcut slows down what your hands have to do to get there. Both are invisible until you fix them, and both are the difference between a tool someone tolerates and a tool someone reaches for without thinking.
There is a second reason I keep doing this across every tool, even the smallest ones. A terminal-first audience, and a fair share of the people using Git Dojo, Statusline Builder, or OhNine, already live with their hands on a keyboard for most of the day. Forcing that person back to a mouse for a routine action is not a small tax. It is a tax on exactly the users most likely to become daily, habitual ones. Skipping shortcuts would save me a small amount of build time and cost me the attention of the people I most want to keep.
The Rule That Decides Which Actions Get a Shortcut
The temptation with keyboard shortcuts is to bind everything. Every button on screen could theoretically get a key, and a first pass at this feature in any tool tends to look like that, a shortcut for every action because every action feels important while you are the one building it. That instinct is wrong, and I learned why the hard way on an early version of the Statusline Builder editor, where I bound a dozen actions in one sitting and then watched myself forget half of them within a week. If the person who built the shortcuts cannot remember them, nobody else stands a chance.
So the rule now is a frequency test, applied before anything gets a key: would a regular user of this tool trigger this action more than a handful of times in a normal session. If the honest answer is no, it does not get a shortcut, no matter how satisfying it would be to bind. That rule alone cuts the list down fast. A "delete my account" action never gets one. A "duplicate this entry" action, something people do constantly once a tool has more than a few saved items, usually does.
The second filter is reversibility. An action bound to a single keypress needs to be either instantly undoable or hard to trigger by accident, because a keyboard shortcut removes the confirmation click that would normally catch a mistake. That is why destructive actions in RAXXO tools rarely get a bare shortcut. If they get one at all, it takes a modifier key, never a single letter on its own, so a stray keypress cannot quietly delete something.
Running both filters together usually lands a tool somewhere under ten shortcuts total, and that ceiling is deliberate, not an accident of how the filters happen to shake out. Past roughly that number, a shortcut list stops being something a regular user absorbs naturally through repetition and starts being something they would need to sit down and study, which defeats the entire point. The design system that makes five RAXXO tools feel like one studio works the same way at a different layer, a small shared vocabulary that stays small on purpose, because the value of a shared pattern comes from how little effort it takes to learn, not from how much it covers.
How I Keep Shortcuts From Colliding With the Browser or the OS
The fastest way to make a keyboard shortcut worse than useless is to bind it to something the browser or the operating system already owns. Ctrl+W closes a tab in nearly every browser, no matter what a web app underneath it might want to do with that key. Cmd+, opens system preferences on a Mac. Space scrolls the page unless something explicitly stops it. A shortcut that silently loses that fight does not fail loudly. It just does nothing, or worse, it does the browser's thing instead of the tool's thing, and the user has no idea why the key they memorized suddenly stopped working.
Every shortcut I add gets checked against two lists before it ships: the handful of bindings every major browser reserves for itself, and the OS-level shortcuts on both Windows and Mac, since RAXXO tools run in both environments and a key that is safe on one is not automatically safe on the other. Single letters without a modifier are the safest category, since browsers rarely reserve a bare letter key, but they only work at all when a tool is not also expecting that letter as normal text input somewhere on the same screen. That single constraint rules out plain letter shortcuts for any tool with a search box or a text field visible by default, which is most of them, so those tools lean on modifier combinations instead, checked the same way.
This is also where a shortcut earns or loses trust fast. The first time a keyboard shortcut does the wrong thing, or nothing at all, a user stops trying the rest of them, even the ones that work fine, because the entire feature now reads as unreliable. That single bad experience costs more than the shortcut list was ever going to save that person in clicks. So the collision check is not a nice-to-have step in building this feature. It is the step that decides whether the whole feature is worth having.
I test this the plain way, not with anything automated: open the tool in an actual browser on an actual machine, trigger every bound key by hand, and confirm the tool's action wins over any default. It is slower than trusting a reference list, but a reference list goes stale the moment a browser ships an update, and I would rather catch a collision once, by hand, before launch than have a user discover it for me.
The Legend Every Tool Ships So Nobody Has to Guess
A shortcut nobody knows about might as well not exist. Every RAXXO tool binds the ? key to a small legend that lists exactly what is bound and what it does, and that single decision has done more for adoption of this feature than any individual shortcut choice. People do not read documentation for a free tool they just opened. They will press one memorable key to see what is available, especially once they notice similar tools use the same convention, and ? has become close to a standard for exactly this reason across a lot of web apps built for a technical audience.
The legend stays as short as the shortcut list itself, because a long legend defeats the same purpose a long shortcut list would. A handful of rows, each showing the key and a plain description of what it does, nothing more. No categories, no search box inside the legend itself, no settings for remapping keys. RAXXO tools are built for someone who wants to get in and get something done, not for someone who wants to spend ten minutes configuring how they get things done.
The onboarding screen I rewrote three times for OhNine covers a related lesson: a first-time user should discover a feature by using the tool, not by reading about it before they have touched anything. The keyboard legend follows the same principle from the opposite direction. It stays invisible until someone asks for it, with a single obvious key, instead of interrupting a first session with a tour of shortcuts nobody needs yet on their first visit. The feature waits for the moment someone actually wants it, which is usually a few sessions in, once the repetitive actions have already started to feel repetitive.
Bottom Line
Keyboard shortcuts are a feature nobody requests and almost everybody who stays long enough eventually benefits from, quietly, in a way that never shows up as a support ticket or a review. The discipline that makes them worth shipping is not the shortcuts themselves but the restraint around them: a frequency test that keeps the list under ten, a reversibility check that keeps destructive actions off a bare key, a collision check against the browser and the OS so a bound key never silently loses, and a single ? key that explains the whole system in one glance instead of asking anyone to memorize it upfront. None of that is complicated engineering. It is a short list of rules, applied the same way every time a new tool reaches this stage of being built, and the payoff shows up months later, in the fact that the people using a RAXXO tool daily never think about their hands leaving the keyboard, because they rarely have to.
Top comments (0)