Mixing docs and groups

I read in the ebook the suggestion not to mix docs an groups within a group.

I am actively replacing my finder with DTPO, and am running into this in three-pane view. Curious how others handle the single docs in their groups. Anyone make a ‘miscellaneous’ group?

If you mean one that contains documents and groups: yes, plenty of them.

You can also make a group that contains one item.

So, for example, I might have a group 2009 Taxes that contains subgroups the subgroups “charitable donations”, “deductible taxes” that contain multiple items, but the subgroup “mortgage interest” would only contain one item. I do it that way because I’m going to use the same group structure year after year and it’s useful to have a “bucket” where I’ll put the mortgage interest statement.

I also “mix” groups and items. I have a group for “Home Improvement” that contains multiple single receipts, plus a sub-group for a bathroom remodel where I grouped all the receipts related to that project together.

Good Luck.

sjk-

The ebook also recommends that every group have a different name. So if you are working in Personal Taxes–>2007, but also have Corporate Taxes–>2007, each ‘2007’ would show up in a search, or in a move document operation. If you have multiple ‘Miscellaneous’ groups, how do you distinguish each?

I run into this somewhat frequently, where I am not sure where to move or copy an item. I welcome any suggestions.

Also, in the thread you linked, Bill DeVille states, “Note that we recommend that there should be no documents contained at the top level of a group that also contains subgroups (although I sometimes violate that recommendation myself).” Wouldn’t this imply that NO single documents would be at any level but the lowest?

Thanks!

  1. I try to keep each group name unique, usually by adding a referent to the containing group in the sub-group’s name. So, for example, Under the group “Personal Taxes” subgroups could be named “Personal Taxes 2007”, “Personal Taxes 2008”, etc.

  2. Yes, Classify will learn your organizational structure better if there are not BOTH documents and subgroups within a group. But DEVONthink will not initiate corporal punishment of the user if this recommendation is occasionally violated. :slight_smile:

Does it mention why?

For me that can be impractical to self-enforce in a larger, strictly hierarchical context. But I can see more value having unique group names in a tagging context like DT’s where groups/tags can be used interchangeably. I still haven’t done much with tags in DT but when I switch to Tags view in my primary (and largest) database there are several instances of identical names for tags that correspond to groups with the same name, but in different hierarchical locations. The location is displayed in the help text when hovering over a tag, though since it’s a flat list it would be nicer if each tag was identifiable by having a unique name.

It’s never been an issue with methods I use to move/duplicate/replicate items because the destination can be determined easily enough, either explicitly under an expanded hierarchy and/or in help text when hovering over a candidate.

With more specific details of what you’re doing I might understand why it poses a problem and could possibly suggest alternatives. Even with identical usage methods it could simply be that something acceptable for me may not be for you. And vice versa. :slight_smile:

That interpretation is what had elicited this response:

I normally violate that recommendation and it’s hard to imagine what using DT would be like if it was an enforced restriction…

Bill’s comment and my response are what the “yes, plenty of them” post link in my original reply was specifically referring to. Seemed essentially the same issue as the ebook’s “suggestion not to mix docs an groups within a group” you mentioned.

I saw both as recommending: A group only contain other groups or documents, but not both. That would seem to make it logically impossible to have documents anywhere except in the deepest groups under any branch in the hierarchy, as you’re questioning.