Conference iosg::all-in-1_v30

>>  1) GOLD E to set printing chars when printing the document

ALL-IN-1 Print styles can be used to create Print jobs which contain paper
tray selection parameters.  There are various ways in which print styles 
can be used.  The best method depends on:

    1.  if you want users to specify the input and/or output trays each
	time they perform a print operation, or you want users to create 
	their own print styles

    2.  if you as the ALL-IN-1 manager want to create additional system
	print styles which have the trays defined - this does the same as 1 
	but will mean less navigation through menus and typing for the user

    3.  you want to create additional ALL-IN-1 printer destinations which
	have different default print styles - this may mean a bit less 
	typing for the user that 2. because a print style will not need to
	be specified 
	


>>  2) different queues in ALL-IN-1 (and VMS?) for different trays

ALL-IN-1 has printer destinations,  which are directed to VMS print queues.
If you are referring to ALL-IN-1 printer destinations then it's the same as 
3. above.  CPS provides mechanisms using logical names to add default 
parameters to print queues.  This could be used but is outside the control 
of ALL-IN-1.



>> 3) certain ASSETS to achieve this

The ASSETS packages were used to support print server options on ALL-IN-1 
V2.4.  Although they will still work on V3.0 they do not interoperate with 
the new Print styles and therefore I would advise they they are not used.


Richard

Hi,

DEClasers without PS option require a print form to select trays. We had an 
ASSETS (ALL-IN-1 Printing Menu) which handled this in V2.4. I am going to 
write this new for V3.0 beacuse our customers are very unhappy with GOLD E
and the user defined print styles... Contact me if you are interested.

Stefan

If the purpose of the ASSET is to create a Print Job with a different VMS 
Print form this can also be done with a print style.

Why are your customers very unhappy with GOLD E and the user defined print
styles?


Richard

Hi,

>> I am going to write this new for V3.0 beacuse our customers are very
>> unhappy with GOLD E and the user defined print styles

The users don't need to use GOLD E or user-defined print styles.  The manager
can set up the default print style for the queue with the desired features,
or provide a special print style for certain features: the user just needs to
put this name in the Print Style field.  To me this seems a lot easier (both to
implement and to use) than re-writing a custom "Printing Menu".  Plus it is
upgrade-proof.

Just a suggestion

Scott

Hi Richard!

>Why are your customers very unhappy with GOLD E and the user defined print
>styles?

There are a lot of causes that makes our customers unhappy:

1. Using GOLD E the user is prompted with a hell of a lot of new parameters. For
a 'normal' ALL-IN-1 user it is too much.

2. Users do not understand why they have to look for one simple parameter 
(sides) over 6 pages.

3. Another userunfriendly point is the matter of fields on these screens that 
may not been changed by the user. Something like dynamic menues depending on
the printer used would be much nicer.

4. Users without DCL experience may have problems to set the right parameters. 
For example, if you want to print a double-sided page on an LN06, the user has
to enter the name of a print form intended for this purpose. That's the first
problem; if he does not know which form to use, he presses GOLD L and expects a 
description for the different possibilities. It's not possible to support users 
in this way.

5. User defind print styles: It's a nice idea to have own print styles. But
there are same problem as with GOLD E. And when a unskilled user creates print
styles without knowing what he does, it will make the work more difficult for 
the system manager to find the problem. Another problem: if I want to print
the first document one-sided and the second two-sided, I had to choose an other
print style. Userfriendly?

There are a lot of nice features in V3.0. But the printing Interface isn't very
overturning. Since printing is one of the points that lets people make a lot of
mistakes I think it's worth to do the most possible. V3.0 doesn't in this point.

I hope you'll tell me that I'am wrong...and you will show me the way how to
print in V3.0 :-)


Stefan

Hi,

I mentioend this earlier, maybe I didn't make it clear enough.

If the Print-Styles screens are too complicated for ordinary users, the manager
can create a number of system-wide print styles to cover the most common
requirements.  The users can then just enter the name of the required print
style in the "Print Style" field of the printing form.

Thus users need never use GOLD-E, unless they want very esoteric print settings,
in which case they're probably competent enough to cope with the complicated
form!

Scott

Re: .5

