This design document describes a proposal for enhancing Calendar so that it can manage tasks in better ways.
The terminology used in this document is defined in Calendar Help's glossary.
These assumptions are the basis for this design:
- Calendar is primarily a calendar application.
It is not primarily a task-management application. It provides some basic features for managing tasks. Users who want more advanced ways to manage tasks should use an extension or a separate application that is dedicated to that purpose.
- The iCalendar standard is for data interchange
It does not limit the data that Calendar can store internally, nor the features that it can implement.
- Calendar is not groupware
Calendar is a personal calendar application that does not support group processes (like shared tasks, task allocation and workload balancing).
- Restrictions on events also apply to tasks
The ways that Calendar handles events might restrict the ways that it handles tasks. There is further discussion of this below.
The intention of this document is to keep the design within the existing restrictions in Calendar. There is no point in designing features that cannot be implemented.
There is also no point in designing task-management features that draw a lot of development effort away from core Calendar function.
General enhancements to Calendar that would particularly improve task- management can be noted in the Restrictions section below.
Enhancements that apply equally to tasks and events can be discussed in the Other remarks section below.
Enhancements that mainly apply to events are out of the scope of this document.
Different users prefer to manage tasks in different ways.
The following are radio button choices:
- Do not use Calendar to manage tasks
This user does not use tasks, or uses a separate application or extension to manage them. Hide the tasks list, and hide the menu choices and toolbar button that refer to tasks.
- Manage tasks and events separately.
This user keeps tasks separate from events. Tasks cannot be scheduled, (but they can still be converted to events).
- Manage tasks with events.
This user mixes events and scheduled tasks. Both events and scheduled tasks appear in all the main views.
- User can select different window layout views
This user wants to switch the task view area with the main day/week/month calendar view area within the application window and vice versa.
A task is a data object with the following properties:
- Identify the task in lists and views
- Description (called Note)
- Plain text content
- Calendar file
- Identifies the file where the task is stored
- Estimated elapsed time between starting the task and finishing it. (The elapsed time might be longer than the working time.)
- Default set in preferences, (initially one day).
- Date/time before which the task cannot start. Defaults to Latest and cannot be after Latest.
- Computed date/time when the task must start in order to be completed by Due.
- Optional date/time when the task is really to start. If scheduling is enabled, this schedules the task, placing it in the calendar views.
- If the scheduled start is set to a date/time after the Latest start, then the user must choose whether to change the duration, or to move Due (and perhaps Cutoff).
- Optional date/time when the task should be completed.
- Default set in preferences, (initially makes Latest now).
- Optional date/time when the task must be completed. Not applicable to tasks of Low importance.
- Default set in preferences, (initially none).
- Setting that defines what happens to a task that is not completed by its Due or Cutoff:
- The task must be completed. If it cannot be completed by its original Due, the Due is moved to allow it to be completed. If it cannot be completed by its original Cutoff, the Cutoff is moved to allow it to be completed.
- The task must be completed if that is possible before the cutoff date. If it cannot be completed by its original Due, then Due is moved to allow it to be completed. If it cannot be completed by its Cutoff, then the task is abandoned. Default.
- The task should be completed, if that is possible before the Due. If it cannot be completed by its Due, the task is abandoned. There is no Cutoff.
- Setting that suggests the order in which tasks are to be performed:
- High, Medium or Low.
- The actual order also depends on the Due and Cutoff. Default Medium.
- Percentage value from 0 (not started) to 100 (complete).
- Checkbox that cancels the task without deleting it. Clearing the checkbox reinstates the task.
- Computed value:
- Cancelled by user.
- Cancelled by program (see Importance, above).
- Complete is zero; Defer is in the future.
- For action
- Complete is zero; Defer is not set or in the past; Latest start is in the future.
- Complete is zero; Latest start is in the past.
- Complete is not 100; Due is now or in the past.
- Computed value that suggests the sequence of tasks for the user to perform, in effect sorting tasks by Status, Priority and Latest.
- The same meanings as for events (whatever that might be).
A task can raise an alarm for any or all of its date/time values:
- Defer, Latest, Scheduled, Due, Cutoff
Defults set in preferences.
A task can only have recurrence if Scheduled is set.
Due is its recurring date/time. Defer, Latest, Scheduled and Cutoff recur at the same fixed interval with respect to Due.
Complete and Completed are not supported.
Importance can be set, but it is ignored.
Each Cutoff must be before the next Defer, so that recurrences never overlap.
See the Restrictions section below for a better design.
The tasks list displays tasks in the selected calendars.
It has settings for hiding or including:
- Completed tasks
By default, the first column is Sequence and is sorted so that Overdue tasks are at the top, followed by Late tasks, then For action and finally Future. Within each of these Status groups, tasks are sorted by Priority. Tasks with the same Status and Priority are sorted by Latest, so that the first Latest is at the top.
Dragging a task from the tasks list and dropping on a main view schedules the task (if scheduling is turned on), or converts it into an event (otherwise).
This design changes the data items stored in a task, the user interface for tasks, and the tasks list.
The Latest and Status properties of a task are computed, but Calendar does not seem to support changing data items on schedule. So these properties could be computed for display by the tasks list, and computed again for storage whenever a task is edited.
This design should be compatible with existing Calendar data and with imported iCal data from other applications.
Restrictions and enhancements
Calendar restricts what can be done with entries, whether they are tasks or events. If some of these restrictions could be removed, then there could be enhancements to the way that Calendar handles tasks (and events).
This section describes some of these restrictions and enhancements.
Calendar cannot modify entries on schedule. The only supported scheduled action is to raise an alarm. If Calendar could modify entries on schedule, then the design for recurring events could be improved:
- Complete and Completed are reset by the program when Defer is
reached for the next occurrence.
Calendar cannot schedule entries. (Recurrence only adds multiple dates to a single entry.) If Calendar could schedule entries, then the design for recurring events could be improved more, allowing each recurrence to have its own Complete, Completed, etc, and to represent an independent task.
It is not clear how scheduled entries could be linked, or how they might share properties like Title and Note.
Undefined times, vague dates
Calendar only supports undefined times for All-day events, and it only allows dates to be specified as actual days. If Calendar could support undefined times in a more general way, then the design for events and tasks could be improved.
A task (or event) could be scheduled for a day, week or month at an unspecified time/date. This would allow it to appear in the views, in a similar way to an All-day event, without having a specific date and time.
Examples and scenarios
This section is for user scenarios that the design supports or does not support.
There needs to be a way to print the task list. There needs to be a way to import and export the task list.