Do we have any other shortcuts exposed in dialogs to be consistent with the styling of, or is this treading new ground? (Nothing springs to mind, but...)

Also, if we’re exposing the shortcut for one option, should we maybe add a shortcut for the other one as well? ‘Ctrl-alt-v’ or similar, for always-convert?

In T196789#4268512, @DLynch wrote:

Do we have any other shortcuts exposed in dialogs to be consistent with the styling of, or is this treading new ground? (Nothing springs to mind, but...)

Yes, open the save dialog, and press Enter in the summary field. You'll get a note informing you to use Ctrl+Enter to save.

Yes, open the save dialog, and press Enter in the summary field. You'll get a note informing you to use Ctrl+Enter to save.

This is slightly different because we are using mw.notify in response to a user keyboard in put. In this case there is no second event on which to fire an mw.notify, so we'll need a different design.

Also, if we’re exposing the shortcut for one option, should we maybe add a shortcut for the other one as well? ‘Ctrl-alt-v’ or similar, for always-convert?

Yes, I considered this - sounds like a good idea. Image editing software tends to have multiple paste shortcuts, but we should check for browser conflicts.

Something to consider:

In this design we'd probably want to capture these shortcuts while the dialog is open in case the user thinks they need to use that shortcut to choose that option.

A variant on that, which I think is probably overkill, would be to use the key styling from the help dialog:

Yeah probably not neceesary, we don't use that styling outside of that dialog, for example in toolbars:

Including shortcut keys in buttons

Thinking about it, it's essentially the same as the toolbar setup (tools are quite button-like), but just with a different layout (vertical vs horizontal):

Change 444008 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/VisualEditor@master] Show and capture paste triggers in wikitext conversion dialog

https://gerrit.wikimedia.org/r/444008

Screenshot of Ed's patch:

I think this would be useful and rather unobtrusive. @Deskana Are you okay with this proposal?

What does it look like on mobile? Aside from taking up extra screen space, these shortcuts also wouldn't be much good to a mobile user who doesn't have a keyboard?

I'm still very hesitant to add shortcut keys to buttons like this. @Pginer-WMF What do you think?

In T196789#4402767, @Deskana wrote:

I'm still very hesitant to add shortcut keys to buttons like this. @Pginer-WMF What do you think?

If the issue is the dialog interrupting users, I'd try to make the interaction less interrupting instead of adding more information layers for the user to figure out how to avoid the interruption.

Instead of interrupting users with a choice, a more fluent interaction would be to apply the default approach (e.g., paste with format) while surfacing the alternative as a possible follow-up action. With that approach, (a) if the result is expected you can continue without further effort, and (b) if the result is not what you wanted, you have a clear path to fix it.

I illustrated some possible approaches where rich text pasting is provided by default, and the possibility to paste without format is announced after the action is completed in a non-blocking way:

A) A panel appears at the bottom (goes away if the user keeps typing)	B) A contextual action appears next to the pasted paragraph (goes away if the user keeps typing)	C) A message surfaces the shortcut to paste without format (goes away after a few seconds)

I created a quick animation to illustrate the first approach. These are just some examples of the idea, but it can be executed in many different ways.

The proposed solution in the ticket tries to avoid the interruption by proposing an alternative for users to learn, and readjust from a very well stablished shortcut such as pasting. Surfacing keyboard shortcuts for advanced users to go faster makes sense, but I don't think it should be required to avoid this interruption.

Also, by looking at F23364768, it is not clear to me what "Ctrl+V" is doing. Is it (a) showing the dialog to chose an option, or (b) is it converting to wikitext directly?

In T196789#4402767, @Deskana wrote:

What does it look like on mobile? Aside from taking up extra screen space, these shortcuts also wouldn't be much good to a mobile user who doesn't have a keyboard?

We should disable on mobile, like we do with toolbar shortcuts, should be easy enough.

Thanks Pau, I think we both discussed this option at the time and I don't really have any strong objections to it. Both approaches (dialog/fixup) have their merits (for example the dialog is more intrusive, but gives less preference to either option). In the end the dialog seemed to be more feasible technically, and we wanted to get something in place for users to try out. With this issue (adding the keyboard shortcut) I am not ruling out trying this different approach in the future.

Also, by looking at F23364768, it is not clear to me what "Ctrl+V" is doing. Is it (a) showing the dialog to chose an option, or (b) is it converting to wikitext directly?

It's both. Pressing ctrl+v will choose the option, and in future show the dialog that allows you to use rich paste. Primarily the labels are to let the user know about the lesser-known ctrl+shift+v.

In T196789#4408679, @Esanders wrote:

We should disable on mobile, like we do with toolbar shortcuts, should be easy enough.

Actually VE source mode (2017 WTE) isn't available on mobile yet, but we can disable them anyway in preparation.

Just to add a few points in defence of the current approach (although again, I think both have their pros and cons):

• The fixup approach requires us to choose a default action, which could lead to disagreement over what that should be.
• The dialog approach is more disruptive but:
  • Paste is not an action you are likely to be performing frequently and repeatedly (and if you do, the extra shortcuts can help)
  • The dialog pattern may be familiar to users from Excel and other places.

In T196789#4408758, @Esanders wrote:

Thanks Pau, I think we both discussed this option at the time and I don't really have any strong objections to it. Both approaches (dialog/fixup) have their merits (for example the dialog is more intrusive, but gives less preference to either option). In the end the dialog seemed to be more feasible technically, and we wanted to get something in place for users to try out. With this issue (adding the keyboard shortcut) I am not ruling out trying this different approach in the future.

Thanks for providing context, Ed. Checking with users an initial approach, observing their behaviour, and iterate based on that, makes perfect sense. With a better idea on the actual impact in their workflow, it may be easier to decide whether to spend more technical resources on this. Measuring how many people are seeing the dialog, and how many of those select each option, may be also a useful data point to consider.

In T196789#4408786, @Esanders wrote:

• The fixup approach requires us to choose a default action, which could lead to disagreement over what that should be.

Just some considerations about this. Ideally we would choose the most frequent action, so that most users have a better experience. But even if each option were preferred by 50% of the users, I think it is better to have a solution better for some of them if the situation for the rest is not worst than the alternative.

In a 50-50 scenario the fixup approach would provide half of the users with the result they want directly. The other half would have to go through a decision point just as they would with the dialog solution, but with a simpler decision process: just one option to chose from instead of two, and the same opportunity to communicate the keyboard shortcut to make things better the next time. The dialog option is more neutral, but that means not to provide the expected result (initially) to 100% of the users.

Change 444008 abandoned by Esanders:

[mediawiki/extensions/VisualEditor@master] Show and capture paste triggers in wikitext conversion dialog

Reason:

https://gerrit.wikimedia.org/r/444008