> 1. Using GOLD E the user is prompted with a hell of a lot of new
> parameters. For a 'normal' ALL-IN-1 user it is too much. 

The GOLD-E screens provide access to all the features available to all VMS 
Print jobs and jobs for Print Servers (the CPS V4.0 software).  We had many 
requests to provide access to these features from the ALL-IN-1 user 
interface.  

If you are suggesting we should not support all the features which ones
would you leave out, and what would you say to a customer who wanted to use
a feature we didn't support?

We know from past experience that if we decide not to support some features
we will very probably get SPRs about the missing features.  Therefore it is
better for us to support everything.  

If a particular customer does not want everything it can be customized
out.  Removing things is a much simpler customization than adding things
not supported in the standard product. 



> 2. Users do not understand why they have to look for one simple parameter 
> (sides) over 6 pages.

The SSB kit uses 2 screens for the standard parameter, and 2 screens for 
the additional parameters, which makes 4 screens maximum.  We originally had 
2 screens but were asked by the translation centre to use 4 screens because
they were too crowded to translate from English to languages which have
longer words and phrases. 

What kit are you using which has 6 screens?


> 3. Another userunfriendly point is the matter of fields on these screens that 
> may not been changed by the user. Something like dynamic menues depending on
> the printer used would be much nicer.

What exactly do what you find unfriendly.  Fields that cannot be changed
can have a fixed value specified by the manager.  Displaying the field,
even though the user cannot enter it, allows the user to see what the value
will be. 

I cannot comment on your suggested alternative until you explain it in much 
more detail. 


>4. Users without DCL experience may have problems to set the right parameters. 
>For example, if you want to print a double-sided page on an LN06, the user has
>to enter the name of a print form intended for this purpose. That's the first
>problem; if he does not know which form to use, he presses GOLD L and expects  
>description for the different possibilities. It's not possible to support user
>in this way.

If the manager sets the print style information as follows:

 Print Form:
   Changeable: Y                       Value:
   Validation:               Validation type: DATASET
     QUI$FORM

the user can press FIND (GOLD L) to display all the VMS Print forms defined 
on the system.


Also, the manager could create a style specifically for double-sided LN06
printing and define the required VMS print form in the style.  A user would
only have to specify the style on Printing Document form, and would not
have to use Gold E if they did not want to change any other parameters. 



>5. User defind print styles: It's a nice idea to have own print styles. But
>there are same problem as with GOLD E. And when a unskilled user creates print
>styles without knowing what he does, it will make the work more difficult for 
>the system manager to find the problem. 

As the designer of this part of ALL-IN-1 I was aware that it would allow
users to access to features of print jobs which they may not know how to
use.  This was the reason for implementing 'Changeable' control on all the
fields of a print style.

Managers can choose whether to allow their users the freedom to change
fields in a print style, or they can set all the fields on all the styles
as 'Not Changeable' and therefore tightly control what their users can do.  

The reason we put 'Changeable' on each field was to provide degrees of
freedom.  Fields which are more likely to cause problems, such as VMS Print
forms specific to types of printers, can be set unchangeable.  Fields which
are unlikely to cause problems, such as 'Copies' or 'Notify user' can be
set to changeable. 

The 'Print Destination Type' field on a print style allows a manager to
define which print styles can be selected for a particular style.  
Therefore Print styles which are not suitable for the destination cannot be 
selected.  


>Another problem: if I want to print
>the first document one-sided and the second two-sided, I had to choose an other
>print style. Userfriendly?

If you think this is unfriendly what do you suggest as an alternative?

It is difficult to create a VMS print job which does one sided and two sided 
printing within the same job.  The normal methods (VMS Print Forms or 
/PARAMETER=SIDES=) are both Job parameters which apply to all files of a 
job.  Therefore you have to perform another print operation to create 
another print job, and the way you tell ALL-IN-1 how to perform a print 
operation is to use a different Print style, or modify a field of the 
default or last used print style.


> There are a lot of nice features in V3.0. But the printing Interface isn't
> very overturning. Since printing is one of the points that lets people make
> a lot of mistakes I think it's worth to do the most possible. V3.0 doesn't
> in this point. 

