Re: [w3c/manifest] Add field: note_taking { new_note_url: <URL> } (#965)

Thanks for the feedback! I agree this might be better as a more general proposal to do with declaring capabilities.

If we used the existing Shortcuts manifest field, we would need to add a way for the user agent to identify shortcuts as intended to be used for specific purposes/tasks (eg. a new optional "purpose" field on each shortcut entry, with a defined set of values like "new-note", "new-contact", etc). As Reilly mentioned, some of these future tasks might need additional parameters/context.
I'm also thinking about a similar need for a "[lock screen start URL](https://discourse.wicg.io/t/proposal-lock-screen-api/4372)" soon, which would indicate a capability but should **not** be displayed in the regular Shortcuts menu.

So perhaps we could have a more general-purpose field like:
```
"special_capability_urls":  [
  { "task": "new-note", "url": <URL> }
  { "task": "add-to-existing-note", "url": <URL>, <additional params> }
  { "task": "lock-screen", "url": <URL> }
  { "task": "new-contact", "url": <URL>, <probably additional params> }
]
```
It seems like these individual purposes might need to be specified individually anyway, so I'm not sure if we get much benefit from grouping like this (and in fact there might be a drawback to grouping disparate features and tying their specification together rather than having separate tiny specifications). So I'm leaning towards the original approach, or adding a "purpose" to Shortcuts entries (and solving this in a different way for the lock screen URL).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/965#issuecomment-796358873