[Printing-architecture] Another Common Dialog

[Printing-architecture] Another Common Dialog

[Petrie, Glen]

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

Have you ever considered creating/defining a Common Status/Monitoring
Dialog.   CUPS may have something already but does it support
multi-function devices sub-units like fax, scan, memory card, etc and
can it provide the status/monitoring information on a sub-unit by
sub-unit basis or as a roll-up for the entire MFD or both????

 

glen


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

Re: [Printing-architecture] [Printing-summit] Another Common Dialog

[Petrie, Glen]

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

Thanks for the inputs Michael.  This provides some seeds for the
implementation details.  I am hoping Peter will provide similar comment
for the look-and-feel of the interface.

 

Glen

 

 

________________________________

From: Michael Sweet [mailto:msweet@apple.com] 
Sent: Thursday, April 16, 2009 2:18 PM
To: Petrie, Glen
Cc: Till Kamppeter; peter sikking;
printing-architecture@lists.linux-foundation.org;
printing-summit@lists.linux-foundation.org
Subject: Re: [Printing-summit] Another Common Dialog

 

Due to numerous practical issues, most MFPs that support fax and print
have to use two separate print queues; detecting this from the print
dialog or monitoring application is fairly easy (compare device URIs and
capability bits, merge queues that differ only by capabilities), and
supporting this at the OS level is essential (and then you can really
make things easy by creating both queues, "foo" and "foo_fax"...)

 

Scanning functionality is managed separately from CUPS at the OS level
(usually SANE + a USB driver) but can be merged in the UI as long as the
OS provides the necessary hooks.

 

Supporting memory cards (presumably exposed as USB mass storage or some
sort of network share) is also possible, again as long as the OS has the
necessary hooks.

 

On Apr 16, 2009, at 11:21 AM, Petrie, Glen wrote:





Have you ever considered creating/defining a Common Status/Monitoring
Dialog.   CUPS may have something already but does it support
multi-function devices sub-units like fax, scan, memory card, etc and
can it provide the status/monitoring information on a sub-unit by
sub-unit basis or as a roll-up for the entire MFD or both????

 

glen

_______________________________________________
Printing-summit mailing list
Printing-summit@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/printing-summit

 

________________________________________

Michael R Sweet, Senior Printing System Engineer

 


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

Re: [Printing-architecture] [Printing-summit] Another Common Dialog

[Till Kamppeter]

Petrie, Glen wrote:
> Thanks for the inputs Michael.  This provides some seeds for the 
> implementation details.  I am hoping Peter will provide similar comment 
> for the look-and-feel of the interface.

To see which devices (scanners, card readers, printers) belong together 
as one MF unit, one only needs to look at the output of "lsusb -vvv" or 
"lshal".

    Till

Re: [Printing-architecture] Another Common Dialog

[peter sikking]

Glen,

> Have you ever considered creating/defining a Common Status/ 
> Monitoring Dialog.

for printing: sure that is the next project, together with
printer installation.

> CUPS may have something already but does it support multi-function  
> devices sub-units like fax, scan, memory card, etc and can it  
> provide the status/monitoring information on a sub-unit by sub-unit  
> basis or as a roll-up for the entire MFD or both????

for users printing, faxing, scanning, memory card reading are
totally unrelated activities. so it follows that faxing, scanning,
memory card reading is never going to be seen in a printing dialog
and also not in a status/monitoring dialog.

     --ps

         founder + principal interaction architect
             man + machine interface works

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

Re: [Printing-architecture] Another Common Dialog

[Till Kamppeter]

peter sikking wrote:
> Glen,
> 
>> Have you ever considered creating/defining a Common Status/Monitoring 
>> Dialog.
> 
> for printing: sure that is the next project, together with
> printer installation.
> 
>> CUPS may have something already but does it support multi-function 
>> devices sub-units like fax, scan, memory card, etc and can it provide 
>> the status/monitoring information on a sub-unit by sub-unit basis or 
>> as a roll-up for the entire MFD or both????
> 
> for users printing, faxing, scanning, memory card reading are
> totally unrelated activities. so it follows that faxing, scanning,
> memory card reading is never going to be seen in a printing dialog
> and also not in a status/monitoring dialog.
> 

I would say so, too. The scanner should appear in scanning applications, 
memory cards should simply get auto-mounted and appear on the desktop 
(at least for locally connected devices, for network devices they should 
appear when scanning for file system shares in the network). Sending 
faxes should be done by a print queue where the printing dialog shows an 
appropriate widget for the fax number. A dialog to put these functions 
together is not needed. It can even get counter-intuitive if an MF 
device and a scan-only device is connected to the same machine.

    Till

Re: [Printing-architecture] Another Common Dialog

[peter sikking]

Till wrote:

