Currently notes have two “titles”: the “name” shown on the top of the window (basically hidden in current design and wasting tons of space in the new design) and the first header in the markdown text itself. When creating a note Joplin automatically creates the first from the second, but does not later keep them in sync: if changing the title you have to clumsily change it in two places. When printing the note the title is printed twice: first the “name” and then the markdown content that typically replicates it.
I think the “name” is entirely superfluous and should be removed. The first nonempty line of the note should be used as its name displayed in note lists etc. (similarly to Apple Notes). The extra line at the top of the window showing this name should be removed (saving tons of space in the new design that I hope I never have to switch to).
Moving to this system also has the benefit of having pdf exports behave a little more sane. Currently the title is included in the pdf even if it’s not desired
Of course migrating all of Joplin’s users over to a new title system seems to be beyond a headache. Would it at least be possible to have a toggle for this? So existing users can have the current behavior and those that want this can have the title always tracking the first line? It wouldn’t be too hard to write an API tool that would change each note for either system.
Unfortunately this assumes that everyone uses Joplin the same way you do. Personally I do not have two titles in a note as I do not duplicate the title in the text of the note itself.
No matter how you use it, the current approach is broken:
It copies the first line as the name when the note is initially created, but does not keep them in sync.
[[_toc_]] includes H1. It shouldn’t if H1/first line of the note is meant to be used as the note name, which the previous behaviour suggests.
In the interface H1/#-headers are more prominent than the note name (this is a bit different in the new space-wasting design), but in the print/pdf export the other way around,
Instead of the current hybrid, it should be either:
As I describe above, remove the superfluous note “name”. This is consistent with notes being full markdown documents that contain everything necessary.
Make the the note “name” a prominent title across all interfaces (desktop, app, pdf/print), and relegate h1/#-headers to document internal headers.
The problems I see with option 2 are
A disconnect between HTML H1 (which should be the document title) and the markdown content (# should now logically become H2, with the separate note name H1).
A clumsier interface, the note name being a separate field from where you have to navigate to the content. This could be fixable by making the interface to set the name part of the markdown meta-section, auto-filled when creating a new note, removing it from the GUI, and specifically rendering it within the rendered document.
---
title: Note name
---
Of course, option 1 also has some problems, the first one easily fixable.
The [[_toc_]] issue above. H1 shouldn’t be in the TOC (at least unless there are many).
A HTML document can in principle contain multiple H1, different from \title in LaTeX, which HTML doesn’t properly have (<title> is not shown in the document itself). This suggests that only one H1 header should be used.
Although in this case, I guess it was used to make the section heading smaller in the preview window.
But as you can see the first heading is missing altogether.
It’s the same as using a book’s name for chapter one and use sub-chapters for the real chapters.
Thus you end up with a book that has only one chapter which has the same name as the title of the book.
Am I the only one who thinks that this is idiotic?
It is idiotic to
a) have a separate GUI box for the name, from which it is extra work to navigate to the main content to continue writing (have to switch from keyboard to the trackpad/mouse).
b) to work around that major usability issue, copy the first line of the content to that box, but not keep it synced.
c) as a result of having a distinct main header and name, display the same information twice in the interface.
The correct solution is to have the title in the markdown content. The only standard way to do it is with #. The other solution is the meta-section
You flag my post, but in the next post you basically tell me that I am an idiot while I did not name a person, but a workflow.
have a separate GUI box for the name, from which it is extra work to navigate to the main content to continue writing,
That's not an issue. I am not saying it can't be in the same content area. All I am saying is that it should not be a heading 1. You can style it as a heading 1, but not make it a # title
That's a matter of opinion. And I don't think that this is the correct solution.
have a separate GUI box for the name, from which it is extra work to navigate to the main content to continue writing,
That’s not an issue. I am not saying it can’t be in the same content area. All I am saying is that it should not be a heading 1. You can style it as a heading 1, but not make it a # title
This is a major issue, having to switch from keyboard to mouse and use the rat to hunt for a small box in the interface. Zero thought for usability. A totally retarded workflow.
# or H1 is the only way to have a visible document title in a HTML or plain markdown document. Period. HTML/markdown is not latex, that has \title that actually gets displayed unlike the pointless <title> of HTML. So # is the way to write a title for the document. PERIOD.
It's not an opinion. It's the only way in plain HTML/markdown to have something that is both semantic and displayed. <title> is not displayed, and anything else requires some <div class="title"> + CSS magic. No longer basic HTML, and not semantic (i.e., standardised).
The notes should also work as markdown outside Joplin. The content itself should contain the title. Otherwise it's vendor-lockin just as much as Apple Notes (which makes it very difficult to get anything out from it—especially scans).
You apparently still haven’t understood the implications.
