Confusion over two types of annotations

[FrankT]

@lerone

It is quite a good and pargonal example of where the power of DT contradicts its UI/UX, IMO.
That is because the different functional domains are never really explicated to the full.

I don’t know why that is. In the automotive industry, there are manufacturers who build attractive cars that are poor in quality, and there are manufacturers who build good cars that are unattractive. There have been attempts to bring together people who are skilled in one area and people who are skilled in the other. These attempts have been unsuccessful. Let us leave it at that.

I often use DT in views that show no columns or not all columns. That’s why I try to display what is not visible in the document icon, which is always visible.

Example for annotations: This icon shows me that it is an RTF document with an annotation. If I want to see the annotation, I start the script with a shortcut. Other modified icons show me something else. It’s certainly not very attractive, but it’s functional because I can see it immediately. Good enough for me.

[anton]

that indeed would be great! to have this working symmetrical. I wonder, however, if you have an annotation file which has text from different locations / documents…?

Anyways, with our friend ChatGPT, here are the user stories based on our discussions; maybe the DT Team will accidentally see them

Epic A: Make annotation files easier to access and discover

Story A1 — Create annotation file from context menu

As a DEVONthink user

I want to create/open an annotation (aside note) from the document’s right-click menu

So that the feature is obvious and fast to use without hunting through panels.

Acceptance criteria

• When I right-click a document, I see an option like “Open Annotation” / “Create Annotation”.

• If an annotation exists, the option opens it; if not, it creates it and opens it.

• Works consistently for common document types (PDF, web archive, text, etc.).

Story A2 — Add a dedicated “Annotation” button in the UI

As a DEVONthink user

I want a visible button (e.g., in the toolbar/inspector) to open/create the annotation for the current document

So that the feature is discoverable for new users.

Acceptance criteria

• Button is available when a document is selected/viewed.

• Button state reflects whether an annotation exists (e.g., “Open” vs “Create”).

• Clicking the button opens the annotation in the expected place (aside or tab, per app conventions).

---

Epic B: Make document ↔ annotation relationship symmetrical and easy to navigate

Story B1 — Show annotation link in the same place as other document links

As a DEVONthink user

I want the document → annotation reference to appear in the same “Links/Incoming links” area used elsewhere

So that navigation is consistent and I don’t need to remember a separate path (“Info → Annotations”).

Acceptance criteria

• From the document’s Links section, I can see its related annotation file.

• The location of this link is consistent with other link navigation patterns in the UI.

Story B2 — Provide symmetric navigation from annotation back to document

As a DEVONthink user

I want the annotation → document relationship to be reachable via the same navigation route as document → annotation

So that the relationship feels truly two-way and predictable.

Acceptance criteria

• From an annotation file, I can open/jump to its parent document via the same “Links” UI pattern.

• From the document, I can open/jump to its annotation via that same pattern.

• Both directions require the same number of clicks (symmetry).

Story B3 — Highlight the “annotation relationship” as a first-class link type

As a DEVONthink user

I want annotations to be visually marked as a special relationship (not just generic links)

So that it’s easy to spot this “power feature” relationship at a glance.

Acceptance criteria

• Annotation link is labeled (e.g., “Annotation”, “Aside Note”) and visually distinct from generic links.

• The annotation relationship is shown clearly in both directions.

• This does not require using Graph view.

Story B4 — Improve discoverability without relying on Graph view

As a DEVONthink user

I want quick, dedicated visibility of document ↔ annotation connections without needing Graph view

So that the feature is practical for everyday work and not hidden behind a visualization tool.

Acceptance criteria

• The document view makes it obvious whether an annotation exists.

• I can navigate between document and annotation in 1–2 clicks from a consistent UI area.

[rkaplan]

@FrankT

I don’t know why that is. In the automotive industry, there are manufacturers who build attractive cars that are poor in quality, and there are manufacturers who build good cars that are unattractive. There have been attempts to bring together people who are skilled in one area and people who are skilled in the other. These attempts have been unsuccessful. Let us leave it at that.

Can I suggest that those who have UI suggestions propose a mockup of the suggested features?

I don’t think there is a tradeoff in DT with regard to quality vs attractiveness.

I think to the extent there is any tradeoff it relates to complexity/capability of features vs simplicity of UI. The capability DT offers is unmatched anywhere. I am not sure it can be achieved with a simpler UI.

[lerone]

Not sure about the car analogy (set up in this way) and where this takes us or this case.
TBH, here it sound a little like a departure/sideway away from accepting UX is a thing to be adressed. Or, just lower expectations/ambitions w/o any obvious need.

