I see that “Exclude Groups from Tagging” is checked by default now in the Database Properties. I think this makes a lot of sense in that the delineation between a group and a tag becomes clear to new users who are typically otherwise confused. I’d like to keep my database this way. However, I was compelled to uncheck it again. I thought it might be useful to you if I ran through the reasons why so that possible improvements might be implemented.
The Tags Bar is an incredibly easy way to assign items to groups. Typing in the beginning of the name and using auto-complete is extremely fast and efficient. There is no comparable way to assign a group to an item if it is not a tag. Perhaps a similar “Groups Bar” would be useful?
You can’t search by group. Yes, you can restrict your search to a single group but you can’t compound it, for instance, by saying search in group 1 and group 2. You can do this easily with tags. Implementing a way to do this with groups would go a long way towards having me keep groups and tags seperate.
You can’t easily see which groups an item is assigned to. You can, of course, see the icon which tells you its assigned to more than one. But you can’t tell which ones they are. At best you can have the program “Reveal” the primary group for the item. This isn’t a problem if your groups are also tags. The tags are right there in the “Tags Bar”. Again, a “Groups Bar” might be helpful.
Nice work on the new version. Love the full screen mode. This program needs it more than any other I regularly use with the possible exception of Mail which, of course, got it with the OS update.
I have a couple of thoughts, and a question, to perhaps help you make the best of what 2.3 has to offer.
If you want the ability to conveniently assign documents to groups, is there a reason why you would want to turn off tagging for groups?
The toolbar search function works relativity well for this. You can make group selections by shift- or command-clicking groups and check the option to search in selection. However, you don’t get the advanced search features of the search window.
If you bring up the Inspector, you’ll see in the Instances section where all replicants and/or duplicates are located.
Well, that is a pretty good question. I suppose keeping the two separate appeals to my sense of order more than anything else. There is also one practical issue.
I’m probably like most people in that I consider groups to be collections of documents related to a specific person, group or project. Tags, on the other hand, I consider to be relevant over a broad number of groups.
For instance, an email from John Smith would find its way into the “John Smith” group. It would also be tagged with “Correspondence”. If I wanted to find emails associated with John Smith I would create a smart folder which searches for “Correspondence” in the “John Smith” group.
On a practical note, DT is pretty good at picking up relevant groups using “See Also & Classify”. Its not very good at picking up groups like “Correspondence” (in my experience). If “Corresondence” is a tag only, I can tag an email in my “Inbox” as “Correspondence” with the Tag Bar and auto-complete. I can then use “See Also & Classify” to move it to all the relevant relevant groups (which it will pick up). But it turns out I can’t do that if “Correspondence” is both a tag and a group. In this case, using “See Also & Classify” causes DT to move the item out of the “Correspondence” group, even if it is also a tag.
Your example of the Classify procedure suggesting a different group than Correspondence has a better explanation than the point that at the moment groups were also included in tagging (which is in fact irrelevant to Classify’s decision-making).
When Classify looked at the contextual relationships of the words contained in the email message, it looked only at the text content of the message and compared its terms and their relationships such as frequency to the patterns of words in each of the groups in your database.
Your Correspondence group is a grab-bag of messages about a variety of things, in all probability. Unlike many of the other groups you created it doesn’t have a defining theme (in words and their contextual relationships) among the documents populating that group, that Classify might be able to discern.
Suppose, for example, that you select within your Correspondence group a message that’s about contributions of amateurs to observations of comets and asteroids. You have hundreds or thousands of messages in the Correspondence group, but very few with a topic similar to the selected message. If you ask Classify to suggest a location for that message - and if your database includes a group that contains a number of documents about astronomy - then Classify will likely suggest moving it to that other group location. That’s the way it works, and it doesn’t ‘care’ whether or not groups are excluded from tagging.
Yes, I figured that was likely the case. The classification as “Correspondence” generally has more to do with the file type (usually email).
My thoughts are kind of developing as this thread develops. If the question is, “Why would you want to keep tags and groups separate without making groups tags?” this is why. Its true, you could still have all of your groups tags. But there are definitely some categories which are better used as tags only. This leads to a better understanding of what the difference is and how the program works.
I’ve struggled with the difference between tags and groups since I started using the program (probably like most people when you come down to it). Building a wall between the two and explaining the concept just as you did makes the whole concept easier to understand. Goups are specific collections that the program can easily auto-classify. Tags are broad groupings that it can’t easily classify based upon the text of the document. The reason there’s a tags bar is to make it as easy as possible to assign these tags given that the “See Also & Classify” won’t work for that kind of category as a group.
So just ot summarize my thought at the risk of being repetitive, you could still have all of your groups as tags in my example. It would make no difference. But for the beginner, keeping them separate simplifies everything and makes the whole program easier to understand.
Perhaps the better question is, “Why would you ever want to make groups as tags?” I’ll have to think about it.