Command palette

[vwkd]

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.)

[BBaoVanC]

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. The system mentioned here should probably run fine alongside the existing one, though, and it would be nice to experiment.

[vwkd]

Many new feature requests propose to add this UI element here and that UI element there. One thing nobody seems to think about is the total effect of all of these UI additions. The UI will inevitably grow more complex, more hierarchy, more places to go, more things to click, etc. pp. "More, more, more".

I think a command modal offers even more advantages than just the more intuitive and logical behaviour argued in my original proposal. A command modal can be used:

• From anywhere

  One doesn't have to go someplace deep in the UI first.

• Faster

  One doesn't have to go someplace deep in the UI first.

  There is a keyboard shortcut available and commands are autocompleted.

• Easier

  One doesn't have to go to different places each time. One doesn't have to interact with different UIs each time.

  There is only a single keyboard shortcut to remember: how to open the command modal. From then on everything uses more expressive textual language like invite @user to #room instead of an arbitrary keyboard shortcut like CTRL/CDM + XYZ. The UI can show helpful hints like suggestions and autocomplete commands while using keyboard shortcuts is driving completely blind.

• At no cost

  One doesn't have to invent new UI to add a new functionality. All it takes is to hook up the logic to a new command. No new UI to create, no old UI to maintain. Cinny can evolve much more quickly!

  One doesn't have to invent complex UI to add complex functionality. Commands can be as advanced as desired. Cinny can become mighty powerful!

Maybe you recognise, these are some of the very same advantages that a terminal has over a GUI.

I think VSCode is a great inspiration here. Complexity is neatly tucked away in commands, which are easier for power users that use keyboard shortcuts and nicer for simple users that don't get overwhelmed by UI. It reminds me of the principle to "Make simple things simple, and complex things possible.". It makes life easier for everyone!

I'd hate to see Cinny end up as cluttered as Element. There is value in staying simple and minimal.

Cinny can stay as beautiful as it is yet become even more powerful than Element!

[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.

[kfiven]

I am not sure how this could be implemented. We have commands that are room specific or input specific (emote cmds, op, ban, spoiler, rainbow etc) and then we have commands that work globally (display name, profile pic, join/leave rooms/spaces).

So creating modal means that we are putting these room specific on a global level.

If we leave room specific in msg input and make modal with rest then there will be two places for cmds.

Having them in as they are right now is also confusing.

[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

2) 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.

[williamkray]

i think that, while i don't disagree that a modal would be a nice user interface, the original argument is flawed. there are lots of chat programs, going back as far as many IRC clients originating in the 90s, that use the paradigm of commands sent in the same field as the message composer.

"this is how it's always been done" is not usually a good argument for anything, but in the sense of ingrained patterns and recognizable interfaces, lots of features carry on simply because there are old-timers who are used to doing things that way, and that doesn't mean we should get rid of them. even the idea of using # to designate a comms channel is a holdover from IRC.

[vwkd]

@williamkray It seems you are speaking for a small minority of the population that’s familiar with older messaging services. None of the most popular messaging services I’m currently aware of (Facebook Messenger, Instagram Messages, WhatsApp, Android Messages, Apple Messages, Slack, etc. pp.) overload the input field. I find it hard to imagine they could ever do. Contrary to your comment, the majority of people doesn’t actually use input field overloading. And my argument is that it wouldn’t want to.

I see the Matrix ecosystem slowly stepping out of being a hobby project for the niche. Beeper is as far as I’m aware the only and coincidentally (?) first commercial Matrix client that tries to cater to the broader population. Coincidentally (?) it is the first to have had a Command Palette. I think Element recently added one too, coincidentally (?) as they seem to get away from being directed by technical developers like Matthew. Again, it seems that being commercial makes you think about what the majority of users actually wants since your value depends on that which then determines your existence.

Of course, it’s up to Cinny to decide which users it wants to cater to - if it ever wants to be useful to the broader population or stick to a small minority of highly technical users. I assumed Cinny wanted the former, but I might be wrong.

[williamkray]

@vwkd slack and discord both use the composer field to support "slash commands". slack has recently implemented a popup over the composer when using them, but you're still typing commands into the composer field.

Coincidentally (?) both slack and discord are commercially successful, and are the most commonly drawn parallels to matrix/cinny.

[williamkray]

relevant conversation happening in the cinny room:

[ribosomerocker]

If my feedback was to mean anything, I'd say a command pallette would definitely be possible to implement and furthermore it would be a very nice improvement. for the people who prefer IRC-style commands, I dont think they'd be left behind by this feature, because I imagine that normal commands would still be usable, it's just the command pallete is much easier to work with. In every app I've seen that uses a command pallete, it allows a textual way to invoke it first, if you dont want to go through that menu.