[Openicc] GoSoC 2011: CPD and target printing

[Hal V. Engel]

On Thursday, May 05, 2011 12:38:29 PM Chris Murphy wrote:
> On May 5, 2011, at 1:24 PM, Alastair M. Robinson wrote:
> > Having a CPD flag that applications use to signal that "advanced" options
> > should be shown would be just about tolerable, I suppose, but still
> > seems like needlessly sacrificing functionality on the altar of
> > user-friendliness to me.  (And we see so much of that these days that
> > some of us, myself included, are admittedly hyper-sensitive and quick to
> > shout if we see any hint of it happening!)
> 
> This is not a hill I'm going to die on. However, I just think we're talking
> about an extreme fraction of users who need to even use the feature so why
> subject real estate, even in advanced options. This will certainly be the
> least used advanced option.
> 
> It isn't merely about user friendly. It's about use necessary. I just don't
> see the vast majority of apps needing such a control, therefore there is
> no sacrificed function.
> 
> Chris Murphy

Keep in mind that in the CPD UI design EVERYTHING, other than which printer 
queue to use and how many copies to print, is treated as advanced options and 
are only made visible to the user if the user specifically selects to display 
one or more subsets of these options.  In addition, for GutenPrint, and 
perhaps other drivers, these advanced options already include things that 99+% 
of users will never touch (ink limits for example).  The user can control 
exactly what advanced options are included in the options area of the UI (it 
does not have tabs) so the user can decide exactly what groups of options are 
visible.  This UI design is specifically to deal with the issue of user 
friendliness without a loss of power features for users that want full 
control. 

The idea is that by default users get only the absolute minimum options in the 
UI.  Just enough to "just print it" (what ever "it" is) and nothing more.  
This is limited to what printer do you want to use and how many copies do you 
want.  It just does not get any simpler than that.  The user can then select 
from a drop down to display additional groups of options and the groupings 
available in the drop down are controlled by the printers PPD file.  The user 
can display any combination of these all the way from none of them to all of 
them. I believe that for the GutenPrint drivers that there are about 7 or 8 
advanced options groups defined in a typical PPD.  These go from things like 
changing the paper size and media type (many users will use these) to setting 
things like GCR and ink limits (almost on one uses these).  What we are 
talking about is adding a CM options group that is not controlled by the PPD, 
since these are not driver related options, that has those options needed for 
CM.

These CM options might include things like rendering intent overrides, profile 
overrides and opt out among other things.  Since we have some control over how 
we would like this presented to users we could make sure that all of the CM 
options were marked with something like "For experts only" which would prevent 
most nave users from playing with them.  We might also make it so that these 
were always set to default values so that the user would have to override them 
each time they printed.  This would keep nave users from changing the default 
CM settings for more than one print job and this would prevent the vast 
majority of use cases where a nave user changes something and then can't figure 
out why their print jobs are giving crappy results.  I think this would also 
work for profiling experts since it would only add a few mouse clicks for them 
to opt out each time they print a target.

I also agree with those that think having a specialized app for printing 
profiling targets is a design error.   We shouldn't go there particularly near 
term.  Right now we want something that works and we want it sooner rather 
than later and having to create a special app means it happens later.  In 
addition, there are the maintainence issues that others have written about.  
Having this in the CPD also gives us some experience at doing this in the CPD.  
If we find that nave users are having issues with it then we can talk about 
removing the CM options or making them so they appear only when the calling 
app requests them or some other way to deal with the issue.  I don't think we 
should assume that there is going to be an issue with nave users until we have 
actual cases of it happening.

I also don't think that the "most apps don't need it so we shouldn't provide 
it" argument holds too much water.  First do apps really matter here or are 
use cases what matters?  Should the CPD not make ink limits visible to users 
because no apps care about it or use it?  Does that question even make sense?  
Or should ink limits be eliminated because there are a very limited set of use 
cases where this is used?  This strikes me as a valid question to ask. 

These are very different considerations since one is a question about software 
and the other is about how people do their work.   Which of these do we really 
care about?  In addition many users will have have more than one use case for 
their printing work flows depending on what they are doing.  Even our profiling 
experts often print things like word processing docs, emails, PDFs, 
spreadsheets and perhaps photos or other graphics where they use the printer 
in a very basic way.  At other times like when they print profiling targets 
they use a totally different work flow.  They may even use these different work 
flows from the same app.

Hal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110505/616f480a/attachment.htm>