Read on Twitter
1/ Good morning, @RoamResearch early-adopter community, I& #39;d like to ask your input on a concept. (that& #39;s why I am putting the "Roamsignal" up in the clouds.)
The topic of this thread is, "Elegant Calendars in Complex Worlds", and it& #39;s about Calendars, and how we want them to be.
The topic of this thread is, "Elegant Calendars in Complex Worlds", and it& #39;s about Calendars, and how we want them to be.
2/ "Elegant" is a word that I am using here, in the way that mathematicians use it - that is:"elegant solutions" are simple pathways through complex territories - a concept that software engineers sometimes call "Simplexity".
@RoamResearch, as of this writing, is highly Simplex.
@RoamResearch, as of this writing, is highly Simplex.
3/ For example, it doesn& #39;t really have a fully fledged calendaring system - yet.
Dated entries have some functionality, but we can& #39;t yet do many of the things that, e.g., Google Calendar can do. No monthly views, no programmably-recurring events, no quick social sharing.
Dated entries have some functionality, but we can& #39;t yet do many of the things that, e.g., Google Calendar can do. No monthly views, no programmably-recurring events, no quick social sharing.
4/ But this doesn& #39;t have to be a limitation - I think it might be an opportunity:
*What if we rethink the calendar entirely?*
What if we question the arbitrary structure of what we currently have - and try to break it down to its atomic basis?
*What if we rethink the calendar entirely?*
What if we question the arbitrary structure of what we currently have - and try to break it down to its atomic basis?
5/ (P.S., if you need Google Calendar RN, no worries, it& #39;s a trivial thing to throw a hyperlink into your daily note-page; and macro-generators like TextExpander you can automatically always bring up your current-day view, in G-Calendar... but that& #39;s an aside, here ...)
6/ Because ... what if we re-built the very concept of a calendar, from scratch?
What if @RoamResearch could disrupt the hierarchy of existing calendars, in some of the same ways it has disrupted the hierarchies within existing knowledge-systems?
I have some ideas...
https://abs.twimg.com/emoji/v2/... draggable="false" alt="đ±" title="Setzling" aria-label="Emoji: Setzling">https://abs.twimg.com/emoji/v2/... draggable="false" alt="đ±" title="Setzling" aria-label="Emoji: Setzling">https://abs.twimg.com/emoji/v2/... draggable="false" alt="đ±" title="Setzling" aria-label="Emoji: Setzling">
What if @RoamResearch could disrupt the hierarchy of existing calendars, in some of the same ways it has disrupted the hierarchies within existing knowledge-systems?
I have some ideas...
7/ We can& #39;t just toss the anchor to the Gregorian Calendar.
It& #39;s the basis of our "common language" around time- at least for the large portion of the world that has adopted it.
But maybe the anchor should be minimal,
+ the tools built on top of it, as flexible as possible.
It& #39;s the basis of our "common language" around time- at least for the large portion of the world that has adopted it.
But maybe the anchor should be minimal,
+ the tools built on top of it, as flexible as possible.
8/In a sense the "Daily Note" is that anchor.
But what else do we need?
I propose a particular kind of data-structure, which I would call a "cycle".
A week is a cycle. It& #39;s a kind of variable that can have seven values, dependent on time. A month is a cycle; so is a year.
But what else do we need?
I propose a particular kind of data-structure, which I would call a "cycle".
A week is a cycle. It& #39;s a kind of variable that can have seven values, dependent on time. A month is a cycle; so is a year.
9/ (Frustratingly, the cycles of "week", "month", and "year" don& #39;t really align. And "year" doesn& #39;t really even align with "day")
But that& #39;s precisely why it would be wonderful to "define" them independently;
INSTEAD of the implicit question of G-cal:
"What day is this?" -->
But that& #39;s precisely why it would be wonderful to "define" them independently;
INSTEAD of the implicit question of G-cal:
"What day is this?" -->
10/ We would ask a much more powerful question:
"What are the cycles, to which this day belongs?"
AND we would have the power to define those cycles ourselves.
(Yes - anchored to Gregorian-calendar cycles, if needed.)
but the Gregorian calendar is just a starting point.
"What are the cycles, to which this day belongs?"
AND we would have the power to define those cycles ourselves.
(Yes - anchored to Gregorian-calendar cycles, if needed.)
but the Gregorian calendar is just a starting point.
11/ Cycles of birthdays, relationships, academic years, biz quarters, aren& #39;t really contained within the Gregorian calendar.
In far more important psychological ways, they DEFINE the Gregorian calendar.
What if we respected that hierarchy, within our own organizing systems?
In far more important psychological ways, they DEFINE the Gregorian calendar.
What if we respected that hierarchy, within our own organizing systems?
12/ What I& #39;m suggesting is that a "cycle" be a primary kind of data-structure for building calendars, and that its existence be entirely user-defined, included its relationship with all the other "cycles" within any given calendar.
The "cycle" deserves to be the "atomic unit".
The "cycle" deserves to be the "atomic unit".
13/ You would "build" yr days, weeks, months and years out of defined "cycles". They could map + anchor to the Gregorian Calendar, but wouldn& #39;t BE the Gr& #39;gor& #39;n Calendar.
For a beautiful example, just look at the "ToDo" checkbox, which is a tiny example of
"a bi-valent cycle."
For a beautiful example, just look at the "ToDo" checkbox, which is a tiny example of
"a bi-valent cycle."
14/ It marks time -
Time before (time of intent); time of completion (done); time after.
It& #39;s a tiny marker of "entropy-locally-decreasing", in your personal world.
Lots of other things could work this way.
Some maybe would need to be automated, like the cycle "Week" -
Time before (time of intent); time of completion (done); time after.
It& #39;s a tiny marker of "entropy-locally-decreasing", in your personal world.
Lots of other things could work this way.
Some maybe would need to be automated, like the cycle "Week" -
15/ For obvious, practical reasons, we would need to be able to "define that" as a circular cycle that increments through seven steps.
But if that cycle could be nested within other cycles, some of them user-defined, and also have other things nested within it -
But if that cycle could be nested within other cycles, some of them user-defined, and also have other things nested within it -
16/ We& #39;d have something very powerful.
Lots of things could be neatly "fit" within a flexible structure of things-in-time that both contain-and-are-contained.
Projects are cycles. Spaced repetition study is a cycle. Friends& #39; birthdays are cycles. Academic years are cycles.
Lots of things could be neatly "fit" within a flexible structure of things-in-time that both contain-and-are-contained.
Projects are cycles. Spaced repetition study is a cycle. Friends& #39; birthdays are cycles. Academic years are cycles.
17/ From trivial things (want to read-->reading-->finished reading, applied to a book) to big things (completing a Ph.D maybe, launching a new company, seeing a kid graduate) the "cycles" we define, each wi/ their beginnings, intermediates, and conclusions, are how we plan lives.
18/ Is there a way we can make the "cycle" primary?
I think there might be. And I think @RoamResearch offers us some amazing tools to do so.
What I am imagining is a calendar that doesn& #39;t look like boxes in a grid, but more like ripples on a pond.
I think there might be. And I think @RoamResearch offers us some amazing tools to do so.
What I am imagining is a calendar that doesn& #39;t look like boxes in a grid, but more like ripples on a pond.
19/ Something that might help us rethink our relationship, to time itself.
"The most authentic endings, are the ones that are already revolving to a new beginning" - Sam Shepard
alright, thread over. /fin/.
comments welcome.
"The most authentic endings, are the ones that are already revolving to a new beginning" - Sam Shepard
alright, thread over. /fin/.
comments welcome.
20/ @Malcolm_Ocean , @kcorazo , @RoamBrain , @Mappletons , @CatoMinor3, @JoelChan86 , @RobertHaisfield - specifically wondering if you guys might have any thoughts on the above thread -
TIA if you have anything to add/question/clarify here, etc etc.
TIA if you have anything to add/question/clarify here, etc etc.
21/ @anthilemoon would love to hear if you have any thoughts on the above, too - especially in light of the idea that "calendars are really just maps of time"
Wondering if your map-thinking explorations, might have led you to any more elegant solutions, here.
TIA.
Wondering if your map-thinking explorations, might have led you to any more elegant solutions, here.
TIA.
22/ Wait WHAT I wrote this thread about calendars, and time, and I forgot to ask the one person I know who is a full time historian AND an early Roam adopter (that would be @calhistorian) -
Mark, any ideas on the above thread?
TIA for any thoughts you might have on the topic!
Mark, any ideas on the above thread?
TIA for any thoughts you might have on the topic!
23/ and also... @codexeditor, do you have any further thoughts on the best data-structures to use, for flexible and powerful representation of the unfolding of events, through time?
