OK, I’m looking at moving my stuff from Journler to something else. I’m a power user of Journler and Omnifocus and do scripting work daily - so I embrace complex and deep software.
DEVON is for sure a finalist
However there are some quirky things I’m having trouble getting past.
One is the way tags work. I know its beta.
Tagging in nearly every app I’ve used it in is a method of meta information. In DT it seems to be badly conflated with hierarchy organization.
When I move an item from a group to a tag-folder, I don’t expect that the item will be removed from the group - I’m meaning “apply this meta data”
That is a tag-group should be much more of a smart-folder that has the power to modify an entry.
To get my expected behavior I pretty much have to opt-cmd drag every time.
It doesn’t make sense to auto tag everything dragged to a group (more conflation). Groups and tags should be different things.
Tags are also not searched in the expected way (I see another thread on that).
My preferred way of working is to think of all notes dumped into one giant repository, then organize them into groups and with tags, but that this organization is just meta information and that I can put move an item from the library into one or more groups without having the opt-cmd drag to create aliases.
This is more the iTunes approach than the Finder approach - and why I seek an app to help manage info instead of just the finder.
Also its confusing that the “Tags” parent group, and smartgroups count groups in their counts in parens.
I’m sure I’ll have some other Q’s - still taking it around the block.
I like the way Tags behave like a glossary. I can sort my database in an alphabetical list and I often find items faster than browsing the folders structure or using the search engine. But you’re right, maybe they should call tags ‘glossary’ or something like that.
Personally, I do not use tags in any other application exactly because they are not hierarchical, because they do not contain any relationship information, and because I can never remember which tags to apply where (did I call that tag “Foo Bar” or “Bar of Foo” …). So for me, “nearly every app” is completely and utterly useless.
DevonThink’s approach of having replicated groups, where each replica adds its own set of tags, solves all the issues I used to have with tags. Again, that’s just me. And yes, the UI, search, shortcuts, etc. can be improved – but I do like the general concept.
You can enter freeform tags in DevonThink (in the Info panel), and you can exclude groups from tagging (again, the setting of default values could probably be improved). Thus, your suggested approach to tags could be easily done with DevonThink.
If one doesn’t like tags and don’t use them, then not sure you’re opinion carries much weight about how they are implemented.
My issue is that Devon has shoehorned their tag implementation into their hierarchy/replicant view of information.
A hierarchical location for information ie:
animals -> dogs -> German Shepherd
Is a discrete location. While tags might be more attribute like:
Finding items that match one or more tags is often a transient exercise. To create a location in a hierarchy for each permutation of tag combinations, and then to replicate an item into each of those possible locations is just silly. Tagging is a faster way of assigning a piece of information to multiple groups.
Basically what I’m asking is that adding/removing tag information (blue tags) not alter an items location in a hierarchy and vice versa. That they be true parallel systems, each with their own strength and weaknesses.
I don’t like that when I drag an item from a group in the hierarchy, to a tag group, that it removes the item from the group to assign the tag.
I only said that I don’t care much for other implementations.
For me, there are primarily 2 separate workflows associated with tags: assigning them, and searching for them. I’d love to use them more for #2, but I haven’t found a usable implementation for #1.
DevonThink has a traditional tagging system. On top of that, a documents location may introduce additional tags (if set up to do so - it’s entirely up to the user). I happen to prefer the second way of introducing tags, while others may want to use only the traditional approach.
My point exactly: I have a tag “Family”, but then I realize that I also need “Myself”, “Sister”, “Father”, “Mother” … Now, if I tag something as “Sister”, it should also come up when I search for “Family”. The only way to achieve this is to remember than whenever I use the “Sister” tag, I also have to use the “Family” tag. Same thing for shades of a color.
I’m just a taxonomical kinda guy
While certainly not universally applicable, I like using (replicated) groups for assigning tags, and using traditional tag interfaces for utilizing them afterwards.
There is no need to “create a location in a hierarchy for each permutation of tag combinations”, as documents can be replicated themselves, or tags can be assigned directly (right from the tag bar, just click and type).
Hopefully tag searching will be more robust in the final 2.0 release, but until then you can do this now with a smart group search. If you create a tag group ‘Family’ and nest the tag groups ‘Sister’, ‘Father’, etc. under ‘Family’, a smart group search for the tag ‘Family’ will also return all items tagged ‘Sister’, ‘Father’, etc.
Sure, but that means I’ll have to constantly update my searches as I add tags. Even worse, imagine location tags (North America > Canada > Quebec > Montreal > Downtown) - with a hierarchy, that’s super-easy, and always up-to-date. Manually maintaining smart searches for this would be endless work.
All I’m trying to say here is that I see great potential in DT’s approach to tags. It works great for me, and solves my problems. Beyond that, DevonThink still allows users to apply more traditional tag workflows (many forum post sound as if the group-based approach was exclusive, and hence the world is about to be coming to a stop).
And I am sure that everybody’s aware that the UI could use more work, no question. But the underlying concept of having multiple ways to assign tags (via groups AND/OR manually), but to use them in a unified way for accessing documents, is very promising.
I agree-as a permanent solution this approach would be a nightmare. However, I expect that tag searches in the 2.0 release will be greatly improved over what is available now.
While I like the fact that “location” tags are also added automatically, I haven’t found any preferences for this behavior. My problem is not with that feature however, its more with the reverse.
The standard groups seem to act basically like folders. Default drag behavior is a move, opt-drag is copy, cmd-opt-drag is alias/replicant.
Thats fine for Folders/Groups - but not for tags. For tags the default drag behavior should be replicate. When I drag an item to, or delete from a tag group, I’m saying I want to apply or remove a tag, and not effect its place in any other groups. If I drag from a tag group to a location, the tag should remain applied, and a replicant should be added to the group.
This is the default unless I hold cmd-opt - so I would say it does it unless I tell it not to - unless I’m missing something.
