I completely disagree. This is a strange mixture of (i) is Bob a PERSON (i.e. is PERSON anywhere on the tag hierarchy on Bob), and (ii) is PERSON the smallest set containing Bob (i.e. is PERSON a leaf tag on Bob).
If you want to indicate (ii) to the user, use some other UI indicator, but don’t simply make Bob vanish e.g. add a column to the list pane with the next-applicable child tag names (MAN and WOMAN), perhaps group them by MAN or WOMAN in the list pane and grey out all that are not leaf-tagged PERSON, … If you want to visually clue the user in to the shape and population of tag sub-trees, specifically design a UI for that. DT should experiment with Things and other good UI examples.
I cannot stand the current UI or user mental model. Throw in unacknowledged bugs and it gets much worse.
Sorry for speaking bluntly, but I have been in other established technical communities where highly intelligent people, who have invested a lot into The Way Things Are and devised good ways of operating within it, find it difficult to take a fresh outside look that might question underlying assumptions. I have seen this hurt those communities, costing them new members who will not or cannot internalize The Way Things Are.
That “flat” list is awful. Having to switch to it in order to use tags the way tags are commonly used is bad. Why hide the hierarchy? And when I am focused on one part of the database, why show me every tag in the universe? Look at Things for ideas on clean, intuitive, and context-smart UI for tags.
If DT requires this for the UIs to make sense, then DT should enforce it automatically for all non-leaf tags. There are better solutions than manually creating “Misc” folders on populated non-leaf levels.
I understand your explanation, although I don’t think it addresses the issue.
Greg, Thanks. So what I was seeing in the listed contents of tags is “not intended” DT behavior? I did not do anything complex, I just don’t remember the specifics.
That is correct-it is not the intended behavior. The pictures that Charles and I posted demonstrate what it should like. Some suggestions include verify & repair the database and if it still persists, try rebuilding the database. Also, if you can create a new database and duplicate the results, I’d suggest sending a copy of that database to Dtech to allow them to take a look and see what is happening. Or, if it doesn’t contain sensitive data, send them the current database.
Please forgive me if I’ve wrongly understood this thread – I’ve tried hard to follow the logic behind DEVONthink’s current implementation.
But I’m still strongly in agreement with the original post, and I’ve posted previously that I think the currently implemented file count in brackets is counter-intuitive. (I also complained about the use of bracketed suffixes instead of right-aligned rounded boxes for the count numbers!)
My simple view is that files are real, recognisable and familiar items on our computers. I don’t think that analogies such as ‘man’, ‘woman’, or ‘person’ are very helpful here. Files are different entities from folders and tags. Files are contents, folders are containers, and tags are labels. Folders and tags are abstractions to help us organise files.
So the top level folder or tag should always show a count of the total number of files in all its sub-containers. Only files should be counted. Folders and tags should not be counted. Reorganizing files does not, and should not, change the file counts!