[FR] Support weekly calendar

[annieappflowy]

Description

I'd like to have a weekly calendar to manage my weekly events and to-dos.

Impact

Calendar users who prefer to plan tasks by week

Additional Context

No response

[hgkamath]

Just attempting a more elaborate feature description of "A PLANNER" which is more than just a "Weekly calendar" / "Task scheduler"

Below, is a description of a paper-based planner-workflow system that many people do use after buying a paper based weekly-planner book. What is done by using pencil-marks, erasers, bookmarks and references should be mimicked by the digital system. My usage of this system is as best as I understand it. If you have used this system, you should be able to find mistakes in the intended flow.

I am sure other's will have their own variations to describe, that are similar to various paper-planner-schemes that are in use. It may be possibly to reconcile other systems with other planner-workflows, as long as they aren't inconsistent with one another, So that everyone can use their own planner-workflow.

PSGK v0.01 20230625 2380#issuecomment-1605653365 : A PLANNER SPECIFICATION (open spec)

1. Should embed the data format for Planner-Data for a planner-period inside a RFC-5545 icalendar ical format-data-stream.
   • This is a key-distinguishing-feature.
   • The planner mechanism should live and be managed in the ical. As a direct benefit the daily scheduled entries and tasks are transparently rendered by ical presentation software. Adding/deleting/modifying daily scheduled entries from any icalendar-software should also work seamlessly and concurrently with app usage. The app should pull any changes and do some housekeeping to keep the planner features in order.
   • Its not a good idea to create/invent a new planner file-format which has its own encoding for storing events, be it even in .txt or .md, because this will only make calendar round-tripping more difficult, as it will later necessitate inter-conversion between one kind of scheduling-specification to another. This inter-conversion is not a simple computer engineering problem. Hence, it is better to first work within the limitations of the ical format, and later hack the ical format itself to store data needed in order to add any functionality beyond what it can already. Many other planner/calendar tools stalemate their development and fail at this ical round-tripping stage as well as in the support of multi-device synchronization. They end up restricting the user to only do export from to ical-calendar using their client-software from a single device.
   • Most ical calendar services can transparently upload and allow download of ical data without losing anything. As an add benefit, ical-services may optimize synchronization by using ical data entries with creation and modification timestamps. The timestamps allow quick identification of only those ical data entries that have changed.
   • Data can be stored inside an ical-task-description. The data format holding the properties inside the task description could be json (TBD)
   • Most non-scheduled, non-event, non-task data can also be stored either in a special-event-entries such as a midnight entry of 1st day of planning period, (ex: Jan-1 00:00am) or a special-task-entries in ical-tasks (ex: ZZpsgk000). Call this the common-block.
   • Software-client app-instance-specific settings, like layout defaults, could also be stored in their own special-entry-task/block for speedy retrieval. A list of clientname:software:taskname mappings could also be saved in the common block. ex (host123:appname:ZZtask001). Call this the client-settings-block. No use is intended as of now.
   • If an external file-format it absolutely needed for non-scheduled data (if any) its better to store them in a second ancillary file.
   • The ical format is a marked-up plain text format. If required, one could embed the ical file as a text-block inside a plain-text .txt or .md file.
2. Should be able to configure the planning-period boundary (i.e. start of new planning year)
   • The planning-period is defined by its start-date and end-date
   • This essentially defines the planner-book. Different planner books will have different periods.
   • The common-block should have entries to store
     • planner-start-date: starting date of the planning-period in the book
     • planner-end-date: ending date of the planning-period in the book
   • Academic students may prefer August to be the start and July to be the end.
   • Some parts of the world may prefer start of spring (Mar-1/Apr-1/Feb-10=Chinese new year/configurable) as start of a new year or even use the luni-solar-calendar or lunar-calendar and so the start date on the solar-calendar varies from year to year.
   • Most working adults prefer Jan-1 to be start of new year to coincide with administrative and tax calendars.
   • Typically, planner period is 1 year. But a busier person may prefer half-yearly.
   • The ability to set planner period can also help in transitioning between an academic year to a fiscal new year by having a 5-month (Aug-Dec) planner-period to bridge the two.
