Not sure if this came up before, but is it possible to show hierarchical tags (tags with parent tags) at the bottom of ones article in its hierarchical order? E.g. considering the following tag group:
doctype
appnote
brochure
datasheet
press release
an article tagged as ‘appnote’ will show: ‘appnote’ ‘doctype’ not ‘doctype’ ‘appnote’
Where this is important is one has assigned multiple hierarchical based tags, it really becomes one big jumble of items at the bottom as the tags seem just sorted alphabetically.
For example, if there is another tag hierarchy as follows:
company
acme
bigbros
smartcorp
tagging an article with both ‘appnote’ and ‘acme’ shows as:
‘acme’ ‘appnote’ ‘company’ ‘doctype’
I would really like an option that allows tags to be shown with a clear parent/child relationship. So using the example above, I rather like to see:
‘company’ ‘acme’ ‘doctype’ ‘company’ or even better:
‘company/acme’ ‘doctype/company’ ( <— thats the one I really like)
I don’t mean to change the way tags work, just would like to see an option for how they are displayed at the bottom of the article.
no. there is no way to change this behavior, as far as i know, and this is one area in which tagging gets kind of clumsy. in fact, devonthink is relatively good with tag management, and i haven’t found any app yet that has smoothed out the rough edges of tag management. there are lots of opportunities for improvement out there.
Yes at the bottom of the “interface”. I realize there are no options today to change they way it is displayed - but could the (programming) staff think of including something like this in the future? Not to trivialize things, but i am only asking for an option to display this in an alternative way.
Tagging is a very powerful way to get information from a big database. Yes it takes time to set it up and get a good taxonomy going but it is worth it. However, that list of tags at the bottom is sometimes very confusing because the hierarchy (structure) is lost with the current display method.
I’m not a fan of tags, and wouldn’t use the option – but it’s an option so if it doesn’t squeeze out more important features, I’m okay. But I have a difficulty visualizing how this would work in anything other than View > As Tags. The tags bar at the bottom of the document is (now, at least) linear. The tags are alphabetical, AFAIK. If you wanted to show a “hierarchical display” in a horizontal line what would you do? Developers actually need to know what customer opinions are on details like this, otherwise they will guess at what you mean and maybe get it wrong. How would you know the levels of the hierarchy since the horizontal display cannot portray indention. How would you handle a case like this:
Trees
– Eastern Woodlands
– -- Oak
– -- Ash
– Nut Bearing
– -- Oak
I think this would get really messy really fast. The point is not my stupid example. The point is how to provide an easily comprehended display of info in the case where a complex hierarchy exists. Believe me, there are readers who have really complex hierarchies. Examples of other programs that do what you want would be very useful to know. If there are no examples, then that’s also an indicator of feasiblity.
While it is possible to create a system of hierarchical tags in DEVONthink, that’s probably due more to the initial tag design where Groups (with tagging enabled) and Tags are, for the most part, the same. Outside of DEVONthink, tags are typically thought of as a flat, non-hierarchical organizational system, while folders are a strict hierarchical system of organization. That’s probably not something new to anyone here, but I mention it only because I wouldn’t expect ordinary Tag groups in DEVONthink to become even more hierarchical than they are now.
Are you using Group tags or ordinary tags in DEVONthink? If you use Groups tags, which IMO is a better choice for anyone wanting to create tag hierarchies. The path to the document in the database (which is then the tag hierarchy) is displayed at the top of the DEVONthink window immediately below the main toolbar.
And yes, the tag display at the bottom of the document is in alpha order. If the order of tags at the bottom becomes confusing, the display can be turned on/off from the View menu.
Apologies for wading in here, without really answering the question – but on the off chance that the Developers do see this, I figured I’d add my few pence!
This doesn’t solve the hierarchical problem, but a [i]really/i simple solution (for me at least), would allow the user to option to add colours to labels, using the already-existing drop-down arrow.
Since I understand that moving away from the current approach of alphabetising the tag-‘list’ could get very messy, very quickly (although I’d love the option of being able to try that for myself) – I guess the option to colour selected tags on a per document basis (i.e. only when I open/select that document, will I see the coloured tags) could solve some problems/allow for additional possibilities.
Yip. I’d like to individually colour certain tags.
The tab-bar at the bottom of the pdf when opened in a separate window, or along the bottom of the display, when the file is selected in 3-pane view.
Here it is:
Since it’s already there – it might be used to add a colour to that specific Tag?
In my case, I might have 10> tags associated with a file, since it touches on several different topics. But in essence, it is focused on Topic A (and maybe Topic B). I would then, for instance, colour that Tag that represents the MAIN/‘in essence’ focus of that pdf, in RED. I might colour another, possibly the Topic B, in a lighter shade of Red, for example.
That next time I open that File, I see the tag list at the bottom of the file, and two of them are coloured RED and Light-red [those same colours could also be indicated in the Tag column over in the 3–pane view] – and I can instantly “see” what the primary focus of the article is…
So the tag(s) that represent the main focus of one document, might be of secondary focus when assigned to another document. In other words, the tag is not colored universally, but only in the context of the document(s) it is assigned to. From a logistics perspective, I would expect this would present a challenge because the color metadata is on a document-by-document basis, rather than associated with the tag. This would mean that the document itself would need to be modified somehow, or a corresponding .plist of the document created, to include the color metadata.
Assuming this could be accomplished, why/how would you have a ‘next time I open that File’? I ask because this seems counter to my typical use case where the tags are used as metadata to locate a group of related documents, and then I use the document title/comments/executive summary/annotation(s)/skimming of the article to determine the primary focus.
@korm Getting more specific on what I am working with/on: I have large db where I have collected various articles of industry information, competitive info, standards etc. Our company is structured to follow specific industrial segments - I happen to have a role across these segments.
Depending on what the specific focus of the discussion is, I may need to find all information relevant to a competitor, or to a specific segment or a particular industrial technology, a standard you name it.
At first I collected info by competitor in a folder and technology news in another. With a search query I attempted to then narrow down results to what I was interested in. The problem; you need to specify that search query which means you need to know what you’re interested in. When at first simply brainstorming - looking at the landscape so to say - you have no idea what you are going to be interested in.
I thought that multi-tagging articles would be a much better option so I could specify a variety of wide, open-ended attributes by clicking on the tags to get to a more specific result. But I have a lot of tags. There are many competitors, many products they have, the industry contains a wide variety of technology aspects, there are many different document types etc. So to keep it all a bit organized I keep related tags in tag groups. Most of the time these are 1 or 2 levels deep, only one group is much deeper. When I am poking around on the internet and find something interesting, I save it to the DB’s inbox and later on assign it tags and put the article in some folder. Consistency of assigning tags is key of course. Generally I look at the tag groups which I can almost read as a question ‘is this article part of …’ and assign it a tag from one or more groups. But, being human, I don’t always do this correctly and then looking at the jumble of unrelated tags at the bottom of the article isn’t too easy to read and determine if my tag assignment was correct/complete.
To give you a feel for the tags I have (short version):
asset
blower
compressor
– axial
– centrifugal
– recip
– rotary
pump
– hydraulic
– metering
– piston
– submerged
company
name
– products for
name
discipline
asset lifecycle
cm
reliability
process and control
doctype
news feed
press release
manual
brochure
segment
steel
pulp and paper
food and beverage
standard
ISO
VDi
Oreda
technology
featureX
fuzzy
nnw
matrix
Most articles will have 2 or more tags assigned, many have quite a few more. With this I can cross select on any of these dimensions to find ‘stuff’. As an example here is an actual tag set as it is currently displayed by devonthink:
bearing, cm, company, component, zycc, discipline, doctype, featureX, fuzzy, technology, white paper
displaying these with their tag parent relation would be:
The latter is much easier for me to read and determine if the tags are correct.
@korm - your tree tags example. I have the luxury that so far non of my tags have multiple parents. I.e., your ‘oak’ tag occurring in both ‘Eastern Woodlands’ as well as ‘Nut Bearing’ is not a problem in my tag tree. I understand that multiple parents may need some additional thinking to display this right/intuitively.
@Greg_jones: I don’t use group tags i.e., folders appearing as tags I have turned off. Folders are a very stiff structure I find not very useful as a tag. I think of folders purely to keep files with a loose relationship together and to make sure the folders don’t get too big.
Of course the whole purpose of tagging is to find an interesting collection of articles. At the moment I use a combination of the tag ‘view’ (displayed at the right), the advanced search as well as simply clicking the tags in the tag groups. Now the problem with clicking multiple tags in the groups is that it operates as an OR (all selected tags are displayed) whereas I need it as an AND so that I can select a specific cross section. Would be great if that tag view could be expanded with the hierarchical tags to make finding the relevant tags easier…
Greg – re your first point, yes – that’s what I had in mind. I am hoping it would be connected somehow to each individual document. As you explained, this might pose its own set of problems/challenges – and given my absolute lack of knowledge in these things, is potentially something not easily overcome (if at all).
Re your 2nd point – I might come to a particular grouping of documents through a variety of ways – e.g. searching by Author, or by Year, or by Tag intersection (selecting Tags A/E/W), or by the See Also function etc. etc.
In those instances, the coloured-tag would but be a further addition of meta-data – to allow for a quicker visual dissection of what might be relevant, or not.
Obviously, fine-tuning the search function would yield similar results – but the way I see things, the ability to add that colour would be of assistance when I am doing the initial tagging.
By example, I prefer to cast my net quite wide when I tag.
I certainly don’t tag every little thing – but took the decision early on (and the merits of my approach are no doubt open to criticism) to rather Tag if the topic was discussed in the article, than to leave it out on the basis of ‘that discussion’ not being extensive enough (or whatever). I figured I could always whittle down my search criteria after the fact.
I preferred this approach to the alternative, where I would need to spend more time (at the point of tagging) deciding on whether or not to add a (possibly) relevant Tag – mainly due to a legitimate(?) concern that I might, in the future, come to find Tag A!A (and its related topic) far more important than initially appreciated [as my research requirements change].
I would then not want to be sitting in the situation where I know I have scanned through many documents that potentially touched on Topic A!A, but they were never tagged, since I felt it wasn’t enough of a discussion at the time. After the fact – something there might have been important, but it is potentially more tricky to find it now, in the absence of the appropriate tag.
My thinking was that if I could also colour-code Tags, I could then cast the net wide, but quickly mark one or two Tags as being Primary/Secondary. I would then have the best of both worlds – not being concerned about a particular document having too many tags, and potentially obscuring its core topic, but simultaneously, not being concerned with adding as many tags to that document, as my initial scan suggests.
Again – this could possibly be done in the Comments field etc., but by ‘adding that layer’ to the Tag, I don’t have to be concerned with taxonomy issues in how I describe the comments etc.
And again – as you mention, surely I would in any event be able to ‘see’ what the core topic is, just by seeing the topic/scanning through it – but that really depends on my search approach at that particular time. If I’m in 3-pane view, and have identified a large group of files (for whatever reason), instead of jumping down through each selection, to scan the attachment view at the bottom, a colour-coded tag could be of great use in drawing attention to particular files that might be on-point.
There might very-well be a far-easier way of doing the above, that hasn’t occurred to me [and I’ll be all to willing too face-palm appropriately this side] – but in the absence thereof, I figured the colour-tag approach would be simplest, and would have the added benefit of that visual cue…
Hope I’ve managed to explain my reasoning coherently. Whether the underlying premise thereof is coherent, is of course a completely different question!
@joost, have you considered something like this. (Full disclosure: I would find this a pain to work with, but it’s easy to trial because the names of existing tags can be changed – carefully!)
@Cassady you’ve got a finer mind than most if you can distinquish subtle meaning in all those colors – and remembering what the scheme means a week, or months after you set it up
Isn’t the use of colorized tags just a substitute for text or symbols in your tag names? Maybe a distinction without a difference?
@korm; yes that would be a pain to work with indeed. Funny you mention this because that is how I use tags on yosemite at the moment. In OS X, the tags aren’t even sorted alphabetically so it is a real pain to find anything. I don’t have as many tags in OS X as in the DT database, and they are for a different purpose but I did find it necessary to include parent names in the full tag exactly as you describe. Barely workable.
Ammonite; yeah, forgot about that tool. Gotta go play with it again, thanks for reminding me.
It is meta-data about meta-data, but not that much – one or two colours shouldn’t be too difficult to handle.
That being said – I think OP’s point, and comments made here and elsewhere, point to a huge need/want on the part of many users, for increased meta-data functionality. Here’s hoping the Powers That Be will be able to give us something along those lines… If not colours, then hopefully fonts, typefaces or shapes to the tags!
From Godel Escher Bach: Genie: I am pleased to report, Achilles, that you have exactly one (1)
Typeless Wish-that is to say wish, or a meta-wish, or a meta-meta-wish,
as many “meta”'s as you wish even infinitely many (if wish). Achilles: Oh, thank you so very much, Genie. But curiosity is provoked. Before I make my wish, would you mind telling me who or what GOD is? Genie: Not at all. “GOD” is an acronym which stands for “GOD Over Djinn”.
The word “Djinn” is used to designate Genies, Meta-Genies, Meta-Meta-
Genies etc. It is a Typeless word. Achilles: But but how can “GOD” be a word in own acronym? That doesn’t
make any sense! Genie: Oh, aren’t you acquainted with recursive acronyms? I thought
everybody knew about them. See, “GOD” stands for “GOD Over Djinn”-which can be expanded as “GOD Over Djinn, Over Djinn”-and that can, in turn, be expanded to “G( Over Djinn, Over Djinn, Over Djinn” which can in turn, be further expanded … You can go as deep as you like. Achilles: But I’ll never finish! Genie: Of course not. You can never totally expand GOD.
Thanks for the great early Monday morning discussion and humor!