Event, Task, and Simple Reminder Notifications

[Mikenux]

Context

• An issue in GNOME (https://gitlab.gnome.org/Teams/Design/settings-mockups/-/issues/52) and an initial design from the design team (https://gitlab.gnome.org/Teams/Design/settings-mockups/-/blob/master/notifications/notifications-expanded.png) highlighting alarms and calls as notification types.
• I thought we could also have events, simple reminders , and tasks ("to do") as notification types, as I think these should be explicitly added (see Goals).

Goals

• Register the properties of events, simple reminders, and tasks ("to do") in order to identify them;
• Tell the user that an event, a simple reminder or a task has been added, especially if the user wants to be notified of it when Do Not Disturb is active, and provide reliability as to what is added.
• Have a notification type that can be toggled on and off for events, simple reminders, and tasks;
• Show a standard notification with standard actions;
• Display these different items in standard widgets if wanted.

Required

• A Task Store to register any "task", namely events, simple reminders, and tasks in this case. Registered "tasks" are categorized by app.

App Registration

• An app with events, simple reminders, and/or tasks is registered when it is installed or updated. The fact that the app uses such items must be detectable. Also, this registration is updated when the app is updated (if there is a change in what it supports).
• The app communicates which properties of the events, simple reminders and/or tasks, as well as those of the notification actions it supports (see the registrations below).
• Any app must communicate the unique label it uses for the “Description” and “Category” properties.
  • Available labels for "Description": Description, Notes.
  • Available labels for "Category": Category, Tag, Label.
• Apps with tasks must report the label they use for the "List" property, either "List" or "Project".
• Any app reports all predefined calendars, categories and lists, if they have them. Their names must be reported. Colors and Emojis are supported depending on whether it is an event, a simple reminder or a task; see the respective properties of these items below.
• An app with tasks communicates whether it supports setting a task's level of completion − called "Completion", by registering the unique completion format it uses: a "format" property where the possible values are:
  • "binary" for defining a task as completed or not, and nothing else.
  • "percentage" for the use of percentage.
  • "fraction" for the use of fractions. The app also indicates the number of levels (e.g. 10).
  • "labels" for the use of labels. The app lists the labels to use in ascending order of completion (e.g. Not Started, In Progress, Half Done, Almost Done, Done).

General

• Simple reminders and tasks that are undated are not registered, so not available in standard widgets.
• Apps share their event / simple reminder / task registrations with the Task Store.
  • Because of that, they don't need to be launched or run in the background. Updating items according to the triggered notification action is performed on the system side. As a result, these apps update the display of items within their interfaces when they are launched or are running.
  • This allows dated items to be migrated to another app, if it is wanted.
• For events and tasks that include "Participants" and "Location" properties (see the registrations below), the app must expose attendees (i.e. contacts) and use an app-side service for the location. Location service is app-side if one service is preferred over another; the user selects the location on the app side, and the app returns a name (e.g. place, company name) and coordinates.

Widgets

• An event widget displays all events.
• A simple reminder widget only displays simple reminders with a date.
• A task widget only displays dated tasks.
• Widgets can open the relevant app.
• All of these items can have actions to reschedule and cancel them (see Notification Actions below for each item).
• Tasks can have an action to set their level of completion (see Notification Actions below for Tasks).

Portal and App User Interfaces

Why a Portal-Side User Interface?

To achieve the second goal, it is necessary to confirm the addition of events, tasks, and simple reminders and to be able to review their content.

I thought about showing a notification to confirm the addition. However, it would make a big notification to show all the properties of an item, and the user wouldn't necessarily have time to review the content because, usually, notifications aren't shown for long. Furthermore, this would mean that the user would have to review the content twice.

For the reasons mentioned above, notably to avoid the user having to review the content twice, I therefore chose to have a portal side user interface.

UI Considerations

The portal UI is then a standard dialog for adding and updating events, simple reminders, and tasks.

Deleting an event, a simple reminder or a task can be done using a Delete button in a standard dialog or in the app UI. If the Delete button is in the app UI, it triggers a standard delete confirmation dialog to appear. The minimum number of relevant properties appear in this dialog to indicate to the user which item is being deleted. Multiple items can be deleted with a confirmation dialog listing them.

Each property of an item can be called individually by an app. This means that apps can have a button in their user interface that calls the portal to display a specific property. The portal user interface must then directly display the called property, also presenting its options, while offering the possibility of editing other properties.

Event Registration

Core Registration

• Name. Text can be added from the app (e.g.creating an event from an email).
• Location. Optional. Location name and coordinates.
• Calendar. The name of the calendar the event belongs to and its color (color value). Color is optional.
• Dates. They can be multiple due to recurrence.
• Start Time. HH:mm
• End Time. HH:mm
• Description. Optional. The text of the description or notes. Text can be added from the app (e.g.creating an event from an email).
• Category. Optional. Name of the category/tag/label. Colors and emojis can be used optionally, either one or the other, but not both at the same time. Example: color1, category1; color2, category2; emoji3, category3; emoji4, category 4.
• Apps To Open. Optional. This allows to open apps when an event is about to start. The apps to launch are specified.
• Files To Open. Optional. This allows to open files when an event is about to start. To open files, file paths and/or opening files with a specific app are used. If only a path to a file is used, the system opens it with a default app.
• Web Links To Open. Optional. This allows to open web links when an event is about to start. Web links are specified with or without a web browser in which to open them. If no web browser is specified, the link is opened with the system's default web browser.
• Participants. Optional.

Reminder Registration

• Core Registration.
• Reminder. Options are:
  • "before-start" for a reminder before the event starts. Set date, days, hours, and minutes at which the reminder must start (e.g. yyyy-MM-dd.HH:mm) and before the event start; an error is returned if the reminder is not before the event start. Set to "0" or leave blank for no reminder. There can be multiple "before-start" reminders.
  • "to-open" for a reminder to open apps, files, and/or web links specified above before the event start. Set the time in minutes before the event starts; this will be the time at which all apps, files, and/or web links will be opened. If minutes are set to "0" or left blank, there is no reminder. This option can be used only one time for an event.
  • "before-end" for a reminder before the event ends. Set time in minutes before the event end, and within the interval between event start and event end; an error is returned if the reminder is set outside of the interval. Set to "0" or leave blank for no reminder. There can be multiple "before-end" reminders.
  • "on-end" for a reminder on event end. Leave blank for no reminder. There can be only one "on-end" reminder.

Notification Actions

• Open Apps / Files / Web Links (or combination). This action opens apps, files, and/or web links specified for an event. This action can only be triggered for the "to-open" reminder and for the notification when the event starts. If this action has been triggered with a "to-open" reminder, then it is not available on event start.
• Reschedule. This action is there in case an event has been canceled or postponed. It is set on all reminders and on the event start notification if the user missed rescheduling the event at the event start or on a reminder. (It is recommended to have user experience to reschedule events relative to simple reminders, tasks, and other events.)

Simple Reminder Registration

Registration

• Name. Text can be added from the app (e.g.creating an event from an email).
• Description. Optional. Text. The text of the description or notes. Text can be added from the app (e.g.creating a reminder from an email).
• List. List to which the reminder belongs and its color (color value). Color is optional.
• Category. Optional. Name of the category/tag/label. Colors and emojis can be used optionally, either one or the other, but not both at the same time. Example: color1, category1; color2, category2; emoji3, category3; emoji4, category 4.
• Dates. They can be multiple due to recurrence.
• Reminder Time. The time at which the reminder must be presented (HH:mm).
• Repeat Time. The interval time in minutes if the user wants to remind later. Set to "0" or leave blank to use a default system value.

Notification Actions

• Do Not Remind.
• Remind in X min. X took from Repeat Time settings.
• Reschedule. The Reschedule action is there if the user decides to cancel or to postpone the reminder.

Tasks ("To Do") registration

Core Registration

• Name. Text can be added from the app (e.g.creating an event from an email).
• Belonging Task. Task to which the task belongs. This allows to define a hierarchy of tasks (main task, subtasks, etc.). Leave blank if the task does not belong to another.
• List. List to which a task belongs. This field is required if the task is not part of a hierarchy or is the main task of a hierarchy. It is left blank if the task is part of a hierarchy, but is not the main task. Colors and Emojis must be supported and can both be used; they are optional.
• Description. Optional. Text. The text of the description or notes. Text can be added from the app (e.g.creating a task from an email).
• Category. Optional. Name of the category/tag/label. Colors and emojis can be used optionally, either one or the other, but not both at the same time. Example: color1, category1; color2, category2; emoji3, category3; emoji4, category 4.
• Location. Optional. Location name and coordinates.
• Start Date with Start Time. Start Date is optional. Start Time is optional too, but can only be set if a Start Date has been set. There can be multiple Start Dates and Start Times if recurrence.
• Due Date with Due Time. Due Date is optional, but can be set only if a Start Date has been set. Due Time is optional if a Due Date has been specified. There can be multiple Due Dates and Due Times if recurrence (and linked to corresponding Start Dates and Start Times).
• Apps To Open. Optional. This allows to open apps when an event is about to start. The apps to launch are specified.
• Files To Open. Optional. This allows to open files when an event is about to start. To open files, file paths and/or opening files with a specific app are used. If only a path to a file is used, the system opens it with a default app.
• Web Links To Open. Optional. This allows to open web links when an event is about to start. Web links are specified with or without a web browser in which to open them. If no web browser is specified, the link is opened with the system's default web browser.
• Completion. Optional. This property is left blank to not use the completion level for a task. It is set to any other possible value registered by the app. This property will be updated according to the value set by the user using a notification that has the "Completion" action (see "Notification Actions" below).
• Participants. Optional.

Reminder Registration

• Core Registration.
• Reminder. A reminder can be added only if a Start Date and a Due Date has been set. Options are:
  • "before-start" for a reminder before the task starts. Set date, days, hours, and minutes at which the reminder must start (e.g. yyyy-MM-dd.HH:mm) and before the task start; an error is returned if the reminder is not before the task start. Set to "0" or leave blank for no reminder. There can be multiple "before-start" reminders.
  • "to-open" for a reminder to open apps, files, and/or web links specified above before the task start. Set the time in minutes before the task starts; this will be the time at which all apps, files, and/or web links will be opened. If minutes are set to "0" or left blank, there is no reminder. This option can be used only one time for a task.
  • "continued-task" for a reminder to continue a task (i.e. for task that spawn more than 1 day, but has not been split into subtasks). Set date, days, hours, and minutes at which the reminder must start (e.g. yyyy-MM-dd.HH:mm) and in the interval between the task start and the task end; an error is returned if the reminder is not in the interval. If set to "0" or left blank, there is no reminder. A "completion" option can be enabled if setting completion level of a task is needed; the completion level is put on a notification (see below "Notification Actions"). There can be multiple "continued-task" reminders.
  • "before-end" for a reminder before the task ends. Set the time in minutes before the task end and in the interval between task start and task end; an error is returned if the reminder is outside of the interval. Set to "0" or leave blank for no reminder. There can be multiple "before-end" reminders.
  • "on-end" for a reminder on task end. Leave blank for no reminder. There can be only one "on-end" reminder.
• Description. Optional. A description to add to a "to-open", "before-start" or "before-end" reminder. Not possible for an "on-end" reminder. If not set, the event description is used instead.

Notification Actions

• Open Apps / Files / Web Links (or combination). This actions opens apps, files, and/or web links specified for a task. This action can only be triggered for "to-open" and "continued-task" reminders and for the notification when the task starts.
• Reschedule. This action is there in case a task has been canceled or postponed. It is set on all reminders and on the task start notification if the user missed rescheduling the task at the task start or on a reminder. (It is recommended to have user experience to reschedule tasks relative to events, simple reminders, and other tasks.)
• Completion. This action allows the user to set the completion level of a task. It is only available for the following reminders: "continued-task" with "completion" option enabled, "before-end", and "on-end".

Email Reminder

Since items and reminders will be added through a dedicated portal user interface, email reminders can be part of the portal instead of depending on an app.

Sensitivity Registration

(see https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/103)

Sensitivity concerns the sensitivity of the properties of an event, a simple reminder or a task. This defines how a notification must be displayed on the lock screen. This property applies to events with all their reminders, dated simple reminders, and dated tasks with reminders.

I think sensitivity should be a sub-property of:

• "Calendar" and "Category" properties in case of events;
• "List" and "Category" properties in case of simple reminders and tasks.

The values are:

• public. The notification is displayed with its full content.
• private. The notification is displayed only with the name of the event, simple reminder or task.
• secret. Show only that there is an event, a simple reminder or a task. The device must be unlocked to view content. Consider a possible differentiation between unimportant and important notifications.

Notification Importance

If an event (especially with a reminder), a dated simple reminder or a dated task (especially with a reminder) is added, it is certainly important for the user.

Questions

• Portal UI: Should the portal dialog be styled according to the desktop environment or to the app UI style?
• Registration: Are there more properties of events, simple reminders, and tasks to add?
• Notification Actions, "Open Apps / Files / Web Links (or combination)": Should this action be triggered manually, automatically (directly or with a countdown to cancel it), or choosing one of the two?
• Migration: How about migrating existing events, simple reminders, and tasks for apps that were not using the portal before? The thing would be to review each item, but that can be cumbersome if there are many items.

[Mikenux]

Other issues with the Task Store: #1027, #1025

[GeorgesStavracas]

To the best of my knowledge, there is no one planning on working on this proposal, and application developers haven't requested this kind of functionality for portals so far. At least not in the way it is currently specified. This issue, or any spiritual successor, can be reopened opportunistically if such necessity arises.

[Mikenux]

Need to investigate adding notes.