3. Should ensure the planner-book has a name/identifier, as well as forward and backward references, in order to help with automated browsing across planner-period-boundaries
   • identifiers could be 2-letter series identifier followed by a planner-start-date ex: aa20230101
     • This makes planner book naming trivial, next successive planner book can be deduced from its planner-start-date.
     • Typically, a person only ever needs one series.
   • The common-block should have entries to store
     • planner-book-name: name/identifier of current-planner-book
     • previous-planner-book: name/identifier of previous-period-planner-book
       • The field is empty if a previous-planner-book does not exist.
     • next-planner-book: name/identifier of next-period-planner-book
       • The field is empty if a next-planner-book does not exist.
       • The next-planner-book's planner-start-date is usually the next day of the planner-end-date of the current book.
       • The next-planner-book's planner-start-date must not be less than the current-planner-book's end-date
       • As long as the next planner book is not created, the planner-end-date of a previous book should not be allowed to be changed easily. Tampering with end/start dates after a planner-book is created requires more care.
4. Should have a concept of role
   • example roles: parent-of, child-of, spouse, extended-family, neighbor, pet-owner, work-1, work-2, group-participation-1 ... , group-participation-2, ... , citizen, student, research, self-improvement, self-leisure
   • Every task (project/hierarchy/subtaskname) is done within the context of a role.
5. Should have an concept of project, subtask and scheduled-entry as follows
   • A subtask is essentially a todo-item, something that must be worked on and scheduled, usually resides in the task list
   • Subtasks have the following properties
     • task-state(active/inactive), priority(A/B/C/D), completion-state, no-longer-bring-forward-flag, role
     • entry descriptor for 4-quadrant identifier for: important/unimportant + immediate/deffer-able
     • expected duration, percentage-completed, deferred, deferred-reason, waiting-on, waited-on-by
   • Projects are a logical grouping of subprojects and subtasks
     • Projects can form a hierarchy, but not a cycle
     • Projectnames including those of subprojects are unique
     • A project or subtask can have only one unique parent. (maybe relaxable, unsure)
     • A project has within in list of subprojects and a list of its own subtasks
   • An entry is that which is scheduled and shown in the periodic-sheets daily-task-entries.
     • It could be either be an event or a time duration allocated to work on a project/subtask
       • events usually are commitments made as part of role/project (ex attending colloquiums), group-meeting, tennis-practice etc. Its not always necessary to have an assoiciated subtask. The subtask to participate in events is implicit.
   • An entry should have a title, description, start-time, duration-info, location-info, recurring-info,
6. Should be visually presented as sections
   • GUI could be in a side-bar or tabs
7. Should have a section for defining roles
   • The defied roles are stored in the ical's common-block
8. Should have a section for configuring projects and subtasks
   • The projects are stored as task-entries in the ical
9. Should have a section for custom-sheets (maybe 9. and 10. could merge?)
   • These sheets are similar to blank paper sheets
   • These could be links to sheets elsewhere in the app, but it is useful to consolidate them inside the planner-book.
   • This are used to save for quick-reference/emergency, personal/private information of self/family members/assets etc.
   • The blank sheets are stored as task-entries in the ical with prefix ZZSP_pb<pbid>_ ex ZZSP_pb<pbid>_INFO
   • The common-block should have an entry for list of custom-sheets
10. Should have a section for archive-able special sheets such as mission, vision, goals statements
    • These section views should look like a sheet of paper
    • Goals, mission, vision are not the same as projects or subtasks
      • These set direction for personal growth and higher purposes in various roles.
      • They guide what projects one might choose to do.
      • The baser simplest of goals may be interpreted as a performance target or milestones for some activities.
    • One should be able to review/edit
      • After having edited, a user is expected to distinguish between a major change and minor changes.
      • If it is a major change then before over-writing, the older statement should be date-stamped/archived.
    • A subtask entry is usually described by name. The project hierarchy part is optional as it may not make sense to have concepts of project at the goal level.
    • When a subtask entry is first created, entries are created in the ical-task-list. Usually, entries in this section are not scheduled, but doesn't hurt to keep the schedule-ability-features, The default behavior during entry creation need not require completion of time, date,recurrence fields.
    • Entries on the sheet should be sortable by role/priority, optionally group-split by the task-state , or hide one or the other
    • The view should be filterable so as to focus on fewer relevant entries. The filtered-out entries can be pushed to the bottom, greyed-out and/or made invisible.
    • These sheets are mandatorily archived on a planner-books planning-period-boundary (ex: every year), even if no change/edit.
    • One should be able to go back in time to see sheets of older archived statements.
    • The special sheets are stored as task-entries in the ical with prefix ZZSP_pb<pbid>_dt<mmdd>_ ex ZZSH_PBaa20230101_DT1231_VISION
      • DT0000 can be used to refer to the default undatestamped sheet.
    • The common-block should have an entry for the list of special-sheets
