Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

APA WG comment: ability to pause notifications #259

Closed
michael-n-cooper opened this issue Jun 8, 2017 · 13 comments
Closed

APA WG comment: ability to pause notifications #259

michael-n-cooper opened this issue Jun 8, 2017 · 13 comments

Comments

@michael-n-cooper
Copy link
Member

The Accessible Platform Architectures (APA) Working Group review of Push API suggests that additional feature support is required by emerging use cases.

APA believes a mechanism is needed to allow applications to temporarily block any push notifications or events. All such notifications or events should be queued until the application requesting temporary blocking has cleared the blocking request.

Two use cases supporting such a feature:

==Use Case #1: time-critical tasks

A user engaged in a financial transaction at the point of making (or receiving) payment should not be interrupted by unrelated notifications and events. This is especially important for persons with disabilities
relying on assistive technology, but is also relevant to all users of emerging web payments specifications.

==Use Case #2: reduce interruptions

Users need the ability to interact with certain web content without automated updates that might cause presented content to update in an adverse manner.

This might be satisfied by allowing temporary pauses in push events, or by controlling a minimum time interval between push events.

For more on this use case see the comment at: http://lists.w3.org/Archives/Public/public-apa/2017May/0026.html

APA tracking of Push API comments
@martinthomson
Copy link
Member

User agents provide the capability you describe already. Can you further more justification for why you believe that applications need to be able to request this. This could be used for a denial of service on other applications, so we'd need to understand more about how this would be controlled.

The linked email seems to say something else:

For instance, a person may be reading an article’s comments and the comment feed is updated every 30 seconds to add additional comments. That may cause the layout to jump and the user may want to turn off the comment pushes, or slow down the update to once every minute.

I think that this demonstrates a misunderstanding of how the Push API fits with the other capabilities of the platform. The kind of error that Ted describes here is unaffected by the existence of push. Sites can commit this sort of usability mistake using fetch or websockets (and they frequently do in my experience). Adding push, use of which is generally inadvisable in the scenarios described anyway, doesn't make this problem worse.

@delapuente
Copy link

@michael-n-cooper these issues are more related with the visible part of notifications, not with the protocol itself and I, personally, consider them very valuable but perhaps it is better if those capabilities are added to the Notification spec.

@LJWatson
Copy link

LJWatson commented Jun 9, 2017

Perhaps it's worth adding an informative "Accessibility considerations" section (as there is already a "Security and privacy considerations section")?

@martinthomson
Copy link
Member

@LJWatson, I don't think that this is warranted in this specification. If you think that frequency of notifications is something that has accessibility implications, then that is something to take to the notifications spec. I'm not seeing any action for this specification.

@LJWatson LJWatson mentioned this issue Jun 20, 2017
Closed
@martinthomson martinthomson mentioned this issue Jun 23, 2017
Closed
@michael-n-cooper
Copy link
Member Author

APA concerns are not addressed by the above discussion. APA acknowledges that the core issue of notification interruption may be more appropriately dealt with another spec, and will follow up accordingly. But the issue is proximate enough to the features of Push API that we think information about this is also needed at least in an accessibility considerations section of the spec, much like the existing security and privacy section. APA will refine this proposal and follow up soon but meanwhile the comment should not be considered closed.

@beverloo
Copy link
Member

@michael-n-cooper, has APA come up with a proposal?

I agree with Martin that this issue is out of scope for the Push API. While suspending or delaying visible Web Notifications can definitely matter, time sensitivity of push message delivery entirely depends on the developer's use case. Delaying message delivery for use cases that don't involve notifications or other UI would be inappropriate, and there is no definite way for either other applications or the user agent to be aware of that.

@michael-n-cooper
Copy link
Member Author

APA is actively working on a proposal, @JaninaSajka is writing it up. The rough general approach is to request a warning in an accessibility considerations section of the spec (we'll provide proposed language), with a reference to a proposed change filed in Web Notifications. The rationale is the use case impacts users of the the Push API spec even if the solution is (potentially) in the Notifications spec. I hope to have something more concrete in a couple days.

@JaninaSajka
Copy link

Accessibility Considerations (Informative)

Push API features introduce a number of needs for a "Do Not Disturb"
functionality in various web applications, whether accessed via mobile
device or desktop browser. This functionality should be addressed by the
Web Notifications specification. Web Notifications currently does not
provide this feature but an issue has been filed requesting the feature:

[URI of issue available soon]

Meanwhile, until the use cases described in this issue are appropriately
addressed, implementers of this specification should be aware that
accessibility problems might be triggered by implementations of this
specification and attempt to minimize their impact.

@martinthomson
Copy link
Member

I don't think that we should add this text. The Notifications API is the right place for this text. The proposed text clearly acknowledges this point. I realize that adding text here might appear to help the case for adding text to the Notifications API, but that's not the right way to approach this issue.

Please take this issue to the Notifications API. The need for user controls over whether notifications are shown is clearly a good thing. To my knowledge most user agents provide these controls, so I don't anticipate any issues with adding some informative text there about the impact of notifications on accessibility.

@LJWatson
Copy link

Have discussed this with @adrianba and @chaals, and we agree with @martinthomson. The issue is out of scope for Push API, it is an issue with the Notifications spec (and that itself is out of scope for the WebPlat WG).

@JaninaSajka
Copy link

JaninaSajka commented Aug 30, 2017 via email

@martinthomson
Copy link
Member

@JaninaSajka, I didn't expect that you would submit this text, but some text. And yes, I expected that the text you propose would make any change here unnecessary (hence my closing this issue).

I am not actively participating on the Notifications API.

@JaninaSajka
Copy link

JaninaSajka commented Sep 26, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@martinthomson @beverloo @delapuente @michael-n-cooper @LJWatson @JaninaSajka