Command palette

Is your feature request related to a problem? Please describe.

To me it seems a foreign idea to type in a command into the chat box of a specific chat. A command acts on the client and has nothing to do with a message in a specific chat (with the exception of “Autofill commands” which are rather text aliases than commands). This is a typical example of functionality overloading. One input is overloaded for two completely different things. It’s as if in VSCode I’d write commands into the currently open editor and execute it by pressing “save file”… It doesn’t make sense.

I always hesitate pressing “Enter” on a command since my intuition worries that it could be sent as a message into the chat. I don’t think this is the fault of my intuition. I’m glad I have that intuition which prevents me from sending messages out into cyber space without a guaranteed way of getting them back. The overloading of commands mess with that intuition. I can’t assume anymore that everything I type into that chat box becomes a message in the chat. I end up typing things into the chat which I wouldn’t want to become messages in the chat. Btw. changing the appearance doesn’t make the wrong place suddenly right (https://github.com/ajbura/cinny/issues/129#issuecomment-932660870).

I’ve never used IRC and instead grew up with messaging apps. I can understand if this is the traditional way that commands have been implemented. Maybe in the earlier days it was just easier to deal with a single input field instead of two? I don’t know. But nowadays those constraints should be gone since websites can be full fledged applications.

As a new client, Cinny has the opportunity to rethink things. Element sticks to the old route as usual. I’m glad Cinny does many things differently. I think here Cinny could do things differently too. If Matrix is to take over the world, then many young people will come from messaging apps which are unfamiliar with commands. For them the old way doesn’t make much sense.

There are more problems with overloading one thing for two unrelated jobs than just being unintuitive and illogical. Not interpreting a file path as a command #65. Not sending typing notifications when typing commands #81. This list will only grow. It should be clear that overloading just isn’t the right way to go here. You can try to fix the ever growing list of issues that crop up or you can fix the one underlying issue that causes all them crop up in the first place.

Describe the solution you’d like

A command modal which can be evoked using a keyboard shortcut instead of overloading the chat box. References include VSCode Command Palette or GitHub’s Command Palette (at time of writing still in Preview).

One could consider making the command modal part of the search modal depending on the first character like VSCode (CTRL/CMD + P and >) and GitHub (CTRL/CMD + K and >) do. The issue is that one has to add an escape when searching for something with that first character. It is again overloading of one input for two separate things - search and commands. Instead, two separate modals invoked by two separate keyboard shortcuts should be used. To switch from one to the other using the same keyboard shortcut as to open the other. The two modals can still look the same, be at the same position on the screen, etc. Now it makes sense to use some colouring to differentiate them.

Another benefit of a modal is that it can use the whole screen real estate and doesn’t need to hijack space at the bottom of the chat box.

Note, on mobile there needs to be an UI element somehow that’s accessible everywhere because mobile lacks keyboard shortcuts. A button in the main menu (whatever that will be when Cinny gains mobile support) seems best to me since the main menu is the one thing that needs to be accessible everywhere already. It could be right next to the search button for #132.

Note, the “Goto commands” should probably be part of search #132

Describe alternatives you’ve considered

None.

Additional context

The History of Command Palettes: How Typing Commands Became The Norm Again

(Note, this refers exclusively to client commands, not bot commands within the chat. It would actually help distinguish bot commands from client commands if I knew that everything I type into the chat box becomes a message in the chat.)

[daemonspring]

My experience of using the Atom text editor, with its command modal, makes me strongly agree with this idea. Atom also lists shortcut keys next to the commands it lists as you type, so it’s a natural way to find and learn shortcuts.

Vivaldi Browser has a search box in the settings page which, while not actually being part of its command modal, demonstrates how increasingly complex settings pages can be made manageable. This kind of feature could naturally be integrated into a command modal. Fuzzy search improves this further.

Both of the above applications are excellent design references.

A quality command modal could honestly replace most of the interface and normal navigation for me. I like it when I can stay purely on the keyboard and it’s the slickest way I’ve seen applications make that possible. Certainly beats just having shortcuts, and it’s nice to have a big comfy input overlayed on the interface than squish the autocomplete options at the bottom.

Currently, I can use /invite and a menu opens to search for/select people. I think it’s better to use a more generic autocomplete system rather than open special menus. In addition, instead of the normal interface buttons opening those special menus, they could instead open the command modal with the appropriate command already partially filled and just rely on the autocomplete. This is a natural way to introduce people to using commands while unifying the way the UI works.

In general, I think it helps to design programs first around command line style input, then layer graphical design over the top when it’s most helpful (e.g. sorting pins would certainly be easier with a mouse than commands). Text-first also especially makes sense for a chat client.

Most of my interactions with cinny have something to do with a named thing. The more people I meet and rooms I join, the more efficient it becomes to type names than click through nested structures. For example, to get to cinny’s room I’d like to do this: ctrl+shift+p #cin tab enter

The system mentioned here should probably run fine alongside the existing one

Just be careful to completely migrate away from the message box if a command modal gets fully implemented:

• Simplifies message box behaviour
• Avoids potential leaks of private information if the command system gets expanded: Imagine commands which take room/user name arguments being posted accidentally

It’s best to make a complete switch at an appropriate time rather than let users continue to use a riskier method by habit.

I don’t think it should be too confusing about whether you’re going to accidentally send a command since it outlines the box in green and says you’re in command mode.

Emoji-autofill is also a green outline. Nobody is going to be actively reading those parts of the interface when a mistake happens, so any visual distinction needs to work in the peripheral vision. A command modal that overlays the UI and maybe even greys it out very clearly indicates your focus has shifted away from chat to a more global context.

I think the more important problem than the visuals though is using a printable character to trigger command mode. This introduces complications like having to escape / in messages and making mistypes more likely than if commands used a shortcut like ctrl+shift+p like Atom does, or something else not easily mistyped.

I think smart stuff in the message box ought to be restricted to actions that modify the text in the box. No side-effects.

[daemonspring]

Solution

1. Modify commands so they can take arguments that will fully specify the context:

I’m currently DMing Alex, and we both like baking, so I want to invite Alex to a couple of relevant rooms

invite @alex_54:matrix.org #flapjackland
invite @alex_54:matrix.org #bakeranons

1. When arguments are not supplied, implicitly fill them in from the context:

I’m chatting in #cookiemadness and I suddenly remember I forgot to invite Alex here too

invite @alex_54:matrix.org // no room supplied, so assume it's #cookiemadness, the currently active room

You could apply that back to the first example too:

invite #flapjackland // In a DM with Alex, we can assume the target user is `@alex_54:matrix.org`

Analysis

From the first example you can see that the desire to invite someone doesn’t always occur in the target room. It may even be more likely to occur away from the target room because that’s where you meet people who might be invited. Being strictly tied to the active room being the context is thus quite limiting.

Using a global command modal doesn’t stop you using the active room for context. The global context includes the active room. But it also includes things like the full list of rooms a user has joined. People know the context in which they invoke the command modal, so it’s quite natural to implicitly fill in arguments, or supply autocomplete suggestions that are weighted in favour of the currently active room etc.

If you want to make it more explicit which implicit arguments will be filled in, you could indicate what will be automatically chosen with some muted text in the input where the implied argument should be.

Suggestion

It’s probably better to start by trying to make an autocomplete list first. You can replace the existing search box that comes up when you run /invite with something that supplies a shortlist of names as you are typing.

This is a good opportunity to think about the context the application provides:

• The shortlist shouldn’t include users who are already part of the group being invited to
• Users in the currently active room should be preferred, followed by users in rooms the user has joined

Once you have a good autocomplete, it’s a lot easier to add arguments to commands in a way that feels good. Typing @alex_54:matrix.org would be a pain, while typing alex tab would be a breeze.