Zettelkasten Forum


Title length sweet spot

Hello! :-)

It is good practice to keep the titles of a Zettel short:

  1. On the one hand, the task of writing a short title helps the learning process.
  2. On the other hand, the visualization of the notes is better if the title is short.

However, my question is, do you know if there is a sweet spot for the length of a title?

In my case, I try to write titles of 80 characters or less (with the UUID included). I selected this quantity due to my background in programming, where it is recommended to limit code lines to 80 characters. In my experience, this length is a good challenge that helps both objectives (1) and (2).

But I am considering increasing it a bit: maybe 100 characters.

What maximum length for titles do you use?

“If I have seen further, it is by standing on the shoulders of giants.” —Isaac Newton
eljardindegestalt.com

Comments

  • I don't like when titles break onto multiple lines, so I do try to go for brevity. Also to show as much as I can in the front of the title so that the key words and phrases are visible in narrower file listings.

    Author at Zettelkasten.de • https://christiantietze.de/

  • edited February 27

    I write note titles with an "eye towards searchability".

    I do not try to encapsulate the gist of a note in the title, i.e. do not use the title as stand-alone summary of the note. Instead, I use the two or three keywords in the title that I think I would search on in the future.

    So, most titles probably 30-40 characters, but I have no max length per se.

  • When I create a zettel, the file name is pithy. However, I expand the file name when revising the title so that I have a good idea of what the zettel is about. I generally keep the title length to one line; if I feel that it needs some expansion (as in a few zettels), I add a sub-title on the second line.

    I mostly rely on tags for searching, although if you type a word in the search field, you get tags, words in titles and words in the main body of the note.

  • I, too, write my titles with an eye towards search. Note titling is an art form, and, as alluded to by @FernandoNobel, it is a way to investigate and interrogate an idea.

    Here are two examples of my titling. Currently, I put the UUID at the end of the title so more of the title is available in the note list. I don't know why this isn't the default in The Archive. I'm considering leaving off the UUID and including it only in the YAML front matter of the note.

    Most of my titles are short, but I don't consciously put any length limits. Some of my note titles are questions. Do you use questions as note titles?


    This Title Is Here To Persuade You To Read This Note 202310250804
    ---
    UUID: ›[[202310250804]]
    cdate: 10-25-2023 08:04 AM
    tags: #writing-tip
    ---

    This Title Is Here To Persuade You To Read This Note

    Subatomic: This subtitle backs up my claim that it’s worth reading.

    Actionable - Powerful Writing

    I find this interesting because... this article uses its teaching principles as a format for powerfully demonstrating those principles.


    This photo is here to make the article look professional

    Go straight into a question.

    Use the question as the hook or lede. Don't hem and haw with introductory stuff. Don't tell them what I will tell them, just tell them. "Identifying a knowledge gap and then filling the space. Creating a thirst to read on that needs to be sated."
    - Style: Toward Clarity And Grace §[[202310260718]]
    * Focuses on the "how" of good writing. Actionable steps to revising initial drafts.
    #counter-argument
    - Specific Image Significant Details [[202009071919]]
    * Imagery that is meaningful to the story line is important. Everything else is unnecessary.

    Not all content is equal.

    • Descriptive
      Our walk takes us along an old railway line, now a tarmac path. It leads us into the Scottish countryside.

    • Poetic
      A poet might linger descriptively on how the globules of rain sparkle on the ripe raspberries by the side of the path, magnifying their red, yellow-pink blush, black, and purple.

    • Environmental
      An environmentalist might draw your attention to the newspaper fluttering in the undergrowth beside a rusting can and the remnants of last night’s fish supper and comment on how a proud nation like Scotland lacks pride.

    • Journalistic
      A journalist might ignore everything she sees and hears and tell you about the thoughts in her head. Concentrating on the bigger issues: wars, politics, the economy.

    People love stories.

    "Stories are an engaging way to open articles. They are equally effective ways to illustrate a point. They don’t have to be excessive and garish to be gripping. Nobody has to die."

    –––––

    References and Resources


    How-to: Tie the title with the note's idea 202105050918
    ---
    UUID: ›[[202105050918]]
    cdate: 05-05-2021 09:18 AM
    tags: #title
    ---

    How-to: Tie the title with the note's idea

    Titles are for content, and tags are for context.

    - The annotation - Think of this a being a subtitle.

    1. Why titling a note is a superpower.

      • I'm calling titling a superpower from now on.
      • It adds value to the note

        • Subtitling too! My Evolving Workflow [[202008230753]]
      • It provides the first impression. Think of a note title as being an introduction you might give. You will be introducing this idea to a friend, your best friend, your future self.

        • Linking and Back Linking [[201901081201]]
        • Notes to the future selves [[202008111645]]
      • A note title is the idea's elevator pitch. It is the hook that catches the fish.

      • A creative, appropriate title "sells" the future you.
      • Find the phrasing for a title is hard work but has lots of learning power.
        • Titling Zettels [[202004202105]]
          • trigger and sandbox for further exploration.
    2. How to tell an okay title from a suitable tile from a title the sparkles. There is a spectrum to how much a title sparkles.

      • think of the distance between Wikipedia section titles and poetry
      • think of the difference between rout memorization of the times tables and dancing in the dark with a lover
      • think of the distance between your picture in your high school yearbook and a physical meetup with friends.
      • think of the difference between 480p and 8K
    3. How to develop the titling superpower.

      • Practice, practice, practice

        • Everyone's work sucks at the beginning. It will get better only if you begin and keep at it.
          • Creative Work - Ira Glass [[201902141904]]
      • Ask yourself, does it have a technical pull, mental charisma? Does it tug at your heartstrings and your mindstrings?

      • Use explicit and inviting terms when titling.

    15 skills that will supercharge your titling

    (These all can't be implemented at the same time. Some are contradictory.)

    1. Encapsulate the idea of the note
      • Spanning different contexts [[201812221638]]
    2. Don't obscure the idea of the note
    3. Use powerful verb phrases vs. weak noun phrases
      • Strong Verbs List
        • bear://x-callback-url/open-note?id=B1B9C558-E9B8-467A-9946-34668325121C-12365-000078D0B6632CBC
    4. Tell what the idea in the note is about
    5. Use keywords not found in the note
    6. Use the title as a way to expose your understanding of the idea. Relate the quality of the title to the quality of your understanding of the idea expressed in the note. Dissatisfaction with the note title equates with a poor understanding of the idea. Refactoring the idea will produce a more satisfying and more precise title.
    7. Make titles a complete phrase
    8. Use declarative or imperative language.
    9. Use a question to be answered by the note as its title.
    10. Spread the heavy work of idea capture over time. When in doubt, create a "working title, " put the note in an "in process" status, and sleep on it, letting your subconscious work on the titling problem.
    11. Refactor the title with the same enthusiasm as you refactor the idea in the note. I'm calling this 'Progressive Titleization'
      - Phrasing Ideas Clearly Is Work And Has Learning Value [[202105310648]]
    12. Write titles in the note not as link-bait but as exciting preludes to the idea.
    13. Titles should be refactored together with the note.
    14. The Future You has to be sold on the idea of reviewing a given note. This is done through titling - salesmanship and skilled writing technique, gaining attention, inspiring interest, establishing credibility, stoking desire, and making a case for immediate action—all the usual methods of writing influence.
      - Take notes for your future self [[202008111359]]
    15. Cultivate skills in succinct communication, stating the core of the idea. Titling is a transferable skill.
      - Note first approach [[201901261658]]
      - Cultivating An Ability To Imagine [[202101150821]]

    References

    I've adopted a technique I stole from @Sascha where I pre-append various monikers to the beginning of a title. This is much like a tag, except it is quickly visible in a note list and a link. It foretells the idea in the note.

    Will Simpson
    I must keep doing my best even though I'm a failure. My peak cognition is behind me. One day soon I will read my last book, write my last note, eat my last meal, and kiss my sweetie for the last time.
    kestrelcreek.com

  • In my note system, note title and filename are the same, and I happily make titles as long as the maximum length allowed in the macOS filesystem (around 255 characters) when necessary, and for me it is often necessary to have such long titles.

    Necessary length of the title for me correlates with note type. This is also well demonstrated in the third screenshot in @henrikenggaard's post "Field Report #1: A PhD About Writing with His Zettelkasten" (2021). There you can see that a title that is a subject/concept is shorter ("Maxwell-Boltzmann constellation shaping") whereas a title that is a proposition is longer ("Maxwell-Boltzmann constellation shaping minimizes the average energy for a given entropy" or "SNR designed Maxwell-Boltzmann constellation shaping is not optimal for dispersion-managed channels"). Most of my titles are propositions or questions, so most of my titles are longer. I am thinking about using more subject/concept notes, but they are currently not important in my note system.

    However, when I am writing the first draft of a note, the filename is only the UUID, and there is no title. I always write the title last and then change the filename to only the title. (UUID is in the note metadata.)

    I find other people's different title conventions to be very interesting, and it's useful to know about them.

  • edited February 27

    I always try to balance between the need of having a title that well describes the note itself (according to principle "A well designed title is the best summary of the note") and having not too long titles.

    "A well designed title is the best summary of the note", (the original is in italian, "Un titolo efficace diventa il miglior sommario di una nota") is an example of a title for what I call "principle notes". Best-effort in description but also concise, evocative.

  • I don't think that titles scale well. You can't memorize them all, or effortlessly capture their meaning or understand the difference between seemingly similar titles.

    I locate a note indirectly through its connections. Much less to keep in mind in order to find a specific note.

    my first Zettel uid: 202008120915

  • @Andy said:
    In my note system, note title and filename are the same, and I happily make titles as long as the maximum length allowed in the macOS filesystem (around 255 characters) when necessary, and for me it is often necessary to have such long titles.

    Side note on max file name length:

    Was reminded of a server maintenance problem the other day -- while macOS accepts long file names (no matter the path), synchronizing to a Linux server can wreak havoc because there, file paths can be limited to 255 characters.

    So a file name with 200 characters can work fine in many instances until you sync to a server that stores files in a deeper directory tree than you'd expect, adding 55 characters, and you're screwed :grimace:

    Author at Zettelkasten.de • https://christiantietze.de/

  • @ctietze said:

    @Andy said:
    In my note system, note title and filename are the same, and I happily make titles as long as the maximum length allowed in the macOS filesystem (around 255 characters) when necessary, and for me it is often necessary to have such long titles.

    Side note on max file name length:

    Was reminded of a server maintenance problem the other day -- while macOS accepts long file names (no matter the path), synchronizing to a Linux server can wreak havoc because there, file paths can be limited to 255 characters.

    So a file name with 200 characters can work fine in many instances until you sync to a server that stores files in a deeper directory tree than you'd expect, adding 55 characters, and you're screwed :grimace:

    Yes. I don't use Git with my note system, but in another context I noticed that Git chokes on long macOS filenames too—which is perhaps not surprising, given that Git and Linux were essentially created by the same person, if I'm not mistaken.

    I am thinking about putting some of my note system on the web, so I will need to consider this issue in the future. Usually when I do websites I use AWS S3 for storage, and fortunately the filename length limit in S3 is around 1024 characters, so it seems that I will have no problem if I use S3 for my web hosting as usual.

  • @Will said:
    Here are two examples of my titling. Currently, I put the UUID at the end of the title so more of the title is available in the note list. I don't know why this isn't the default in The Archive. I'm considering leaving off the UUID and including it only in the YAML front matter of the note.

    I think having the UUID at the beginning of the filename helps to find the notes. The reasons I can think of are:

    • Checking if it is the correct note to open is quick (from a programming perspective). The first word of the filename is the UUID, which is easier and faster to check than instead of finding the UUID at the end of the filename.
    • It is not necessary to open the contents of the note to get the UUID (as would be the case for the YAML header).

    Changing the filename standard (UUID + title.md) should be taken cautiously as a change in this standard may have unexpected consequences (as we do not have all the implications in mind). In my personal case, I trust that @Sascha, @ctietze, and the zettelkasten.de community have made a good decision in choosing this standard.

    @Will said:
    I've adopted a technique I stole from @Sascha where I pre-append various monikers to the beginning of a title. This is much like a tag, except it is quickly visible in a note list and a link. It foretells the idea in the note.

    Yes, I usually do things like that. For example, I use "-S-" at the beginning of a title to denote that the note is a structure note, "-Meeting-" for meeting notes, and the typical "How to..." for guides I write for myself. But I always add those monikers as a tag: #-S- #-Meeting- #how-to

    @ctietze said:

    @Andy said:
    In my note system, note title and filename are the same, and I happily make titles as long as the maximum length allowed in the macOS filesystem (around 255 characters) when necessary, and for me it is often necessary to have such long titles.

    Side note on max file name length:

    Was reminded of a server maintenance problem the other day -- while macOS accepts long file names (no matter the path), synchronizing to a Linux server can wreak havoc because there, file paths can be limited to 255 characters.

    So a file name with 200 characters can work fine in many instances until you sync to a server that stores files in a deeper directory tree than you'd expect, adding 55 characters, and you're screwed :grimace:

    Wow! I never thought that there was a maximum character limit for filenames. Thank you for pointing it out.

    “If I have seen further, it is by standing on the shoulders of giants.” —Isaac Newton
    eljardindegestalt.com

  • @FernandoNobel said:

    @Will said:
    Here are two examples of my titling. Currently, I put the UUID at the end of the title so more of the title is available in the note list. I don't know why this isn't the default in The Archive. I'm considering leaving off the UUID and including it only in the YAML front matter of the note.

    I think having the UUID at the beginning of the filename helps to find the notes. The reasons I can think of are:

    • Checking if it is the correct note to open is quick (from a programming perspective). The first word of the filename is the UUID, which is easier and faster to check than instead of finding the UUID at the end of the filename.
    • It is not necessary to open the contents of the note to get the UUID (as would be the case for the YAML header).

    Changing the filename standard (UUID + title.md) should be taken cautiously as a change in this standard may have unexpected consequences (as we do not have all the implications in mind). In my personal case, I trust that @Sascha, @ctietze, and the zettelkasten.de community have made a good decision in choosing this standard.

    Do you use The Archive?

    From a Python programming perspective, my experience has been that with modern computer architectures and 3866 notes, the speed at which you look for the first parts of a file name or the last parts is so little as to be perceptually indifferent.

    As far as opening the file to access the UUID, this would need to be done rarely. Without the UUID in the file name, all file names would have to be unique. I can only envision a few important instances where I'd need the UUID instead of the filename. Maybe you could enlighten me.

    I, too, was cautious about moving the UUID to the end of the file name. I jumped in with a backup in case I ran across problems I couldn't solve. This was about three years ago, and I haven't looked back.

    Which note list makes more sense?

    OR

    Finding a note is 99.32% the result of a structured search and not a perusal of the note list.

    Will Simpson
    I must keep doing my best even though I'm a failure. My peak cognition is behind me. One day soon I will read my last book, write my last note, eat my last meal, and kiss my sweetie for the last time.
    kestrelcreek.com

  • My rule of thumb is that I need to understand the note while reading the list. Right now, it is 50 characters. But I don't obsess over it. Sometimes, I understand enough from the first 50 characters, I don't mind that some of the notes are hidden in the note list.

    But I do shorten titles. This:

    Maxwell-Boltzmann constellation shaping minimizes the average energy for a given entropy

    Would turn into something like this:

    Maxwell-Boltzmann constellation shaping minimizes average entropy energy

    (In German, I feel comfortable to do this with no loss of meaning)

    I am a Zettler

  • @Will said:

    @FernandoNobel said:

    @Will said:
    Here are two examples of my titling. Currently, I put the UUID at the end of the title so more of the title is available in the note list. I don't know why this isn't the default in The Archive. I'm considering leaving off the UUID and including it only in the YAML front matter of the note.

    I think having the UUID at the beginning of the filename helps to find the notes. The reasons I can think of are:

    • Checking if it is the correct note to open is quick (from a programming perspective). The first word of the filename is the UUID, which is easier and faster to check than instead of finding the UUID at the end of the filename.
    • It is not necessary to open the contents of the note to get the UUID (as would be the case for the YAML header).

    Changing the filename standard (UUID + title.md) should be taken cautiously as a change in this standard may have unexpected consequences (as we do not have all the implications in mind). In my personal case, I trust that @Sascha, @ctietze, and the zettelkasten.de community have made a good decision in choosing this standard.

    Do you use The Archive?

    Sadly no, because I don't have a mac. I use Vim as a text editor and some bash scripts to imitate the functionality of The Archive.

    For example, when I want to follow a link to a note ([[202402231043]]), I use the following custom Vim function and key binding:

    function FollowLink()
        let uuid = expand('<cword>')
        let filename = system('rg --files | rg "' . uuid .'"')
        execute "e " . filename
    endfunction
    
    nnoremap gf :call FollowLink()<CR>
    

    which would be equivalent to running the following command in bash:

    rg --files | rg "202402231043"
    

    which the result is just the full name of the file:

    202402231043 Un entorno reproducible permite una funcionalidad invariante.md
    

    which I can then open it using VIM.

    From a Python programming perspective, my experience has been that with modern computer architectures and 3866 notes, the speed at which you look for the first parts of a file name or the last parts is so little as to be perceptually indifferent.

    You are totally right. With modern computers, the difference in speed is negligible. I did a quick test using the previous code to find a note with the UUID at the beginning:

    $ time rg --files | rg "202402231043"
    202402231043 Un entorno reproducible permite una funcionalidad invariante.md
    rg --files  0,02s user 0,00s system 121% cpu 0,013 total
    rg "202402231043"  0,00s user 0,00s system 34% cpu 0,013 total
    

    and at the UUID at the end:

    $ time rg --files | rg "202402231043"
    Un entorno reproducible permite una funcionalidad invariante 202402231043.md
    rg --files  0,01s user 0,01s system 136% cpu 0,013 total
    rg "202402231043"  0,00s user 0,00s system 40% cpu 0,013 total
    

    In my Zettelkasten, I have 1200 notes. I don't know if this result holds when increasing the number of notes, and the only thing I did was change the UUID to the end of just this note (the ideal case would be changing the UUID to the end of all notes). So, more rigorous testing could be done.

    As far as opening the file to access the UUID, this would need to be done rarely. Without the UUID in the file name, all file names would have to be unique. I can only envision a few important instances where I'd need the UUID instead of the filename. Maybe you could enlighten me.

    I use the same filename structure (UUID + title + .md) in both my Zettelkasten and my second brain notes. The benefit of this is that using the search function of a file manager (in my case Nemo) I can resolve the references of a link from my second brain to my Zettelkasten.

    For example, in my second brain, I could have a note where I have a task about improving the note "202402231043" in my Zettelkasten. Then I open Nemo and I can search that note in my Zettelkasten quickly (or use my Vim script or The Archive). And the opposite is also possible.

    This workflow can be also achieved by storing only the UUID inside the notes (and not in the filenames), but it would require more programming to set up and to do full-text search of the notes. And, if you ensure that the filenames are unique (and do not change over time), you don't even need the UUID: you could just use the title.

    Another advantage is that having the UUID at the beginning of the filename automatically sorts the search results with the date of creation. This advantage is deceptively useful because, at least in my personal experience, it helps to improve my familiarity with my Zettelkasten (as it gives me something to orient myself and improves my working memory).

    I, too, was cautious about moving the UUID to the end of the file name. I jumped in with a backup in case I ran across problems I couldn't solve. This was about three years ago, and I haven't looked back.

    Which note list makes more sense?

    >

    OR

    Finding a note is 99.32% the result of a structured search and not a perusal of the note list.

    The one without the UUID one makes more sense :-)

    Would it be possible to have the second list but ordered with the date of creation? (Because then I don't have any more good arguments about using the UUID at the beginning instead of the end of the filenames).

    For comparison, this is how it looks when I do a search in my Zettelkasten. I don't have the left panel search as The Archive (because I don't know how to code something like this in Vim). But I have a pop-up window with enough space to read the titles.

    “If I have seen further, it is by standing on the shoulders of giants.” —Isaac Newton
    eljardindegestalt.com

  • @FernandoNobel said:
    I use the same filename structure (UUID + title + .md) in both my Zettelkasten and my second brain notes. The benefit of this is that using the search function of a file manager (in my case Nemo) I can resolve the references of a link from my second brain to my Zettelkasten.

    Why not change the naming convention in you second brain too? You'd still use the file name/note title as the link. The maintains the association, but instead of [[202002290908]], you'd have a more sensible link like [[An Excuse to Use Pens and Notebooks]] in both the Zk and the second brain.

    This workflow can be also achieved by storing only the UUID inside the notes (and not in the filenames), but it would require more programming to set up and to do full-text search of the notes. And, if you ensure that the filenames are unique (and do not change over time), you don't even need the UUID: you could just use the title.

    The filesystem keeps track of filenames and keeps all files in the same directory, ensuring they are unique.

    Another advantage is that having the UUID at the beginning of the filename automatically sorts the search results with the date of creation. This advantage is deceptively useful because, at least in my personal experience, it helps to improve my familiarity with my Zettelkasten (as it gives me something to orient myself and improves my working memory).

    The Archive uses file creation and modification date and time for sorting. This is likely faster than reading the UUID and converting it to a date/time then sorting the list.

    For comparison, this is how it looks when I do a search in my Zettelkasten. I don't have the left panel search as The Archive (because I don't know how to code something like this in Vim). But I have a pop-up window with enough space to read the titles.

    That is cool! Having the note list as a popup window is genius. You have a window that includes the entire note title. You've got me thinking. I can set the note list very wide and use a keyboard shortcut to hide and show it. This mimics the popup window functionality.

    Will Simpson
    I must keep doing my best even though I'm a failure. My peak cognition is behind me. One day soon I will read my last book, write my last note, eat my last meal, and kiss my sweetie for the last time.
    kestrelcreek.com

  • @Will said:

    @FernandoNobel said:
    I use the same filename structure (UUID + title + .md) in both my Zettelkasten and my second brain notes. The benefit of this is that using the search function of a file manager (in my case Nemo) I can resolve the references of a link from my second brain to my Zettelkasten.

    Why not change the naming convention in you second brain too? You'd still use the file name/note title as the link. The maintains the association, but instead of [[202002290908]], you'd have a more sensible link like [[An Excuse to Use Pens and Notebooks]] in both the Zk and the second brain.

    This workflow can be also achieved by storing only the UUID inside the notes (and not in the filenames), but it would require more programming to set up and to do full-text search of the notes. And, if you ensure that the filenames are unique (and do not change over time), you don't even need the UUID: you could just use the title.

    The filesystem keeps track of filenames and keeps all files in the same directory, ensuring they are unique.

    My second brain notes are not inside my Zettelkasten folder. In fact, the second brain notes span over many different folders (in the style of PARA). So I can't ensure the unique filenames using this method :-(

    Another advantage is that having the UUID at the beginning of the filename automatically sorts the search results with the date of creation. This advantage is deceptively useful because, at least in my personal experience, it helps to improve my familiarity with my Zettelkasten (as it gives me something to orient myself and improves my working memory).

    The Archive uses file creation and modification date and time for sorting. This is likely faster than reading the UUID and converting it to a date/time then sorting the list.

    There is no need to convert the UUID to time. If you order the filenames in alphabetic order, as the UUID is at the beginning, you get chronological sorting for free.

    For comparison, this is how it looks when I do a search in my Zettelkasten. I don't have the left panel search as The Archive (because I don't know how to code something like this in Vim). But I have a pop-up window with enough space to read the titles.

    That is cool! Having the note list as a popup window is genius. You have a window that includes the entire note title. You've got me thinking. I can set the note list very wide and use a keyboard shortcut to hide and show it. This mimics the popup window functionality.

    Wow, it looks really good. If I were using the Archive, I'd use that keyboard shortcut :-)

    “If I have seen further, it is by standing on the shoulders of giants.” —Isaac Newton
    eljardindegestalt.com

Sign In or Register to comment.