<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'DejaVu Sans'; font-size:12pt; font-weight:400; font-style:normal;"> 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</body></html>