Many customers asked us to provide access to the Print and Printer server
features and so we did.  As I have described above access to these features
by normal ALL-IN-1 users can be very tightly controlled by ALL-IN-1
Managers if they want to run their system in that way.  


Richard

    Hi,
    
Re: .6
    
>The users can then just enter the name of the required print
>style in the "Print Style" field of the printing form.

    If users print their documents on different printers they have - under
    some cicumstances - to select another print style when changing the printer
    (LPS20, LN06, LN03). They have to know which style to use for the
    selected printer to get the document printed the way they want to have
    it printed; further they have to know which features are supported by
    the different printers to select the right style. This means: there is
    not a lot of support from the system for the user.
    
    
>Thus users need never use GOLD-E, unless they want very esoteric print settings,
>in which case they're probably competent enough to cope with the complicated
>form!
    
    With V2.4 every user could have a look at the named data of a form. Now
    in V3.0 this requires a certain privilege. I think one cause for the 
    change is to prevent users from being confused by something they do
    not understand. An ALL-IN-1 user without DCL experience will be
    confused by all the fields in the GOLD E screens. What I want to say
    with this: At one hand there are efforts to prevent confusion at the
    other hand confusion will be forced. 
    
    One example for perfect confusion is the value that can be entered for
    the first and the last page printed. Within GOLD E the entered value is
    file oriented in GOLD A it is document oriented. The text describing
    the purpose of the text is the same (in German).
    
    
Re: .7

>The GOLD-E screens provide access to all the features available to all VMS 
>Print jobs and jobs for Print Servers (the CPS V4.0 software).  We had many 
>requests to provide access to these features from the ALL-IN-1 user 
>interface.  

    That's great and I am happy with this. 
    
>If a particular customer does not want everything it can be customized
>out.  Removing things is a much simpler customization than adding things
>not supported in the standard product. 

    That's probably the way we will manage it at our customer sites -
    selling the ASSETS mentioned in .1 or .2.
    
>The SSB kit uses 2 screens for the standard parameter, and 2 screens for 
>the additional parameters, which makes 4 screens maximum.  We originally had 
>2 screens but were asked by the translation centre to use 4 screens because
>they were too crowded to translate from English to languages which have
>longer words and phrases. 

>What kit are you using which has 6 screens?

    I am using a German ALL-IN-1. Because they translate the (more...) with
    (1 of x) and this x is 7 on the form WPPARG, I came up to the number of
    6 screens. In fact there are 4 screens only.

> 3. Another userunfriendly point is the matter of fields on these screens that 
> may not been changed by the user. Something like dynamic menues depending on
> the printer used would be much nicer.
>
>What exactly do what you find unfriendly.  Fields that cannot be changed
>can have a fixed value specified by the manager.  Displaying the field,
>even though the user cannot enter it, allows the user to see what the value
>will be. 

    What's userfriendly - what's unfriendly? I'd say a system, that does as
    much as possible for the user is a userfriendly system.
    
>I cannot comment on your suggested alternative until you explain it in much 
>more detail. 

    I'll try to explain you what I mean:
    
    The user should have the possibility to modify some print parameters.
    Because the manager wants to have the possibility to define which
    parameters are changeable by users he should have the possibility to
    restrict it. This can now be done with the print styles. Users should
    only see the list of parameters they can change and the list of
    parameters showed to the user should be related to the printer they
    want to use. 
    
    Example: A system serves LN06, LN03 and LPS20 printers. The system
    manager wants that normal users may change following parameters: SIDES,
    NUMBER_UP, DATA_TYPE, PAGE_ORIENTATION, FONTS_USED. 
    
    Three printers - three different sets of print possibilities. A
    user-friendly system would show a user one of the following screens after 
    pressing <RETURN> in WPPARG. 
    
    To be more flexible this breakpoint could be set by loading a permanent 
    symbol within the user set up menu. Using this symbol users could wish to 
    whether they want to use user defined print styles, the following 'printing
    menues' or none.
    
    Experienced users (for example those with VIEW privilege) may use GOLD
    E which should be a hidden option. 
    
    The field PTRTYP within WPPARG should be filled with the destination 
    printer type of the selected printer (as in V2.4). For users who wish to 
    use their own print styles as designed in V3.0 this field should be 
    handled as it actually is in V3.0
    
    The main idea of this menu is to confront users with the smallest
    common denominator of features offered by the printer and the system
    manager.
    ------------------------------------------------------------------------
                          LN06 Printer Parameters
    
    		Sides:      		DUPLEX		(last used value)
                Fonts Used:		______________	(only if Datatype ANSI)
    -----------------------------------------------------------------------
                          LN03 Printer Parameters
    
                Fonts Used:		______________	(only if Datatype ANSI)
    -----------------------------------------------------------------------
                          LPS20 Printer Parameters
    
    		Sides:      		DUPLEX		(last used value)
		Number Up:  		2		(last used value)
    		Datatype:   		POSTSCRIPT	(document depending)
                Page Orientation:       PORTRAIT	(last used value)
                Fonts Used:		______________	(only if Datatype ANSI)
    -----------------------------------------------------------------------
    
