Edwin Kofler's profile picture

Edwin Kofler

Semantic Hotkeys

Hotkeys are present in nearly all software. However, in my view, both software users and application developers do not realize the full potential of hotkeys.

I believe the full productivity of hotkeys can be unleashed through the concept of semantic hotkeys. First I’ll introduce some current problems with hotkeys, then I’ll explain how semantic hotkeys can provide a solution, and lastly, show what an implementation might look like.

Current Woes

The crux of my claims boils down to consistency. In one perspective, there are three costs of hotkeys:

  1. The cost of learning
  2. The cost of context-switching
  3. The cost of hotkey clobbering

The first cost is somewhat-inevitable, especially for large enterprise softwares like Blender or Houdini. Sometimes, this cost is rarely a consideration because it is easily amortized by ample use of the hotkeys themselves. But, with less frequently-used or non-unique applications, it is often not worth learning the hotkeys. The cost of learning hotkeys of a particular application is typically not proportional to the total time using that application.

The second cost deals with context switching among multiple applications (that have different sets of hotkeys). A high familiarity with each applications’ hotkeys can mitigate this penalty somewhat, but it will always exist. As applications with incongruent hotkeys increase, the cost of context switching will only remain high.

The third cost involves clobbering. This can occur in applications that provide an extension or plugin environment, such as VSCode or NeoVim. Hotkeys of extensions are often defined arbitrarily, usually just set for the sake of being set. This creates high potential for hotkey clobbering; such conflicts have to be resolved manually. Inconsistent conventions make learning new hotkeys, especially those defined within plugin-based environments, difficult.


An ideal solution involves constructing a set of shared keyboard shortcuts across applications. But, the meaning of those shortcuts mustn’t be domain specific; they must translate intuitively.

Introducing, semantic hotkeys:

The “physicalities”, “geometries”, and “commonalities” part of semantic hotkeys ensure that the semantics are intuitive enough to mitigate the penalty of context switching.

In contrast,

Confusingly, the shortcut Ctrl+P may mean print, previous, or project. Furthermore, users’ native tongue, keyboard, or keyboard layout may differ; these differences affect the intuitiveness and sensibility of the shortcut.

That is, more generally, semantic hotkeys are more resilient to any changes of the Human Computer Interface itself.

Lastly, Incorporating these shortcuts encourage interface designers to thing about making UI paths more explicit and cohesive, eventually improving UX.


An implementation may start by creating a program that outputs application-specific hotkey configuration (binding key to action) from a common configuration file.

A reasonable implementation assumes that each applicable application supports:

The keys h, j, k, l are a great starting point - they correspond to directions. More specifically, they move a cursor, selection, or item directionally within a particular context. For example:

We can generalize to include the following actions:

There are some other challanges:

This blog post mainly exists to explain the problem and solution - I don’t have a full “semantic shortcut system”. But, applying such a system will undoubtedly improve productivity, at least for me. I’m doing some preliminary work at github.com/semantic-hotkeys to apply this idea to everyday applications and websites. When its ready, you may find it useful, or employ a similar system in a program of your own.