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.

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

Defer & Queue #107

Open
JaninaSajka opened this issue Sep 6, 2017 · 14 comments

Comments

4 participants
@JaninaSajka
Copy link

commented Sep 6, 2017

The Accessible Platform Architectures (APA) Working Group at the W3C believes there
are significant use cases requiring API support for "Do Not Disturb"
functionality in various web applications, whether accessed via mobile
device or desktop browser. We are advised by W3C colleagues that the
appropriate locus for our feature request is the Notification
specification.

One such use case is the conclusion of a financial transaction where it
is critical that the key terms of the transaction can be completed
without distracting interruptions--which could also trigger timeouts
that would exaserbate the user's ability to complete the transaction.
The key juncture of a financial transaction might include the screen
where payment is finally authorized, a digital signature is applied, and
an accessible receipt is recieved.

Another use case is to prevent a list of items from scrolling while a
screen reader user is iterating through the list. Push actions which
result in scrolling exaserbate the user's ability to function smoothly
by causing the focus to shift outside the user's control.

We note this kind of functionality is available heuristically on mobile
platforms. An example Android application providing similar
functionality is:
https://play.google.com/store/apps/details?id=com.tryagent

However, what is needed is the ability to temporarily suspend push
notifications via an API call, so that an application can invoke a "Do
not disturb" feature based on context, and so that users may gain easier
access to turning notifications on and off directly, whatever the
platform, without navigating multiple menus.

We propose the addition of a section in support of this feature
requirement as follows:

Section 2.12 Defer and Queue

When this flag is set no notifications are delivered to the user
interface. Rather they are queued for display once the flag is cleared.

@annevk

This comment has been minimized.

Copy link
Member

commented Sep 6, 2017

Thanks for the feedback!

I think I'm missing something, as it seems to me that the application already has all the control to temporarily disable notifications. If they don't create any notifications, none will be shown. It seems to me this kind of queuing logic is better implemented in a library on top of the standard API.

However, you also suggest that users should have easy access to such functionality, which makes me think you don't want this to be an API for applications?

And just to be clear, push notifications are defined in https://w3c.github.io/push-api/ as far as network traffic is concerned, but this here is indeed the standard that's responsible for showing notifications to end users.

@JaninaSajka

This comment has been minimized.

Copy link
Author

commented Sep 18, 2017

Thanks for the prompt response, Anne, and sorry I'm slow getting back to you. I'll try to stay more on top of this.
The requirement in the first of our two use cases is to control subscribed notifications that come from outside the current application. The idea is to generalize a mobile device's "Do Not Disturb" functionality across all browsing/application environments, desktop as well as mobile.
The second use case could certainly be handled by the application, but we think it would be far easier to allow the AT a user is relying on to get this on/off effect using the same gesture, regardless the underlying application.
Does this help explain things? I think we're actually far more concerned with the first use case as people working on payments in W3C believe its applicability is wider than just accessibility. However, we believe both use cases present accessibility requirements.

@annevk

This comment has been minimized.

Copy link
Member

commented Sep 19, 2017

I think I still don't understand the scenarios well enough or the technologies that would be involved in creating it. "Subscribed notifications" makes me think you want to file an issue at https://github.com/w3c/push-api/issues/new instead, but I'm definitely not sure that's what you're after.

E.g., one way of reading what you're saying that is that the user agent should expose more functionality to the user to control the flow of notifications. However, that doesn't match with you suggesting the need for some kind of API. Or did you not mean an API exposed to applications?

@JaninaSajka

This comment has been minimized.

Copy link
Author

commented Sep 19, 2017

It's kind of funny--but we filed this issue at the suggestion of W3C's Web Platforms WG. APA had comments on the W3C Push API, and we were told our use cases were inappropriate for Push API, but would be appropriate for the Notifications API. Since the W3C work on Notifications is now closed, we were advised to come here. Anne, will you be at TPAC per chance? Perhaps, as a worst case, we could discuss there?
Meanwhile, let me try another explanation vector ...
Our argument is that bad things can happen for users unless:
1.) An application handling a payment transaction can't stop interruptions to the UI at key moments.
2.) An AT can't give the user a quick way to defer any toasts, popups, spoken output, etc.

@annevk

This comment has been minimized.

Copy link
Member

commented Sep 19, 2017

I won't be at TPAC this year. If you think this would be easier to communicate through voice I'm happy to join some call, provided it's a somewhat convenient time for Europeans (I'm generally available 9AM-5PM or 7PM-9PM, Zürich time).

Questions:

  1. If an application handling a payment transaction cannot be interrupted, is that because of a flaw in the application? How would you envision that to be solved?
  2. Why can AT not give the user a quick way to defer notifications et al?
@JaninaSajka

This comment has been minimized.

Copy link
Author

commented Sep 20, 2017

Anne, W3C APA's telecon is Wednesdays at Noon Boston, currently 16:00 UTC. Would that work? I'd like to propose Wednesday 11 October at that time, if that works for you. Earlier and we wouldn't have the people we'd like to bring to the discussion.
BTW, you're absolutely right to ask for use cases. I'm not sure just typing them in a comment field is the way to put that together, though. I'll endeavor to create a document before the 11th to start defining those.

@beverloo

This comment has been minimized.

Copy link
Member

commented Sep 21, 2017

Mind if I tag along to that call, @JaninaSajka, given that I'm involved in both the Push API and Notifications?

@annevk

This comment has been minimized.

Copy link
Member

commented Sep 21, 2017

I could do 17:00 UTC. I have to pick up my kid from daycare around 16:00. There's also some risk I can't make that date at the last minute due to it being rather close to the due date of our second child. Earlier would be better (or say, November).

@JaninaSajka

This comment has been minimized.

Copy link
Author

commented Sep 21, 2017

Peter, your participation would be most welcome. And, Anne, your need to be present for the birth of your child certainly takes precedence! Let's hold for the 11th for now. I'm also juggling availability of W3C people. But, if we need to postpone--even last minute--we can do that. I will post a URI to the agenda a few days ahead of the call. We use Webex with password, and need to ensure the passwords don't become visible, so I'll need an email address for that bit.

@annevk

This comment has been minimized.

Copy link
Member

commented Sep 21, 2017

@JaninaSajka thanks, I emailed you at a11y.org (also included Peter in the email).

@martinthomson

This comment has been minimized.

Copy link

commented Sep 27, 2017

It seems like there is a confusion here between the UX piece (notifications) and the networking piece (push API). My understanding is that @JaninaSajka is concerned about the effect on the user experience. I trust that Peter can help you sort this out because I like to sleep at that hour.

@JaninaSajka

This comment has been minimized.

Copy link
Author

commented Oct 10, 2017

@JaninaSajka

This comment has been minimized.

Copy link
Author

commented Oct 11, 2017

Minutes from our teleconference are available at http://lists.w3.org/Archives/Public/public-apa/2017Oct/0025.html

@annevk

This comment has been minimized.

Copy link
Member

commented Oct 12, 2017

The conclusion was that we should advice users agents to give users sufficiently control over the flow of notifications. For instance, by perhaps not unduly distracting users when the user agent knows they are otherwise occupied (e.g., via a web site using a payments API).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.