I’ll share a personal calendaring philosophy. Take it for what it’s worth, but the less you schedule, the better for your productivity and the better for your mental health.
By productivity, I refer literally to your ability to produce content of some sort, be it written prose, be it business solutions, be it space music. And for productivity of authentic value, you shouldn’t require a calendar entry.
As ancient as the topic may appear, I still encounter much obsessive and even self-destructive behavior in how I observe some people manage their time. But anyway…
Any assimilated and beneficial habits likewise shouldn’t factor into the calendar. Neither should your hobbies or those activities you take genuine pleasure in.
It’s the ad-hoc meetings and events that normally consume it. So commit to less. Or empty the calendar altogether. Say no to everything.
And still I’ve known individuals to take immense pride in the vastly saturated calendar grid of colored rectangles: meditation, calendar entry; barbell curls: calendar entry; wipe the counter tops: calendar; blend a detoxifying cocktail; call X; check correspondences; purchase y, z, α, β, Ω; replace the blown fuse; write in the journal; practice the ukulele.
I’ve too probably contaminated various calendaring systems with similar nonsense. And while some of it may warrant a reminder, it probably shouldn’t occupy the calendar.
This is material for disposable to-do lists, if it even deserves to be documented. There usually isn’t a need to date/time-stamp all manner of rubbish; not unless you pretend to self-induce a sense of hyperactivity.
With hopefully but a few items remaining that merit a calendaring system, I’ve experimented with a few tools.
Paper
A paper calendar I find preferable. And I don’t mean a glorified planner of craftily designed labels and grids.
A sheet of paper, an index card, or a notebook suffices. Denote the repeated events on one sheet, and the one-time, ad-hoc content in another rolling section, purging the older entries. There you have a calendaring system; a much lighter calendaring system; but effective.
Hopefully most activity falls among the repeated events. This way you need but glance at one compact list in one location. There is not a benefit in seeing the repeated content replicated from day-to-day, week-to-week, month-to-month, per the fatiguing software calendar rendering mechanisms.
And with a paper solution one is not overwhelmed with metadata. At a minimum, and in a majority of cases, even a time-sensitive appointment is nothing but a month/day, a start time, and a terse (or longer) description.
Digital
I’ve used calcurse for a long time, a Unix-based CLI calendar with an optional Ncurses interface. Under the guise of an extremely lightweight solution visually, it nonetheless draws certain inspiration from the monolithic, enterprise products, such as a calendar grid, a list of appointments and a task list.
There’s still much less, and as offline CLI solutions tend to be, it operates at lightning speed. But it’s not without a share of configuration, fields and connector functions to represent data of otherwise brute simplicity.
The digital solution I’ve ultimately adapted is the classic BSD Calendar, usually available within repositories in Linux/Unix-based distributions as well as compilable from source.
The most drawing feature is the lack of an interface. Nor does it need one.
The calendar is entirely manageable within a specially (and simply) formatted plain text file that bears a strong resemblance to the simplicity of the paper solution I’ve described:
date <TAB> description
date <TAB> description
<TAB> more description
<TAB> more description
...
date <TAB> description
Every entry is but a date and a one or multi-line description. No need for a separate ‘notes’ file specific to the entry (à la Calcurse). No need for a separate view to redact all possible metadata.
The most curious aspect is the ‘date field’. It accepts a combination of formats that follow these man page examples:
#include <calendar.usholiday>
#include <calendar.birthday>
6/15 June 15 (if ambiguous, will default to month/day).
Jun. 15 June 15.
15 June June 15.
Thursday Every Thursday.
15 * 15th of every month.
May Sun+2 second Sunday in May (Muttertag)
04/SunLast last Sunday in April,
summer time in Europe
As you see, the date format enables all manner of flexible repeatability syntax.
There isn’t a need for designated start or end time fields. If necessary, that can form part of the description, as well as whatever other nonessential metadata:
4/18 10:15 Call with X.
<phone>
<email>
My much beloved feature is the C-syntax compatible #include <calendar> optional directives. These enable you to abstract the calendar files into separate components.
For instance, the primary calendar.2020 could include the following supporting calendars:
#include 'calendar.yearly'
#include 'calendar.birthdays'
#include 'calendar.holidays'
Albeit minimal, all this syntax is necessary. The main command-line executable, if invoked, outputs all entries for the next couple of days (or any time period optionally passed in), accumulated from the main and all included calendar files, and properly sorted by date (and even time, if present in the description).
But the underlying syntax follows such a simple, almost paper-based structure, that I often find myself merely glancing at the file without so much as running the utility.
Mobility
Is there a need for Cloud-based solutions? Synchronization? I don’t think so. A single, offline calendar I find sufficient for most needs, although I still synchronize the plain text documents with a (personal) backup server in case of hardware failure.
If wanting to access a calendar entry while mobile, simply make a couple of paper notes. Or employ a paper solution, per the first strategy.
Again, I allude to a relatively sparse calendar system, not oversaturated. You shouldn’t much struggle to recall the important and the limited pending content.
I mention nothing of a mobile phone since the solution, as well as most others I here present, cater to a digitally-light way of being.
Lastly, take comfort in this. The notion of calendaring, insofar as connecting tasks with dates, has existed over millennia. There’s nothing in it that strictly demands centralized, monolithic, closed-down products or a mobile device. Everything necessary you have among a few simple tools.
Questions, comments? Connect.