>4. Users without DCL experience may have problems to set the right parameters. 
>For example, if you want to print a double-sided page on an LN06, the user has
>to enter the name of a print form intended for this purpose. That's the first
>problem; if he does not know which form to use, he presses GOLD L and expects  
>description for the different possibilities. It's not possible to support user
>in this way.
>
>If the manager sets the print style information as follows:
>
> Print Form:
>   Changeable: Y                       Value:
>   Validation:               Validation type: DATASET
>     QUI$FORM
>
>the user can press FIND (GOLD L) to display all the VMS Print forms defined 
>on the system.
    
    It seems you do not understand the problem. Using this method the user
    will be prompted with the names and nothing else of all available print 
    forms. Since ALL-IN-1 often will be used on large VAXes there is a good 
    chance for the existance of hundreds of forms. And there is one other 
    point I mentioned: The description of what the listed forms are intended 
    for is missing using your suggested validation. This will mislead users 
    to play around with all available forms. I have to ask again: is this 
    user-friendly? I know, I could create a DSAB which contains all
    ALL-IN-1 related forms or ...  
    
    
    
    >...Also, the manager could create a style specifically for double-sided LN06
>printing and define the required VMS print form in the style.  A user would
>only have to specify the style on Printing Document form, and would not
>ave to use Gold E if they did not want to change any other parameters. 

    Using a different style when printing double sided on an LN06 and an
    LN06R is very transparent for 'normal' users. It the same a using once
    the parameter /FORM and then /SIDES. I have to say: Very very clear for
    users... 
    
    Since the documentation about user defined print styles is rather poor I 
    assume the engineers are not very proud about this chapter ;-). I hoped
    to find some nice advices in Tony's book: I found one phrase in the
    introcuction...
    

>5. User defind print styles: It's a nice idea to have own print styles. But
>there are same problem as with GOLD E. And when a unskilled user creates print
>styles without knowing what he does, it will make the work more difficult for 
>the system manager to find the problem. 
>
>As the designer of this part of ALL-IN-1 I was aware that it would allow
>users to access to features of print jobs which they may not know how to
>use.  This was the reason for implementing 'Changeable' control on all the
>fields of a print style.
>
>Managers can choose whether to allow their users the freedom to change
>fields in a print style, or they can set all the fields on all the styles
>as 'Not Changeable' and therefore tightly control what their users can do.  
>
>The reason we put 'Changeable' on each field was to provide degrees of
>freedom.  Fields which are more likely to cause problems, such as VMS Print
>forms specific to types of printers, can be set unchangeable.  Fields which
>are unlikely to cause problems, such as 'Copies' or 'Notify user' can be
>set to changeable. 
>
>The 'Print Destination Type' field on a print style allows a manager to
>define which print styles can be selected for a particular style.  
>Therefore Print styles which are not suitable for the destination cannot be 
>selected.  

    Thank you. This is the confirmation for what I assumed but never found
    in the documentation. Although, I coudn't convince system managers of
    the goodies of the new way of printing with ALL-IN-1. A lot of them
    will remove the option to define user print styles ...
    
