Notification summary is confusing

[schbrns]

Is your feature request related to a problem?

I've read the knowledge base and have looked over the previous issue regarding this.

Undefined terms:

Reduce interruptions

• "non-urgent"

...Without missing out

• "urgent"

Exclude conversations

• "conversations"

---

Choose apps for your summary

• Without waiting 6 hours to test this, what does this mean?
• Is any app excluded from this list considered a conversation, or are conversations predefined?

---

From the knowledge base:

Then, choose all apps from which you don’t receive notifications immediately but in batches.

• So apps in the list means you get them every 6 hours.

Exclude conversations Deliver all conversations immediately, even for apps in your summary.

• Sounds predefined. What is considered a conversation and why can't we make a list, similarly to summary?

---

From the knowledge base Eisenhower matrix, which suggests emails as a "not urgent summary":

So, you’ll always get a batch right after waking up if you have any new notifications (given that you sleep for more than six hours) and usually get two to three batches a day.

• Why can't we schedule it? This is a valid use case but nobody wants 6 hour email delays during the workday.
• Am I guaranteed that every messaging/email app is considered a "conversation" so that I can include it in the summary list and also get immediate notifications for it?

Describe the solution you'd like

Add the "work" back into "work-life balance" for the digital wellbeing initiative.

It has great foundations and is one of my favourite features (even if I would prefer treating the notification summary as a notification centre rather than digital wellbeing).

• At the very least, allow the user to provide a work schedule so that the digital wellbeing begins and ends outside of those hours.

The more the better, allow for a custom schedule or sleep schedule.

• Define conversations, whether it be allowing the user to make their own list, or transparency of Android's limitations as what it considers a "conversation".

If the rest is up to app devs to ensure their "conversation" apps meets Android guidelines/standards to be viewed as such, clarify this.

Feature Request Procedure

• [X] I have read the knowledge base article on feature requests and followed the steps mentioned