11. Should have a section for periodic sheets
    • These section views should look like ruled sheets of paper, with checkbox and other indicators for completion, priority
    • Periodic sheets contain the todos(tasks):
    • Periodic sheets are used to keep todo-s for various time-spans
    • Time-spans include daily/weekly/fortnightly/monthly/semi-annually/yearly/biennially/4-yearly/longterm
      • Yes, the event-start, event-duration, event-recurrence could lie beyond the planning-period of the planner-book.
      • Later, it will be described how planner Housekeeping, will make some alterations.
    • The default view is the daily-periodic-sheet in daily-tasks-by-day view, set to "today"
    • A subtask entry is fully described by project/hierarchy/subtaskname
    • When a subtask entry is first created, entries are created in the ical-task-list and are optionally scheduled. A task is taken up during a time scheduled for tasks of that role/project. An entry becomes inactive when no future scheduled event exists in which it can be taken up, such as time set aside for working on a prefix of projectP1/SP1/SSP1/hierarchy,
    • Entries on the sheet should be sortable by role/priority, optionally group-split by the task-state , or hide one or the other
    • The view should be filterable so as to focus on fewer relevant entries. The filtered-out entries can be pushed to the bottom, greyed-out and/or made invisible.
    • When an entry is marked as completed,
      • It is indicated by a check sign (an incomplete task may have a v-center-dot)
      • The entry's "no-longer-bring-forward-flag" is also set.
      • In some orderings, completed entries should be push-able to the bottom in the list with other completed tasks, as it no longer competes for focus.
    • The daily periodic sheet is special in that, in addition to list of daily-task-entries-by-day, it should also have following additional views listed below
      • The additional views include
        • daily-task-entries-by-day but also over longer time-spans such as daily-task-entries-by-week and daily-task-entries-by-month.
          • The daily-task-entries-by-week is what you would call the WEEKLY-CALENDAR.
          • The daily-task-entries-by-month is what you would call the MONTHLY-CALENDAR.
        • Each of these views mentioned has a corresponding hourly schedule view, wherein tasks in active state in the day are visualized by placing them as blocks at nearest half-hourly points.
      • These views are different from the weekly monthly and other periodic sheets. These views contain the same daily-entries.
        • The tasks-by-day is like a single ruled sheet
        • The tasks-by-week shows the same daily tasks of 7 days in a 7-column sheet
        • the tasks-by-month shows the same daily tasks arranged in a grid of 5-row-7-column sheet
      • These views should look similar to a sheet of paper
      • Ability to sort the views of the todo/task list by role/priority, optionally group-split by the task-state , or hide one or the other
      • These view should also be filterable so as to focus on fewer relevant entries. The filtered-out entries can be pushed to the bottom, greyed-out and/or made invisible.
    • One should be able to browse forward and backwards in time
    • BRING-FORWARD/POPULATE SHEET FEATURE
      • Normally, a new periodic-sheet should be blank except for events that have a recurrence in that period.
      • When a user has decided a period (day,week, month) has ended, user goes to new sheet and presses populate-sheet-button,
        • If recurring tasks are missing in that period-sheet, they are to be re-populated
        • All tasks from last period (day/week/month...) that were marked not-completed and no-longer-bring-forward-flag is unchecked will be copied to the next period, and its task-state will be reset to in-active state. If future page exists, the user must manually reconcile.
12. Should perform housekeeping when the planner-book is opened when current-time is beyond the planning-period-boundary (end-date) of the planner-book.
    • An entry in the common-block could store
      • housekeeping-already-done: to indicate whether housekeeping has already been done before
        • The settings needs needs to be cleared to false in order to allow rerun housekeeping.
    • After present time passes the the planning-period-end-date boundary (ex: a year boundary, such as the New Year, the day after Dec 31st) and the setting housekeeping-already-done is not set.
      • If the next-period-planner-book entry is not set, or if next-period-planner-book cannot be found, a new planning-period planner-book should be created and opened.
        • The planning-period of the new book, can be inferred to be same-duration as but continuing from the past-planning-period
      • This ensures that when a planning-book for a planning-period is opened, the software only has to process those events in the current planning-period.
      • Special sheets and Custom sheets should be copied (allowing those in the previous period to be archived)
      • Recurring events should be recreated in the sheet for the new year, with the same recurrence.
      • Unfinished project/hierarchy/subtasks should be copied from the previous-planning-period
      • An event that spans across the period boundary is broken into two, one in each planning-period.
      • The new planner book will keep the link to the ical
      • set the previous planning period variable
    • In the past planning-period planner-book
      • The recurring events of the past year should be ended.
      • Then the past planning-period planner-book should be archived.
      • set housekeeping-already-done variable
      • set the next-planning-period variable
    • If a planner period book is being opened, the planner period book is opened in a special edit mode
      • This edit mode requires verification and confirmation as every edit as these are changes to records of the past, and can potentially introduce discontinuity into the next planner-period planner-book. Correcting typos, information, description are less problematic. Changing completion status, recurrence schedules etc are more problematic
      • As a general rule, one should not edit passed-period planner-books.
      • The old planner book should no longer automatically synchronize with ical.
    • This allows a year-wise archival system of planner books.
