Re: [whatwg] Notifications improvements

On Fri, Aug 8, 2014 at 2:48 PM, Peter Beverloo <beverloo@google.com> wrote:
> Hi Andrew,
>
> On Wed, Aug 6, 2014 at 12:59 PM, Andrew Wilson <atwilson@google.com> wrote:
>>
>> On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren <annevk@annevk.nl>
>> wrote:
>> > On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson <atwilson@google.com>
>> > wrote:
>> >> I understand your concern that is driving this proposal: you don't
>> >> want to provide rich APIs that can't be well implemented on every
>> >> platform, and thereby fragment the web platform. I just don't want to
>> >> see us go down this path of adding these new notification types that
>> >> are so limited in ability that people will just keep using general
>> >> notifications anyway - I'd rather just stick with the existing API.
>> >
>> > Are you unenthusiastic about any of the proposed additions (what about
>> > those already added?) or is this more about the more "complex"
>> > features such as indication of progress?
>>
>> I'm (somewhat) unenthusiastic about the new semantic types, because
>> I'm not sure they'd get enough uptake to be worth the effort to
>> implement (note that this is just my personal opinion - I'm no longer
>> as heavily involved in the notification work within Chromium, so Peter
>> B's opinion carries much more weight than mine when it comes to
>> determining what we'd implement).
>
>
> I find myself being in favor of the semantic types.
>
> The primary reason for this is that it allows us to provide a much more
> consistent user experience, especially on platforms where we don't control
> rendering of the notification, compared to HTML notifications. On Chrome for
> Android we want to provide for a consistent user experience, where
> notifications should be visually indistinguishable (aside from clarifying
> the origin) from those created by native apps. The proposed semantic types
> would get us there.
>
> Furthermore, support for HTML notifications will be much more difficult to
> implement across the board. Some mobile OSes, notably Firefox OS and iOS,
> wouldn't support this at all. Others, such as Android, theoretically could
> support it, but won't because it means creating an entire WebView -- causing
> very significant memory pressure on already resource constrained devices.

To be clear, I'm not arguing for HTML notifications - as I said in my
original post to this thread, HTML notifications were removed from the
spec for various good reasons. But I think it's a mistake to just bake
in canned notification types. What if a developer wants a progress bar
with a cancel button? A progress bar with a timestamp? A list
notification that contains an event with timestamp? Or some other
different notification that doesn't specifically match one of your
curated templates, but could easily be built if you gave him a
lower-level set of primitives?

>
> Implementation wise, Chrome recently switched to rendering Notifications
> using a new message center implementation, which already supports rich data
> such as progress bars, timestamps, lists and buttons. On Android many of
> these features will come down to calling an extra method on the Java
> Notification.Builder.
>
>> I am quite enthusiastic about adding support in the API around
>> allowing users to interact with notifications after the parent page
>> has closed, however.
>>
>> >
>> > Having a new field timestamp that carries a particular point in time
>> > related to the message seems quite useful for instance and not very
>> > intrusive.
>>
>> Perhaps I'm not understanding how this would be used. What would such
>> a notification look like for (say) a calendar event ("Your 1PM meeting
>> starts in 5 minutes") versus a countdown timer ("In 73 seconds, your
>> hard boiled egg will be done cooking")? Would we have to provide a
>> format string so the UA knows where to inject the time remaining, or
>> would it always have to be put at the end? Do we need to specify
>> granularity of updates (i.e. if I have a stopwatch app, I probably
>> want to update every second, but for a calendar app, updating every 5
>> minutes is probably sufficient, until we get down to the last 5
>> minutes)?
>
>
> I would argue that this is a feature that should be defined by the UA or
> platform. I'm not sure whether using a counting notification is the right
> way to implement a count-down -- I would expect normal, foreground UI
> displaying a counter, and a notification if that UI was moved to the
> background and the counter expired.
>
> The timestamp doesn't necessarily need to be in the future either.
>
>> At least for me, a calendar notification that is constantly updating
>> its countdown every minute but has no snooze functionality is actually
>> a mis-feature, because it's distracting.
>
>
> The notification wouldn't visually re-announce itself on every update.
>
>> Again, I don't want to be overly negative about this - maybe there are
>> use cases like list notifications where the new API would be really
>> useful, but as soon as I start thinking about more complex display
>> scenarios, I immediately want to start having more control over the
>> formatting of the text being displayed, and i wouldn't get that with
>> this proposal.
>
>
> I think the benefit of being able to closely match the UI and UX of native
> notifications on the platforms is something that's enabled by using
> declarative properties, whereas that would be near impossible to do with
> HTML notifications. As long as advanced features, especially more compatible
> ones (say, buttons or timestamps) can be feature detected by developers so
> that they can provide a fallback when they're not available, I would be in
> favor of extending the future set with Jonas' declarative proposals.
>
> Thanks,
> Peter
>

Received on Monday, 11 August 2014 08:28:10 UTC