Configurable notification actions

[cketti]

To avoid supporting a lot of different very specific notification action configurations I propose we allow users to fully customize which actions are displayed on a notification.

For the user interface I have have the following in mind: a list with three sections. The first one takes 3 items max and is for notification actions displayed on the device. The second section takes 5 items max and is for additional actions that can only be displayed on Android Wear devices (where I believe the maximum number of notification actions is 8). The third section is for actions K-9 Mail also supports but that are not currently used. Items in the list can be moved via drag and drop to change the order in a section or to move an action from one section to another.

On device with Android versions prior to 7.0 we use two kinds of notifications:

1. a notification for a single new message where a preview of the body text is displayed
2. a notification for multiple new messages where name and subject of the 5 most recent messages are displayed Android 7.0 introduced support for notification groups where multiple single message notifications can be bundled and the group can be expanded/collapsed by the user.

Some notification actions like "reply" don't make sense when applied to a group of messages. Often the order of desired actions is also different between the two types of notifications. So on devices with Android versions prior to 7.0 I propose we have two different configuration settings for notification actions. One for group notifications and one for single message notifications.

[nomeata]

Would it make the configuration interface easier there is a single list that you can reorder? “Notification action preference”? The user will quickly and intuitively notice that the top actions show up in the notification.

[cketti]

Would it make the configuration interface easier there is a single list that you can reorder? “Notification action preference”?

Easier yes, but it would also make it impossible to only have one or two notification actions.

The user will quickly and intuitively notice that the top actions show up in the notification.

That hasn't been my experience with users :)

[nomeata]

Easier yes, but it would also make it impossible to only have one or two notification actions.

Good point. Was just a quick idea, three lists are fine as well.

[jkuester]

