Debugging Color...

I've had some interesting experiences in this regard - particularly with those unskilled in color.

First off - what do I mean by "debugging color"?  In large complex systems color failures do not occur on a screen where a message box pops up and says "sorry your job failed".  In these system things are put together in such a way as to work 24x7.  They process standard inputs and standard outputs - all tested and carefully organized.  So a "failure" in this context occurs only when someone actually notices the problem.

What do I mean by this?

Large systems are typically built to be, at least to a certain extent, fault tolerant in the sense that at various steps along the way checks are performed to ensure what is supposed to be going on is actually going on.  Jobs that have various incorrect elements "pop out" in fail folders and humans collect them, diagnose them, and resubmit them for processing (presumably after fixing the problems).

Color problems do not manifest themselves in quite the same way as, say, a missing database entry for a mail merge job.  In this later case a logical integrity check says - "hmmm - there is no entry for this" and the job stops processing.

If the "color is wrong" what happens?  First off - there are no systems along the way to check.  Maybe that logo is now red and not blue.  The software cannot not know this because there is nothing to check it against.  Secondly, something - a human or a machine - has to look at the result of processing the entire job - usually by looking at what's in an output bin - before the problem is identified.  So, after maybe two to four hours of processing through five different servers and ten different processes we discover something is wrong.

So the night operator, whose job it is is to run the jobs nightly, notices that something doesn't look like its supposed to.  In the production world people are trained to notice things that don't look the same as everything else.  In this case the job doesn't look like it did yesterday (or, if you're lucky there's a sample to compare it too).  The logo is a different color or shade.

So at this point the operator probably does not know what is wrong - if anything.  The system that provides working job samples for comparison might be broken, i.e, the operator did not get updated production sample, or the output might be wrong, or the device producing it might be working incorrectly.

Generally an operator will be able to identify problems related to things under their control, e.g., are other jobs producing wrong colors.  So generally the problem does not escalate unless these "standard" sort of issues get ruled out.

So now the problem has "escalated" to the supervisor.  At this point generally things become more interesting.  Someone has to decide if the output is actually "wrong" or if the criteria to judge it is incorrect.  As remarkable as it seems often no one is able to make a precise diagnosis.

The reasons are very interesting.  Typically in a large shop the world of operations, job preparation, QA, graphic arts, and customer service all fall into different silos.  Each silo has its own managers, contractors, vendors, processes, and so forth.

Now the job has to "work backwards" through the system.  At each step those involved (from whatever silo is responsible) have to look at what inputs they received and compare them to the incorrect output.  In the world of color things get more interesting than in the case of, say, data value, i.e., a bad mailing address.

Each silo has its own idea of how color is handled and measured.  Some don't really know anything about it other than how it "looks".  Others tend, like CSRs, tend to think about it in terms of "approved color" or "not approved color".  Programmers tend to think about the numbers in the code that produced the values.

So as the job works backwards each silo applies its own criteria to the output and decides if its responsible for what it sees.  Generally this occurs in an ad hoc meeting on the shop floor where fingers are pointed.

(This will be continued tomorrow on the AFP Outsider blog as it applies to both PDF and AFP workflows.)