Bug 452264

In which desktop shell are you running this? In Plasma here the notification body contains the event start time, the icon in the notification is interactive, and the notification panel allows group dismissal.

https://invent.kde.org/pim/akonadi-calendar/-/merge_requests/15 has a proposal for making past reminders easier to distinguish.

> In which desktop shell are you running this?

Plasma, as indicated. (There may or maynot be settings that restore part of the behaviour, but I did not find them easily.)

Created attachment 148002 [details]
single reminder notification popup

 I've attached a screenshot of how this looks here for a single reminder notification.

> single reminder notification popup (19.75 KB, image/png) 2022-04-06 15:15

This matches my memory. As you can see, the date is not indicated and if this was an event taking place yesterday, you may get the wrong impression. (I cannot say if https://invent.kde.org/pim/akonadi-calendar/-/merge_requests/15  improves the situation).

Oh, I see, yes, the body text can be improved in a number of cases, https://invent.kde.org/pim/akonadi-calendar/-/merge_requests/17 should help with that.

Thanks Volker (for the improvements). Any idea how I get a "dismiss all" only for appointments back?

Click on the notification icon in the panel, that gives you a view which shows all active notifications grouped by application/source, on the right next to the application entry is a 'X' button that dismisses all notifications of that group.

I would like to add that the new notification also misses the remind later function for other durations than 5 minutes.

I used this a lot. For example when I was in a phone call and a reminder popped up, i said remind me in a hour or so. Now, I am either bothered every 5 minutes or I have to re-configure the event in Korganizer, which is quite cumbersome.

(In reply to Till Schäfer from comment #8)
> I would like to add that the new notification also misses the remind later
> function for other durations than 5 minutes.
> 
> I used this a lot. For example when I was in a phone call and a reminder
> popped up, i said remind me in a hour or so. Now, I am either bothered every
> 5 minutes or I have to re-configure the event in Korganizer, which is quite
> cumbersome.

Bug 453298: kalendarac: Notifications miss option to remind later with other time duration than 5 minutes

Bug 453299: kalendarac: Notifications miss option to edit event directly

(In reply to Volker Krause from comment #7)
> Click on the notification icon in the panel, that gives you a view which
> shows all active notifications grouped by application/source, on the right
> next to the application entry is a 'X' button that dismisses all
> notifications of that group.

Yes, works, thanks for the hint.

(In reply to Till Schäfer from comment #8)
> I would like to add that the new notification also misses the remind later
> function for other durations than 5 minutes.

I agree with that observation, I also used this a lot and the functionality is gone now.

We cannot have the same level of detail for the suspend time UI as the old dialog had, system notifications are much more restricted in that regard. However, there is certainly room to improve the current system.

The 5 minute interval makes sense for events at a fixed time in say the next hour or so (eg. meetings or calls) I think. For events in the more distant future, all day events, todos (or events used to represent tasks) we can probably find better defaults. Something proportional to the distance to the event would seem like it would address at least some of the problems?

We also have the option to re-purpose the third action button for an additional choice. That is currently used to open online meeting links or the map of the event location, which are actions that are most relevant close to the event, while days earlier a second suspend interval choice might be more useful instead?

Created attachment 148553 [details]
screenshot of hamburger menu in notifications

(In reply to Volker Krause from comment #13)
> We cannot have the same level of detail for the suspend time UI as the old
> dialog had, system notifications are much more restricted in that regard.
> However, there is certainly room to improve the current system.
> 
> The 5 minute interval makes sense for events at a fixed time in say the next
> hour or so (eg. meetings or calls) I think. For events in the more distant
> future, all day events, todos (or events used to represent tasks) we can
> probably find better defaults. Something proportional to the distance to the
> event would seem like it would address at least some of the problems?
That does not really fit my use cases (see also Bug 453298). For example, the duration of a phone call or meeting does not depend on distance of the event. What would make more sense to me is a constant distance before the event. But also in this case a single duration would most probably be not enough to be useful in the majority of use cases. 

Some Ideas here (I am not very familiar with the implementation specific limitations, so please say if they are not worthwhile to consider). 
A) Is it possible to have a drop down button that let you select a list of default snooze times? Having just multiple intervals with good (maybe configurable defaults) would make more sense to me, if a custom input is not possible.   For example: 5 Minutes, 30 Minutes, 1 Hour, 2 Hours, 5 Hours, 1 Day, 1 Hour before the even, 30 minutes before the event start, 5 minuted before the event, when the event starts.
B) When copying a file, there is a hamburger menu in the notification area, where i get full access to file operations about the copied file (see screenshot). If a direct drop down button is not possible for the snooze button (see A), it maybe possible to give advanced options in such an hamburger menu. I think such a drop down menu would also make sense for things like a direct editing of events (see Bug ). 
C) maybe it is possible to open another message box that asks about a custom delay if such an option is available (e.g., through A or B)
D) Is it possible to display more complex widgets  than a simple line based menu for the hamburger?

(In reply to Volker Krause from comment #13)
> We cannot have the same level of detail for the suspend time UI as the old
> dialog had, system notifications are much more restricted in that regard.
> However, there is certainly room to improve the current system.

My first aim is to understand which uses the old system had (in the wild) and
which of those got lost in the technical transition. I lack the overview to estimate 
if the technical change is an improvement in the summary. All I can do is to describe
the uses I was missing (on first) sight.

Any my use case was often to have a 15 minutes standard reminder and then 
when reacting to to the reminder, to push it back e.g. 2 minutes before the event.
This was a variable time and it was good I could enter it.

Some more technical background:

The notification popup UI is entirely outside of our control, it's provided by the platform shell (Plasma, Gnome, Android, Windows, etc). What we can use are two text elements (title and body) with some basic rich text formatting, the default "activate" and "close"/"discard" actions and up to 3 named action buttons. Additionally, there are a few special-purpose controls for indicating progress, for things related to files/URLs (that's the mentioned hamburger menu), inline replies to text messages or media playback controls, neither of which is really applicable to event reminders.

So essentially the thing we can work with are the three action buttons. They however also close the notification when activated on most platforms, so clicking 3x 5min for a 15min suspension is also not possible for example.

Right now we use those buttons for "Dismiss" (which duplicates the default/built-in dismiss action and thus isn't strictly needed, it's just easier to hit than the small 'X' button, considering how often it's needed), "Suspend" and a context-specific action when available ("Open URL", "Show Map"). As mentioned before, that allocation doesn't need to be fixed, we can adjust that depending on the context.

What we can do in theory is launch a separate UI from there, with whatever UI we want. Not doing this has the advantage that we don't have to bother with desktop vs mobile usability, notifications popups are appropriately adjusted for us for free in that regard. The other thing to consider is to not make things too convoluted for users for whom the current setup works very efficiently.


That aside, the important part here IMHO is to properly understand what people actually use this for, and derive from that how we can best support that. My impression from the feedback here and elsewhere is that this is basically split into two groups:

(1) reminders for things like meetings or calls, typically set shortly before the event. That's the use-case the current implementation seems to support rather well. The need for fine-grained suspension times is further reduced there by the popup being able to remain open without interfering with continued use of other applications while showing a countdown to the event.

(2) reminders being used as part of some form of task management workflow (on either events or todos). That's where the reminder distance to the event is typically bigger, or might not really matter at all as there is no hard deadline (ie. reminders might be deferred past the event). That's where the current approach isn't helping.

Is there a way we can distinguish those use-cases reliably? Then we could at least give the second case three different suspend options quite easily.

Thanks Volker, for the additional background and explanation.

So far I cannot say how others use the reminder functionality.  And one difficulty of getting closer to this understand is that many important users will not run "beta" versions or freshly released ones, but are a few years down the line until their long term distribution will carry a new version. So feedback coming now will be skewed by this. My suggestion is to at least have an idea about what is continued to be supported and why.

Personally my use case is in group (1) but I adjust the reminder according to the preparation time I need for different types of appointments. Then I sometimes use the delay of reminding me to get another few concentrated minutes. Example for meetings I invite people I usually have 15 minutes (which is a reminder they also get), then I can do preparations, like reading the protocol and agenda, shuffle my papers, open screens. Once I am say the reminder I may still have 11 minutes left, so I set the reminder to 9 minutes to be able to dive into another task. If I do not set the second reminder I may just dive up after 13 minutes, missing the start of the meeting. If I do not set the first reminder I maynot be prepared. On an appointment at my home I need to change and drive there, so I put the reminder to 30 minutes. For an appointment shortly after lunch, I set the reminder to 1 h, so to see it before lunch break. (This all are examples, but they all are a story about being reminded, not about task management as far as I understand it.)

(In reply to Volker Krause from comment #16)

Thank you for the explanation. That clears things up (also about the motivation to replace korgac). 

Here are some of my use cases 

(1) Some event your need to participate. I would like to differentiate here a bit more.
(1a) As you described. A meeting, where you need some short lived prepare time in advance. For example: online meetings, a meeting at work in the room next door. Here a default delay of 5 minutes might be a good compromise. you can configure a second reminder as a workaroud to not forget the event during preparation, e.g., 2 minutes before the event. 
(1b) A meeting where you need longer time to prepare. E.g. make some presentation. I  used to configure a very early reminder and a late reminder in that case. I think this actually mixes up (1a) and (2).
(1c) A real meeting with someone where you need longer time to get there. For example: going with the kids to the doctor, doing some sport in a remote location, etc. As for (1a) you may need some prepare time, which you may want to delay. However there are some other use cases for delayed reminders. For example, if you do not know the exact time of someone who will pick you up to arrive you may enter en early reminder and delay it according to more recent information. The same is true for public transport, where you may just take a second option because the first one is missed, canceled or delayed.  Sometimes this use case is not perfectly separable from (1a). For example, if you have a real life meeting at work and you do not know if you are at already at work before that event starts or you actually need to get there (e.g., because you are working form home at that day).  At the time the event is put into the calendar, you may not be able to know which case is true. 
(1d) Some event that is not exactly timed. E.g. Meet with some friend in the "afternoon". In this case i often just create an event for the full afternoon, such that this time is somehow blocked and I do not accidentally add another event there. The reminder is set at the earliest possible time of that event, such that i am actually remembered and may delay it according to recent information or my personal preference (e.g. I want to finish some other stuff and just shift it an our, because that would still be early enough to not upset the other person.) So this is also an example for shifting the reminder past the start of an event. 

(2) Task management. 
(2a) Prepare for an event with larger task. Eg. make presentation. Some limited delay possible
(2b) Some TODO. For example: call someone, do the kitchen job at work.

In general there are some workaround for delaying reminders: 
(a) Setting up real TODOs instead of calendar events. IMO this is only well suited for one time events, e.g., a one time call and you may still want to delay a TODOs reminder. But at least it will stay there with a high priority in the list of TODOs. However, TODOs face other limitations as given below:
  -> Recurring Events. TODOs cannot be repeated every xth week or so. E.g., do the kitchen job every forth week at work. In that kitchen job example, I used to set up a reminder at the start of the work day. Then I delay it to a suitable time depending on other work that needs to be done and the situation in the kitchen (e.g. dishwasher is not full jet, lets look at it in another 2 hour.  This delay is unpredictable). Usually the other blocking events are not known at the time of creation of the kitchen job event. So configuring a suitable reminder time is not an option. Especially, I do not want to reconfigure that event for every recurrence. 
  -> An calendar event depended TODO. This is basically the prepare for something situation with and extensive amount of preparation time. When creating a second TODO for preparation in addition to that calendar event, the TODO is decoupled from the event. If the event is than moved to another day or deleted you need to modify that decoupled TODO as well, which is very error prone and cumbersome. Thus, I do not use TODOs in that case. 
(b) Using multiple reminders from the start. As stated previously, not every event is fully understood at the time of creation. The situation might change dynamically and thereby an a-priori creation of suitable reminders is not possible. 

Outlook / Proposal:  
I think, the above use cases are very hard to archive with some well chosen default delay options. Thus, I suggest to provide a default delay as is (i.e., the 5 minutes) and add another button "custom delay" that opens another dialog with an option to specify a delay time. Some other calendars such as business calendar 2 (android) take a similar approach to have a custom dialog for more advanced reminder handling. 

Other things like the direct editing of an event might not be so important to present directly in the reminder, if the highlighting and editing capabilities inside KOrganizer are better supported (see shortcomings of current implementation in Bug 453299: kalendarac: Notifications miss option to edit event directly).

Thus, the third button then might be used for kontext dependent things like open position of map or something like that.

Note also bug 148663 (mark a to-do as complete).

Created attachment 149018 [details]
Screenshot of German Reminder Dialog with "Ablehnen" Button

One more usability degradation:

### confusing "decline" button

The reminding dialog  per appointment remnder offer me a "decline" option (in German "Ablehnen"). I am unsure what is does. Usually "decline" (and more so "Ablehnen") for an appointment would mean that I want to refuse to make the appointment, especially when this is a meeting in the Kalender this would potentially mean that I inform the others that I will not participate in the meeting. I guess that this is not what the button does, it probably just declines being remined of this meeting. However that is not clear from the presentation of the dialog.

(In reply to Bernhard E. Reiter from comment #21)
> One more usability degradation:
> 
> ### confusing "decline" button
> 
> The reminding dialog  per appointment remnder offer me a "decline" option
> (in German "Ablehnen"). I am unsure what is does. Usually "decline" (and
> more so "Ablehnen") for an appointment would mean that I want to refuse to
> make the appointment, especially when this is a meeting in the Kalender this
> would potentially mean that I inform the others that I will not participate
> in the meeting. I guess that this is not what the button does, it probably
> just declines being remined of this meeting. However that is not clear from
> the presentation of the dialog.

With no localization (i.e., English language) this is called "dismiss". IMO, a fitting German translation would be "Verwerfen".

A possibly relevant merge request was started @ https://invent.kde.org/pim/akonadi-calendar/-/merge_requests/24

Git commit be3c95e8a7704507e2448da99cbdda0c76707729 by Volker Krause.
Committed on 20/05/2022 at 15:26.
Pushed by vkrause into branch 'master'.

Add translation context for the "Dismiss" action

Should help with fixing the misleading German translation of this.

M  +1    -1    reminder-daemon/alarmnotification.cpp

https://invent.kde.org/pim/akonadi-calendar/commit/be3c95e8a7704507e2448da99cbdda0c76707729

I was surprised by this regression as well as I updated my Archlinux machine. I have read the comments with this report and see it slightly different: For me, distinguishing between a task (fixed appointment) and a ToDo/task (rough time estimation) is not that strict. The extremes are a fixed appointment and a strategic document. Between them, there is a (linear, analogous) space/gradient. The different approaches mentioned here are falling within this gradient.

I confirm the statements in #16 and #18 are true. These types of delays are valid and I can confirm. I want to add other points additionally:
1. I use a central Nextcloud server to sync tasks/appointments between phone and laptop. So, for me it is essential that any solution is compatible with the webdav-based appointments/tasks.
2. When driving in the car, I often get (good?) ideas. I want to fix them in a quick manner. Normally, I do not have the time to decide if this is better a task or an appointment. It's more like adding an appointment "Call Mom, mobile app" to remind me that I need to call her and ask if I need to install a certain app on her phone (just a dumb example). I will put a reminder (default 15min) after I arrived and most probably will be back on the computer. There I can process further and call her.
3. When coming to my laptop, I am typically greeted by a bunch of notifications that are informing me of whatever I need to do now. With the old korac I was able to process the tasks in "my" order. Some could be dismissed directly (already done). Others need more caring. One trick to get this done fast was to delay all still-to-be-cared-of notifications for 1-2 minutes and then dismiss all altogether. This was typically much faster than 1 on 1 dismissing.
4. I might be able to adjust to thinking if it is a hard deadline or not, most of my appointments are rather tasks instead of appointments. Explaining the concept to my parents or my girlfriend would seem rather complex. I do not know if I can get them used to the difference.
5. Speaking boldly: What would be the benefit of differentiating between appointments and tasks? The restrictions imposed by the UI to appointments hold true for tasks, are they not?
6. If you put a hamburger menu for appointments/tasks in the UI, you could think of an option to shift the event/task due time instead of delaying the notification. That might be useful as it will propagate to all synced devices.

Eventually, I will have more comments, that it for now :-)
Christian

(In reply to Bernhard E. Reiter from comment #0)
I experienced the same issue when upgrading within my distribution.
As neither here nor in the many duplicates I see any progress to a solution,
I've set up a discussion about possible workarounds to which I invite anybody 
interested: https://bugs.kde.org/show_bug.cgi?id=481024#c1

A possibly relevant merge request was started @ https://invent.kde.org/pim/akonadi-calendar/-/merge_requests/82

Git commit 22fbeb4e48646ab4fa9abce21c4ef1eab31475e5 by David Faure.
Committed on 13/02/2024 at 15:57.
Pushed by dfaure into branch 'master'.

Implement a dialog for the user to choose the suspend duration

The "Remind in 1h" action has been replaced with a "Remind later..."
action which pops up that dialog.

The UI is QWidget-based (reusing some code from korgac).
On mobile we could just not show the "Remind later" action or
implement a similar QML-based UI.
Related: bug 481024, bug 457046, bug 453298, bug 457046

M  +2    -0    reminder-daemon/CMakeLists.txt
M  +5    -4    reminder-daemon/alarmnotification.cpp
M  +2    -2    reminder-daemon/kalendaracmain.cpp
M  +21   -5    reminder-daemon/kalendaralarmclient.cpp
M  +4    -0    reminder-daemon/kalendaralarmclient.h
A  +136  -0    reminder-daemon/suspenddialog.cpp  *
A  +33   -0    reminder-daemon/suspenddialog.h  *

The files marked with a * at the end have a non valid license. Please read: https://community.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page.


https://invent.kde.org/pim/akonadi-calendar/-/commit/22fbeb4e48646ab4fa9abce21c4ef1eab31475e5

Git commit 0dea82b7100a3f79a81bfdc2e627ba8923131abe by David Faure.
Committed on 15/02/2024 at 19:40.
Pushed by dfaure into branch 'release/24.02'.

Implement a dialog for the user to choose the suspend duration

The "Remind in 1h" action has been replaced with a "Remind later..."
action which pops up that dialog.

The UI is QWidget-based (reusing some code from korgac).
On mobile we could just not show the "Remind later" action or
implement a similar QML-based UI.
Related: bug 481024, bug 457046, bug 453298, bug 457046

M  +2    -0    reminder-daemon/CMakeLists.txt
M  +5    -4    reminder-daemon/alarmnotification.cpp
M  +2    -2    reminder-daemon/kalendaracmain.cpp
M  +21   -5    reminder-daemon/kalendaralarmclient.cpp
M  +4    -0    reminder-daemon/kalendaralarmclient.h
A  +136  -0    reminder-daemon/suspenddialog.cpp  *
A  +33   -0    reminder-daemon/suspenddialog.h  *

The files marked with a * at the end have a non valid license. Please read: https://community.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page.


https://invent.kde.org/pim/akonadi-calendar/-/commit/0dea82b7100a3f79a81bfdc2e627ba8923131abe