in order to find information in my database I relatively often know the tag of the document or a combination of tags plus the keywords I’m looking for either in the file name or in the content of the docs. In order to search efficiently I would like to create search strings like: “tag:xxx tag:yyy filename:zzzz” or “kind:docx aaaa”. The first term should search for docs with both tags xxx and yyy and zzzz in the filename, whereas the second should only show all word docs with aaaa in the content.
That is similar like in spotlight or Google although also in Spotlight it is implemented only very rudimental.
Currently I can do that only in a multiple steps by using smart folders or search first for one criteria and then the results for another, but that is not very handy. Any advice how this can be achieved more efficiently?
Any comments from power users or the dev team?
Say you have two tags, Oranges and Apples. If you want to find Oranges AND Apples, then open tags view, select Oranges and select Apples. You can’t add kind, here, but you could sort the selection by kind.
If you want to find Oranges OR Apples, then open three pane view and in the Tags group select Oranges and select Apples. Actually, once you’ve selected the two tags in one view you just need to switch to the other view in order to toggle between AND and OR.
Many thx for the reply. Indeed I’m using these kind of approaches, but find them not very ergonomic because depending on the combination of criteria one has to choose a different path to accomplish the objective and it is a relative click-intensive and lengthy process apart of the fact that if working with thousands of docs it makes it very difficult finding the required info. Since we work here with a DB, I wonder whether search strings with keyword support would make the entire workflow much simpler.
Based on your example a search string could look like “tag:(Apple && Orange) kind:docx” just typed in the search field. How much easier and more flexible would that be…
Yes. You’re right. Good idea.
I agree with @Novice’s thinking on this. Would it be helpful if we started a group or thread for the purpose of clearly and succinctly describing the elements of an efficient such workflow? There may be a lot of development being done in this area, though, and all we need to do is wait for a little while for it to make it’s way into a release. Comments from Eric, Christian, Bill, …? Thanks very much, Keith
This is more of a filesystem/search engine kind of task, in my view. Wouldn’t exposing the DTbase to Spotlight so that DT’s tags are searchable right next to existing file-based metadata do the trick?
@Innatech – Spotlight reports the Kind of everything it returns as a “DEVONthink…Document”, which is not helpful. Impossible in Spotlight to discern Group that a document belongs - or any other such DT database-centric attributes.
@KeithKendrick – isn’t this the thread?