[Discussion] Rethinking Journals concept

[srg-kostyrko]

The more I work with journals thee more I get the feeling that having 2 journal types (calendar vs interval) was not a good idea. Partially I did it because I was working of Periodic Notes plugin. Even at that point it seemed not right but I did not see a better way at that moment.

After some considerations I plan to remove this dichotomy and have just one concept:

A journal is set of notes that you write on regular basis - daily, weekly, monthly or some custom period (like every 2 weeks).

For current concepts this means:

• Calendar journal - will be split into separate journal for every period
• Interval journal - will be a journal with custom period of writing

To compensate for some calendar journal functionality I plan to also add a concept of journal group (for example work or personal) - that will allow to have focused calendar view for just work related journals for example.

As this is quite a big of a change I plan to make it a major plugin release. Settings and data migration will be done automatically on first plugin start after update.

I would like to hear feedback. concerns or ideas from anyone using this plugin

[arnoesterhuizen]

I like the simplified view you propose: intervals are just intervals, and a calendar is just a set of intervals we've internationally agreed on.

I don't see the value for journal groups yet. wouldn't using existing tags be enough to meet the filtering requirement?

[srg-kostyrko]

Good question

I got an idea of journal group when I was thinking on how to keep same functionality in calendar-nav and calendar-timeline blocks. There you can get not only to current level (like daily) but to other notes within same calendar (like weekly, monthly or yearly notes) given they are active. As there will be no such direct connection we should somehow connect journals in other way. If you are using just one set of connected journal - you might not even need groups. But for people who have work vs personal journals combining everything in code blocks might be not convenient. Focused calendar view was a further idea on how to use groups.

In some sense you are right - groups are similar to tags just on journal level. But I wanted to avoid confusion as it might not fully work as regular tag - for example I don't see a way to make it searchable

If you have any other idea on how to change code blocks with new journal concept - please let me know

[arnoesterhuizen]

I want to make sure I understand what you are proposing:

Option 1

1. A user will add a journal in the plugin settings, but instead of choosing a type, they will be able to check all the intervals they want to add:
   1. Yearly, quarterly, monthly, weekly, daily, and/or a custom interval like every x weeks starting 2024-07-12
   2. intervals could be stored using a format like https://en.wikipedia.org/wiki/ISO_8601#Durations
2. The journal ID and journal-section will then be added in the frontmatter as usual
3. Code blocks like the following would be used to navigate the journals

    ```calendar-timeline
    journal-section: [one of: year | quarter | month | week | day | interval]
    journal: [journal ID]

or

# Option 2

1. A user will add a journal in the plugin settings, but instead of choosing a type, they will be able to **select a single interval** they want to add:
    1. Yearly, quarterly, monthly, weekly, daily, or a custom interval like every `x` weeks starting 2024-07-12
    4. intervals could be stored using a format like https://en.wikipedia.org/wiki/ISO_8601#Durations
1. A `journal-group` to connect the various intervals, as well as a `journal` ID and `journal-section` will be added to the frontmatter
2. Code blocks like the following would be used to navigate the journals

```markdown
    ```calendar-timeline
    journal-group: [month or year or interval]
    journal: [journal ID]
    journal-section: [not used anymore?]

or something completely different?

[arnoesterhuizen]

Using option 1 would move the journal type interval as a sub-option inside the current journal configuration, instead as a sibling, e.g.

[srg-kostyrko]

It is option 2 - for example instead one journal for daily and weekly notes there will be 2 separate journals

as for frontmatter

• journal-section would be removed as obsolete (it was needed before because one journal might have several different sections active at the same time)
• not sure about adding group as plugin can read it from config (but might be handy for queries probably)

code blocks will probably be renamed but ability to set what group or journal should be used will definitely be there

also as part of journal unification functionality that currently is only in interval journals will be avaliable for every journal - like start date, journal end (specific date or after some number of repetitions) and indexing

[arnoesterhuizen]

I feel that option 1 might be easier to understand for end-users, easier to design from an interface perspective, and it aligns better with the way the plugin already works, so less migration steps.

The plugin already makes provision for adding different sections to a journal, so adding a custom interval would just be another toggle switch with a configuration screen behind that. Grouping is then already built in (via the journal ID), and you'd need to do less to migrate -- less frontmatter properties to add/change.

With option two, I feel there is more risk of end-users misunderstanding how the grouping works, and additional places for user error if you have to fill in the journal-group for each journal. Then, updating the interface to somehow show the journals connected to the same group adds a layer of complexity.

Either option would need the same amount of work in the back-end, I suspect, so I'd vote for option 1 as being more user-friendly.

[arnoesterhuizen]

Interface mockup for option 1:

After adding a new journal, a toggle is added for a custom interval:

Settings for Custom interval notes already exist:

[srg-kostyrko]

Hm, good point I did not think that way

Though for more flexibility custom intervals should be probably not as toggle but with possibility to add multiple custom intervals

And maybe changing regular intervals (daily, weekly etc) to be added not as toggle as well - in case someone wants to have multiple writing intervals but not default ones