That is what the tags do, so that is what they should show, in all list views.
There are some quite intuitive UIs for tags in “Things”, where only tags that are applicable in the currently visible context are displayed, with hierarchical drilldown on demand. DT could use some of these ideas.
That’s what the Tags view does. The 3-pane view on the other hand shows only the children of the selected group(s).
Here (this post + the next) are screen shots of my test, in 3-pane view. What cannot make any sense of what I see, and am totally confused. Note the tags at the bottom and the numbers in parenthesis.
I also don’t agree that the 3-pane view should show what it does. Tags are meant to be labeled sets, multiple tags allows overlapping sets, and hierarchy gives subsets. All views should reflect this, unless my understanding of tags is wrong.
The tags view shows no hierarchy structure at all in the right hand panel.
btw, I all things considered I do like DT. I think it could benefit hugely from some (further?) usability improvements, and tags in particular are quite raw. I am spending more time than I like getting to grips with stuff.
4 more pics.
last pic
The numbers are actually correct:
t2 contains c => 1
t3 contains b => 1
t1 contains a, c, t2 (containing c), t3 (containing b) => 6
Tags contains a, b, c, t1 and its children => 10
The main question right now is how you’ve created this? Because it’s probably not the intended tagging which should be…
Tags contains only t1 => 6
t1 contains a, t2, t3 => 5
t2 contains c => 1
t3 contains b => 1
And over here it is the one above after entering all tags (t1, t2, t3) via the Tags bar and finally moving t2 & t3 to t1.
Ouch! CAPS are tags below:
PERSON
…MAN
…bob
…steve
…WOMAN
…mary
Then PERSON contains 5 items? Sorry, but that badly mixes up tag thinking with folder thinking. I either want to find items (in which case the child tags should not count), or I want to narrow my search (in which case I may want to select a child tag). bob, steve, mary are items, PERSON, MAN, WOMAN are tags and are definitely NOT items.
In set language: S1 = {a, b, c} & S2 = {b, c} then it is NOT true that
S1 = {a, S2, b, c}.
And please don’t say that the Tags view is meant for that. It simply cannot be right for me to see T1(3) in tags view, and T1(6) in another view. Which is what I currently see.
Just because DT uses (a) some smart common underlying implementation machinery for tags and groups does not mean it should force (b) the user’s mental model to be the same. DT does great at (a), not so good at (b).
The actual items listed also cannot be right either. Items B and C are completely symmetrical: each is tagged with a child-tag of t1 (t2, t3 respectively). Each shows its tags as (t1 + a child-tag of t1). Yet only C shows up in a listing of tag t1, and B does not.
I really don’t remember, I’m sure I did nothing complicated, and I’m not sure why it is the main question. I can only look at the current snapshot of what DT shows me, and that current snapshot of the tags, items, counts, and listings makes no sense to me.
I urge you to do some serious hands-on experimentation with Things, or other apps with tagging, that do this correctly (and smoothly, a different discussion).
Am I missing something, please? This tool should not take so much effort to understand. I was really hoping this one was just a bug, and would like to be constructive.
See
PERSON
…MAN
…bob
…steve
…WOMAN
…mary
When I look at this I see a set of 6 elements, hierarchically arranged. Three elements are tags, three elements are tagged items. The conventions used in DEVONthink make it easy to distinguish the tag and tagged item elements.
If in Three Panes I select the tag ‘PERSONS’ I see that it has 5 members, two of them tags and 3 of them tagged items.
If I switch to the Tags view and look at ‘PERSONS’ I see that 3 items have been assigned that tag, 2 men and 1 woman. If I click on ‘WOMAN’ I see that only 1 item has been assigned that tag, and the tag bar displays ‘PERSONS’ and ‘WOMAN for that item’. If I select both ‘PERSONS’ and ‘WOMAN’ I see, correctly, that there is 1 item that is tagged with both designations. And if I select all three tags, I see, correctly, that no item has been tagged with all thee designations. Inheritance within the hierarchical tag structure worked.
If the user hasn’t been logically inconsistent in applying tags, the results will be correct and consistent. While it has been many years since I picked up a bunch of graduate hours in logic, it seems to me that no rules are broken, and the tag system is simple and straightforward.
There are many ways of displaying information, of course.
So you’ll (Bill? Christian? DT?) really see nothing wrong with DT displaying for the same data:
T1 (6) : in three-panes view, and
T1 3 : in tags view
??
And you’ll see nothing to be improved when DT shows T1(6) in a view, yet displays just 2 (!) elements in the list view when T1(6) is selected?
And you’ll really see nothing wrong with claiming “MAN is a member of PERSON” in the same breath as “sam is a member of PERSON”??
Then further discussion will not help, but I am very disappointed. Perhaps you will re-read this later and re-consider, more likely not.
You’ll are always polite rather than rude, and always helpful to questions. However, for DT’s sake I recommend listening with genuine openness to the points being made, rather than defending the way things are. Prioritizing if and when to make a change or fix is always a totally separate decision.
Thank you, anyway.
Sophie, I’ve already used the set theory argument in other posts where I strongly disagree with the implementation of tags in DT. That didn’t seem to sway anyone - in fact other users were very pleased with the way DT implemented them.
I suppose we’ll just have to live with it.
I know, I know. It’s been more than 40 years ago that I took several graduate courses in mathematical logic, a couple of which were heavily into set theory.
At least at that time, there had been some theorists who would have been comfortable with the idea that MAN and WOMAN are members of the set PEOPLE, and in their turn can constitute sets (which can hold sets), all of which are related to PEOPLE — and all of these can be members of still other sets, ad infinitum. I particularly liked a Polish logician who wasn’t terribly impressed by Bertrand Russell, and whose book The Logic of Intensions and Decisions had influence in the development of concepts of artificial intelligence and networks.
And then there’s the old taxonomy model, which has been around a few hundred years (with variations) and perhaps fits a concept of hierarchical tags pretty well.
Sophie, I suppose the simple answer is that the numbers differ in Three Panes and in the Tags view because they are NOT counting the same data.
That’s right, some like it the way it is but others don’t. But that doesn’t mean that it will remain always that way.
Bill, Christian: Please tell me if the pictures I posted under “4 more pics”, showing the contents listed in the right hand list pane under tags t1, t2, and t3, are correct and consistent according to DT’s intended behavior.
If it is a bug, I am relieved.
If it is as intended, I give up.
Thanks.
Every bit of DT’s behavior can be explained trivially by how it has been designed and coded to behave.
But rather than “explaining it away”, it would be more beneficial to ask “is that really how we want it to be?”
The answer will depend on how and where DT chooses to balance and expose (a) technical wizardry, (b) intuitive and consistent mental model for the user, and (c) natural user interface for user tasks. I think that balance should always be heavily towards (b), then (c), then (a). But regardless, to not ask the question itself would be a big mistake.
Not many users would put in the effort it takes to carry through such uphill discussions. Take advantage of those that do.
Just my 2 c.
Hi, Sophie. At the risk of sounding defensive, let me observie that the view of a tagged hierarchical structure in the Three Panes view is not alogical, and has important consequences for guiding the user as to how to properly assign tags wihin a hierarchical tag structure. That, in turn, will be of fundamental importance in the operation of a future AI (Artificial Intelligence) feature to suggest potentially useful tags for a selected document, in much the same way that the Classify feature suggests potentially appropriate groups into which a document might be classified.
Lets create a little database using the tag structure and content of your example above, for a hierarchical PERSON tag.
In the Three Panes view of the Tags, if I click on the PERSON tag, no content is displayed. That’s correct, because no document was assigned to that tag. And that’s important, because a) there should be no content assigned to the top level of a hierarchical group and b) the future AI to suggest tag(s) for a document should never choose an empty tag group, but should examine only those tag groups that hold document replicants, and suggest one or more based on the contextual relationships of the contents of tag groups to the document being evaluated.
If I click on the WOMAN tag in Three Panes I see that one document has been assigned that tag. If I examine the Tags Bar I see two tags for that document, PERSON and WOMAN. That’s correct, as the document was assigned the WOMAN tag, which is a child of the PERSON tag.
Let’s click on the PERSON tag in the Tags Bar. It shows 1 document, the same one that was assigned the WOMAN tag. And that’s correct, as it is displaying the single document that has both tags. If I instead click on the MAN tag in Three Panes and select one of the documents so tagged, it will also display two tags in the Tags Bar, PERSON and MAN. Now if I click on the PERSON tag in the Tags Bar it will show two documents, the only two in the database that meet the two-tag criterion.
Now let’s switch to the Tags view, which displays a flat list of tags for the database. If I click on the PERSON tag (which shows the number meeting that tag is 3) I do indeed see three documents displayed, which is again correct. A total of three documents in the database inherited the PERSON tag.
Many users assign tags by dragging documents into the Tags structure in the Three Panes view. To repeat, documents should not be tagged at the top level of a hierarchy, as that’s ambiguous. If necessary, additional subgroup(s) in the hierarchy should be created, even if the subgroup is a miscellaneous one.
Let’s illustrate that by a hypothetical example. Not long ago a group petitioned the European Union court to declare (as I recall) a chimpanzee as a person. If the court had ruled favorably, we would have to modify our little database by adding two additional subgroups, HUMAN and CHIMPANZEE under PERSON, and subsuming the existing subgroups for MAN and WOMAN under the HUMAN group. If we then added MALE and FEMALE tags under CHIMPANZEE and populated them with some documents, the number of documents subsumed under the PERSON tag would change in Tags view, but the number of documents subsumed under the HUMAN tag would remain the same as the previous total for PERSON.
As Christian noted, the fact that Tags are displayed in Three Panes as they are currently doesn’t mean that the display may not change in the future. There will be continued evolution of Tags.
But I’ll argue that the present display of the Tags group in Three Panes has intuitive value, especially for hierarchical tags, and is supportive of the future AI feature to guide the user in appropriate assignments of tags to documents, which should NOT be assigned at the top level of a tag hierarchy, in this case, PEOPLE. (If so assigned, items should be reclassified into lower-level tags, else the organization becomes ambiguous and the future AI feature will be weakened.)
So I don’t think issues of set theory are applicable as suggesting that the content of the PERSON tag when clicked in the text pane should be non-null in the Three Panes view of Tags (or that the item counts are wrong), but of course they are applicable in the case of the Tags view of the PERSON tag as well as of the other tags under the PERSON hierarchy.
Do I make any sense? 
It is intended but v2.0.3 might revise this.
Just to be clear:
…t1 —> shows {a, c}
…t2 —> shows {c}
…t3 —> shows {b}
is intended?
thanks.
I believe the way that Christian and Bill have described tagging is the expected behavior, however I believe there is clearly something wrong with the tagging displayed above. Either there is a problem with the database or something else going on, which is probably why Christian asked how you were able to create the above hierarchy. I’ve duplicated the above in a new database and here is what I see:
This structure does, according to my understanding of the current implementation, show the correct numbers:
Tags=8, as Tags includes t1, t2, t3, a, b, c + t2 is tagged with t1 and t3 is tagged with t1
t1=7, as t1 includes t2, t3, a, b, c, + t2 is tagged with t1 and t3 is tagged with t1
An additional challenge is why any files show when the Tags group is selected as they should not-see my selection of the Tags group above (original grab produced below)?
Greg, you are right. The image showing ‘Tags’ selected and displaying documents is strange. I’ve checked several of my databases that contain tags and none of them reproduce that behavior.
Something is quirky.
Do you have any other databases that have tags, and do they show that behavior?
Note that although it’s possible to store the original documents only within a Tag group, that’s not good practice, and I wonder if that is what happened in your database.
Documents should be stored in a ‘normal’ group outside the Tags group. When a document is then dragged into a Tag group it is assigned that tag. If it is later deleted from the Tag group, it isn’t deleted from the database, but only has that tag removed.
FWIW, I get this:
and this:
