On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> Hi All, > > We've on and off discussed various features added to notifications. > It'd be great to move forward with some of these improvements. > > I think the most low hanging fruit would be to add the following as > data that can be displayed in a notification: > > * Progress bar > * Lists of title/body pairs > * Date (for things like "event will happen in 10 minutes") > > So, many of these cases were what the original HTMLNotification API was supposed to address. This was eventually shot down for a number of (good) reasons: too much complexity on the implementation side, and more importantly, the fact that these more complex notifications aren't compatible with various platform notification frameworks and so this would be a source of platform/UA incompatibility. It's not clear to me that re-adding support for these use cases one at a time as distinct notification types is really a good path forward, or that it's necessarily "low-hanging fruit" unless we have a good idea for how to deal with the platform-compatibility issue. > > Second, we really need to figure out the story around handling user > clicking notifications after the user has closed the original page. > > At the very least we need the ability to send a message to a > ServiceWorker when the user clicks a notification. This way the SW can > decide if UI should be shown, and if so if an existing window can be > reused or not. > > SW integration will require some other changes too. > > We need to change the GC behavior. Right now it seems like if a > Notification object is created, but no event listeners are attached, > because the page is expecting to use the SW event to listen for > clicks, the notification won't be kept alive and so the SW can't get > to any of its data. > > We also need to keep state on the Notification object if the user has > clicked the notification or not. > > We should also consider enabling passing a URL to the Notification > constructor which is opened when the user clicks the notification. > Probably this should attempt to reuse an existing tab with said URL if > one is open. > > > Third, we should look at enabling minimal user input through the > Notification. It's very common for notifications to support having one > or more buttons that the user can click. It would also be good to > enable putting a simple text-input in the notification. This area is > definitely more complex though so happy to put this last. > > I think if we want to address the "more complex data type" use cases above, then this needs to be part of that proposal - for example, I'm not sure how valuable having something like a "Date/Event" notification would be without a "Snooze" button.
