Enable Quick Linking by Auto-Setting UUID

[GfEW]

• I have searched for existing issues that may be the same as or related to mine.

Note: This is a sibling issue to #347 , it focusses on (a) rather than (b) (see below). Shared parts are marked italic.

When mapping complex, inter-linked topics, links to other notes can prove extremely helpful. As of Orgzly Revived 1.8.27, they are perfectly possible, but require you to either

• (a) use UUIDs that involve bothersome extra steps to copy & paste them, or
• (b) use memorizable custom_IDs that however need to be set in the link destination in order to work.

Both ways feel like moot, monotonous tasks that put a significant burden on efficient, high-volume note creation.

The linking workflow would get a lot smoother if Orgzly offered an option to automatically generate and assign UUIDs to the ID field of every new note. There's no point whatsoever in users either having to perform those steps manually for every note, or being unable to link to it.

We could even go as far as to auto-assign UUIDs no questions asked, but the current non-option really doesn't make sense. Ideally, users should be able to set links to any note along the way, by typing [[, possibly followed by a title substring, then selecting the destination from available title completions (like you can select tags from the completions dropdown in the Tags field).

By activating this option, users could save themselves the hassle of manually generating an UUID externally (if they even manage to do that) and transferring it to the ID field, for every single note.

Moreover, this would substantially improve org-roam compatibility (see #174).

[credmp]

Automatically creating on the book level is a good idea (and roam compatible). I would not auto-create on a heading, as this means that every heading will show up in roam's search.

[amberin]

Been thinking about a reasonable UX for adding these ID properties to books and notes.

Since books are always created in a manual fashion, I believe a checkbox "add book ID property" should be added to the "new book" prompt dialog. We could store the user's last choice and pre-check the box if it was checked the last time. This means one less setting to fiddle with for the user. Alternatively, there could be a setting with three possible values: "always" , "never" and "ask" (the default). The first two options would hide the checkbox.

For notes, I don't really see anything better than adding a "add unique note ID property" action to the top right context menu. This should be hidden when editing a note which already has the "ID" property. This would mean that it takes two clicks to add a UUID when creating a new note. But note-creation is not insanely fast and streamlined anyway, so I believe it should be acceptable as a first step.

Does anyone have other ideas?

[GfEW]

Been thinking about a reasonable UX for adding these ID properties to books and notes.

Thank you for devoting some of your thinking time to this.

[...]

a checkbox "add book ID property" should be added to the "new book" prompt dialog. We could store the user's last choice and pre-check the box if it was checked the last time. This means one less setting to fiddle with for the user. Alternatively, there could be a setting with three possible values: "always" , "never" and "ask" (the default). The first two options would hide the checkbox.

In my view, both are good solutions. As hiding the checkbox would provide little advantage over just remembering its state(*), sparing the option slot might be slightly preferable, especially given the need for the (IMHO) more important "add unique note ID property" option (see below).

[...]

adding a "add unique note ID property" action to the top right context menu
[...]
takes two clicks to add a UUID when creating a new note. But note-creation is not insanely fast and streamlined anyway, so I believe it should be acceptable as a first step.

An action in the context menu feels like going in the right direction but stopping halfway. Why, of all things, not provide a proper option for this one? Creating a new note is likely one of the most frequently performed actions (much more so than e. g. creating a new notebook), and if you want org-roam link compatibility, you need to assign every note an UUID. Every additional tap matters here.

As of v1.18.31, efficient creation of UUID-equipped notes mainly suffers from two UX issues:

1. Too many taps required (1. to initiate new note, 2. to focus a property field (after filling in the title), 3. to focus the content area, 4. to save the note), so you have to switch between tapping and typing multiple times.(**)
2. Too many steps required to generate and assign the UUID. (There's no point in making this require any manual steps at all, unless you explicitly want to.)

I think we should hope for 1. to be improved over time, rather than treat its suboptimal current state as a reason to address 2. in a likewise suboptimal way that even increases the number of required taps for an action as frequent as note creation.

Should you really want to avoid the additional option, it might be better to always add an unique note ID property. Some users might object the needless (for them) clutter in their org files though, which is why in my view, an option always/ask/never (or perhaps a state remembering checkbox?) would make most sense.

(*)

This boils down to "clean UI" vs. "clarity/adaptability", and I think neither point clearly dominates the other.

(**)

This obviously matters more with dedicated keyboards and/or touch accessibility issues.

[amberin]

I am confused, probably because I'm not familiar enough with org-roam.

@credmp:

I would not auto-create on a heading, as this means that every heading will show up in roam's search.

@GfEW:

if you want org-roam link compatibility, you need to assign every note an UUID.

You seem to contradict each other, no?

[credmp]

No, I think it is important to have definitions straight here. In roam the following happens:

1. When I create a new note (an org file) the file has a top level property such as this:

:PROPERTIES:
:ID:       654b25a7-aed4-42c5-b47a-68d4351b3d7c
:END:

2. In this file I write text and create headings.

* Heading 1

These headings, by default, do not get IDs. Only when there is a special operation, such as creating a new interlinked file, will org-roam create an id for an heading.

At any point in org-roam a user can call the org-id-get-create function to create an id for a heading. When this happens org-roam will recognize the heading and use it as an insertable interlinkable entity. Thus, creating an id for every heading (* Heading 1) makes each and every heading show up in the org-roam node finder.

[credmp]

In the manual it says the following:

5.1 The Org-roam Node

We first begin with some terminology we’ll use throughout the manual. We term the basic denomination in Org-roam a node. We define a node as follows:

    A node is any headline or top level file with an ID.

For example, with this example file content:

:PROPERTIES:
:ID:       foo
:END:
#+title: Foo

* Bar
:PROPERTIES:
:ID:       bar
:END:

We create two nodes:

    A file node “Foo” with id foo.
    A headline node “Bar” with id bar. 

Headlines without IDs will not be considered Org-roam nodes. Org IDs can be added to files or headlines via the interactive command M-x org-id-get-create. 

Lateron the manual explains that org-roam does not create ID's for every heading:

16.3 How can I stop Org-roam from creating IDs everywhere?

Other than the interactive commands that Org-roam provides, Org-roam does not create IDs everywhere. If you are noticing that IDs are being created even when you don’t want them to be (e.g. when tangling an Org file), check the value you have set for org-id-link-to-org-use-id: setting it to 'create-if-interactive is a popular option. 

The org-mode manual explains the reference in the manual:

org-id-link-to-org-use-id is a variable defined in ‘org-id.el’.

Its value is t
Original value was nil

Non-nil means storing a link to an Org file will use entry IDs.

The variable can have the following values:

t     Create an ID if needed to make a link to the current entry.

create-if-interactive
      If ‘org-store-link’ is called directly (interactively, as a user
      command), do create an ID to support the link.  But when doing the
      job for capture, only use the ID if it already exists.  The
      purpose of this setting is to avoid proliferation of unwanted
      IDs, just because you happen to be in an Org file when you
      call ‘org-capture’ that automatically and preemptively creates a
      link.  If you do want to get an ID link in a capture template to
      an entry not having an ID, create it first by explicitly creating
      a link to it, using ‘M-x org-store-link’ first.

So, when you perform a "special operation", such as creating a new node for org-roam, it will create an id to link it to.

Hope this helps.

[GfEW]

@credmp
Thanks for highlighting the differences of terminology between Orgzly and original org-roam. So far, I've been sticking with "notebook/note" here because of my (noobish) impression those were the established "Orgzly terms". Of course, the term "note" can be confusing if it's not clear to the reader whether it refers to Orgzly or rather to org-roam with its "note/headline" terminology. For better clarity, I'll use the terms org file and headline in the remainder of this discussion.

On the actual issue at hand, I suppose we agree that Orgzly isn't going to offer anything near org-roam's customizability, flexibility and sheer power. Therefore, it's important to focus on the few points that really matter in order to get the best mobile, org-roam compatible experience.

My primary point is, we should eliminate (rather than perpetuate) the extra effort currently required in Orgzly to create links to other headlines. Doing so obviously requires linkable headlines in the first place.(*)

My secondary point is, users should have the choice whether (and where) UUIDs are assigned automatically. Note that we don't have the problem "How can I stop [...] from creating IDs everywhere?" in Orgzly, but rather the opposite: "How can I ensure Orgzly does create linkable IDs wherever needed?"

• If you don't use org-roam at all (nor similar org related modes that might require headline UUIDs), you should be able to reject auto-assigned headline UUIDs once and for all, without having to confirm this preference everytime. (This wish is readily fulfilled, as of v1.18.31.)
• If you tend to use many smallish org files and prefer roam's search not to be flooded by thousands of (possibly irrelevant) headlines, you should be able to assign IDs to manually selected headlines and org files, only.
• If you tend to use few but large org files and prefer all headlines to be readily linkable in Orgzly, you should be able to have UUIDs auto-assigned to every headline created, without having to confirm this preference everytime. (On that ground, the procedure of selecting a link destination could be further improved in future versions by suggesting matching headline candidates.)

(*)

That is, unless Orgzly learns to create UUIDs "on demand", by allowing the user to choose a link destination even if it doesn't have an UUID yet, and then automatically assigning a new UUID to that destination and adjusting the link accordingly.

[amberin]

Alright, an option toggle to add UUIDs to all new notes seems simple to add. The property could then be pre-populated when the "edit new note" view shows, so that the user can easily discard it if they want IDs most of the time, with only a few exceptions.

So, to combine this "always add" toggle with the context menu choice I mentioned - I feel that should be the current goal. There's not really a reasonable place in the UI for a checkbox or prompt, as I see it. A prompt would have to be an extra dialog before or after the "edit new note" view, and that seems very clunky to me.

[credmp]

I think that is a great solution! Pre-population based on a setting seems to be a great choice here.