I see the point about not contradicting the manual and I guess that one of the things I wanted to say when I objected against routinely putting inexperienced users on the wrong footing is that the groups are tags and tags are groups mantra shouldn’t be in the manual.
To my experience and to the experience of the friends and colleagues I helped with DevonThink, the differences in behavior between tags and groups are not minor (think also of all the group or tag discussions - they would not make sense if the differences were really minor) and the decision what to do with groups and what with tags is crucial to the efficiency of a database (the colleague who used project groups and subject tags reorganized his database when he discovered that how efficient DevonThink’s AI can be when the references are grouped according to subject rather than project).
So explaining that for most purposes groups should be seen as collections of references and tags as properties of documents (perhaps with a footnote saying that technically groups and tags are the same) would be much more useful for them than the standard ‘groups are tags and tags are group’ tune.
you cannot use DevonThink’s AI to tag documents
you cannot move/duplicate references by typing
you run the risk of accidentally deleting files when deleting a group but not when deleting a tag
if a document has more than one tag these are not treated as replicants, neither is the reference of a document in a tag group treated as a replicant of that document in a non-tag group (for instance, if you delete a reference to a document that has no replicants it will be deleted, no matter how many tags it has!)
tags cannot be indexed
These are important behavioral differences and these differences make sense if and only if groups are seen as collections of references and tags as properties of documents. That the developer choose to implement groups and tags by means of the same kind of entity means good luck for creative users, but it is no reason to confuse inexperienced users by saying that groups and tags behave the same.
Tags and groups can behave the same, and in fact the default behavior for a new database is that they [i]are[/i] the same. If groups have tagging enabled, everything that you just posted above about tag behavior is wrong. I can have a thousand tags in a database, and have none of them appear under the ‘Tags’ group.
The argument can be twisted around and around.
The fact seems to be that there are differences between groups and tags, so saying they are the same is wrong; similar would be better.
However, as The New User, boy, its confusing! Even experienced uses cannot seem to agree. If there wasn’t a chance of losing a document (by remove a group) I dont think it would matter so much. This seems so important to me that its now become the central thing to base all other decisions off.
Is it your point that groups (or rather group names) can be made to behave like tags by disabling ‘exclude groups from tagging’ in the database properties?
If so I like to point out that
In the current version of DevonThink (2.3) the ‘exclude groups from tagging’ option is by default enabled, meaning that new users will experience the differences I describe.
Disabling this option does not eliminate all differences between groups and tags (for example, as you say, the groups (perhaps they should be called ‘group tags’ if ‘exclude groups from tagging’ is disabled) do not appear in the Tags group unlike the non-group tags, and more importantly, you can still not use non-group tags for AI.
Disabling ‘exclude groups from tagging’ is useful in several cases, including:
you prefer tags over groups and want to avail yourself of DevonThink’s AI for tagging
you are looking for a semi-automated system to replicate documents
There are, however, many set ups in which it is convenient to have groups and tags behave differently (IMHO having tags and groups behave differently is more intuitive than having them behave in the same way) and in this case it is helpful to see groups as collections of references and tags as properties of documents.
Perhaps we can agree that to new users it is best to explain that in the default case groups should be seen as collections of references and tags as properties of documents, but that this can be changed by disabling ‘exclude groups from tagging’, instead of unhelpfully repeating that contrary to what they experience, groups are tags and tags are groups?
You have adopted a paradigm that “groups should be seen as collections of references and tags as properties of documents” and personally I agree with the concept 100%. However, that doesn’t change how tags and groups work, nor does it necessitate that group tags be turned off (or on) for a particular use. The user can still assign a document to a collection with a group (gray) tag, and the user can still assign a property to a document via a tag (blue) tag. The tag (blue) tags will appear under the Tags group, and the group (gray) tags will appear under their respective groups. However all tags (blue and gray) will be displayed in the Tags view (command-6) and all tags can be assigned to a document via the tag bar. This is why Christian states that groups are tags and tags are groups.
Again, it may very well be useful to think of them differently (collections/properties) for the configuration and optimization of the database. I believe we are in complete agreement on that. But with respect to the underlying mechanics of tags and groups in DEVONthink, they are more similar than different. And with that thought, I should move on and get some of my own work done.
I am not sure that I have understood the first sentence (English is my second language and I have trouble understanding colloquial expressions).
Are you saying that you do not need DevonThink’s AI? If so, consider not using DevonThink at all. Consider using a single folder on your hard disk as your black hole with DevonSphere Express as a better spotlight.
For me it is important that the stuff I currently don’t use is organized into a subject hierarchy because that makes it easier for me to find the relevant stuff when I start a new project. I want DevonThink do the grouping and I want to determine what belongs to which project myself (with help of DevonThink) and for that reason I use tags for projects (I could also have used groups excluded from classification, search and see also, but using tags seemed easier).
I have the impression that for you the organization of the stuff not yet or no more in use, doesn’t matter (as long as you can find it by searching). In that case you could collect everything in a big ‘My stuff’ group and replicate the things you need to the relevant project group (by replicating rather than moving the items from the ‘My Stuff’ group to the project group you prevent accidentally deleting files when you delete a project group – there is always a replicant left in the ‘My Stuff’ group).
If you do want to avail yourself of DevonThink’s AI for tagging consider using groups for tagging the files in the ‘My stuff’ group. This is easiest if you disable the ‘exclude groups from tagging’ option of your database. If you do so, the names of groups can be handled in the same way as tags. When you tag an entry with such a group tag, it is replicated to the corresponding group.
If you use groups as tags it is handy to have a separate group (say ‘group tags’) with subgroups that serve as the tags (separate from the project groups). It might also be handy to exclude the project groups from classification, search and see also.
@Greg_Jones: I understand the mechanism and I understand why the developer says that groups are tags and tags are groups. I believe also that we are in complete agreement on what happens, as well as on the mechanism.
My point is a point about what to explain to new and inexperienced users. I think it is not very helpful to tell those users (in the manual or in the forum) that groups are tags and tags are groups or to say to them that for all practical purposes groups and tags behave in the same way, when they see before their eyes that tags and groups behave differently (as Edgley puts it: “The fact seems to be that there are differences between groups and tags, so saying they are the same is wrong”) and when it is important for the design of their databases to understand the differences or, perhaps, to minimize the differences by disabling ‘exclude groups from tagging’.
I belief it is even less helpful to dismiss ‘the groups are collections tags are properties’ model (which is often a useful model but, as you point out, it doesn’t describe the mechanism, and other models can be useful too) as too technical and to canonize the groups are tags and tags are groups view as the correct user experience (as Korm did).
Of course, my opinion on what is helpful and what is not, is based on my very limited experience (some friends and colleagues and some discussions in this forum) and your mileage may vary.
Sorry for being unclear, I get told that by people who speak better English than I
I do wish to use the AI, that is the main reason for going for DT.
I have made the plunge and have started a group way of thinking.
It means I have lots of folders called things like eBook and images, but we shall see. At least its not a major pain to have to change things around.
I shall try using smart groups in the far left window for projects so I can get some visual separation from the actual data. If that doesnt work then something will be tried.