In terms of “good enough”: I see your point about the icon flagging and labelling. This one is helpful per se. (Though it would probably helful for others to understand which labelling mechanism you are exactly referring to here.)

But then that was not my point.
It was about about creating annotations, and understanding as “ordinary user”– via good UI/UX architecture – what is going on. That is: being guided/helped by the UI instead of puzzling pieces together (as distributed as all the micro-actions around annotation-files are ATM).
All that assuming annotations are as central or powerful as they are discussed here. And that therefore it´s worth discussing how it works currently, and how it could be improved.

Indeed a good interface should be like a map for orientation and finding/comprehending the functional space of an app, and different functional “sub-spaces” (workflows) of it.
That is very obviously not the case with the whole “annotation”-file functionality as discussed above.

I do not see any particular reason not to discuss ways to improve and point out problems for (some) users. Or to leave UI/UX out of the equation. It´s not like a moral ostracism – it´s simply pointing out potentials for improvement. And I do not know what could possibly be wrong about that.

[lerone]

… you mean a real and serious mockup, worthy of the name like those that are done by professional, paid UX designers?

Telling users in a user forum to provide a high level solution to any observation about pain points seems certainly the best way of killing discussions.

Also, as all honest developers know and will tell you: users are good in telling their issues. They are naturally (that is: as *users*) not good (= in the role/position) for handing out the solutions.
Actually, I hardly know a developer who would a) want that or b) ever follow direct input by any user coming up with such a “solution”…

@rkaplan

I don’t think there is a tradeoff in DT with regard to quality vs attractiveness.

I think to the extent there is any tradeoff it relates to complexity/capability of features vs simplicity of UI. The capability DT offers is unmatched anywhere. I am not sure it can be achieved with a simpler UI.

In this specific case (annotations) there simply is.
There are some other – specific – cases, discussed in other parts of the forum.

The very general fact that “the capability DT offers is unmatched” (and offers some helpful UI/UX solutions) has been stated regularly, including by me. But I do not see the productivity of overgeneralizing in every discussion which points to very specific ideas/proposals/painpoints etc. Because all that does is making every thread an excercise of ostracism (“for – against”).

Let´s stay focussed on how usable and transparent the annotation(-file) functionality set is for average users, and where/whether it can be improved…
That is what forum threads are for.

[chrillek]

@lerone

That is what forum threads are for.

IMO, everybody participating here may state their opinion and/or requests. And what @rkaplan wrote was just a suggestion.

A reasonable one, I think, since if someone does not like the current state of affairs, they might well have ideas about how to ameliorate them. Just stating how something does not work is less helpful than concrete suggestions on how to get it working.

[lerone]

I am not against discussion and expressing opinions. Rather the opposite.
I am all for constructive discussions. And keeping them open.

But as said, and as you can find underscored by the link, turning users w/ issues into UI/UX-solutioners doesn´t seem helpful (reasonable) to me. (Here´s another + longer one, same tenor ).

Plus, anyone interested in concrete suggestions as ‘starter kit’ can start off w/ the specifics of what @anton has kindly AI-curated out of the discussion. That is for those genuinely interested in improving the annotation function and the overall topic of the thread…
Or in case you are even more serious about it, set up a matching process beyond ‘please turn in a solution yourself’.

JMO, of course

[BLUEFROG]

Tangentially…

Also, as all honest developers know and will tell you: users are good in telling their issues. They are naturally (that is: as users) not good (= in the role/position) for handing out the solutions.

Users (i.e. people who use software, but more generally people that interact with complex systems while not being experts) are quite good at knowing when something is not working well for them.
(emphasis mine)

for them is subjective and while it may feel valid for an individual, that does not make it universal.

1. We aren’t developing software for one person or even a tiny group of people.
2. You should realize people sometimes do things that may be familiar but inefficient or even unnecessary. I can fill my bathtub with a spoon, running back and forth from the kitchen but that doesn’t mean it’s a good way to do it, even if it’s familiar. Making a spoon more like a ladle wouldn’t be a good use of resources since the complete process is inefficient.
   • It is often a good and wise thing to offer alternatives and even corrections regarding their “habits”. Teaching someone an improved process (even if replacing their current one) is a better solution than undergirding a faulty one.

Back to topic…

… you mean a real and serious mockup, worthy of the name like those that are done by professional, paid UX designers?

No one asked for “professional, paid” anyone here. You could mock something up in GIMP, Krita, Pixelmator, etc., etc.

Actually, I hardly know a developer who would a) want that or b) ever follow direct input by any user coming up with such a “solution”…

