Thanks for sharing this! I find these kind of articles very interesting, as they go really deep into the analysis behind product development. As for the feature itself, as other people have already mentioned, I think it depends on whether your users are more accustomed to GUIs or CLIs. Personally, I prefer the latter so I'm definitely biased.

We are trying to present GUI users with good arguments for a switch. Our tests with people that are unfamiliar with CLIs showed they were up to speed after a short amount of time.

I'm very confused by the fact that this page itself does not have a visible focus style on interactive elements, making it very difficult for somebody who navigates the web with a keyboard to see what they are clicking on. I could not tell even if all the links on screen were actually reachable by tab key.

Maybe I've missed the point, but there are people who use they keyboard exclusively when navigating a web page already, and I would think accessibility for those people would be a big consideration in what you are doing.

You are right, I created a ticket for this to be fixed in the next release!

Interesting, particularly useful for power users and high frequency usage products.

Have you researched which applications have the highest penetration of keyboard usage and why? Afaik most users even on desktop apps (e.g MS office suite) can only retain a handful of shortcuts. What's your strategy to train users to have a fully keyboard based navigation?

Btw did you use any open source library to manage keyboard shortcuts?

We have not found any reliable numbers on keyboard usage vs mouse input yet, but it would be quite valuable.

Compared to normal shortcuts the commands are easier to remember, because they mostly represent the verb for the action you want to accomplish. Instead of memorizing Ctrl + E or similar for a new article, you type /write or an alias like /new. This way you only have to know what actions are possible, without connecting them to an inconclusive key combination. Most commands will auto-complete after the first two letters, so you are not losing that much time either.

Our frontend is build on Vue.js and the shortcuts are handled by global JS events.

A big issue here are mobile/touch devices.

You don't want to force your users into keyboard driven interaction there.

But as decent mobile support is almost a requirement nowadays (even if just inside the browser), you end up with two completely different interaction designs and would require users learning everything twice.

That's definitely something we have to look into. We currently see mobile usage primarily for searching and reading and less for creating content. But you are right, this needs special attention. We do not want to maintain two different approaches.

Please add a language selector so I can read the website in English. Or maybe lose the German localization altogether.

As a German native speaker, I find the German translation quite difficult to read.

You can change that on the account settings page. https://emvi.com/account

In case you're talking about our blog, you need to change your browser language :3

Using slash ("/") for commands can slow down many users not on QWERTY keyboards because "/" requires one to press shift (e.g. QWERTZ or AZERTY keyboards)

Good point. We are on QWERTZ aswell, so we are thinking about making it customizable at some point.

I understand you will like this if you like command line interfaces.

We showed it to some people who are unfamiliar with command lines and they liked it. It's just that most non-technical users never encountered an interface like this, but they do like it if you show them how it works. This is why we're going to add an interactive tutorial.