Command Registration Service

[adambarlow]

Proposal: Command Registration Service

Summary

A pattern is emerging where application capabilities are being exposed via a common search experience at the top level of the UX. This search bar is often included near the title bar or within a command region, like the Ribbon. VS Code as well as other apps have adopted this pattern. In those apps it has been met with good customer feedback.

Additionally, many times these search regions utilize telemetry to make command suggestions. Sometimes they even utilize various flavors of AI to determine the set of items that are suggested. While I believe it would be advantageous to offer an 'intelligent commanding suggestion system' within WinUI, providing a common way to even register commands within an app seems like a logical first step.

TL / DR This feature proposal covers a command registration service, which is a first building block for more advanced 'command searching' and ' intelligent command suggestion' features.

Rationale

Creating this registration system would enable:

• Command search boxes
• Easier collection of telemetry associated with command usage
• Future ability to offer AI assisted command suggestions

Functional Requirements

#	Feature	Priority
1	API is straightforward and simple	Must
2	Takes as input UICommands, XamlUICommand, or StandardUICommands	Must
3	Can be utilized to create a basic command search box	Must

Open Questions

• What should the object model look like?
• What is the set of APIs we need available to offer the simple search experience?
• What additional APIs would we need to incorporate AI into the command suggestion experience? (future proofing)

[mdtauk]

Some way to know the current context (as in what item/element/control is currently selected) so the search results of available commands can be contextually relevant.

A friendly name for each command, so in XAML or Code Behind, you can easily populate ContextMenus, CommandBarFlyouts, and other commands, from the list of registered commands, and each command can have an icon glyph, keyboard shortcut, tooltip. automation name, etc. Which will apply wherever that command is placed.

This will probably need a settings store which manages each command that is added, which a search control (or possibly cortana voice commands) can surface to the user.

[adambarlow]

@mdtauk The friendly name, icon, shortcut, etc. is contained within our XamlUICommand, so that would be our solution for encapsulating those. It's a good question about what constitutes a 'command' there will likely be 'settings' or other types of capabilities that don't fit the object model of our XamlUICommand that will need to be considered. We have enumerated a few of these like toggle-able items as well as lists with one item that is selected at a time that might also need surfacing here. Good to keep these scenarios in mind as we move forward.

[mdtauk]

@mdtauk The friendly name, icon, shortcut, etc. is contained within our XamlUICommand, so that would be our solution for encapsulating those. It's a good question about what constitutes a 'command' there will likely be 'settings' or other types of capabilities that don't fit the object model of our XamlUICommand that will need to be considered. We have enumerated a few of these like toggle-able items as well as lists with one item that is selected at a time that might also need surfacing here. Good to keep these scenarios in mind as we move forward.

These things should be kept in mind as you add (and remove) items through the "Command Registration Service" and how they could be displayed when searching for the command.

In settings, the search results display an icon, this could be taken from the UICommand.

Office does the same thing

If there is some kind of context aspect to searching through the available commands - then you could choose to only show commands related to the current focus/selection - or perhaps show all results, but disable those not related to the context.

As to how to integrate the notion of context. Perhaps the service could have groups of UICommands, and then you "assign" a group name to a control which then allows the Command Search Box, to filter the commands it presents? So something like CommandGroupName = "ImageCommands".

[michael-hawker]

I guess this ties into #81 as well then?

I think a big challenge with commands like this too, is global keyboard shortcut registration. If the command as part of this system could enable a keyboard accelerator which could be intercepted from anywhere in the app to execute, that'd be super helpful. Right now, I have some issues with things in WebView or other text controls where I have to detect the keyboard input to re-implement my shortcut as the app doesn't get it for it's own shortcuts.

[mdtauk]

I guess this ties into #81 as well then?

I think a big challenge with commands like this too, is global keyboard shortcut registration. If the command as part of this system could enable a keyboard accelerator which could be intercepted from anywhere in the app to execute, that'd be super helpful. Right now, I have some issues with things in WebView or other text controls where I have to detect the keyboard input to re-implement my shortcut as the app doesn't get it for it's own shortcuts.

If the CommandRegistrationService included a global context notion, it could take the list of context aware commands, and enable or disable Keyboard Shortcuts that are applicable to the current context. Maybe there needs to be Global Command lists, as well as Contextual Command lists. The Context may be generic as well as specific. So if the current context object is an image, then the CommandLists with a SupportedContext of image - would become active.

When we group commands in this way, why not allow the future UWP Ribbon control #168 to have Contextual tabs display these commands in the same way Office display image layout controls when an image is selected?