Jump To…: Create New Notes in Inbox (Not as Child Notes)

[werererer]

Describe feature

Using the Jump To... Feature, it feels more natural for newly created notes to go into the Inbox instead of becoming child notes.

The child-note approach makes sense when you’re explicitly structuring a hierarchy, but when capturing something new (especially after a search), the intent is usually to jot first, organize later.

Other tools follow this “inbox-first” approach:

Notion: creating a new page from search or quick add places it flat, essentially working as an inbox. Example:
https://images.ctfassets.net/spoqsaf9291f/1EAjpBexcA1109GPKOGcFd/a5f3e73ade6f52c9fb12c4e2adcf6b34/Search_in_your_workspace_-_hero.png

Amplenote: defaults captures into daily jots, which act like an inbox before organizing.
https://images.amplenote.com/4cf4e692-e58a-11ec-a6de-f2e2bc5c6b4b/897bb357-d20e-4cc2-983c-3240f64b3fcf.png

Logseq: everything captured flows into journals, which function as a daily inbox.
https://en.wikipedia.org/wiki/Logseq

New Workflow Possibilities

This enables a smooth workflow:

1. Jump to a Note, you may need to edit now.
2. The Note doesn't exist yet
3. So you press the Button to create it in the Inbox.
4. Finished.

Additional Information

Maybe I misunderstood how this button works, would be happy to get some insight, @zadam

[rom1dep]

@werererer Actually, Trilium supports the kind of "inbox-first" workflow you promote. It's pretty well hidden, but all you need for that is to define #inbox as attribute for the note under which you want all newly created notes to go (you can even have separate/per workspace inboxes with #workspaceInbox). In the absence of an inbox, a new daynote gets added to the journal.

That said, you are right in that the "Jump to" window shouldn't go against the default behaviour. I think a fix here would be to offer 2 options:

• "Create 'My Notes'" → this would place it under the inbox if one is defined, or under the journal alternatively, or as a child note, as a last resort
• "Create 'My Notes'" as a child note → current default

[eliandoran]

@rom1dep , I believe the existing behavior of note creation in jump to note is not very good. Jump to note is by definition going to another note, so why should notes be created in the current note?

If the user wants to create a subnote quickly, there are already other options:

• There's a keyboard shortcut to create a sub-note and activate it.
• The @ autocompletion can be used and a child note can be created from there.
• The include note button also has this child note creation behaviour.

Having two options, in my opinion, complicates the UX for little benefit.
So, I think the best solution is to go with your first bullet point only.

[werererer]

@rom1dep yes, i am aware of this feature, and I like it very much.
However lets take your suggestion and apply it, by comparing your proposed workflow vs the worklow after change:

Old

So the workflow would be:

1. Search for a note → typing: ~1 s
2. Wait for search to load → 200–300 ms (~0.2–0.3 s)
3. Realize it’s not there → human reaction: ~1 s ¹
4. Copy what you wrote → 0.5 s
5. Type > → 0.2 s
6. Type “Create Note Into Inbox” → 2–3 s
7. Press Enter → 0.1 s
8. Wait for new note to open → 200–300 ms (~0.2–0.3 s)
9. Press Ctrl+V → 0.1 s

Resulting in 5.3 s - 6.5 s per new note.

And now think about spamming it, assume you can spam between 300 - 800 ² new notes a day.
Lets calculate the worst case:
5.3 s x 800 = 70.67 minutes
6.5 s x 800 = 86.67 minutes

Then this workflow results in 70.67 min - 86.67 min

New

1. Search for a note -> Typing 1.0 s
2. Wait for search to load -> 200-300 ms
3. Press New Note -> create note 1 s
   Total per note 2.2–2.3 s

Assume Worst Case 800 New Notes a day.

2.2 s × 800 = 1760 s = 29.3 min
2.3 s × 800 = 1840 s = 30.7 min

Comparison

Old workflow (5.3–6.5 s per note): 70.67–86.7 min/day (800 notes)
New workflow (2.2–2.3 s per note): 29.3–30.7 min/day (800 notes)

Time saved (lower bound): 41.33 minutes/day
Time saved (upper bound): 40 minutes/day

Percentage saved (lower bound): 58.49%
Percentage saved (upper bound): 56.60%

Conclusion

While there are solutions to create new notes, the improved workflow leads to significant (> 50%) time savings. Time savings may induce the creation of new notes, which I assume is a positive effect ³.

Appendix

Appendix 1

I don't think we should have two options, but only the option to create it in the inbox, keeping it simple. As @eliandoran said, there are sufficient options to create a note in the inbox. (1. Ctrl + p, write the title you Want is very natural, as you don't jump around anyways, but write it as a subnote)

Appendix 2

The same issue exists, if you use @ to link to notes

Footnotes

1. https://www.fahrschule-123.de/en/driving-licence-training/driving-licence-knowledge/reaction-distance#:~:text=1%20second , Lets just assume note taking is like driving resulting in same reaction time ↩

2. I only have own numbers, spamming new Notes in University all day (one Concept per note), resulted in daily increase of notes between 300 - 800 ↩

3. https://en.wikipedia.org/wiki/Induced_demand ↩

[rom1dep]

Having two options, in my opinion, complicates the UX for little benefit.

@eliandoran I won't die on this hill, but I think it's good to keep the option to quickly create a child-note with the title provided in "jump to", just because we can't know how many users have built muscle-memory around this workflow.
Compared to some of the proposed alternatives, it saves from the hassle of re-typing the note title in full. In terms of UX, I really like the command palette and how it looks when triggered with > create (see screenshot above): it's clean, teaches the user about new shortcuts, and provides options instead of feeling like a frustrating dead-end.

Since you mention the @ autocompletion and the include/hyperlinking, I think they should undergo the same treatment (by default, pressing enter should place the note in the default location, let it be the inbox/journal depending on the configuration, but a child note should be on the menu one key away, why not?)

@werererer No need to convince me of the merits of consistent defaults, or inboxes in general :-) . I would just prefer we don't throw the baby out with the bathwater and "punish" users with this.