We have asked for mockups from people before so @rkaplan is not suggesting anything untoward, especially when they’re asking for UI changes. However, a user should also not expect their suggestion will be implemented, either at all or in the form they offered. Suggestions are suggestions, not mandates.

PS: Do you think I have gotten every one of my suggestions implemented in the 13.5 years I’ve worked here? Many ideas are good for an individual but not the majority.

PPS: And yes, I often take the time to do mockups, partially for my own assessment but also so it is clear to development what I’m thinking of.

[lerone]

So after “everyone should be able to state their (personal) opinion”, it´s now “but every opinion is just personal”? This is a catch-22, and really sidetracking from the substance of the topic.
– Also, I never stated my take is universal, neither did @anton … or anyone. So, I feel this really fighting strawmen and windmills if now made the central argument in a thread that really is about different users stating what is confusing (“for them”) about the annotation(-file) issue.

As has been discussed elsewhere, the way out of such mirror discussions (everyone should state his/her opinion vs. every stated opinion is just personal) would be methodologies to address this question of “how many people”/”which kind of people have a problem here"?” Things like surveys, UX research etc (see links above). Everything else, like discussing whether a users opinion is “generally valid”, universal or not, is really spinning with air.

I find it quite disappointing to see another specific thread being lost to discussing generalities.
It would be helpful/straightforward to hear other people (or the team) saying things on topic, like: “no, we don´t think (aside-)annotations are that central, really”, or “actually we think the annotation implementation in the UI is the best we could come with”… or anything on topic.
This is all sideways (IMO), or deflecting from the concrete points raised (which are not really addressed at all.)

https://uxdesign.cc/design-feedback-how-to-give-and-receive-better-feedback-5efd76188029

@BLUEFROG

No one asked for “professional, paid” anyone here. You could mock something up in GIMP, Krita, Pixelmator, etc., etc.

So, does that mean the team is interested in improving the annotation function UI/UX wise?
It only makes sense in such a case. And up to now, I do not even know the opinion of the team on the whole issue (see above). This is rather opaque.
And confusing. As “asking people to do mockups” only makes sense if there is some more general sentiment/acknowledgement that things should be (at least could be) improved. Which is the direct opposite of the “spoon”-argument/line (“We aren’t developing software for one person or even a tiny group of people.”).

I think it (user mockups) can be reasonable if a) there is a process/shared understanding around it (which there isn´t – yet… or it´s not known to me and others), and b) if that doesn´t become a prerequisite for (continuing) the discussion or raising points …, (“… that those who have UI suggestions [here equals: “are raising issues” ] propose a mockup of the suggested features”

Again, we are discussing generalities here. While no one really takes up the points raised, or the (constructive) proposal version of @anton .

This is what I see.

[lerone]

@BLUEFROG

You should realize people sometimes do things that may be familiar but inefficient or even unnecessary. I can fill my bathtub with a spoon, running back and forth from the kitchen but that doesn’t mean it’s a good way to do it, even if it’s familiar. Making a spoon more like a ladle wouldn’t be a good use of resources since the complete process is inefficient.

• It is often a good and wise thing to offer alternatives and even corrections regarding their “habits”. Teaching someone an improved process (even if replacing their current one) is a better solution than undergirding a faulty one.

Can you tell me what this refers to? I do not understand how this relates to the topic of the thread, or things said here. TIA.

[BLUEFROG]

It’s commenting on this quote from the page you linked, with the emphasis on the ignored subjectivity of the author’s statement. And as I said, “Tangentially…”.

[lerone]

I understand that you are taking the general “only subjective opinions” to the max level here.

I still do not understand the comment itself, or how it relates to annotation irritations, or this discussion.

– But maybe that’s “just me”. So, let’s leave it (this aspect) at that, maybe.

[BLUEFROG]

So, does that mean the team is interested in improving the annotation function UI/UX wise?
It only makes sense in such a case. And up to now, I do not even know the opinion of the team on the whole issue (see above). This is rather opaque.

(Emphasis mine.)
You statement is only true if you ignore my comment: However, a user should also not expect their suggestion will be implemented, either at all or in the form they offered. Suggestions are suggestions, not mandates.

We listen/read/consider suggestions, every day… literally.

• That does not mean they’ll be implemented
• It doesn’t mean they make sense in the context of our applications
• It doesn’t mean they’re technically feasible
• It doesn’t mean we have the time and resources available to implement something now
• It DOES mean we have read the suggestions personally.

If you are making suggestions expecting them to be implemented, you’re only leading yourself to disappointment with occasional moments of happiness.
On the other hand, if you just want to make suggestions or criticisms, including on these forums, we have not shut you or anyone down. Whether that includes a mockup – which makes things more visually clear as we aren’t mind readers and can’t see your computer screen – or not, everyone can offer what they like and discuss these things, both for and against. Never think a thread must follow a particular bent. Dissenting opinions are as important as agreements. As long as things are handled with civility and respect and a light touch, it’s all welcome here.

PS: I can’t comment on internal decisions but we are always assessing things in our apps. That involves UI/UX as well. But UI/UX comes with its own subjectivity. Just look at Liquid Glass. No one can claim it’s objectively “better” but it’s what is here now.

[FrankT]

Note: Almost everything required here can be done with BTT and/or KM. If you want software that is “perfect” for you, I’m afraid you’ll have to adapt it yourself.

[lerone]

Sorry. But this really is a “ghost” discussion for me.
Maybe others can follow.
I do not see any of this as related to the points raised on annotation irritations or proposals.

Instead there is a lot of meta-commenting on (having no) expectations – … or “making universal claims”, or “chasing the perfect app”, “for or against DT in toto” etc etc. Or, alternatively, a certain chain/culture of argument saying “if you are raising problems you see, we a) deem this apriori only a subjective opinion, but b) please everyone doing so - better come up with a mock-up (and the labor behind it), but c) also do not expect it is of interest/relevant to anyone, as we d) do not disclose our opinion on the arguments/points made…”

