Designs for the Keyboard Shortcuts page and Overlay

[maria-komarova]

Pop Shell will introduce new keyboard shortcuts for easier window movement and management. The overlay with keyboard shortcuts will display desktop keyboard navigation shortcuts to aid users can't or don't want to use the mouse. It shows on a long press of the Super key. Along with the overlay, there are designs for the update of the keyboard shortcuts page in Settings.

1.The first design shows the first view of the page - a user sees the categories of shortcuts. There is a setting at the bottom of the page where a user can toggle the overlay on and off.

2. The view of the page with one of the categories expanded to show the list of shortcuts. The new design allows to have multiple shortcuts under each action. For example, to have shortcuts that use direction keys along with their alternatives.

3. There are system shortcuts and custom shortcuts. They have different customization levels. Below are the designs for the dropdown menus for each shortcut. System shortcuts can be reset to default (in some cases) or disabled. You can also add another shortcut to an action.

A user can add another shortcut to an action associated with the custom shortcut. Custom shortcuts can also be removed. When there are multiple shortcuts a user has a choice of which set of keys to remove. Once a user is down to one set of keys, the wording changes to simply "Remove", as shown below.

A user can change a system shortcut to customize it by selecting a shortcut and clicking on it (see hover state shown below). To change a shortcut, one should simply type a new set of keys for the shortcut in the input field.

The next design shows the messaging if one of the shortcuts is already taken by another one. The message is the same as in the current design.

To add a custom shortcut, a user should specify the name, the command, and the shortcut itself. A user also has an option to specify the category where to place a shortcut and an application, if a shortcut is related to one. The screen below shows those two fields pre-filled - those fields should always be set to "custom shortcuts" and "none" by default to make sure a user can leave them unspecified.

The last screen shows how to list the search results - very similar to how it currently works.

Two designs for the overlay for the light and dark theme:

[brs17]

A few comments/questions/concerns:

GNOME Settings

General

• If all of the shortcuts are removed for a specific action, what does the menu pop-up show?
• I find it a tad odd that some settings are available via the hamburger menu and others require clicking on the shortcut itself. I am not sure it is clear/obvious that the shortcuts are intended to be clicked.

Change Shortcut pop-up

• The "Change Shortcut" pop-up does not provide instructions for how to set a keyboard shortcut. A textbox is shown which may lead people to think they need to be written out.
• In the design, when the pop-up shows the message that the "key combo is in use", there is no affirmative ("Save") button. Is that intentional?
• Is there a reason not for just reusing the "Set Shortcut" dialog?

Create custom shortcut

• What is the intended purpose for the "Application" field? To my knowledge this is a new field, what are the benefits?
  • Will all shortcuts have this "Application" field set?
• Will the "key combo already in use" error message appear on this dialog as well?
  • Should we also make checks for the "Name" or the "command"? If the keyboard shortcuts can be rearanaged, we may want to provide warning or intelligently deal with duplicates as it will be more difficult to notice the creation of a duplicate.

[maria-komarova]

Responding to the comments above.

General

• If all the shortcuts are removed for the custom shortcut, the shortcut is entirely removed, the way it works in Settings currently. If all the shortcuts are removed for the system shortcut and the shortcut is disabled, the menu looks as follows: If a shortcut was disabled by default, then the menu should simply show "Set shortcut".
• You are right, it might be confusing. After thinking more, all the functionality for the shortcut can be embedded in the menu:
• The design for setting the system shortcut (if it is or was disabled):

Change shortcut

The designs below should cover the raised concerns about the instructions. The absence of the button was an accident. The reason for not reusing the current window is because from my conversations with users and observing people's reactions, majority find the window to be somewhat confusing, especially those who see it first time. We at least need to include the buttons for canceling and saving the shortcut instead of the current instructions to press Esc or Backspace to either close the dialog or disable the shortcut.

Create custom shortcut

I changed the design for creating a custom shortcut. The following mockups show the flow for setting one. The application field helps users to set a shortcut to launch a frequently used application. When one selects an application from the dropdown, the command field for launching the application automatically populates. Some commands are extremely difficult to guess and with addition of the Flatpak, guessing or knowing the commands will be even harder. The duplicate message for the key combination would appear on this window as well:

[brs17]

Thank you for those updates @maria-komarova . Looking at what the "Application" field does, I have two additional thoughts:

1. Why not just integrate the dropdown application selection into the "Command" field? I might think this would make it more clear what selecting an application will do (instead of selecting an application and it changing content on another row)
2. For what it is worth, this part does feel a bit like a stretch goal, and not something necessary upon release.

[maria-komarova]

Thank you for the feedback @brs17.

1. It would make sense for the application-related shortcuts. But the dialog is for all custom shortcut so my worry is enabling users to still type the command in the field for non-application shortcuts. The idea is that you can leave the application field at "none" but if it is a dropdown in the command line, then it should still function as the input field - gets a little clunky. But maybe I am overthinking.
2. It might be a stretch goal, but I need to plan for that. Especially since it seems to be one of the pain points, even if relatively minor.

[brs17]

@maria-komarova, what I was envisioning was that the "Command" field can be filled in with a combination of text input or from the dropdown. If an application is selected from the dropdown, it appends the command required to launch such an application to the end of the "Command" text field. I don't see that as being clunky.

[isantop]

@maria-komarova We can do a ComboBoxText widget with an entry, which allows the user to type or select to pre-fill text from the dropdown menu. I can mock this up for you if you'd like to see it live.

[WatchMkr]

The ComboBoxText widget doesn't work in this use case. You can't start typing "pop" to create a shortcut for Pop Shop. It won't find "io.elementary.appcenter". Typing in the box would yield inconsistent results (filling out an app name if you guess the command correctly and nothing when you don't).

We have a couple options. First, fill in the command text box with the command of the chosen application and grey out the entry. Second, don't grey the entry and allow the user to append flags to the application command.

I prefer the second option because it seems harmless to let the user append something to the command and if it greys out, and they want to append something, they won't have to write down or remember the command. I'm also not sure what's gained if we grey out the box.

[WatchMkr]

Do you guys think changing the application list default text to “Choose Application (optional)” would help?

We’ll build mockups to test the UX as well.

[maria-komarova]

I have done a round of usability testing with 6 users. None of them had any particular difficulty or confusion about the application dropdown. Some of them found having a pre-populated command helpful, especially the non-power users. Power users were more concerned with being able to edit the command once it appears in the corresponding input field. But they also found it useful to have a command shown to them. I have excerpts with quotes from the usability testing if anyone would like to see more details. Just let me know.

I am also including the updated designs with Arrow keys as a separate category of shortcuts. That way we can use Arrow keys in the popup with keyboard shortcuts.

I am not sure we will stay with an idea of the overlay with shortcuts. I am refining the popup with keyboard shortcuts for Pop Shell and will create a separate issue in the Pop Shell repository for that.

Here are the new designs:

Keyboard shortcuts page in Settings

Same page with the expanded Arrow keys section

Confirmation dialog

All the functionality for changing Arrow keys should stay the same as for other shortcuts. The only difference is that once a user sets a new Arrow key, for instance, "W" as an alternative to "Up", a user should see a confirmation dialog that would list all the shortcuts that use "Up" in them.

[maria-komarova]

Adjustments to the designs.

To get closer to how the page might work in the upstream, the shortcut categories should become separate sub-pages. Each category should include information on the number of modified shortcuts in each section.

View of the page

View inside the category.

Custom shortcuts

Search results

Use GTK theme styling for the keycaps.