W3C home > Mailing lists > Public > public-web-notification@w3.org > August 2013

Re[2]: Moving to Last Call

From: <sokoldv@ukr.net>
Date: Tue, 06 Aug 2013 12:35:33 +0300
To: Andrew Wilson <atwilson@google.com>
Cc: Jon Lee <jonlee@apple.com>, Justin DeWitt <dewittj@google.com>, WG <public-web-notification@w3.org>
Message-Id: <1375781204.15320647.k71q009w@fmst-11.ukr.net>
('binary' encoding is not supported, stored as-is)

 ('binary' encoding is not supported, stored as-is)
Hello everyone, 
We have no use knowing that notification was closed by user or platform cause in second case we still didn't know whether user have seen it or not (platform closes notification before user actually see it or user just ignore it). Also we can close it manually before platform does it (actually I do so). 

--- Оригінальне повідомлення --- 
Від кого: "Andrew Wilson" < atwilson@google.com > 
Дата: 6 серпня 2013, 11:05:37 

On Mon, Aug 5, 2013 at 11:22 PM, Jon Lee < jonlee@apple.com > wrote: 

Is there a specific situation where understanding the reason is crucial to the page’s functionality? On iOS and Mac, for example, notifications are expected to act like taps on the shoulder, and not necessarily return vital information that users cannot get from the web page or app. Given that the spec declare the event model is best-effort, the web page will not get an accurate picture of which notifications a user has seen and acknowledged, even with this additional flag. 
In the app that i'm familiar with (gmail) I can't think of any reason why I'd care about system-close vs user-close. I would like a robust way to tell if a notification has been closed, but I'm not sure I care about the source. 
That said, web apps can present a much better user experience if it has some idea about whether the platform closes notifications automatically. I'd rather have some way to know if this is the case (perhaps just by requiring this behavior in the spec), per my previous email. 
Received on Wednesday,  7 August 2013 12:14:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:14 UTC