[Openicc] GoSoC 2011: CPD and target printing

[edmund ronald]

I agree with mostly everything here except the "reset to defaults" thing,
but a way around that is to be able to save out the dialog state and then
load it in with the non-default values you used the last time.

As Hal points out, we are combining a huge number of use-cases here, from
simple wordprocessing black-only to the most demanding graphics uses where
the media and indeed print time is worth money. This means that there is no
typical user anymore but rather a "most frequent" use-case, and most users
will understand (I hope) that as they advance down the tabs in a tabbed
dialog they are going into more complex areas.

Paradoxically, though, users of profiled printing will know they should not
expect a big choice of print options as using a canned profile means falling
back on a rigid set of canned settings.

One thing I would like to see is a way to print ALL the user-settings in one
window, print them on a sheet of paper, and have them all spooled into a
file for diagnostic purposes so that conditions can be reproduced, and user
error can be self-diagnosed.

Edmund

On Thu, May 5, 2011 at 11:45 PM, Hal V. Engel <hvengel at gmail.com> wrote:

>  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
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110506/dfe85c43/attachment.html>