Feature Request: Shortcuts categories

[aarongustafson]

A handful of partners have expressed an interest in being able to group shortcuts together under custom headings. For example, a social media app might want to provide shortcuts for your 5 most recent conversations under the heading "Recent Conversations". I’ve been thinking quite a bit about this as a feature and my brain had always gone down the path of thinking about these shortcuts as being nested within a larger data structure, but that would break the existing shortcuts setup and would not be as compatible with platforms that don’t support this kind of shortcut grouping. To that end I had an idea I wanted to log here: Adding an optional category (or similarly named) member to the ShortcutItem definition.

With this new member, developers would be able to define shortcuts just as they do today, providing additional information that could be used in host browsers/OSes that support the feature, but without locking out browsers/OSes that don’t. ShortcutItems that have the same category would be automatically grouped together. So, for example:

{
  "shortcuts": [
    {
      "name": "Timeline",
      "url": "/timeline"
    },
    {
      "name": "Mentions",
      "url": "/mentions",
      "category": "Conversations"
    },
    {
      "name": "Direct Messages",
      "url": "/messages",
      "category": "Conversations"
    }
  ]
}

Might result in something like this:

Shortcuts

• Timeline

Conversations

• Mentions
• Direct Messages

The same approach could be used in the context of the forthcoming JS API too.

I’d love to hear y’all’s thoughts on this.

[marcoscaceres]

We would need to check if this is supported in various OSs... it's definitely easy to add to create the grouping, and would be backwards compatible, so no objection from me.

[aarongustafson]

Windows supports multiple custom “JumpLists” plus two predefined system-level lists “Recent” and “Frequent” (which refer to files). Documentation. iOS and Android don't seem to support it. macOS send to have multiple collections, but I'm still looking for the documentation.

[christianliebel]

macOS send to have multiple collections, but I'm still looking for the documentation.

Yes, macOS does (sort of). The menus are called Dock Menus. A Dock Menu essentially is an NSMenu that can take different NSMenuItems. Those again can either be a regular item, a submenu, or a separator.

With the help of separators, you could build different categories:

User agents could even choose to show the category title:

func applicationDockMenu(_ sender: NSApplication) -> NSMenu? {
    let dockMenu = NSMenu()
    dockMenu.autoenablesItems = false
    dockMenu.addItem(withTitle: "Timeline", action: #selector(action), keyEquivalent: "T")
    dockMenu.addItem(NSMenuItem.separator())
    // Uncomment for category title
    // dockMenu.addItem(withTitle: "Conversations", action: #selector(action), keyEquivalent: "C").isEnabled = false
    dockMenu.addItem(withTitle: "Mentions", action: #selector(action), keyEquivalent: "M")
    dockMenu.addItem(withTitle: "Direct Messages", action: #selector(action), keyEquivalent: "D")
    return dockMenu
}

Generally, I think this feature is super important, and developers would like to have it, so I strongly support it!

However, I’m not sure if simply adding the category property is sufficient:

• How are the categories sorted? By the appearance of the first categorized item in the array? Or would the items have to appear consecutively? What if they don’t?
• Can I have more than one category with the same name? (e.g., in macOS, you could have different “unnamed” categories)

[marcoscaceres]

Thanks for the research @christianliebel! Super helpful.

[aarongustafson]

Awesome info, thank you @christianliebel!

How are the categories sorted? By the appearance of the first categorized item in the array? Or would the items have to appear consecutively? What if they don’t?

My gut says that categories should be created in the order they are defined and that subsequent members of that category should be pushed into the array of category members. My initial thought is that uncategorized shortcuts should be at the top of the menu (mainly because they read better that way, in my opinion).

Can I have more than one category with the same name? (e.g., in macOS, you could have different “unnamed” categories)

I think multiple identical categories (perhaps with the exception of uncategorized shortcuts) would be confusing for users. Do you have some use cases in mind as to how this might be beneficial? Real world examples of this practice would also be helpful.

Implementation-wise, even in the connect of the proposed API, I don't see it being a huge headache because the shortcuts would always be written en masse, but I think use cases would still be useful as it feels more complicated from a user standpoint and from a teachability standpoint for developers.

[marcoscaceres]

Perhaps category could perhaps be treated as an opaque-ID (maybe "group"?), not a something to be shown to the user. We should have category labels.

[marcoscaceres]

... there is something not very "DRY" about this that's kinda bugging me.

[christianliebel]

I think multiple identical categories (perhaps with the exception of uncategorized shortcuts) would be confusing for users.

@aarongustafson Let’s look at this example dock menu from Apple Music:

As you can see here, there are different unnamed categories. Sure, user agents could achieve the same appearance by just dropping the category title on macOS and only show it in jump lists on Windows.

Again, I’m strongly supportive of the feature! Just adding the category property might even work, but it somehow doesn’t feel right for me. I think apart from DRY I’m also a bit concerned about the forward-safety of this approach. What if a category can have icons or a descriptive text? Does Linux (or some of their desktop managers) support categories? I think a bit more research would be helpful.

[christianliebel]

Windows 10 seems to take the same approach by taking a GroupName on JumpListItems: https://docs.microsoft.com/en-us/uwp/api/windows.ui.startscreen.jumplistitem.groupname

[aarongustafson]

Another approach would be to add a second key for shortcut_groups that could define the groups (and order), along the lines of

"shortcut_groups": [{
  "id": 1
},
{
  "id": 2,
  "name": "Conversations"
}]

Which would allow for multiple groups, both named & unnamed. Then the individual ShortcutItems could reference the group by its id:

"shortcuts": [
  {
    "name": "Timeline",
    "url": "/timeline",
    "group": 1
  },
  {
    "name": "Mentions",
    "url": "/mentions",
    "group": 2
  },
  {
    "name": "Direct Messages",
    "url": "/messages",
    "group": 2
  }
]

The question I have about this is what to do with orphaned shortcuts, where the author has either intentionally or unintentionally omitted the group indicator. Perhaps to address that we could define a phantom unnamed group that is first int he groups and is only used for ungrouped shortcuts (which would also cover the existing behavior).

It’s worth noting that this approach would require that the forthcoming JS API also include the ability to gather group information in order to make informed decisions about which group to assign new shortcuts to.

[marcoscaceres]

For group, remembering what each number means will be hard - so let's make it an opaque string.

[christianliebel]

I now checked the situation on Linux: At least KDE and Gnome seem to have application actions which cannot be grouped: https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#extra-actions

[Desktop Entry]
Actions=new-window;new-private-window;

[Desktop Action new-window]
Name=Hello, it's me.

[Desktop Action new-private-window]
Name=Open a New Private Window

The scenarios on the different desktop platforms seem to be as follows:

• Windows: groups with a name
• macOS: implicit "groups" (= separator between menu entries), not named
• Linux (KDE/Gnome): no groups

So we could indeed go with a group property that directly contains the caption. On macOS, group captions would simply not be shown. Neither Windows jump lists nor macOS dock menus have changed much over the past years, so if we would ever need to add more properties for a group, we could still introduce the shortcut_groups map.

Perhaps to address that we could define a phantom unnamed group that is first int he groups and is only used for ungrouped shortcuts (which would also cover the existing behavior).

That would make sense then.

[marcoscaceres]

As with other feature requests, I'm inclined to defer this until after we get some more implementation experience - specially with the base shortcuts member. @aarongustafson, that doesn't mean that Edge shouldn't experiment with this tho.

[kenchris]

@diekus is Edge still pursuing this? or can we close?