Manifest: Add field: note_taking { new_note_url: <URL> }

[phoglenix]

Note-taking apps have special integrations in some user agents and OSs to take a quick note. Examples:

• keyboard shortcut on Windows
• action center button on Windows
• stylus tools button on CrOS
• Google Assistant on Android
• touch bar or Siri on OSX

Such integrations could begin to be supported for web apps too, if they had a way to identify themselves as note-taking apps and a URL to launch for taking new note. This wouldn't cover all the use-cases linked above (eg. voice assistant actually adding items to the note) but it covers the core flow of adding a new note.

So, I'm proposing a new dictionary manifest entry note_taking with an entry new_note_url to specify a URL, within app scope, to launch for taking a new note. By using a dictionary we can easily group other note-taking app functionality if this is extended in the future.

{
  "name": "My note taking app",
  "note_taking": { "new_note_url": "/new_note.html" },
}

-Glen (Chrome OS Web Apps team)

[aarongustafson]

This is interesting, but feels overly focused on solving one problem. Generally, I’m interested in finding ways we can create a generalized interface that can solve multiple problems. At present, this feels like the kind of thing that can be solved (to an extent) with Shortcuts. Users can activate the icon menu for their note taking app and launch the composition URL from there.

Stepping beyond that, I think I’d be more interested in exploring a way a PWA could advertise it’s capabilities, like the work on file handling, for example.

[reillyeon]

I had similar thoughts but Glen's message seems to imply that there would be additional note taking-specific entry points which make this proposal more similar to Web Share Target, which requires its own manifest field to express more complex semantics. If this were limited to only an "create new note" entrypoint then I agree that Shortcuts can solve the problem if we standardize a set of tasks for which shortcuts can be created. Other ideas could be "create new calendar entry" or "add contact". In both of those cases however it seems valuable to add some additional context and so maybe task-specific members (and associated microformat definitions) are appropriate.

[phoglenix]

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" 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).

[aarongustafson]

I like how this is expanding & generalizing. One of the other things we’ve discussed in the past is the ability of sites to advertise their ability to participate as consumers or providers of information like this. It would probably make sense to define a system that worked in both ways as an addendum to the Manifest in its own spec, much like Share Target and App Info. Maybe something like this (based on @phoglenix’s concept):

"integrations": {
  "notes": {
    "create": "<URL>",    // creates a new note via POST
    "read":   "<URL>",    // all provided notes via GET (JSON? XML?)
    "update": "<URL>",    // updates existing note via POST/PUT/PATCH
    "delete": "<URL>"     // removes a note via POST or DELETE
  },
  "calendar": {
    "create": "<URL>",    // creates a new note via POST
    "read":   "<URL>",    // all provided notes via GET (iCal format?)
    "update": "<URL>",    // updates calendar item via POST/PUT/PATCH
    "delete": "<URL>"     // removes a calendar item via POST or DELETE
  },
  …
}

Each URL could be a URL and each key would be optional, so if you only wanted to offer creation, you just define create, but if you want r/w you could do create, read, and update. I think most apps would shy away from delete, but it wouldn’t hurt to offer it. It might even be possible to allow for more configuration of the fetch by turning the URL into an object (like Share Target does) so devs could define params, verbs, etc.

To me, this feels much more manageable in the long term because it’s a one member extension to the manifest that can evolve independently, with each integration defining it’s own data contract (like Share Target does). Honestly, a generalized approach like this could have worked well for Share Target too:

"integrations": {
  "share": {
    "create": {
      "action": "share.html",
      "params": {
        "title": "name",
        "text":  "description",
        "url":   "link"
      }
    }
  }
}

[aarongustafson]

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).

To be clear, I agree. I think it would be possible to create the extension point—even define it in the Manifest—and then allow other, discrete specs to integrate there. But perhaps that horse has left the stable (see Share Target, File Handlers, etc.).

[aarongustafson]

@phoglenix Have you looked at @slightlyoff’s declarative web actions at all?

[phoglenix]

Ah, I hadn't seen declarative web actions, but it seems to have a lot of overlap with what I'm proposing (almost a superset). It seems a bit more focused on items that appear in some menu UI than this one. If we allow each integration to define its own data contract, then declarative web actions could easily be an extension of this "integrations" approach, just adding new integrations / parameters. I like that idea.

So I guess this proposal is now for an integrations manifest member (like aarongustafson's comment above), in which keys and their contracts are each defined in their own mini-specification.

And also for the first such integration mini-specification, in the form:

"notes": {             // Defining this member identifies the app as a note-taking app.
    "new": "<URL>",    // URL to open for the user to take a new note.
}

[phoglenix]

Another potential use that just came up on slack: adding a settings url for web apps (which could be linked from the context menu on the app in the OS (currently happens for "Hosted Chrome Apps" like Drive on CrOS).

[alancutter]

I'm not so keen on this "integrations" member. I don't think it's serving a different purpose to the root manifest object.

[marcoscaceres]

Agree with @alancutter. Web Share Target sets a good precedence in that the "share_target" member signals support, and defines the things that it can do with respect to being a "share target".

[phoglenix]

Fair point, I think it would be just as good to add a mini-specification for notes like I mentioned above but as a top-level manifest entry instead of inside an "integrations" object.

[aarongustafson]

I'm not so keen on this "integrations" member. I don't think it's serving a different purpose to the root manifest object.

That’s fair. Sometimes I feel the root manifest is getting cluttered and could benefit from some organization, but that’s on me.

[alancutter]

I think grouping things by high level orthogonal use cases like "note_taking" is the way to go for keeping things organised. They could have their own manifest module spec similar to CSS modules to keep the main app manifest spec from getting too large.

[phoglenix]

Closing this issue as we now have a proposed field spec in WICG/manifest-incubations.
Please file an issue in https://github.com/WICG/manifest-incubations/issues if more discussion is needed.