A lot of notes on one ID in Bear

I have some IDs that I would like to use Bear notes as my writing platform.
For example let’s say I have an ID for my companies sales process.
In my opinion, that is one thing → one ID.

Let’s say it has 4 subtitles. I don’t want the parent note to be too long so I would like to split that note in to 4 different notes.

Question is, can I have multiple notes in my Bear app with the same AC.ID? That would feel weird.

If the structure was with word documents, it would look like this:

11.11 Sales Process
  Prospecting.doc
  Sales Call.doc
  Closing.doc
  On-boarding.doc 

With bear notes it would look like this:

11.11 Sales Process
11.11 Prospecting
11.11 Sales Call
11.11 Closing
11.11 On-boarding

There is a lot of confusion at risk. How should I handle this? I really like the way Bear works for writing and brainstorming.

It’s an index, not an inventory.

Seems that I forgot the .doc also for the Bear example, that made it confusing.

My problem is that I would like to have notes written with Bear. If those notes are based around the same subject (let’s say repainting the kitchen), than they will have the same AC.ID and my Bear will have multiple notes with same AC.ID.

For example I could have these:

11.11 Repainting the kitchen (parent)
11.11 Color options for kitchen (subnote)
11.11 People to ask to help(subnote)
11.11 Notes about where things were (subnote)

Should I just have those notes be their own AC.ID? On my cases my notes are so long that it feels wrong to keep them in one note. And I don’t want to use Word for this, Bear feels so much better to write in.

Ah, I gotcha.

Yeah I think this is fine. I like the idea of (parent) so you know which is the ‘main’ note. I might even think about a standard for that, perhaps:

11.11 [P] Repainting the kitchen
11.11 Color options for kitchen
11.11 People to ask to help
11.11 Notes about where things were

Where [P] is the parent or [M] for main if you’re a coder or whatever else makes sense for you. Putting it at the front feels more noticeable?

And in this case you might not need an indication for the other notes, by implication they’re subnotes.

Interesting. If you go with this can you let us know how it works?

Yes, sounds good. I will try it this way!

I will come back later to tell if I had any problems along the way.

1 Like

One note right at the beginning; it is likely that will have only a handful of subnotes.

For that reason I felt it would be more clean to mark the subnote with [S]

My perfectionist mind will not accept that some of my main index entries have [P] in front and some do not. Marking the subnote fixes this ”problem”:grin:

2 Likes

I am deciding how to organize my weekly plans and came across this thread.

My requirements:

  • Use one ID to store them all.
  • Write them in my notes app (Bear).

Like @arttuhann said, if the structure was with Word documents this can be easily done on the file system. However, I want to use Bear and don’t see a way to do this without one long file with different headings. This is not the end of the world, but something tells me I could be doing this a better way.

I came across a similar problem here which links to The Academic Problem.

@johnnydecimal Is this thread related to The Academic Problem as well? Or is the solution that @arttuhann provided a good one for my requirements?

@arttuhann has this solution worked for you?

If they’re weekly plans I’d probably go with this. Assuming your ID is 11.11 Weekly plans.

11.11 2024-07-25 Weekly plan
11.11 2024-08-01 Weekly plan

…and so on. Then they’ll sort nicely.

Or, if you’re using Bear, they’ve improved how you can fold headers recently. So you could have a header per week, and just fold it when it gets old. Newer weeks at the top.

But I can see how one eventually-massive note feels a bit untidy.

1 Like

Just a brief passing thought here. I think “Bear” is a perfectly fine folder in a JD system.

There exists a way to mount iOS folders, including application folders, onto a regular file-system: GitHub - libimobiledevice/ifuse: A fuse filesystem to access the contents of iOS devices

This could then mean that each application on an iOS device is welcome to have its own JD ID if it solves a problem, with some kind of iFuse-JD-ID sync layer, and can then be subject to the parent file-system’s backup strategy from there.

A postfix kind:

11.11 Weekly plans
11.11 Weekly plan 2024-07-25
11.11 Weekly plan 2024-08-01
11.11 Weekly plan 2024-W34

1 Like

@lkcnn

It has worked but I have tweaked it a bit.

Right now I add two underlines before the note and that way I can visually see really fast that this is sub to something else.

Ohhhhh also a great idea. :heart_eyes: And when sorted by title this will group all ‘sub-notes’ together, which might be nice. Gets them out of the main area.