Does anyone know if there is a way to increase the quantity of labels to help with document segmentation? I am finding the 7 to be a limiting factor.
You are limited to 7, and the same labels are shared across all databases. I would like to see each database have unique labels and/or the ability to assign colors to tags, which would make the number of labels unlimited.
… and if DEVONthink tag colors were exportable as OS X tag metadata, then we’d have better alignment with OS X tags
Thanks for clarifying guys. I like the additional idea of colouring tags and being able to sync with OSX tags to increase alignment. Hopefully something for a future DTPO release
Apple has settled on 7 Label colors for a long time. The problem of increasing the number of colors so as to increase the available number of Labels is that people would have difficulty in distinguishing many shades of color reliably.
Back in the day, I had a project for which it would be useful to “catalog” a large number of characteristics of documents. I wanted to be able to quickly search for any characteristic.
I did it with a kludge. The kludge considered of “coding” the set of characteristics in terms of 5 principle divisions using 5 Label colors, plus a Spotlight Comments keyword that would subdivide each division (Label color) into as many characteristics as needed.
The keyword was a 5-character text string beginning with “z”. Permutations of that string were defined as categories. For example, “zzzzz” was a specified subcategory of a Label color, and additional subcategories were defined by character substitution, e.g., “zzzz0”, “zz100”, “zz01a” &c. Obviously, the number of characteristics that can be coded for by Label color and keyword character substitution is enormous. I needed only a few hundred at the time. (I used a similar approach, though with a smaller number of categories, for a project to assess the impacts on health care facilities in Louisiana by Hurricane Katrina, and to assess changes in status about a year later.)
I created a text document that was the “Rosetta Stone” of the classification scheme. Each line in the document started with a defined characteristic, followed by a Label color, followed by the keyword string. (Keywords should be unique within each Label association.) When I needed to do a search for a particular characteristic I could see its coding by Label and keyword in this document.
Using DEVONthink’s full Search window, I set the Label color and entered the keyword string in the query field, using a Comments search. The results displayed all documents that met those criteria.
Such a scheme could handle classification of a large collection of nuts and bolts differing by materials used, sizes, threading, etc. Or the results of an archeological dig. Or a large collection of manuscripts. Just define the characteristics needed. No need to wait for Apple to increase the number of Label colors, or DEVONthink to add more colors to tags (which could be really confusing, I suspect). The scheme could be used across all databases, or differently by database.
I’m lost with writing code and just want something simple like the ability to add additional labels within DTPO. For my dissertation such labels are as follows:
General Labels (column 1)
Status Labels (column 2)
I still think changing DTPO product to allow for adding labels is a good idea, especially for those that are not clued up on coding. Worse case I suppose I could use tags unless anyone knows of a simpler system?
What you are describing is ideal ground for using Tags.
I agree with Jim that the examples of intended use could easily be done with tags. Your examples are very simple ones that are easily accomplished as tags, much more flexibly than with labels.
My kludge didn’t involve coding in the sense of programming, but coding of the Label color and text string as associated to a category word or phrase. I was able to do this long before tags were introduced in DEVONthink. One project involved a list of thousands of lines of classifications, each consisting of a descriptor, a Label color (main category) and a coded “word” (subcategory). Drudgery involved? Yes! But it worked. In the current version of DEVONthink I suspect I could set up a search more quickly than for a tag search. But logically limited compared to tagging, in some ways.
FWIW, the “benefit” of labels, particularly in the example listed above - would be a possible visual indication of file status.
Being able to glance at a particular group/series of files, and instantly “see” which file is Ver1/3; Revision; Final Draft; Concept; To Follow-Up; Broken etc., presents a very useful series of options, imo. Yes - it can be replicated by using Tags – but it would be fantastic to be allowed greater freedom in this regard.
A good example of a similar approach would be in Scrivener – where users have, AFAIK, significant control over this aspect.
Petitio principii. Maybe Apple knows more than we do, but I don’t think this is an example. I can distinquish quite a few colors and I suspect others can too. I believe the OP is asking for the option to have more than what DEVONthink currently provides – not requiring everyone to use them.
Yes, agree. That’s the use case and the point.
Scrivener is a good role model. It handles configuration of labels (and many other meta features) elegantly, IMO.
True, although there are some people who have various issues with color recognition such as color blindness, many people can recognize more colors than the traditional 7 current Label colors.
Apple has experimented with extension of the color UI of Labels. I don’t recall the source (something I read years ago), but the problem found was that users made more errors in color recognition as the number of colors was increased. This became evident even with a small number of additional colors such as 2 or 3 and increased rapidly as the number grew. Testing indicated that even with a population of users who could distinguish colors in a larger color set under ideal conditions, their error rate nevertheless increased rapidly in making decisions based on color as the number of colors increased.
That becomes a UI issue. Yes, the flexibility of use of Labels would be increased by increasing the number of Label colors. But the price of flexibility would be an increase in errors by users, which grew rapidly as the number of colors was increased. Apple’s decision was to stick with only seven Label colors.
As in many other instances, DEVONthink simply calls the Labels built into OS X. In principle, it would be possible to add additional colors to Labels in DEVONthink, although this would involve more coding than might be thought at first glance, and raise issues with Label colors of files exported to the Finder. If we were to adopt the “more colors” approach, significant UI testing and decisions would emerge. How many more colors? Which ones would be most distinguishable given the variety of monitors in the user community? How much beta testing of color options would be required to determine the best colors and most effective increase in number of colors? How much of DEVONtechnologies resources would be required to result in real improvement of a DEVONthink feature, and at what cost by displacement of resources for other features? My suspicion is that as a practical matter, the range of additional classification distinctions offered by increasing the number of colors in DEVONthink would not be large.
Bottom line, the OP’s request for extension of Label colors isn’t a simple issue to approach. By contrast, there’s an existing UI, tags, that can meet his needs. Even my kludge used before the appearance of tags in DEVONthink worked (for a much larger universe of classifications than could reasonably be addressed by color distinctions), without the error rate issues raised by increasingly fine distinctions among colors that would be involved by modification of Labels.
The suggestion of adding colors to tags is a different issue that might offer possibilities.
Adaptation of my kludge by different keywords in Spotlight Comments for each database would allow use of Labels as database-specific rather than applying to all databases.
Agreed, I use Scrivener for projects between Mac and PC which is where the use of labels comes into its own. The unlimited (Probably is a limit but I’ve not reached it) labels provide the status while groups and tags provide further context. The downside for me is that MindJet MindMaps do not work within Scrivener and although I can store the Scrivener project within DTPO I think any writing is excluded from the search features of DTPO?.
I think this is a work around rather than meeting my needs.
Labels provide additional context separate from tags in the form of the status of the document. This cannot be achieved using tags alone because while adding a tags column to the header bar does show saved tags, if you use more that 1 tag it displays all tags rather than ‘label status’.
I think adding colours would be a good idea for those that prefer to work visually but not having the ability to add additional labels >7 will impact its effectiveness by limiting the status of the documents for non visual users.
Having the ability to display labels within columns works but its functionality restricted to 7 does limit its use both visually and in a text context. For example just having one label called ‘ToDo’ does not provide enough context on the status of the ToDo. While Groups and Tags do provide the additional ‘categorisation context’ they do not provide enough ‘status context’.
This shows there are two different user applications or contexts as follows:
Groups = Categories & Sub Categories
Tags = Additional ‘Group’ context
Labels = ‘Status’ of document
I know we are just throwing ideas around here but from this we could say additional labels would add different value in the form of status contexts, rather than groups and tags that provide categorisation contexts.
Text that follows added 18/12/14
This would also be an improvement by enabling project specific status context labels, rather than large generic lists that might not be applicable to all database projects. For those that just use 1 database though it might be a problem, so (if ever implemented) having the ability to specify labels for a particular project folder hierarchy would be better. This way only items within the parent and associated subfolders would use the project specific status context labels. This would be useful when using predefined DTPO templates that incorporate the relevant project specific status context labels.
As to whether this is technically feasible I’ll leave to others…
Something to keep in mind (and part of what I don’t agree with in your proposal)… what you’re describing is a closed-loop system, a single User environment. Your labels are only meaningful to you. However, many of our Users work in collaborative or corporate environments. The moment you begin sharing data, uniformity and agreement on metadata is critical. (And yes this relates to Tags as well, but as you’ve stated, the Label commonly shows status and needs even stricter controls. I actually think there should be fewer labels myself.) If you send me your data, how would I know what your labels mean? And how would I know if you’ve decided Red means one thing on one project and something else on another?
Also, if you labeled files with chartreuse or seafoam or periwinkle, etc. these labels would only exist within DEVONthink as the label colors would apply in the OS X filesystem. So if you labeled indexed files you would gain no benefit of them outside DEVONthink. the current system works hand-in-hand with OS X.
I tend to agree with Bill on this that Apple has resisted opening this up for many, many years, and most likely with solid reasons.
My two pence.
By the way, what you’re describing (and what you’re requesting) is also “a workaround”.
Tend not to agree with you here because it can be used either as a closed-loop (single user) or open-loop system (multiple users).
The setting of labels within an organisational context is achieved through defining business processes, systems and procedures that use feedback and control mechanisms, thereby providing uniformity and agreement on the critical metadata. The feedback system gathers and monitors the system information status and the control system takes action based on the feedback specific to the organisational requirements.
When the process works but there are still problems with uniformity and agreement around data this could highlight a system issue within the feedback or control mechanism that receives outputs from the process, rather than the process being the problem. Obviously the reverse is true when the process fails the feedback and control mechanisms should highlight it so corrective actions is taken on process inputs or the process itself.
On the question of how many label colors does Apple condone – John Siracusa had this to say about OS X 10.3 Panther
With 10.3, Apple added a 3-bit scheme for indicating Finder item labels. Reserving 000 for “no label”, that left 001 - 111 for seven colors. Perhaps there was some fancy psycho-physio Apple lab testing of color discrimination going on in the background. Perhaps not. Nevertheless, nothing much changed from 10.3 through 10.10, though Yosemite supports four levels of intensity for each color. (Personally, I think that whoever at Apple decided that electric blue was a great hue for folder icons must not spend much time with computers.)
Though well stated, I disagree here in the burden placed on feedback and control mechanisms. If you give Users the ability to work outside constraints (ie. unlimited label colors, in this discussion), the system needs to do more error-checking than is necessary. While you can extend the range of acceptable hits for the monitor, without constraining behavior / ability, it still leads to unneeded error-checking.
For example, I built a corporate workflow that controls file management via auto-naming (including version - revision nomenclature) and system interactions instead of allowing the 40-some odd Users to name their own files, make their own folders, etc. Some don’t like it but for the past two years it has proven itself to be incredibly efficient as well as increasing the level of automation beyond what had been done in the previous 15 years. By limiting their abilities, I can control and maintain the system, with MUCH LESS error checking, far easier as an admin than I could have in their earlier “system” (which was no real system at all).
I’d opt for 4 labels, myself…
Grey: Unassigned / Unstarted
Green: Assigned / In Progress
Yellow: On Hold / Out For Review
Red: Due / Overdue / Problem
Or a temporal heatmap relative to due dates, maybe - from Blue (far from due date - user-definable) to Red (due or overdue).
PS: I once believed Deming’s theory that the problem is the process, not the User. But having done this stuff this long, I find the obstinacy of the User is far more often the problem. Process, sometimes? Absolutely, especially when it’s no real process at all. But in a collaborative production environment, the Users’ DESIRES are secondary to the best production method.
Two more pence.
Sounds like an interesting automatic system that you have working.
These are two different contexts though:
Groups = Categories & Sub Categories
Tags = Additional ‘Group’ context
Volume - High
Variety - High
Here its most likely people/employees are creating new types of documents and folders on a daily basis (high volume) of different content (high variety).
Labels = ‘Status’ of document
Volume - High
Variety - Low
Here its most likely people/employees are changing the status of documents and folders on a daily basis (high volume) of different content (low variety). However the document management system (DMS) review process usually part of any quality management system such as ISO9000 would predefine these because they would be integral to meeting customers expectations of organisations products/services quality delivered. These processes typically have an annual review date where updating/business processes is completed and modification would be completed here.
In addition while Volume usage of the Categorisation Context and Status Context are the same the Variety is not. For example organisations could have an infinite amount of customers (ok most would like an infinite amount) but the Status Context would be consistent across the Categorisation Context, unless amended at the annual (DMS) review.
There will also likely be a specific document review process for new/existing documents that captures the aforementioned as part of the feedback and control mechanism, enabling the (DMS) review.
Some food for thought from Gittell, J. H. (2000). “Paradox of Coordination and Control.” California Management Review 42(3): 101-117 https://hbr.org/product/paradox-of-coordination-and-control/CMR174-PDF-ENG
Therefore the decision to increase or decrease control has an effect on coordination of the organisation depending on the velocity/Volume of the process. While the Status Context usage is high volume the variety is low meaning it would be better suited to lower control than the Categorisation Context. Here it looks to be the management of the feature rather than availability of the feature that creates the problem.
A simple control mechanism would be to have a Status Context check box giving the option of either enabling or disabling adding/modifying labels.
While I find this interesting philosophically, in 30 years I have never seen this successfully implemented nor maintained in any corporation I have worked with (though I admit I have not worked with any Korean or Japanese corporations directly).
“Adequate supervisory staff” is the first issue as “adequate” is too ill-defined, and “supervisors” are often the weakest link in a department. Secondly, though it may seem I may be antagonistic toward employees, on the contrary, I have been their biggest advocate. The coaching and feedback offered in any ISO / Lean Manufacturing / GMP implementation that I’ve been involved in has always been too devoid of realistic views of supervising PEOPLE and created environments that stifled innovation and bred more fear than efficiency.
My goal is building systems that leverage the strengths of the User and the system independently allows the employee and computers to be utilized at a “best and highest use”.
PS: I am speaking from my own experience that, while extensive, is definitely not exhaustive. Thanks for the great conversation!