It would be of great help to me to have more than just 7 labels. Don’t know if anyone else wants that, but it would sure make labels a lot more useful for me.
+1 for more labels
I am curious how many labels you think would be enough and what are you using them for?
The problem I see (and it’s just my opinion 
) is if there were too many labels, then you could get into a situation where you’re trying to recognize colors to subtle to quickly distinguish. Also, depending on your implementation, you may have to remember what each color means. Much easier with a smaller palette.
Cheers!
Jim
BLUEFROG
I agree with BLUEFROG. My aged eyes could easily fail to distinguish subtleties of color in an expanded list of Labels.
Labels can be convenient, as one can search for items that have no label, any label or a specific Label, in the Full Search window.
Think about the logical possibilities if you “extend” your use of Labels by a scheme in which a specific Label is either flagged or unflagged. For example, you could then distinguish between Yellow items that are flagged, and those that are unflagged. A search based on that scheme can be very quickly set up in the full Search window.
You could, if you wish, extend the logical possibilities (to levels of bewildering complexity) of your “Labels” scheme by adding modifier tags and using them via the Advanced button in the full Search window
Any of those approaches to an “extended” use of Labels can of course be used to create smart groups for each logical possibility. (Did you know that you can create a smart group based on the criteria in the full Search window, by clicking on the “+” button to the right of the query field?)
In short, if you think a bit “out of the box” you don’t need the developers to give you more Label colors. You can devise your own scheme to extend the logical possibilities of a marking scheme, effectively increasing the number of “colors” by adding the Flag state, or extending it to a huge number of “Labels” in effect, by adding modifier tags to your heart’s content. Think of the number of logical distinctions to apply to database content if you use Labels (None, Any, one of seven colors), Flag (Any, On, Off) and none, one, two or three of a set of three modifier tags – it becomes a surprisingly big number!
Amen! Preach it, Bill!
And thanks for the tip on the Smart Group creation. SO much to learn…
All this is doable, and very useful.
But the key issue that I see is in the contrast between:
and:
The great thing about labels and flags is that they are immediately visible in the document list, and therefore provide context: labeled and flagged documents are in the list with unlabeled and unflagged documents, and one can sort by Label (but not by Status, or using any compound sort) to get these items to bubble to the top or bottom of the list.
Searches are powerful but they do not provide this context – a search separates the documents that qualify into a list, and their relationship with other documents is lost.
Having context visibly depicted is a great way to get a gut sense of the database’s content at a glance (well, a glance and some sorting and some scrolling and another glance).
For this reason, I believe that having more options for labels is intrinsically more useful than having fewer options. The current labeling scheme could still be implemented, with an option to expand the list using more color/label entries.
Of course, there is more to implementing expanded label capability than this simplistic statement (such as the ability to export and import these color/label definitions among databases), but I believe that this would be a very useful addition. Adding the ability to sort by Status (Flagged, Locked, Unread) and to rename the Status and Label text would be useful too. And compound sorting, too. (And this leads into the discussion of customizable metadata …)
But, back to the ability to see context in the document list: using colored labels and using searches is sort of a left brain - right brain thing. At minimum, the ability to create customized Labels consisting of user-defined colors and text would be very useful.
This is a curious thread. Two users said “I’d like more labels, please”. The developer could respond, “yes, I think I’ll do that” or “no, I don’t think that’s in the cards”. Why spend so many electrons explaining to the users that they don’t really want what they asked for? Maybe it’s just possible they actually do want what they asked for?
I know, I know – I didn’t have to read this thread, but still … why can’t DEVONtech just answer yes or no to a yes or no question?
Which is what DEVONthink already does, BTW
Quite right, in the Colors tab in Preferences, one can set up the seven colors and labels. Sorry, I should have been more specific and said more than seven. Sorry for the confusion.
Indeed …
korm, shoolie:
This is a place of exchanging information and ideas and it is an interesting topic for discussion. Sometimes people think they know what they want because they’re not aware of alternatives. Other times they may be suggesting something that others may not be aware of. (BTW, the OP wasn’t asking a “yes or no question”)
If the question only wants a developer’s perspective, and potentially a “yes or no answer”, then I would suggest using DEVONtechnologies bug tracking system to issue a feature request.
Cheers!
I appreciate the argument against too many colors. But the real value of labels to me is not their different colors, but the words I can assign to each.
I may have more than 7 words I’d like to assign as labels to items in a database. I know I can make them tags or Spotlight comments, but those help only after I’ve done a search. The great value of labels to me would be to have them visible at all times along with Name, Kind, Flag, etc.
But if there were the possibility to display a column for tags (e.g. in 3-pane view), then more labels wouldn’t be necessary anymore?
I’m a bit puzzled by some peoples’ reluctance on this. If you don’t want to use more labels, simply don’t use them. But why argue against other people having them who want them?
Oh well.
The unique value of Labels as a means to mark items for distinguishing characteristics comes from (and depends upon) the user’s ability to recognize instantly the colors used in the set of Labels.
Most (but not all) users can reliably distinguish the “standard” set of 7 Labels.
How many more Label colors or patterns would satisfy your wish? There are UI problems that would result from even a small number of additional color palettes, shadings or patterns. For example, we may be reliably able to distinguish between gradations of color intensity when the samples are adjacent to each other, but much less able to reliably identify the distinction implied by a single sample.
Aside from issues related to color blindness, there have bee many studies of color perception that should be considered when thinking about extending a set of Label colors.
I might be able to distinguish the differences between several shades of green when all are visible at the same time, but find it difficult to tell which is which when one of them is viewed by itself. This issue can be exacerbated when displaying the Label colors on a different computer screen, which may have different color balance.
Suppose I wish to label items in my database with Green, but need to distinguish between two classes of Green Labeled items, each of which has, in one case, 9 variants and in the other case, 14 variants. Trying to do that by a number of Green Label visual cues would be very unreliable in practice.
That’s why i suggested an alternative approach, using modifiers such as Flag state and/or tags to almost indefinitely extend the range of Label colors, yet remain easy to discern and unambiguously searchable.
If, as Christian suggested, the tags used for an item labelled Green were visible, and one had documented the scheme of Labels and their extensions, selecting that item would unambiguously allow interpretation of the meaning of the Label and extensions.
It’s likely, if I use such a scheme, that I would want to quickly view all the items that match an “extended” Label. I could create a group named “Green” and place within it smart groups that list the variant classes of Green items.
@korm: I’m sure Christian could add to the current set of Labels. But if one were added, someone might ask for more, and so on. My point is that UI problems would make color cues increasingly more unreliable in use, as their numbers grow. DEVONthink is flexible enough to allow the equivalent of any number of Label “colors” without the UI difficulties associated with recognition of color gradations. (Adding a Tags column to the Three Panes view has bee requested by users for other reasons anyway.)
I never want to disagree with Bill DeVille, but here I must.
He writes: “The unique value of Labels as a means to mark items for distinguishing characteristics comes from (and depends upon) the user’s ability to recognize instantly the colors used in the set of Labels.”
Not for me. The unique value of labels for me comes from (and depends upon) the words that are displayed in the labels. And only the words. I could not care less about their colors. That’s why the ability to create more than 7 labels would be helpful to me.
Bill, again: “UI problems would make color cues increasingly more unreliable in use, as their numbers grow.”
My response: Then don’t use more than 7. But why argue against the ability of those of us who would like more than 7 - particularly because of the words, not the colors - to have them?
I use tags content related while I use labels purpose related.
Many labeled items are to-dos (or kind of) that I don’t want to send to OmniFocus to keep my focus straight there and because it’s faster to work through them when I access them directly from DtPO and don’t have to delete them from OmniFocus (e.g. articles and snippets to read and file later).
One big advantage with labels for me is that I can assign and unassign them fast with shortcuts instead of typing a tag or dragging and undragging items to a tag group, especially since tag groups are per database and are not globally available.
Labels have clear distinctions to me and I have smartlists for each label. I don’t want to mix or differentate them with modifier tags or combine them with a flag. Also their colors are not of much importance for me although I customized some of them to meet my taste.
What matters to me is the purpose the items are assigned to via labels and because of this I can completely follow this statement:
I personally do not need more labels right now, but I can totally imagine why others would.
The main argument against more than seven labels is that this would definitely clutter the already overloaded interface even more — and there is already an alternative: tags.
They’re words and you can create as many as you like and use e.g. smart groups to filter etc. There is no Tags column in document lists right now but adding that does not clutter there UI as such as it would be optional (other than adding a whole new UI for adding, removing, sorting, and otherwise managing more labels). Okay, and you cannot assign colors to tags 
Hi Eric,
Thanks for joining in. My problem with tags is mainly that there is currently no column that can display tags, and I’m looking for a column that will contain an assigned word.
Finding it via a search or on the bottom of the browser isn’t as elegant (for me) as simply having a column, such as labels. The column offers me the ability to have one more piece of data visible to me when I look across the columns of an item.
I apologize if I’m being thick here, but I truly don’t see how letting the user decide whether or not to add more labels would “clutter the UI”. It would use an existing column - Labels - and the user can choose how many or few label choices his database requires. I guess I just don’t see what’s the problem with giving the user that choice. People who want to stick with 7 can stick with 7. Those of us who would find more choices beneficial, can have the option.
Anyway, that’s my two cents. Again, thanks for taking the time to join in, and thanks for DevonThink.
I’d like to support the request for more labels. Some at least. My problem is that labels are common for all databases. So I have a set of 7 that fits more ore less for all my databases. But I’d need one ore two additional in each Database with a special meaning. A total of 15 would be nice and sufficient for me.
Johannes
I won’t argue against more labels though I seldom use them in DT. However, I do use the equivalent in Daylite–categories–which allow unlimited color choices and unlimited # of labels. It is also possible to use a color–red, for example–to signify one category in contacts and another in companies and another for appointments. Potentially confusing? Yes. (I never realized how many shades of purple exists and the difficulty even a keen-eyed artist would have in differentiating.) The key is for the user to determine what works for him or her in practical terms. So, if allowing more label/colors is a small programming matter, I see no reason not to make it available at some point; users who operate best by color can make full use of the option, others can choose minimalism. Would I advocate DT spending significant time and resources to implement at the cost of delaying other more fundamental and critical improvements and features? No.
I’ll take a look on the bug tracking link & see if there is a feature request for additional labels (and if not will ad one) as I too would like to have the ability to add more labels. As for the number of labels I would want… couldn’t tell you to be honest, I think the best approach would be to make it a bit open ended (then again in coming from keep it & I loved the ability to have unlimited labels + bundles. I would use the bundles to identify items related to small projects or ‘sub projects/efforts’ & the labels to identify a given context. I believe keep it only allows for the macOS finder label colors, which I believe is something like 5-7. What I did there was re-use colors for related labels so that I knew a green label had something to do with X right off the bat.
I really do like the idea of using smart folders - the AI in DEVONthink along with the more robust file manager were the main reasons I switched, although I’m starting to use more of the other features and love them.
My biggest gripe, however, is that smart folders/groups don’t show up on iOS devices!!!
This is really really frustrating! Maybe with smart groups on the iOS apps I wouldn’t want the added labels, but that’s not the case (will check the tracker to see what the status of smart groups in iOS devices is as I would have a hard time believing it hasn’t been requested yet…).
What’s probably the most difficult byproduct of this is that I tend to add a lot of items via iOS devices and it can be difficult to determine if I have already added the same file, or one just as good as it, to my database without having the smart groups I would normally rely on to quickly bring up the context I’m working on.
Also, is it me or does the search functionality work a little differently between the iOS apps & the macOS app?