Is there a way to remove tags in bulk, from a selection of files?
I tried selecting the group of files, and ‘dropping’ them onto the Tag I want removed, from the “Show Groups and Tags” popup - thinking that doing it in reverse might have the desired effect, but did not appear to work.
If you run the Support Assistant from the Help menu, select Get Extras>Download Extras, there is a script to ‘Remove Tags from Selection’ (there is also a script to add tags to a selection). Install this script and it will appear in the Script Menu>Tags folder. Make a selection and run the script and you will get a pane to enter the tags you want to remove. The only downside is that the script does not auto-complete the tag name-you’ll need to type in in exactly, in its entirety.
It’s not actually deleting the articles-only the ‘replicant’ of the articles in the Tag group.
And realize that if you are creating documents in a Tag group, they will be deleted if you delete the Tag group.
If you Tag a file outside the Tag groups, a Replicant is created in the appropriate Tag groups, so deleting the Tag Group only deletes the Replicants. However, some people attempt to use the Tags group as a filing structure. In this case, no Replicant is made.
(In the case that you created or filed directly in the Tags group, then added other Tags to those files, Replicants would be made in the other Tag groups, but upon deletion of the last Tag, those files would be deleted as well.)
Suffice it to say, I think it’s better (and less confusing) to Tag outside the Tags groups.
The behavior of deleting the only copy of a document if the user had dragged it onto a tag (thus not making a replicant) is baffling to me. Yes, it would be best if users didn’t tag by dragging, but it shouldn’t be possible to delete the last copy of a file unless you specifically mean to do so.
A simple “Deleting this tag will remove the only copy of the files…Do you want to move them to your database before deleting the tag” warning would seem trivial to generate and pretty basic idiot-proofing.
Tags are groups. If you explicitly delete any group and that group has contents, then the contents all go to the trash. If you delete anything using the Delete key on your keyboard you will get the message “Do you really want to remove the selected items?” UNLESS you have previously dismissed such messages by clicking the “Don’t ask again box”. Otherwise, if you use the “Move to Trash” button on the toolbar, or dragged the item to the trash, or used the Move to Trash menu command, or use the “Move to Trash” keyboard action command-backspace, no warnings are given. The reason you get the warning with the Delete key but not the other trashing methods is that the other methods are explicit: “I am deleting this thing and I mean it”. On many keyboards the Delete key is easy to hit inadvertently, hence the warning.
Anything deleted is in the Trash - so its easy to get it back UNTIL the trash is deleted, but there is another level of warning when the trash is emptied. Even when the DEVONthink Trash is emptied, the item is now in the OS X Trash. It takes a sequence of inadvertence to get rid of something by mistake. The design seems pretty “idiot-proof” already. I don’t agree we need more warnings.
I had forgotten about the implications of deleting a tag where the files were dragged onto a tag (and having that tag as the ‘only’ one associated with the files)…
Fortunately, it’s not something I do often, if at all – I tag ‘outside of groups’.
Regardless, thanks to the scripts - I finished a pretty big reorganising of my “tag-cloud” in just over an hour, as opposed to the significantly longer time I would’ve taken, were I to have had to remove them manually… Joy!
In terms of “tags are groups”, they differ (at least as far as I can tell as a user) in a key way. If I select a regular group and see a document in the next pane, I know that the document is “physically” located in that group. Thus, I can predict what will happen if I delete the group – I lose the items in it.
If I click on a tag, however, what shows in the next pane is either (a) a pointer to the original item, stored elsewhere in the database or (b) the original document itself, if I accidentally dragged it onto the tag. If there is a visual distinction between the two, I’ve not figured it out. In case (a), deleting the tag doesn’t affect the original document. If case (b), I lose my only copy of the document.
I’ve always been taught in UX design that the same user action should yield the same result no matter how the user “got there”. Here, the same user action will yield different results, based on something I did in the (possibly distant) past.
If there is a visible distinction between tag cases (a) and (b), I would love to know it.
See the top image. The cases shown are (a) a document created and located inside the tag “I am a tag” and (b) a document located in the Inbox and tagged with the tag “I am a tag”. Look at the path (shown at the top of each display, just below the toolbar). The path clearly indicates the “Location” of each item. It is also possible to add “Location” as a column to several views. “Location” is also shown on the “Show Info” panel for the currently selected document and group. The “Instances” drop down of “Show Info” also indicates for tagged items where the original(s) are located.
And the tooltip also shows “Location” (see the bottom image - the pointer is hovering over the top document – Grab does not always grab images of pointers). In each of these five methods the UI provides the clearest information possible to enable users to conclude that there is a difference between cases (a) and (b).
Since there are already five different methods DEVONthink uses to show location of the original item when one is browsing and selecting documents in a Tag group, it’s possible that not much more could be done to keep the user informed and prevent inadvertent deletion.