Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB

[Gez <listas ohweb com ar>]

El sáb, 02-05-2015 a las 11:18 -0400, Robert Krawitz escribió:
> On Sat, 02 May 2015 11:21:37 -0300, Gez wrote:
> > El sáb, 02-05-2015 a las 06:09 -0400, Elle Stone escribió:
> > > > I'd like to see this discussion heading towards a real world list of
> > > > examples of real needs for such options that can't be satisfied with
> > > > anything else than these toggles.
> > >
> > > You are presupposing that the devs can foresee every possible use to 
> > > which a user might put a given editing operation.
> >
> > No, I'm saying that users like us should describe real world situations
> > where certain options are needed in order to convince developers of the
> > necessity of such options.
> > "Let me do whatever I want" is not a good argument.
>
> Yes it is, because we don't know every possible use to which someone
> will put something.
>
> We've had the same issue come up in Gutenprint.  Gutenprint exposes
> just about every internal control option to users, if they want to
> play with them.  It allows things that could actually cause _physical_
> damage to printers, in particular specifying ink limits so high that
> they would completely soak through non-coated paper and would form
> large puddles on coated papers that could gum up the print head.
>
> But then it turned out that people wanted to do things with printers
> that we had never envisioned: printing T-shirts, and doing chemical
> deposition (in one case, literally printing circuits onto paper using
> electroconductive inks).  It turned out to be very fortunate for those
> users that we had never imposed limits of that kind because "that
> isn't something anybody should be doing".
>
> The one concession that we did make was to group options into
> different levels of interface complexity, and add an option to the PPD
> file generator to generate simplified PPD files with only the basic
> options.  But the default is to use the full-featured interface.
>
> Obviously there are resource constraints here; developers can only do
> so much, and have to make decisions about what to do that are mutually
> exclusive on time constraints alone.  But deliberately leaving
> something out of this kind of project because there isn't an obvious
> real world use case is not, in my view, a good thing.

Let me clarify that I'm not against flexibility or giving users control
on the processes.
It's not about choosing between no control and full control. Is finding
a balance where a UI provides the necessary tools for the regular job
without hindering the possibility of experimentation.
It's extremely difficult to create a UI that both exposes every possible
user and provides a fast and comfortable workflow.
Adding checkboxes and buttons for every need doesn't solve the issue.
Pretending that you can separate the "basic" and the "advanced" users in
two simple groups by providing insufficient tools for basic users and
the cluttered UI for advanced ones is not going to result in a good
tool.
Nodal UIs aren't perfect, but provide a good balance because every tool
is an individual node, and power and flexibility come from combining
those nodes.
In this case of linear vs. perceptual, a gamma node would allow to turn
every operation in a linear workflow into perceptual.
Notice how different is the paradigm: a single tool that changes how
other tools act instead of adding an extra option to every single tool.
And a tool that is added on demand, only people who want to use it will
be exposed to it, and the rest wouldn't be disturbed by a cluttered
interface.
Unfortunately, the UI paradigm in GIMP and similar applications makes
this really difficult, because it's inherited from a time where all the
operations were sequential and destructive.
Again legacy stopping progress.

Part of this is a UI problem, and adding buttons or checkboxes for every
possible alternative isn't a good way to design UIs. 
https://twitter.com/cowbs/status/516045565847535616