gitter-shortcut-review.md

Gitter Shortcuts

I have several pieces of feedback on the shortcuts. The most significant feedback is that, with keyboard shortcuts, staying within conventional "vocabulary" is vitally important. When you use a web browser, any web browser, you can rely on Ctrl-Tab moving between tabs. Even more broadly, in almost any application regardless of purpose, you can rely on Cmd-N to open a "new thing", be it a document, a window, a message, or anything.

Keyboard shortcuts are productive because of these conventions. Gitter appears to eschew almost all conventional shortcuts for analogous actions, and this is a large problem. There are three obvious examples of this:

• Cmd-Ctrl-C focuses chat input. If we look at other chat applications, we see that there are several very standard solutions to this user action. The most common is that the chat field simply always has focus. Gitter does special things with text selection though, so it's fair to say that this might not be an answer. This leads us to the few communication tools which don't auto-focus the text field (e.g. Wave). In this case, the "focus the chat field" shortcut is designed to be the simplest, easiest to hit and most "obvious" interaction in the entire application. For Wave, the chat box focus key was Return. It's the third-easiest button to hit on an American keyboard, and it is highly evocative of the standard shortcuts associated with other message actions (specifically, sending a message). Cmd-Ctrl-C is not evocative of anything other than Emacs.
• Cmd-Ctrl-Up/Down navigates the left panel. This action has two problems associated with it. First, conventional chat clients treat separate conversations as separate tabs, which immediately taps into a standard vocabulary familiar to all users of web browsers: Ctrl-Tab, Ctrl-Shift-Tab, and on Mac, Cmd-Shift-[ and Cmd-Shift-]. Gitter eschews this convention, and makes matters even worse by introducing a modal user interaction! You must first select the conversation you want, and then use a separate shortcut to activate it. It's very unclear what happens in this mode when you just give up and use a mouse (in fact, the UI gets effectively "stuck"). Modal interactions, in general, are confusing and tedious for users. Modal interactions combined with non-standard keyboard shortcuts when standards exist and can be reasonably expected (Cmd-Shift-] was the first thing I tried!) are absolutely anathema.
• Cmd-Ctrl-1 (and friends) select the indexed conversation in the sidebar. Note that this is an immediate selection (it does not require Cmd-Ctrl-Enter), which is fundamentally inconsistent with the "other" way of selecting conversations. Additionally, here again there is a standard vocabulary for dealing with this class of user action: treat the sidebar entries as tabs and use Cmd-1 through Cmd-0 (Ctrl-1 through Ctrl-0 on Windows/Linux). This is the same convention used by every chat client and every web browser (except Safari).

Familiarity, convention and consistency are the glue that makes keyboard shortcuts work in the first place. Gitter eschews all three of these, and sacrifices a massive amount of usability.

Discoverability

As far as I can tell, the only way to even find the set of keyboard shortcuts in-app is using Cmd-Ctrl-K, which is another non-standard keyboard shortcut (Shift-/ is conventional almost everywhere, but particularly noticeable in web apps) and in fact a shortcut which you could not possibly discover in application except by trial-and-error! This is the absolute worst faux pas a UX designer can make: building a class of functionality which cannot be discovered without outside help.

A more standard shortcut should be used here (I do recommend Shift-/, since the chat field is not auto-focused and thus this sequence is available). Even more importantly, "Show Shortcuts" should be a menu item somewhere.

Chording

Experiment time! Take a person with an average sized hand and a Macintosh keyboard. Have them remove one hand from the keyboard and use the remaining hand to hit Cmd-Ctrl-5. The results of this experiment should tell you something very important. Namely, this is a completely unusable key chord without multiple hands. I have exceptionally large hands, and I can barely hit this combo. Most people I know would be completely unable.

Key chords are important, because they open up expressive power beyond the "single-modifier" shortcuts that make up the basic and most fundamental actions (more on this in a moment). However, they must always be very, very carefully designed to be usable without causing cramping in the extremities. Particularly when one expects users to employ these key chords on a frequent basis (e.g. switching between chat rooms).

At present, out of all of its keyboard shortcuts, Gitter only has four chords which are sanely usable with a single hand by the average human being:

• Cmd-/
• Cmd-Enter
• Cmd-Ctrl-C (which has other problems, as previously mentioned)
• Cmd-F

Here's the really serious problem though: Gitter is using key chords with multiple modifiers for common actions where there are not previously-existing, more common actions taking the simpler forms of the shortcuts! Obvious example of this: Cmd-Ctrl-Up/Down is the way in which you select sidebar items, but Cmd-Up/Down isn't being used for anything! This runs into conventionality issues of course (Cmd-Up/Down should scroll the main pane), but the point is more that a chord was used when a simpler shortcut would have sufficed. This is similarly a red flag for the Cmd-Ctrl-C shortcut. Of course, you can't just use Cmd-C, but this is why it's a red flag! Cmd-C is a text manipulation command, which is a very different class of user interaction than giving focus to a text field.

Chording is not innately wrong, but it should be considered a second option behind single-modifier shortcuts. And absolutely critically, all chords must be very carefully designed to be as ergonomic as possible.

Hear, hear. The keyboard usability of Gitter is killing me. I'm glad you took the time to write this out. I hope someone read it, but there's been seemingly no improvement in a year (in fact some regression in Gitter Next, but that's forgivable).

I hate to invoke Slack to Gitter team, but honestly, they have nailed this.

Sadly, we don't have the same resources at our disposal, our total team size is 9, vs hundreds. We hope to grow the team later this year and can spend some more time outside the core of the product.