[Openicc] printing GUI vs. printerdriver, LINUX colorinfrastructure

[Graeme Gill]

Kai-Uwe Behrmann wrote:

> My impression is that a working system without the need of technical user 
> intervention tends to a invisible hard to "diagnose" system. My thought 
> was to represent a technical detail in an easy understoodable manner.
> My impression with linux is, projects like kde and gnome tend to convince 
> the user with a lot of solutions which become more and more 
> internal technically. 
> The transparency for average users gets quickly lost. Let me ask 
> rethorically: who reads html style xml-configurations? No one, it is 
> simply intended to programmers. For a user it is all about strange.

I don't think these things are impossible goals. It's not that the
technical information shouldn't be present, but it should be at
a second layer, and never needed for routine operation.
When needed, the technical controls should be well organized
and explained (particularly the internal workflow represented
by the controls), as well as suitable diagnostic "tap" points
to see what goes wrong where, so problems can be traced one
control at a time, rather than having to try and guess a
combination puzzle.

> The same will be for a CMS. Eighter we go a technical way and customise 
> it. This means we call things by a technical close related name (hopefully 
> clear and recogniseable names) or go the way like many other OS and hide 
> as much as possible behind convenient buttons and names, resulting in a 
> hidden windows/osX style configuration.
> 
> I can follow you with the first intention of a CMS that just works and is 
> very easy to handle or better needs no handling. I would like to see it 
> the technical way, having all that pleasing buttons by hand for the 
> experts.
> On osX all use that nice Aqua gui for print settings. No one has the idea 
> to call http://localhost:631/ to watch the CUPS page. But it is nice for 
> experts to see the internals.
> IMHO we need first a functional layer with the vision of future usage 
> behaviour, and can later set a convenient GUI on top. So I think now you 
> are speaking of the top GUI layer which is able to hide all CMS issues 
> from an user. Ok thats fine to consider as a design goal.

I'm concerned that it's easy for technical people to take a technical
line on how to solve a particular programming problem, and not notice
that the solution adds a considerable burden to the user. Classic
example is adding a control so that something special can be done
on occasions. For instance Output color: "Device profile" vs. "Calibration".
You've instantly confused a naive user. They don't know what either
term is, so they have no basis to choose between them.

"OK you say, I'll fix it":

Output color: "Default", "Device profile", "Calibration"

Now you've confused the more knowledgeable user trying to
figure out a problem. What does "Default" do ? Does that
insert "Device profile" at the print submission dialog level,
or does it mark that option "Default" and leave it for some
later processing element (such as the RIP or the device
driver) to insert a real selection for the default ?
What real selection will that later element insert ?

Your switch is actually a land mine, that has doubled the number
of ways a system can be mis-configured so that it doesn't work properly!

Yet some mechanism is needed to turn off color processing
for diagnostics and printing calibration charts. In fact
it's a common trap when calibrating to forget to do so,
and spend a lot of time creating a useless calibration.

It's a real challenge to have broad flexibility and transparency,
and yet keep a system robust, so that it "just works right" most
of the time.

[The above problem has a solution that avoids adding a switch.]

Graeme Gill.