Hi all, New to the list and the XDG specs, but I've looked into what's proposed and have some doubts about the use case for the "quick reply" in a notification system itself. My thinking on notification systems is that their whole thing is getting the user's attention for some event and providing enough info for the *originating application* to help the user resolve the event (e.g., "open file location" for a downloaded file). Adding an input suggests to be an extension in the scope of the notification spec that quickly becomes painful once the application developer decides to go this route. A couple undesirable things I'm imagining with the current proposal:
1) The user starts typing in their reply, gets about two sentences in, realizes they actually need a more nuanced reply and want more formatting, but the notification system doesn't know what the originating application supports because there's no hints for that. Assuming the notification system's quick reply supports text selection and copying, the user must copy the text and invoke the default action and paste in the text -- there's not a secondary action for taking the current input and adding it to the default action. 2) As I think is hinted at in [matthiasclasen's comment] on github about serialization and robustness, text may not be the only input an application wants for a quick reply. For instance, a calendar application may want a drop-down menu of times in the future for a "snooze" input for a meeting notification. Given the variety of applications that may have cause to get a user's attention, favoring a "message reply" input invites more folks to think their use case is in scope for the notification spec. This can make the notification spec a focus for a lot of non-notification effort and coordination, lengthening the time to get desired features in place. My main point is that the notification system, since notionally it's distracting the user, works better if it stays focused on helping the user decide whether or not to engage further, taking them out of what they had been doing. A "quick reply" starts to take scope from the application that it can't handle effectively: Might as well give it over to the application at that point. I avoided, above, saying what *should* be done alternately. I don't see the advantage of locating this capability in the notification system vs having the source applications themselves popping up their own reply dialog: Do we need to make the applications uniform in how they solicit replies from notifications? How many different chat or messaging applications is a user going to have on one machine? If applications do want a common way to do...less obtrusive message replies, why not have a "quick reply" interface that's its own thing - if the notification system wants to incorporate an implementation of that interface, it could do so. The spec for this interface could reasonably take all of the scope for replying, like supporting a basic or optional set of formatting, continuing to the full application with a partially completed response, or plugging in canned responses (or A.I. generated responses). [matthiasclasen's comment]: https://github.com/flatpak/xdg-desktop-portal/issues/485#issuecomment-630366590 -- Cheers, Mark W. _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