> peter sikking wrote:
>> for users printing, faxing, scanning, memory card reading are
>> totally unrelated activities.
>
> I would say so, too.

it is not just a good idea, it is the truth.

> Sending faxes should be done by a print queue where the printing  
> dialog shows an appropriate widget for the fax number.

even that is mind-boggling incomprehensible for users.
I will fight tooth and nail to avoid that solution.

     --ps

         founder + principal interaction architect
             man + machine interface works

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

Re: [Printing-architecture] Another Common Dialog

[Petrie, Glen]

Not if my function is to manage the MFD.... but memory are on the
priority right now.

> -----Original Message-----
> From: peter sikking [mailto:peter@mmiworks.net]
> Sent: Friday, April 17, 2009 11:54 AM
> To: Till Kamppeter
> Cc: Petrie, Glen; printing-architecture@lists.linux-foundation.org;
> printing-summit@lists.linux-foundation.org
> Subject: Re: Another Common Dialog
> 
> Till wrote:
> 
> > peter sikking wrote:
> >> for users printing, faxing, scanning, memory card reading are
> >> totally unrelated activities.
> >
> > I would say so, too.
> 
> it is not just a good idea, it is the truth.
> 
> > Sending faxes should be done by a print queue where the printing
> > dialog shows an appropriate widget for the fax number.
> 
> even that is mind-boggling incomprehensible for users.
> I will fight tooth and nail to avoid that solution.
> 
>      --ps
> 
>          founder + principal interaction architect
>              man + machine interface works
> 
>          http://mmiworks.net/blog : on interaction architecture
> 
> 

Re: [Printing-architecture] Another Common Dialog

[Hal V. Engel]

On Friday 17 April 2009 11:54:28 am peter sikking wrote:
> Till wrote:
> > peter sikking wrote:
> >> for users printing, faxing, scanning, memory card reading are
> >> totally unrelated activities.
> >
> > I would say so, too.
>
> it is not just a good idea, it is the truth.
>
> > Sending faxes should be done by a print queue where the printing
> > dialog shows an appropriate widget for the fax number.
>
> even that is mind-boggling incomprehensible for users.
> I will fight tooth and nail to avoid that solution.
>

I also agree with Peter here.  A user sending a fax expects to see fax 
specific dialogs.  Till however is correct that hidden below that fax specific 
UI could be a print queue but the user should NEVER be aware of how it is 
actually implemented.

Hal

Re: [Printing-architecture] Another Common Dialog

[Till Kamppeter]

Hal V. Engel wrote:
> On Friday 17 April 2009 11:54:28 am peter sikking wrote:
>> Till wrote:
>>> peter sikking wrote:
>>>> for users printing, faxing, scanning, memory card reading are
>>>> totally unrelated activities.
>>> I would say so, too.
>> it is not just a good idea, it is the truth.
>>
>>> Sending faxes should be done by a print queue where the printing
>>> dialog shows an appropriate widget for the fax number.
>> even that is mind-boggling incomprehensible for users.
>> I will fight tooth and nail to avoid that solution.
>>
> 
> I also agree with Peter here.  A user sending a fax expects to see fax 
> specific dialogs.  Till however is correct that hidden below that fax specific 
> UI could be a print queue but the user should NEVER be aware of how it is 
> actually implemented.


So fax should look like this: On the implementation side we have print 
queues for faxes, the PPD files of fax queues contain the following CUPS 
extension:

*cupsFax: true

