I also think this is not a critical problem per se.
It just adds up, when UI access and placement of things around the annotation we are discussing here intermingles w/ other potential sources of confusion.
But agreed, other parts like occluded/indirect access to creating aside-annotations and non-symmetric relationships (distribution over many different UI parts) is much more relevant for UX than the double naming per se.
(Though there is ample testomony in the forums that it is a regular source for confusion/opaqueness to non-power users - see for example here)
The name confusion for me was a ten second thing. Ok, we’re going to call those things we put in a PDF by the same name as these linked notes. Got it.
Either way they are most handy. I use the linked Annotation files as either narrative for a file I don’t want to modify or for when PDF annotations wouldn’t be as clear as a second Markdown file.
Annotation files are also a great place to put what the note-taking crowd calls a map of contents.
As to censorship here, I believe DEVONthink’s intent is to have sort of a tree-shaded quad for discussions along the line of collegial “hail fellow well met, and by the way have you run across this?”
What we enjoy here on DT’s private turf isn’t free speech, it’s DT’s grace and hospitality. Constructive criticism is welcome from what I’ve seen.
Here’s an example of constructive criticism. I would have preferred keeping the name "replicant.” It’s better to learn a term with history behind it than to alter the lexicon. Besides, a reference implies a target somewhere. DT’s references don’t have a canonical instance.
It’s also a lot of trouble for DT. For instance, one of the right click options on any document or group is “Create replicant.” Of course, creating a replicant indicates there is something that’s been replicated. Once something is replicated, it becomes a replicant, too. Reference. My bad.
DT’s developers missed that use of the old term, but I hesitate to bring it up because I’m nostalgic for replicants. Nice when an old friend pops up.
@BLUEFROG Maybe you could ignore the foregoing. References are fine, but I like to see the ghost of replicants past every once in a while.
I am not sure what this “answers” more concretely.
At least, I thought we were already over the question whether some individuals might have more or less problems w/ double naming, esp. as nobody made this a make-or-break-issue in the first place. (Actually my last comment was somewhat in consent to your take that this is a secondary aspect in itself, even though it causes regular confusion for some others, less DT-/tech-proficient users.)
As to what follows like as to “censorship”, “free speech”, “grace”) I am not sure what these are actually referencing exactly as to things stated here in the thread. So, nothing to say here.
Again, I found @Anton´s comment a very constructive nuanced as well as diplomatic door that could be walked through, if the intent is making things constructive and productive. It would be great to read some explicit comments on this, IMO.
Also, as interesting as I find the thoughts on “replicants”, I am still trying to understand what makes it so hard to stay on topic as to the threads (intended) topic of powerful annotations and relation to UI/UX as we find it in current state.
This is even more intriguing, as we now not only have very explicit stated “pain points”, but also mockups showing easy alternative and very concrete (and I would say: constructive) blueprints by others relating to these matters.
Interesting thing is: these (1 - 2 - 3 - 4 - 5 - 6) do not get any on par comments (as to what they say/propose about annotation UI/UX), while rather speculative and generalizing meta discussions keep burning. I find that kind of rather selective echoing and marked perpetuation intriguing.
But for sure I think, if even the mockups (after long wound discussion) and the user stories (with all the synthesizing effort) don´t warrant any explicit on par reactions and comments, it might be better to just stop, as things can only become futile (on different levels) and some form of mirror fencing, really and (over-)personalized back-and-forth.
It “works”. But, as I said it in a sad way obviously.
As it means actually burrying the topic itself bec meta-discussion takes over.
I´d still hope some others take the energy/interest to react to the substantial contributions mentioned (see links). There was a lot of really genuine and constructive energy put up here, by different people. Such things should be credited with reactions, IMHO.
Let´s hope for 2026, in general and in particular.
@BLUEFROG@cgrunenberg reviving this thread to check if it would be possible from the team to consider adding the rendering of some basic formatting options (in markdown) to the ‘note annotations’ (i.e. the Details section) of the Document->Annotations inspector ?
So that we can have a visual experience +/- similar to the one we have with the Annotation file
Your screenshot is working for me too so I think the error might be user-specific. I did sigh a bit on seeing a post to this thread But your idea is a nice one and I second it I think. I’m guessing you’re thinking about being able to see bold or italic text in the note, or maybe even headers? (do people put them in notes?)
I don’t think I use the inspector panel as cleverly as I could do, and your comment has prompted me to have another look at it!
I was indeed thinking about bold, italic and lists (bullet/numbered), but then I thought: a number of formatting styles are already visible in the Annotations (with capital A) pane, so maybe they could easily be ported to the Details section of the annotations (small a)?
In reality, besides having the formatting available visually in the section (which I would already find very helpful), it would come in handy when I use the “Summarise Annotations” function to create a .md file which includes both the highlights and the comments (Details) → the Markdown formatting applied in the Details pane would then also be available in the .md summary file.
Note annotations don’t support formatting of any kind (and that’s what the Details section is a window on, a note annotation, even if attached to a different type of annotation). This would require subclassing the note to customize behaviors – not necessarily a simple thing. Also, the formatting wouldn’t survive outside DEVONthink, even in DEVONthink To Go, as PSPDFKit doesn’t support rich text note annotations.
In the meanwhile I am experimenting with manually adding some md formatting to the text in the Details section (which I see there as plain text) and then - with a script - stripping the escape characters (backslash) added by DT when I run the “Summarise annotations” function, to have the Details text properly rendered in the .md
But your idea is a nice one and I second it I think. I’m guessing you’re thinking about being able to see bold or italic text in the note, or maybe even headers? (do people put them in notes?)