Printing packets in EBMS - User Overview

Unless and until we come up with a better term, I'll use "board member package" to mean the total of all documents printed for a board member. Package contents include one or more packets for the one or more topics that board member will review.

• Contents of each packet in a package
  
  • Documents associated with the packet
    A board manager can attach zero or more documents to a packet. These are not copies of the journal articles, but other documents created or selected by the board manager. The most common document associated with a packet is a Microsoft Word conversion of the CDR Summary for the topic. The board manager decides whether a Summary should be included, what version of the CDR Summary to include, and whether to include it unmodified or to add notes or make changes.
    • Document formats that can be printed
      In order to print a document the system must have a program that can format that document type for printing, and that program must be capable of being driven by a controller program, without requiring a human to enter print commands from an application.

      The standard Linux printing system supports many document types, including PDF, text, and many image types, but we are not yet sure about Microsoft Word. We will investigate. It is possible that we will find a good method of printing some Word formats, but not all of the Word formats that have existed over the years. In the worst case, if there is trouble printing Word documents, we can either print them individually from Word in Windows, print Summaries from the CDR, or individually save them from Word as PDF as well as Word format, perhaps attaching both forms to each packet and just printing the PDF version.

      The development team will come up with a list of document types that can be printed.

  • Journal article in the packet
    The system will print all of the articles in each packet, including the following for each article:
    • Review response sheet
      These will be generated programmatically, customized for each board member and article.
      • Programmatically generated parts
        
        • Date
          
        • Board member name
          
        • Editorial board name
          
        • Summary topic name
          
        • Journal article identifying info
          
      • Constant part
        The form for recording a response. This will always includes all of the parts that only appear in the electronic version when a board member checks specific boxes.
    • Journal article
      The PDF that we have stored for the article.

It may occasionally be desirable to print a single packet, or a single document that is part of a packet, apart from an entire package intended for a board member.

The system will already have ways to find, display, and print individual documents. Therefore no special software will be written to handle any printing needs below the levels of packet and package.

It was decided at our last meeting that the EBMS will not have any special capability for printing cover letters to accompany packages as a whole or to accompany individual packets.

It will still be possible for a board manager to include any document she likes, so long as it is in a supported format, in a packet. So if there is some case that requires a cover letter, that can be associated with the packet using the EBMS facility for that purpose, and it will be printed with the packet.

We won't be printing for everyone, only for those board members who prefer printed packets over electronic access to the documents. Board members who always want printouts should have an indication set in a profile record. These should probably be entirely under the control of the OCE staff since 1) Board members who don't want to interact with the system online won't be able to change their preferences, and 2) Board members who make a mistake online might stop seeing the articles they need.

We will provide a way to print individual packages and packets (see the section on the User Interface below), so it should not be necessary to have any special mechanism for overriding the stored preference in the profile.

We need to store information about what was printed so that we can find out what was printed, and so we won't accidentally print anything twice. A discussion of how to do that is a design issue, beyond the scope of this user perspective.

• Printing is board specific
  The system will print packages or packets for one editorial board at a time. To print everything available, the print program will have to be told to print each of the boards. This enables board managers to determine their own schedules for printing.

  If a single person is on two boards, then even if we print everything for both boards, he will get two separate packages, one for each board.

• Everything for a board can be printed with one command
  If so requested, the system will need to find all of the board members for the selected board(s) who are to receive printouts, then assemble and print a package for each.
• Reprinting of print batches is allowed
  Normally, when printing everything for a board, only packages of packets that have not been printed before will be printed. However, a user must be able to reprint everything, for example if all of the printouts are accidentally destroyed.
• Printing of any single package or packet is always allowed
  Whether it has been printed before or not, we can always print a single package or a single packet.

To print packages or their components we need a user interface to direct the printing. It should be organized as follows:

• Select one or more editorial boards
  A list of boards will be presented. The user may select one or more of them.
• Select "new" or "previous" for packages
  "New" selects only packages for the selected board(s) that have not previously been printed. If "previous" is selected, the user enters a date range and the system selects all packages for the specified board(s) that were previously printed at any time between the upper and lower date boundaries.
• Optionally, select a specific board member
  If an individual board member is selected, the system will print a package just for that one board member, regardless of his or her profile printing preferences. The package selected may be "new" or, if a date range has been specified, the latest package printed within that range.
• Optionally, select a specific packet
  If an individual packet is selected, the system will print just that one packet, regardless of what board members may or may not normally receive the packet. The packet may be "new" or, if a date range has been specified, the latest packet printed within that range. The user may select a board member, a packet, or neither. She may not select both a board member and a packet.
• Request the print processing
  Initiating the request will cause all of the requested documents to be selected and organized for printing. No printing will be done yet. Some feedback (to be determined) will be be produced to tell the user something about what will be printed, perhaps a count of packages, packets, and total documents - or something that will at least give the general dimensions of what will happen when printing starts.
• Submit the print job
  The user should check that the printer is on and has paper, then click a submit button to begin the actual printing.

The system will be setup for a standard print configuration, probably two sided printing, to save money on paper and mailing, and to reduce environmental impact. No provision will be made for printing some packages or packets or documents with specialized configurations.

The technique that worked best for mailers was to produce a batch of documents as ready to print files, and a queue of print commands to cause them to print in order.

When the queue is ready and the job is submitted, the software will update the database to indicate what was printed.

If something goes wrong, for example a paper jam or a printer failure, the user will take whatever steps are necessary outside the system to fix the problem and restart printing. If some of the printouts were destroyed, the user can go back into the system and request the specific packages or packets to be reprinted, or better, find the specific document that jammed and just print that using other EBMS techniques for printing individual documents, and restart the rest of the queue.