[Printing-architecture] Preview for CPD

[Printing-architecture] Preview for CPD

[Petrie, Glen]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

Peter, Till,

 

I believe my understanding from the print-summit was that the new CPD
would "always" preview the actual print content, which was based on
Peter's usability test results.  The concern I have is that the
potential processing in creating the preview would include the entire
print chain; even though the image is at a very low resolution.  This
level of processing has a potential large time delay.   If the End-User
starts making print option changes that affect the preview; the preview
image will have to be re-rendered, which may take too much time.

 

I would like to suggest that the CPD add and use, as the default, an
internal default image that illustrates the print intent and print
options but not the actual print content.  This would reduce potential
heavy processing for the actual print content preview.  However, the
user should be able to enable display of the actual print content and
willing to accept the potential time delay in creating the actual print
content.

 

glen


[-- Attachment #2: Type: text/html, Size: 3086 bytes --]

Re: [Printing-architecture] [Printing-summit] Preview for CPD

[Petrie, Glen]

Good idea but I still believe it should be the User's choice

> -----Original Message-----
> From: Michael R Sweet [mailto:msweet@apple.com]
> Sent: Thursday, April 16, 2009 10:20 AM
> To: Petrie, Glen
> Cc: Till Kamppeter; peter sikking; printing-architecture@lists.linux-
> foundation.org; printing-summit@lists.linux-foundation.org
> Subject: Re: [Printing-summit] Preview for CPD
> 
> Petrie, Glen wrote:
> >
> >
> > Peter, Till,
> >
> >
> >
> > I believe my understanding from the print-summit was that the new
CPD
> > would "always" preview the actual print content, which was based on
> > Peter's usability test results.  The concern I have is that the
> > potential processing in creating the preview would include the
entire
> > print chain; even though the image is at a very low resolution.
This
> > level of processing has a potential large time delay.   If the
End-User
> > starts making print option changes that affect the preview; the
preview
> > image will have to be re-rendered, which may take too much time.
> >
> >
> >
> > I would like to suggest that the CPD add and use, as the default, an
> > internal default image that illustrates the print intent and print
> > options but not the actual print content.  This would reduce
potential
> > heavy processing for the actual print content preview.  However, the
> > user should be able to enable display of the actual print content
and
> > willing to accept the potential time delay in creating the actual
print
> > content.
> 
> *Or* you could display the default image while generating the actual
> preview image (with some sort of animated progress indicator/spinner)
> so that you get the best of both worlds.
> 
> --
> ______________________________________________________________________
> Michael R Sweet                        Senior Printing System Engineer

Re: [Printing-architecture] [Printing-summit] Preview for CPD

[Ira McDonald]

Hi,

I agree with Glen's suggestion - default images for preview
should ALWAYS be the fallback - for the limited-resource
embedded environment REAL preview images are NOT a
good idea.

I also agree with Mike (and Glen) that displaying the default
image WHILE generating the real preview image is a friendly
design approach.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic@gmail.com
winter:
  579 Park Place  Saline, MI  48176
  734-944-0094
summer:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434



On Thu, Apr 16, 2009 at 1:19 PM, Michael R Sweet <msweet@apple.com> wrote:
> Petrie, Glen wrote:
>>
>>
>> Peter, Till,
>>
>>
>>
>> I believe my understanding from the print-summit was that the new CPD
>> would “always” preview the actual print content, which was based on
>> Peter’s usability test results.  The concern I have is that the
>> potential processing in creating the preview would include the entire
>> print chain; even though the image is at a very low resolution.  This
>> level of processing has a potential large time delay.   If the End-User
>> starts making print option changes that affect the preview; the preview
>> image will have to be re-rendered, which may take too much time.
>>
>>
>>
>> I would like to suggest that the CPD add and use, as the default, an
>> internal default image that illustrates the print intent and print
>> options but not the actual print content.  This would reduce potential
>> heavy processing for the actual print content preview.  However, the
>> user should be able to enable display of the actual print content and
>> willing to accept the potential time delay in creating the actual print
>> content.
>
> *Or* you could display the default image while generating the actual
> preview image (with some sort of animated progress indicator/spinner)
> so that you get the best of both worlds.
>
> --
> ______________________________________________________________________
> Michael R Sweet                        Senior Printing System Engineer
> _______________________________________________
> Printing-summit mailing list
> Printing-summit@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-summit
>

Re: [Printing-architecture] [Printing-summit] Preview for CPD

[Till Kamppeter]

I also agree with the use of a default image, once, while waiting for a 
live preview and second, on systems not capable of generating previews 
due to restricted resources, and also for the case that the client 
application does not support live preview (for example it did not get 
changed towards the printing dialog but Lars' stage-1-CPDAPI-patched GTK 
or Qt is used).

    Till

Ira McDonald wrote:
> Hi,
> 
> I agree with Glen's suggestion - default images for preview
> should ALWAYS be the fallback - for the limited-resource
> embedded environment REAL preview images are NOT a
> good idea.
> 
> I also agree with Mike (and Glen) that displaying the default
> image WHILE generating the real preview image is a friendly
> design approach.

Re: [Printing-architecture] [Printing-summit] Preview for CPD

[Till Kamppeter]

We should also try to get the best for the live preview. For example it 
should render only the visible page (and the CPDAPI should support that).

    Till


Till Kamppeter wrote:
> I also agree with the use of a default image, once, while waiting for a 
> live preview and second, on systems not capable of generating previews 
> due to restricted resources, and also for the case that the client 
> application does not support live preview (for example it did not get 
> changed towards the printing dialog but Lars' stage-1-CPDAPI-patched GTK 
> or Qt is used).
> 
>    Till
> 
> Ira McDonald wrote:
>> Hi,
>>
>> I agree with Glen's suggestion - default images for preview
>> should ALWAYS be the fallback - for the limited-resource
>> embedded environment REAL preview images are NOT a
>> good idea.
>>
>> I also agree with Mike (and Glen) that displaying the default
>> image WHILE generating the real preview image is a friendly
>> design approach.
> 
> 

Re: [Printing-architecture] Preview for CPD

[peter sikking]

Glen wrote:

> I believe my understanding from the print-summit was that the new  
> CPD would “always” preview the actual print content, which was based  
> on Peter’s usability test results.

and the usability test results proved that the preview is a huge
success and needs to be 100% "true". users will fully depend on
it to start trusting the print process, and trust cannot be
betrayed by a quick hack.

no generic image can be a replacement and no army of engineers
can discuss away this requirement.

the speed with which the preview is generated is of course also
100% a usability issue. we basically have 1 second (on modern
hardware) to get that first page there. we will have a busy
indication for that one second (max) wait.

the optimisation opportunities are of course in that the longest
side of the page is a low (225 at the moment) fixed (compile time,
I say) number of pixels. there is going to be no resizing of the
dialog, and no zooming of the preview. that is designed in, for
other UI reasons, but it comes in handy here.

the second optimisation opportunity is that only the first page
needs to be 'immediately' there, in case of N-up > 1 more pages
but the needed fidelity is proportionately lower (in integer steps,
another optimisation opportunity).

every trick in the book will probably have to be used to get
a specialised preview pipeline up to speed. remember that when
the printing dialog comes up that it occupies users' attention
and hence has a licence to hog processor resources. I have
no qualms about that.

the preview is one big conn-trick, it simply needs to never
get caught cheating, whatever the print is. without a real
preview there is simply no common printing dialog.

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture

Re: [Printing-architecture] Preview for CPD

[Petrie, Glen]

> and the usability test results proved that the preview is a huge
> success and needs to be 100% "true". users will fully depend on
> it to start trusting the print process, and trust cannot be
> betrayed by a quick hack.
> 
> no generic image can be a replacement and no army of engineers
> can discuss away this requirement.
> 

In the end, the application may decide to just send you a "caned image";
thus, the "preview" of what is mute.

It is never just usability nor engineering who should decide; it is the
end user.  Usability and engineering provide options in the best way(s)
they can.  It should be the user choice.