Dear Chris - <div><br><div> You think the current Gutenprint interface is awful? Well, we quite understand that this situation should not be inflicted on the saintly angels who come to use our free software out of the goodness of their hearts. </div>
<div><br></div><div> However, the dictators of the computing proletariat have a plan for world domination: Users of color managed printing will be offered the color/bw and paper choice in the "simple" tab, I expect. Not because we love our users so much that we want to simplify their lives, but just because a profile is only valid in the conditions it was made. Tinkerers and color consultants who open the hood of the car and dive into the steaming mechanical entrails deserve ... what they get :)</div>
<div><br></div><div>Edmund<br><br><div class="gmail_quote">On Fri, May 6, 2011 at 9:26 PM, Chris Murphy <span dir="ltr"><<a href="mailto:lists@colorremedies.com">lists@colorremedies.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
<br>
On May 5, 2011, at 7:32 PM, Robert Krawitz wrote:<br>
<br>
> On Thu, 5 May 2011 13:38:29 -0600, Chris Murphy wrote:<br>
>><br>
>> On May 5, 2011, at 1:24 PM, Alastair M. Robinson wrote:<br>
>>><br>
>>> Having a CPD flag that applications use to signal that "advanced"<br>
>>> options should be shown would be just about tolerable, I suppose,<br>
>>> but still seems like needlessly sacrificing functionality on the<br>
>>> altar of user-friendliness to me. (And we see so much of that<br>
>>> these days that some of us, myself included, are admittedly<br>
>>> hyper-sensitive and quick to shout if we see any hint of it<br>
>>> happening!)<br>
>><br>
>> This is not a hill I'm going to die on. However, I just think we're<br>
>> talking about an extreme fraction of users who need to even use the<br>
>> feature so why subject real estate, even in advanced options. This<br>
>> will certainly be the least used advanced option.<br>
>><br>
>> It isn't merely about user friendly. It's about use necessary. I<br>
>> just don't see the vast majority of apps needing such a control,<br>
>> therefore there is no sacrificed function.<br>
><br>
> I don't agree with this reasoning. I think it's important to have all<br>
> such options available from all programs with a print dialog; we<br>
> should figure out how to present them most effectively.<br>
<br>
</div>No offense intended, but: Gutenprint driver presentation, at least on Mac OS X, is brain damaging. It is an extremely user hostile presentation.<br>
<br>
I rarely get headaches, yet the endless conflicting and esoteric options in Gutenprint drivers rapidly gives me a headache. I realize this has everything to do with limitations of CUPS, PPDs and how limited they are in affecting the appearance of the print dialog. But even if I found a purpose for any one of the multitude of features, I would not put it in a print dialog. I would bake it into a preset so that I could ensure I always have that particular option set to the correct value every time and never have to remember what option or what the value should be. This is the domain for a utility application that builds driver presets, not a print dialog.<br>
<br>
This idea that all options are all important to have available is just non-defensible UI because it makes EVERYTHING increasingly non-discoverable for 99.9% of the user base. And non-discoverability makes software obscure, and obscure software design is HUGE no-no. It does not make software more powerful, more cool, or more functional just because of sheer quantity of options. It is, for me, the #1 reason to not use Gutenprint drivers. It's almost endless amounts of clutter and mutually exclusive options that are non-obvious and non-trivial to figure out even with documentation.<br>
<div class="im"><br>
<br>
<br>
><br>
> There are two schools of thought that I see here. One, which seems to<br>
> be exemplified by GNOME (yes, I'm calling that project out by name),<br>
> is to have UI experts determine the minimum set of features needed by<br>
> users and present an absolute minimal interface. The other, which I<br>
> greatly prefer, is what a former colleague of mine described as<br>
> "successive disclosure of complexity".<br>
<br>
</div>I would not call the current presentation of Gutenprint driver options as successive disclosure of complexity. Its present disclosure of increasing complexity occurs in parallel. But even if it were successive, you're talking about a rabbit hole of successive disclosure and that still makes software obscure.<br>
<div class="im"><br>
><br>
> What that phrase means is that inexperienced users, or those with<br>
> simple needs, should see a very simplified view of the system --<br>
> possibly even as simple as Hal's proposal that they only see the name<br>
> of the printer and how many copies or the like. As people's needs<br>
> grow, they can access more elaborate functionality.<br>
<br>
</div>This sounds very nice in theory, but in practice what happens is that as users get more advanced, the options they require differ radically. So what happens is moderate to advanced users will have to sift through multiple extra panels looking for the options they want because the ability for the user to create group options for a specific subset of themselves isn't how print dialogs presently work.<br>
<br>
So what this does is it kicks the bucket of obscurity down the road to just moderate and advanced users. They are still users, just because they are advanced does not mean they should be subject to sifting through options, 90% of which do not apply to them.<br>
<div class="im"><br>
<br>
<br>
<br>
> Most<br>
> well-designed applications actually operate like that -- think<br>
> OpenOffice.org, where you can simply start typing into a text<br>
> document, but as you learn more, you learn how to use spreadsheets,<br>
> with increasingly elaborate functionality as your needs changed. One<br>
> could argue that the default set of toolbars presents too much<br>
> information at the start, but ultimately, if you need to do things<br>
> like mail merge, that functionality is there.<br>
><br>
> I don't see why this shouldn't apply to printing,<br>
<br>
</div>A print dialog is not a monolithic application with thousands of options. If it does, users will start dying. I'm not kidding.<br>
<div class="im"><br>
<br>
> and in particular, I<br>
> don't see why the CPD shouldn't be designed along the same lines so<br>
> that every application has the same dialog (which also helps reduce<br>
> confusion). In particular, just because we don't see a certain use<br>
> case with a certain application doesn't mean that somebody else<br>
> won't.<br>
<br>
</div>This argument works EXACTLY in reverse also. Just because you don't see a prolific UI as brain damaging, user hostile, and a top reason to NOT use an entire operating system doesn't mean someone else won't. If it came to a bet, I will bet the numbers are on my side. I'm a fairly advanced user but I do not appreciate the notion that the two or three options that are important to me, be floated in amongst 280 options I do not give a crap about and I cannot cause to be disabled for the sake of my sanity and workflow efficiency.<br>
<br>
There is a cost to designing a GUI for 99% instead of 80%, and that means 99% of the people will have an increasingly negative experience for each option inserted into a print dialog that cannot be anywhere nearly as effectively hidden from the user as is possible in applications.<br>
<br>
This is why I think the bulk of Gutenprint options should be in an application. Not exposed to most users at all. We still have to sort through all of it and try to decipher the relevancy of these options. I find it absolutely inhospitably maddening.<br>
<br>
There are two sides to every coin. More options are not inherently better. They do come with a cost.<br>
<font color="#888888"><br>
<br>
Chris Murphy<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
openicc mailing list<br>
<a href="mailto:openicc@lists.freedesktop.org">openicc@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/openicc" target="_blank">http://lists.freedesktop.org/mailman/listinfo/openicc</a><br>
</div></div></blockquote></div><br></div></div>