Save tag settings menu data on ctrl/cmd + s

[ErisDS]

We've got ctrl/cmd+s in lots of places now (see #4369 or #4414).

Let's add it to the tag settings menu as well :) Even though we're going to make it auto save (see #4500), for those of us who hit that shortcut instinctively it feels nice if it works consistently everywhere.

[naz]

✋ Would be happy to do it.

[jaswilli]

#4517 specifies that the save button should be removed. It feels wrong to me to switch to auto-save and remove the save button but still put in a keyboard shortcut to save.

[JohnONolan]

Completely agree with Jason

[ErisDS]

I raised this issue because I hit ctrl+s instinctively all the time. Having this supported everywhere else in the settings panel has trained me to continue this behaviour inside Ghost, and without it, I get the browser save dialog.

I think if we support ctrl+s in one place it should be supported everywhere for consistency.

[JohnONolan]

Cmd+s within is a settings panel is not a common UX convention - this isn't consistent behaviour, it's just incorrect. It's like me arguing that Cmd+s works within my text editor so it should work within my system preferences settings panel. Nothing to do with lack of consistency, they're totally different workflows.

[ErisDS]

cmd/ctrl+s works on settings/users/user, and settings/general which are settings panels, and it also works on the post settings menu which looks the same as this tag settings menu.

What makes this workflow so different?

[JohnONolan]

What makes this workflow so different?

Those pages have save buttons and this doesn't.

[ErisDS]

The PSM does not have a save button - the editor does, but the PSM doesn't. Further, the whole problem with keyboard-save is that I don't even look or care to see if there is a save button on the screen I'm on. I fill out a field and hit cmd/ctrl + s - that's my natural trained behaviour (and I'm certain I'm not alone).

Whether a screen has a visual indicator that save is possible or not doesn't affect this behaviour. If I can fill out a field, I ought to be able to press the keyboard shortcut to save it.

[naz]

that's my natural trained behavior (and I'm certain I'm not alone).

I am with you on this one @ErisDS 👍

[JohnONolan]

You are conflating your own habits with default behaviour. The two are not synonymous.

A keyboard shortcut provides a mechanism to activate a form submission element, not a form input. As the settings menu has no form submission button, it makes no sense at all for there to be a keyboard shortcut to something which doesn't exist and isn't available to users who are only using their mouse (or finger).

Again: There is no save button on a preferences dialogue on your Mac, and there is no keyboard shortcut to save the settings there. However almost all settings dialogues have input fields. They are not the same workflow.

[JohnONolan]

I have no problem with globally disabling cmd+s so that the browser dialogue doesn't pop open, for the record. That functionality has no real place within a web application anyway.

[ErisDS]

it makes no sense at all for there to be a keyboard shortcut to something which doesn't exist and isn't available to users who are only using their mouse

We already have other examples in Ghost where this is true - for example cmd/ctrl + backspace to delete a post on the content screen. Users with a mouse aren't able to delete from that screen - keyboard warriors are.

There is no save button on a preferences dialogue on your Mac, and there is no keyboard shortcut to save the settings there. However almost all settings dialogues have input fields. They are not the same workflow.

Pressing ctrl/cmd + s in these scenarios causes a 'beep'. Pressing ctrl/cmd + s anywhere in the browser where the shortcut isn't handled through another mechanism causes the browser save dialog to appear, forcing me to perform an additional action to get myself out of the dialog.

This is absolutely infuriating, because I have already been trained by Ghost that using cmd/ctrl + s is a safe action on every other screen where there are editable values. To have one single screen where I can edit properties but cannot use cmd/ctrl + s is completely inconsistent with every other screen in Ghost that has editable values, and creates a jarring experience for those using their keyboard.

[JohnONolan]

As I've already said: I have no problem with globally disabling cmd+s so that the browser dialogue doesn't pop open. That functionality has no real place within a web application anyway.

The entire point of autosave is to move users away from even thinking about saving as something that's necessary at all, and to remove the need for save buttons in future as we build a proper client-side application, not web-page. Providing crutches like this absolutely does not aid that goal and absolutely does damage it by encouraging incorrect user behaviour with positive reinforcement.

[ErisDS]

I think we cross-posted - didn't see that comment while I was writing mine. Let's globally disable ctrl/cmd + s on all screens in Ghost that don't have a save button, and then remove the save action from the keyboard shortcut at the same time we remove the save button moving forwards?

[JohnONolan]

+1 sounds good

[novaugust]

Should be as simple as adding a keyboard shortcut to the application route that is a noop. From there, any child route that does use ctrl/cmd+s just adds the "save" action like normal