@cketti, I have been doing some thinking about this (would still like to get a solution for the Archive option from https://github.com/k9mail/k-9/issues/3403)! Just have been too busy lately. One of the things I am concerned with is how well a drag-and-drop interface would work on small touch screens where lots of scrolling would be necessary. Maybe I am not understanding what you are suggesting, though. Would this involve some kind of custom Preference class?

A simpler alternative I wanted to propose was just to have separate ListPreferences for each of the three action slots on the notification. For each slot, users could select which action they wanted to display from the drop-down (and have a "None" option so that you could have less than three actions). Then you could have a separate PreferenceCategory for the 5 ListPreferences for picking the Wear notifications (and a third PreferenceCategory for selecting the actions for the old grouped notifications.

I happened to notice, a couple days ago, that the https://github.com/moezbhatti/qksms has a similar setup for their notifications preferences. Let me know what you think:

QKSMS:

[Grunthos]

Any chance of also allowing per-folder notifications? I have filters on my IMAP server that rate my mails according to probable importance,and, for example, I really only want a notification sound for the most important?

[flowgunso]

I don't know about the status of this enhancement, but that is a feature I'm really looking forward to.

[ghost]

I have been working on some solution for this adding the archive option. I made it work for single notifications(tests broken atm) but I would like to confirm how to proceed with the design when including summary notifications.

I would like if you could review the changes so far, as I had to move an enum class from notifications to K9 to be able to use it in preferences.

Going further, the design challenge I face is how to make it work for summary notifications, because I think the notification_quick_delete option could naturally disappear. I thought of three possible scenarios:

1. Provide three more action sets for summary notifications (without options that don't make sense, e.g. reply)
2. Keep notification_quick_delete as a toggle or two-option list, disabled when delete is not a selected action.
3. Provide an extra option for delete, e.g. delete vs delete all (I think this could be confusing for the users)

If we could clarify the point abve and it's ok with you, I would like to work a bit more on this issue and put a PR for this feature.

Thanks for all your work

[cketti]

@akiduki18: The hardest part about this feature is the user interface. I don't think configuring the action for each button individually leads to a great user experience.

• Simply changing the order of actions requires a lot of clicks.
• If you don't handle edge cases, users can configure nonsensical states like using the "mark as read" action three times.
• If you want to prevent those cases, you'd either have to remove actions that are already used by another button from the list or you change the configuration of the (other) button that is currently using the action the user has selected. None of these options are great.

The user interface I described in the first post has none of these problems.

[aqt]

Edit: Of course, as soon as I commented something clicked and I understood what you meant ;) The first section is for items showing on both the phone and watch, with the second section being additional actions for the watch. The third section I had been wondering about but now realize was the available but not chosen actions.

---

@cketti It seems to me that your suggestion of a list with sections implies that an action can only belong to one section. For instance, if I want an archive button, I need to decide whether I prefer it on the watch or the phone. Was that the intent?

In my opinion Symfonium (and probably others but I just noticed it here) implements an elegant UI for this purpose. It uses a list with each item having a checkbox for toggling the state, as well as a handle to allow for reordering by dragging. The three different action sets (sections) would be configured separately.

[ghost]

@akiduki18: The hardest part about this feature is the user interface. I don't think configuring the action for each button individually leads to a great user experience.

* Simply changing the order of actions requires a lot of clicks.

* If you don't handle edge cases, users can configure nonsensical states like using the "mark as read" action three times.

* If you want to prevent those cases, you'd either have to remove actions that are already used by another button from the list or you change the configuration of the (other) button that is currently using the action the user has selected. None of these options are great.

The user interface I described in the first post has none of these problems.

I understand, It was my impression that @jkuester's proposal was welcome since it had a thumbs-up, but I completely agree with your vision from a UX point of view. I am not sure I can spare the time right now to properly implement this, but I may come back in some months if nobody has taken care of the issue yet, for now I hope some people can at least enjoy the changes in my branch even if they are indeed not very user friendly.

[dzfranklin]

I don't see the UX issue described. If a user configures all three buttons to "Mark as Read" then they'll get three mark as read buttons. This is predictable, understandable, and avoidable. It's a similar problem to "I wanted an Archive button but I selected the Mark as Read checkbox": the solution is just not to do that.

[RomeoV]

I understand @cketti's concerns regarding the user interface, but I would be happy to go with a solution for now that is not quite perfect but implemented, especially since there seems to be longstanding demand for it see https://github.com/thundernest/k-9/issues/943 https://github.com/thundernest/k-9/issues/3403 https://github.com/thundernest/k-9/pull/3528 https://github.com/thundernest/k-9/issues/5628 https://github.com/thundernest/k-9/issues/5502 https://github.com/thundernest/k-9/issues/5628 https://github.com/thundernest/k-9/issues/5778 https://github.com/thundernest/k-9/issues/6339 #7651 #8094!

[frabcus]

I just tried out @ghost's patch above, and it is brilliant! Simple, works really well. Am going to use a patched version as my main K9 program.

My only two bits of feedback would be:

1. It should probably have more of the actions that are available from Interactions | Swipe actions - I think spam, add star and move would make sense particularly. I don't need them, but it woudl be more orthogonal.
2. The setting is a global one. I think that's probably right, but should be confirmed it is.

Thanks @ghost - although I note your name is "ghost" because @akiduki18 seems to have deleted their account. What can I do to help get this patch over the line?

[ajayyy]

In case anyone wants it, here is my implementation that just allows switching between Delete and Archive in notifications. Did not notice this thread until after doing it haha, but all's not wasted as I can use it for myself until another implementation is made.

https://github.com/ajayyy/thunderbird-android/tree/archive-button-in-notifications

Screenshots

[pzia]

For the record, here is the UX of Aquamail, from which I'm transitioning.

[RomeoV]

@cketti May I suggest this issue for the K-9 Mail 7.000 milestone? It had previously made it into the 6.000 milestone but was taken off again (not sure why). https://github.com/thunderbird/thunderbird-android/milestone/34

Thanks for your continued work!

[schmitmd]

I've been subscribed to updates on this specific issue for years now, waiting for the day K9 (now Thunderbird) can become my daily driver for email (much as I've loved 9folders' Nine app). This is the very last feature that keeps me from switching. @cketti , can it go into the next milestone?

Will ajayyy 's implementation work well enough to be pulled in?

[couchbat]

According to developers, they want absolutely perfect implementation, so this issue will never be resolved.

[robotfishe]

Is there any update on whether this feature will ever be implemented? People have been asking for 7 years on this thread alone. Like schmitmd, for me this is a dealbreaker - the only one left with Thunderbird apart from proper conversation view, which at least seems to be in the works with the new message database.

[gestate-8]

No. The most important notification feature, arguably the whole point of using an email client, has been completely ignored because of some vague, imaginary goal that no one has ever bothered to explain. And of course it’s no longer even part of the milestone.

Thanks to that users now get to enjoy opening the app every single time just to archive mails. This delightful experience repeats dozens of times a day.

If you take a look at the release notes and milestones, it becomes clear that the devs is far more focused on the app’s appearance and the convenience of adding accounts, a task most people deal with maybe once or twice a year.

[7system7]

It would be so good on GNOME desktop too. But I could not find the desktop app issue list. 🙁

[RomeoV]

Since the project stewardship of this project has somewhat changed since this issue was last discussed, perhaps a current maintainer can comment on whether this issue is still considered as status: help wanted (as the tag from 2018 suggests) and more specifically what help would be appreciated. A design discussion, a code PR, a demo, comparison to other mail programs, etc. I think some people feel discouraged by the previous attempts of help not being further evaluated or discussed, and there not being a clear path forward for further help.

I therefore encourage the maintainers to choose one of:

1. Keep the status: help wanted badge and communicate the type of help that would be appreciated, perhaps commenting on blockers that need to be resolved first; or
2. remove the status: help wanted badge and communicate on the internal prioritization of this issue (perhaps even closing this issue as unplanned or not planned until xxx happened if necessary).

Perhaps @wmontwe can comment on this?