I will leave it at that.
My takeaway: none of the substantial points or proposals raised in the thread on “annotation” are taken up in any explicit, constructive or at least ‘acknowledging’ way or form.
Instead people should change expectations, habits, read (very) indirect arguments.

I was not trained for that. But leave it to others to make more sense of all this. Hopefully.

[lerone]

@BLUEFROG

You statement is only true if you ignore my comment: However, a user should also not expect their suggestion will be implemented, either at all or in the form they offered. Suggestions are suggestions, not mandates.

This statement on the other hand is only true / makes only sense in case

1. one equates acknolwedment of points raised w/ promise/comitment of implementation (which nobody is assuming – but which is what seems suggested in different comments here)
2. you are silently positing that people (users) raising their pain points in the very same movement regard this a) as a concrete/specific feature suggestion AND at the very same time bring a mindset that equates constructive suggestions w/ an implicit entitlement and expectation that suggestions are automatically expected to be implemented.

All this is

1. jumping over any phase of acknowledging any kind of valid/legitimate points raised (regardless of taking a stand on adoption) and thus securing the discussion stays on topic/substance (aside from being welcoming and encouraging)
2. very much projection into the minds of users simply raising impressions/points in UI/UX (maybe a bit too steep for a moderating function)
3. it is also unfortunate, as it can be read as an implicit suggestion that people making remarks/proposals about what they see as improvements for (non-technical) users, are per se assuming a vile poisition, as it is assumed that they – w/o giving any indication of this whatsoever – are automatically assuming entitlement (or projected to be).

Unfortunate overall for a thread on a very specific aspect of UI/UX – the (potentailly) powerful annotation(2) feature. I think at least @anton very substantial effort to turn raised points and user experience into a constructive and suggestive (and unassuming) blueprint, really would deserve acknowledgement. And even better: sober discussion.

[chrillek]

@lerone

as it is assumed that they – w/o giving any indication of this whatsoever – are automatically assuming entitlement (or projected to be).

It is not assuming anything. But if the DT people would not explicitly state that they do not promise to implement whatsoever, people might (silently) assume that they (DT people) will implement it eventually. So, they acknowledge and warn that that’s not a promise at the same time.

One can, of course, read anything into any innocuous statement.

[lerone]

@chrillek

One can, of course, read anything in any innocuous statement.

That’s the whole point.

Also the reason why making these expectation management aspects the main point of discussion while skipping over the real subject points –or at least simple acknowledgment – is superfluous, eventually counterproductive.

So, I agree w/ your last statement. And would extend it into: one shouldn’t read any expectation into pure raising of (arguable) points, while watching a thread going off-topic, and substantial contributions being/remaining simply unacknowledged altogether.

I am still missing people here who really show imterest in discussing points raised about the annotation feature and UI implementation.

[chrillek]

@lerone

I am still missing people here who really show imterest in discussing points raised

I have several hunches why that may be the case. None of them are fit to be posted.

[rkaplan]

@lerone

… you mean a real and serious mockup, worthy of the name like those that are done by professional, paid UX designers?

I never suggested that.

You could easily make something with AI. Or lots of other basic consumer software. Or just sketch it by hand.

It’s a whole lot easier to understand and consider a UI suggestion if you show what it will look like.

That in turn might encourage alternate suggested mockups. And that in turn may lead to discussion about the pros/cons of each.