Bug 452264 - Appointment reminder handling reduces usability and functionality between 21.12.3 and 22.03.80
Summary: Appointment reminder handling reduces usability and functionality between 21....
Status: REPORTED
Alias: None
Product: Reminder Daemon
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: OpenSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2022-04-04 15:26 UTC by Bernhard E. Reiter
Modified: 2022-05-21 07:06 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
single reminder notification popup (19.75 KB, image/png)
2022-04-06 15:15 UTC, Volker Krause
Details
screenshot of hamburger menu in notifications (10.58 KB, image/avif)
2022-05-04 11:03 UTC, Till Schäfer
Details
Screenshot of German Reminder Dialog with "Ablehnen" Button (26.43 KB, image/png)
2022-05-20 10:02 UTC, Bernhard E. Reiter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bernhard E. Reiter 2022-04-04 15:26:26 UTC
SUMMARY
Reminder behaviour changed between kontact 21.12.3 and 22.03.80
Now they do not have a seperate window anymore, but come as part
of the desktop notifications. This reduces functionality and usability.

Reminder behaviour changed between kontact 21.12.3 and 22.03.80
Now they do not have a seperate window anymore, but come as part
of the desktop notifications.

Problems with the new behaviour that the old one did not have:
 * Each reminder does not show the date, so a reminder from a few days ago
   look like they are due today.
 * There is no overview anymore of all appointment due since last start
   and in timely order.
 * Lost the functionality to dismiss all reminders at once.
 * When clicking the calendar icon, the Kontact calendar does not open.
   (Needs to click the text itself to open the calendar.)

Observed the change after the switch from the following version
on an OpenSuse Leap system:

2022-03-05 10:14:39|install|kontact|21.12.3-lp153.178.1|x86_64||KDE-Applications|c862e0234bdd0804f08590d9ba921804c3d87307b0cfb745220f0ed19c18bf86|

2022-04-01 22:06:01|install|kontact|22.03.80-lp153.179.1|x86_64||KDE-Applications|a76922e914e46311d47fb104d28c8d731d9c7e781c1ff65ec98fc340af9975a0|


STEPS TO REPRODUCE
1.  create a number appointments (with old kontact in my case)
2. wait until they were due, e.g. a few days
3. start system (with implicit starting akonadi)

OBSERVED RESULT
You get all past due reminders, each in its own little notification windows.
The window does not show the date, so reminder from two days ago looks like it  is taking place now.
There is no button to dismiss all reminders.
There is no overview of all reminders, if they do not fit in some are just not shown.

EXPECTED RESULT
The usability for overview and handling should be preserved or superceded.
(If there is a possibility to configure the system to behave similiar or better, it should be the default.)
Each reminder should display the data and make clear it is not today, when it isn't.

Clicking the calendar should open the kontact calendar app (or whatever did the reminding entry).

SOFTWARE/OS VERSIONS
GNU/Linux/KDE Plasma: Opensuse Leap 15.3 + KDE.  Kontact Version 5.19.80 alpha (22.03.80)
KDE-Plasma-Version: 5.24.4
KDE-Frameworks-Version: 5.92.0
Qt-Version: 5.15.2
Comment 1 Volker Krause 2022-04-05 16:58:07 UTC
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.
Comment 2 Bernhard E. Reiter 2022-04-06 06:57:22 UTC
> 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.)
Comment 3 Volker Krause 2022-04-06 15:15:43 UTC
Created attachment 148002 [details]
single reminder notification popup

 I've attached a screenshot of how this looks here for a single reminder notification.
Comment 4 Bernhard E. Reiter 2022-04-06 15:54:23 UTC
> 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).
Comment 5 Volker Krause 2022-04-07 16:16:39 UTC
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.
Comment 6 Bernhard E. Reiter 2022-04-11 13:43:07 UTC
Thanks Volker (for the improvements). Any idea how I get a "dismiss all" only for appointments back?
Comment 7 Volker Krause 2022-04-11 16:01:33 UTC
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.
Comment 8 Till Schäfer 2022-05-02 13:08:46 UTC
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.
Comment 9 Till Schäfer 2022-05-02 13:34:53 UTC
(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
Comment 10 Till Schäfer 2022-05-02 13:57:22 UTC
Bug 453299: kalendarac: Notifications miss option to edit event directly
Comment 11 Bernhard E. Reiter 2022-05-03 06:23:31 UTC
(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.
Comment 12 Bernhard E. Reiter 2022-05-03 06:25:54 UTC
(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.
Comment 13 Volker Krause 2022-05-03 15:54:29 UTC
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?
Comment 14 Till Schäfer 2022-05-04 11:03:08 UTC
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?
Comment 15 Bernhard E. Reiter 2022-05-05 07:05:05 UTC
(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.
Comment 16 Volker Krause 2022-05-05 16:10:00 UTC
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.
Comment 17 Bernhard E. Reiter 2022-05-06 07:34:18 UTC
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.)
Comment 18 Till Schäfer 2022-05-06 09:53:22 UTC
(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.
Comment 19 gjditchfield 2022-05-20 01:50:05 UTC
Note also bug 148663 (mark a to-do as complete).
Comment 20 Bernhard E. Reiter 2022-05-20 10:02:41 UTC
Created attachment 149018 [details]
Screenshot of German Reminder Dialog with "Ablehnen" Button
Comment 21 Bernhard E. Reiter 2022-05-20 10:03:54 UTC
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.
Comment 22 Till Schäfer 2022-05-20 11:56:01 UTC
(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".
Comment 23 Bug Janitor Service 2022-05-20 15:27:02 UTC
A possibly relevant merge request was started @ https://invent.kde.org/pim/akonadi-calendar/-/merge_requests/24
Comment 24 Volker Krause 2022-05-21 07:06:57 UTC
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