(see http://www.cups.org/documentation.php/doc-1.4/spec-ppd.html). This 
allows distinguishing print queues and fax queues. Applications are 
supposed to have a "Print ..." and a "Fax ..." entry. If a queue type 
(printing, faxing) is not present, the corresponding menu entry gets 
grayed out. Clicking "Print ..." gives the printing dialog as Peter has 
designed it, but only print queues (and no fax queues) are listed. 
Clicking "Fax ..." gives a dialog (slightly) different to Peter's 
printing dialog, for example with an additional "zone" with one or more 
  widgets to choose the fax destination (by typing in, calling address 
book, ...) and only the fax queues listed. The exact design for an ideal 
fax dialog can also be left to OpenPrinting. WDYT?

    Till

Re: [Printing-architecture] [Printing-summit] Another Common Dialog

[peter sikking]

Robert wrote:

>>> for users printing, faxing, scanning, memory card reading are
>>> totally unrelated activities.
>>
>> I would say so, too.
>
>   it is not just a good idea, it is the truth.
>
> Other than that with all-in-ones they're all physically in the same
> box (and the manufacturers sell them that way).

as long as you remember that it is unrelated user tasks packed
into one physical box, then I am happy.

> We get quite a few
> complaints about the scanner not functioning in multi-function
> devices; users appear to expect that these devices be handled as a
> single coherent unit.


I think the complaint is that the scanner is not working.
they would love if you could make that work for them.
do you really think any of them would expect a scan
workflow that goes through the print dialog?

     --ps

         founder + principal interaction architect
             man + machine interface works

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

Re: [Printing-architecture] Another Common Dialog

[peter sikking]

Till wrote:

> Hal V. Engel wrote:
>> On Friday 17 April 2009 11:54:28 am peter sikking wrote:
>>> Till wrote:
>>>> Sending faxes should be done by a print queue where the printing
>>>> dialog shows an appropriate widget for the fax number.
>>> even that is mind-boggling incomprehensible for users.
>>> I will fight tooth and nail to avoid that solution.
>>>
>>
>> I also agree with Peter here.  A user sending a fax expects to see  
>> fax
>> specific dialogs.  Till however is correct that hidden below that  
>> fax specific
>> UI could be a print queue but the user should NEVER be aware of how  
>> it is
>> actually implemented.
>
>
> So fax should look like this: On the implementation side we have print
> queues for faxes, the PPD files of fax queues contain the following  
> CUPS
> extension:
>
> *cupsFax: true
>
> (see http://www.cups.org/documentation.php/doc-1.4/spec-ppd.html).  
> This
> allows distinguishing print queues and fax queues. Applications are
> supposed to have a "Print ..." and a "Fax ..." entry.

yes. this is the key to making things normal for users.

> If a queue type
> (printing, faxing) is not present, the corresponding menu entry gets
> grayed out.

both will need access installation workflow (the next project...)

> Clicking "Print ..." gives the printing dialog as Peter has
> designed it, but only print queues (and no fax queues) are listed.

yes. excellent.

> Clicking "Fax ..." gives a dialog (slightly) different to Peter's
> printing dialog, for example with an additional "zone" with one or  
> more
>  widgets to choose the fax destination (by typing in, calling address
> book, ...) and only the fax queues listed. The exact design for an  
> ideal
> fax dialog can also be left to OpenPrinting. WDYT?


just like I said for the pdf export dialog: it will be a cousin
of the print dialog, not a twin brother. we can recycle a lot of
good UI concepts and code for these dialogs, but sound UI practice
demands that the design of each is optimised for the particular
activity.

     --ps

         founder + principal interaction architect
             man + machine interface works

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

Re: [Printing-architecture] [Printing-summit] Another Common Dialog

[peter sikking]

Johannes Meixner wrote:

> On Apr 17 20:21 peter sikking wrote (shortened):
>> for users printing, faxing, scanning, memory card reading are
>> totally unrelated activities. so it follows that faxing, scanning,
>> memory card reading is never going to be seen in a printing dialog
>> and also not in a status/monitoring dialog.
>
> Yes and no - it depends - as always - on the details what
> exactly is meant.
>
> In contrast to separated stand-alone devices where printing,
> faxing, scanning, memory card reading works independent
> of each other, all-in-one devices introduce hardware-dependent
> constraints.
>
> For example when the all-in-one device is busy with
> memory card reading, nothing else might be possible
> so that the device status/monitoring in all dialogs
> (i.e. also in the printing dialog) must display that
> the device is busy with memory card reading.
>
> The crucial point here is whether or not status/monitoring
> is meant regarding the actual hardware device.
>
> In contrast e.g. a print queue status/monitoring belongs
> of course only to the printing dialog.


interesting complication. can this lead to the situation that
when the print dialog comes up (or users Just Print) that
the printer (part) actually looks unavailable/not there
to the desktop computer?

     --ps

         founder + principal interaction architect
             man + machine interface works

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

Re: [Printing-architecture] [Printing-summit] Another Common Dialog

[peter sikking]

Johannes Meixner wrote:

> On Apr 17 20:21 peter sikking wrote (shortened):
>> for users printing, faxing, scanning, memory card reading are
>> totally unrelated activities. so it follows that faxing, scanning,
>> memory card reading is never going to be seen in a printing dialog
>> and also not in a status/monitoring dialog.
>
> Yes and no - it depends - as always - on the details what
> exactly is meant.
>
> In contrast to separated stand-alone devices where printing,
> faxing, scanning, memory card reading works independent
> of each other, all-in-one devices introduce hardware-dependent
> constraints.
>
> For example when the all-in-one device is busy with
> memory card reading, nothing else might be possible
> so that the device status/monitoring in all dialogs
> (i.e. also in the printing dialog) must display that
> the device is busy with memory card reading.
>
> The crucial point here is whether or not status/monitoring
> is meant regarding the actual hardware device.
>
> In contrast e.g. a print queue status/monitoring belongs
> of course only to the printing dialog.


interesting complication. can this lead to the situation that
when the print dialog comes up (or users Just Print) that
the printer (part) actually looks unavailable/not there
to the desktop computer?

    --ps

        founder + principal interaction architect
            man + machine interface works

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