13. Optionally as a subfeature integrate with a TIME-TRACKER plugin
    • A role/project/subtask is associated with one in the time tracker plugin
    • Scheduling a subtask in the today sheet, should change the task-state to active, automatically notify time-tracker plugin to track time spent on the role/project/subtask. Time tracking stops when subtask is ended in time-tracker. As a person can't be working on two things simultaneously, starting a different subtask could stop the subtask currently tracked by the timetracker.
14. Should be able to do CALENDAR SYNCING:
    • Ability to sync with ical/caldav/google-calendar
    • A planner-book should sync events only within its planner-period (start-date to end-date)
    • At the start, a sanity check operation can
      • check old planner-book closure, that is whether
        • recurring events created in past period have been ended,
        • tasks created in past period have also been ended (no-longer-bring-forward set).
      • ask and confirm to ensure closure.
    • round-trip syncing of RFC-5545 icalendar
    • https://datatracker.ietf.org/doc/html/rfc5545
15. Should have the ability to export data
    • export options include:
      • planner-year-book
      • periodic-sheet-ranges
      • individual sheets
    • export to formats : markdown, pdf, ical/icsfile

Essence of this planner system:

• A person, has roles in life
• A person, has a vision, mission and goals pertaining to these roles and needs to review these often
• A person, in each role, has a hierarchy of projects, each of which have subtasks
• A person, has at any given time a limited number of tasks can be worked on
• A person, must ahead of time make a schedule and plan their time, so as when to do a role/project
• A person, when it is time to execute, needs to see what has to be done for the day, and what subtasks can be done for any given time.
  • In the time slot for the role/project, a person works on a subtask that leads to its completion
• goals, projects, subtasks have relative priorities, they have deadlines, they need resources, someone else maybe waiting on you to deliver results them.
• long term deadlines must be reviewable.
• In the paper system, a person carries all the future sheets a person needs, often up to two months ahead.
• The planner system is self-documenting, itself records on what roles/projects/subtasks, a person used their time in a giving planning period.
• Spacial placement of scheduled-events and todo-subtasks is important as it helps visualization of time.

Advantage of Paper over Digital

• The finite size of paper, and the limited-ability-carry forces a person to be economical on what to note.
• The tediousness of copying uncompleted tasks does make a user think whether the task itself was necessary, and encourages more pragmatic goals and task culling.
• Does not need an operational computer or electricity to use.
• Coloring and stickers allow for personalization.
• Secure to the extent the owner physically takes care of the planner

Advantage of Digital over Paper

• Automate the tedious-task of having to copy goals/projects/subtasks
• Low priority unattended sub-tasks can projects can be identified and the view can be de-cluttered.
• Its possible to document, log many comments and yet still have them out of view, not cluttering the planning-views.
• Secure to the extent one follows computer-security guidelines and backs-up data.

Notes:

• The WEEKLY-CALENDAR / MONTHLY-CALENDAR are just a view of a daily planner sheets. A PLANNER does much more.
• Being able to go back and forward in time is important to see/study how things panned out, plan and schedule for the future
• The following could be sub-features to achieve later
  • ENTRY-SEARCH
  • ADV-ENTRY-FILTERING in view
  • INTEGRATION WITH TIME-TRACKER
  • CALENDAR-SYNCING
  • INTEGRATION WITH PROJECT-PLANNER
  • ANALYSIS, VISUALIZATION and REPORTS to study activities per role or project
  • COLLABORATION/GROUP FEATURES

[wwwdyne]

Recurring task is a killer-feature of Notion's calendar.
@hgkamath @annieappflowy
Is it possible to implement it in AppFlowy this year?
Please add it to the roadmap for 2024.