>Another problem: if I want to print
>the first document one-sided and the second two-sided, I had to choose an other
>print style. Userfriendly?
>
>If you think this is unfriendly what do you suggest as an alternative?
>
>It is difficult to create a VMS print job which does one sided and two sided 
>printing within the same job.  The normal methods (VMS Print Forms or 
>/PARAMETER=SIDES=) are both Job parameters which apply to all files of a 
>job.  Therefore you have to perform another print operation to create 
>another print job, and the way you tell ALL-IN-1 how to perform a print 
>operation is to use a different Print style, or modify a field of the 
>default or last used print style.

    I don't want to print one-sided and two sided in one job. Printing one
    document after the other requires changing the print style. In my
    suggested solution I only had to change the value for /SIDE - but
    forget it, it's the same expense.
    
    
     
> There are a lot of nice features in V3.0. But the printing Interface isn't
> very overturning. Since printing is one of the points that lets people make
> a lot of mistakes I think it's worth to do the most possible. V3.0 doesn't
> in this point. 
>
>Many customers asked us to provide access to the Print and Printer server
>features and so we did.  As I have described above access to these features
>by normal ALL-IN-1 users can be very tightly controlled by ALL-IN-1
>Managers if they want to run their system in that way.  

    
    I am happy, that somehting happened with the printing interface. It's
    better than in V2.4 but there is still a lot to make better. Since we
    want to be better than others we have to make it better if we have the 
    possibilities to do it.
    
    Writing this reply took me a lot of time. This will show you how
    important this question is to me and to our customers who still love
    ALL-IN-1. And I hope, you will a little bit understand what I tried to
    explain in my rough english.
    
    Stefan

    
    RE: .8  Dein Englisch ist Spitze!
    
    	I must say I like the sound of context sensitive menus. I would
    	even go so far as to say ALL-IN-1 could "sense" the setup of
    	a given queue to see if it is a PostScript queue. Okay, it may
    	not be possible with current CPS software (in which case it should
    	be on their requirements list) so one might have to dream up a
    	scheme where you define the printers to ALL-IN-1 and it generates
    	the COM files to create your queues. I'm trying to obviate the
    	need for telling both ALL-IN-1 and VMS the same information.
    
    	I also like your example where only the fields of interest to
    	the user are displayed.
    
    	Maybe this is an area that would benefit from a session of
    	usability testing?
    
    Regards,
    Paul
    
    PS	If anyone is having difficulty imagining "user-friendly", take
    	a look at Microsoft Excel V4.0 which has had a HUGE amount of
    	user feeback fed back into it.

    Re: .9

