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 _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