>    	I also like your example where only the fields of interest to
>    	the user are displayed.

    The rub here is what constitutes a `field of interest'.  Just because
    a field is `unchangeable' does not make it `uninteresting'.  Perhaps
    what is needed is to keep the GOLD E form, and to also add a small
    `often required options' form. The small form may have unchangeable
    fields and, as a convenience, GOLD E on the small form takes you to the
    full expanded form.

    Cheers,
        Paul.

    
    	Yes, I started thinking on those lines. I think an important point
    	is that "uninteresting" things is context dependant, for example
    	SIDES is uninteresting on an LN03R. The user shouldn't be expected
    	to know the capabilities of every printer, this intelligence should
    	be built into the UI.
    
    	Some fields would easily fall into the "uninteresting" catagory
    	for most sites, such as "Operator text" or "File Setup", but I
    	agree, coming up with a universal list would not be easy. For
    	me, sides and number-up are the only fields I worry about.
    
    Regards,
    Paul

    Other fields are:
    
    Input Tray, Output Tray, Page Orientation, Fonts Used, etc.
    
    Which fields are visible for users should be determined by the manager.
    
    I just spoke with one of the most important system managers of our
    biggest customer (Swiss PTT) in Switzerland. They had the idea to use
    the famous 'Print Styles' or 'User Defined Print Styles'. When they 
    realized that they had to define a style for each combination of 
    paramteres they prefferd to upgrade themselve our ASSETS 'ALL-IN-1 
    Printing Menu' which solves the problem as described in .8 not using 
    dynamic menues...
    
    Stefan

RE: .8

Stefan,

The major design goals of the V3.0 printing user interface were:

    o	to provide support for all 22 VMS print job options and all 15
	Print server options 

    o	allow managers to control which options can be used WITHOUT having
	to customize Digital supplied forms and scripts


We do not know which print options a particular site will want to use, or
will use the most.  Also, some VMS print options, such as Print Forms and
Setup, can be used for many purposes because they extract modules from
device control libraries.  We do not know the purpose of these modules and
so cannot reflect this in the standard user interface. 


If I understand and summarize your concerns correctly, they are:

    1.	a user can select print styles and/or options within a print style
	which will not work with the selected printer

    2.	a user is presented with too many options, some of which they may
	not understand

Print Destination types, the Changeable flag on print style fields, and
validation on some print style fields provides a Manager with a lot of
control over what users are allowed to do.  Therefore your first concern is
mostly addressed.  Further, the control is achieved by 'configuring' the
system, and does not require 'customizing' the system.  I define
'configuring' as using System Management options to add, change, etc.
entries in system master files, and 'customization' as having to use
Customization Management to modify or add to Digital supplied forms,
scripts, etc. 

Your second concern is partially addressed because print styles which don't
use the additional (Print server) fields will only display the first two
screens when GOLD-E is used.  Also, if no fields of the style can be
changed then a message telling the user this will be displayed when GOLD-E
is used. 


I understand your goals for your suggested user interface for printer
specific forms with a small number of options, but I have the following
questions. 

Is it controlled by 'configuring' or by 'customizing'?  If by 'configuring'
how would you implement it?  It would seem to need a dynamic argument form,
which the ALL-IN-1 API (and FMS) does not have? 

Are you suggesting that the forms for the commonly used options for each
printer are shipped in the SSB kit?  If so, which options would you 
support, which would you leave out, and what are the reasons for your 
choices? 


The supplied Printing user interface is very general because:

    o	it provides access to all the VMS Print job and Print server options

    o	we don't know the specific reason for using some options (for
    	example, set-up modules in print forms) 

    o	we don't know which printers will be used, and therefore which
    	options are not required

    o	it does not impose any opinions about which are the important
    	options


A user interface designed to support a small number of printers and a small
number of the print options is probably going to look different to a very
general interface because each has valid but different goals and
requirements. 


Richard

    Richard,
    
Re: .7
    
>The 'Print Destination Type' field on a print style allows a manager to
>define which print styles can be selected for a particular style.  
>Therefore Print styles which are not suitable for the destination cannot be 
>selected.  

    I tried to use this feature but I failed. Maybe I didn't understand how
    it should work. I defined the following 'Site Printer' 
    
      Printer Name:              SMU_EBO1_LN03_2
      Description:               LN03+ first floor office group
      Format Printer Type:       SMU_LN03
      Destination Printer Type:  SMU_SYSTEM_PRINTER
      Print queue:               EBO1_LN03_2
      Printer level:
      Comments:
    
    
    and the 'Printer Type' is defined the following way
    
      Printer Type:             SMU_LN03
      Description:              LN03-Drucker A4
      Printer Device:           LN03A4
      Print Destination Type:   SMU_SYSTEM_PRINTER
      Final Form Style:
     
    
    The destination printer type SMU_SYSTEM_PRINTER is defined as shown
    below:
    
      Destination Type:            SMU_SYSTEM_PRINTER
      Foreground function:         DO WPPSYSTEM
      Background function:         DO WPPBGFORMAT
      Destination check function:
      XP error clean-up function:  DO WPPSYSERRCLEANUP
    
    
    As long as I understand I should no longer be able to use a print style
    different than SMU_LN03  for printing a document on the site printer
    SMU_EBO1_LN03_2. But it's no problem to use any other print style
    printing with SMU_EBO1_LN03_2.
    
    Any help?
    
    Stefan
    

Printer Types can be classed into two types:

    o	Types which can only be used for a specific type of destination -
    	the 'Printer Type' Print Destination Type field is defined 

    o	General types which can be selected for all print destinations -
    	the 'Print Type' Print Destination Type field is blank


When the user is performing a print operation, and has selected a print 
destination they will be able to select destination specific AND general 
Print styles.  They will not be able to select Print styles defined for
other types of destinations.

Are the other Print styles you are able to select 'general' print styles? 



Richard