Printing from the Catalog


There needs to be a way to print a list of records, or a single record, in a way that allows significant user control over the resulting printout, in order to save paper, and also for usability. Patrons should be able to select records and check off what parts of the record they want to print - brief, full, local item info (call number), all item info, sort order etc.

A good example would be a patron who wants a list of all of an author's audiobooks in order by date, showing those that are owned by the local library. You can pull that together, but there's no easy way to print out something that would look nice and be useful to the patron.

Users should be able to preview the list before printing, and save a preferred printing configuration in their online account (if a patron) or by user or workstation (if staff).

Planned development


Re: Printing from the Catalog

I don't know of any site that lets you do this kind of thing, and I highly doubt that the amount of effort required to do this is worth it. Not to mention the headaches of keeping the printed version up to date with local catalog customizations.

Can anyone provide an example of a site that lets you print info like this suggests?

As for dumping lists of things....make a list and export it to CSV. Done!

Re: Printing from the Catalog


Right now, the default print for a bib record doesn't include a call number. It isn't unreasonable for a patron to want to print this information. It may not be an apples-to-apples comparison, but it isn't unusual for databases to offer the option to print citations vs. full text and to select a particular citation format, so I think there is precedent for giving users some control over what is printed. I guess we won't know if it is worth the effort until we see how many people show support for this idea and then get quotes from developers who are willing to work on the project.

Re: Printing from the Catalog

And which call number should it include? Bib level vs deeper can be hard to decide at that layer.

The "easy" solution to that particular problem is probably to ensure that the CSS supports "print" mode to hide most of the header and footer, as well as the easier to hide otherwise not useful links (Place Hold, Add to My List, etc). Then you have the option of getting the "quick info" print/email or using the print functionality of the browser to get a more complete page (with cover graphic if available). Whichever copies are visible at that point would then print. It may be useful to change the Print/Email link set to indicate that it is a brief print at the same time.

A similar CSS change (many of the other changes for header/footer would still kick in) would allow for automatic hiding of the facet sidebar when printing, providing a cleaner output when printing search results, though printing more than the default per page in one shot would be more tedious unless at some point we introduce a "records per page" selector (not hard, add &limit=50 to get 50 per page as it is, just needs a selector or link set to make it easier for staff and patrons to use).

As all of the above is 100% in templates and the CSS (which is also in the templates now) it could qualify as a local customization fairly easily.

Complicated "I want to print X and Z, but not Y" selectors make it very hard to customize your templates and I don't think they will give us enough gain for the pain in getting them working.


For reference purposes, if someone else wants to tackle the CSS approach now, I recommend taking a quick look at the following pages:

Re: Printing from the Catalog


The Boston Globe (and many of the other databases library patrons use) provide flexible options for printing, exporting and creating citations to copy and paste.  They list many different standard citation formats, but for the catalog we could also include a few options for a brief view and a detailed view.  As for call numbers, users should be prompted to choose a call number when they save a record.  This is how SMS worked on our old system.

The other option is to list all the call number that user is seeing -- all of them, if they are searching the whole consortium, or just their library's, if that's what they are searching.  (Or the preferred library's call numbers?)    Listing all would make for a very long list for Gone Girl scoped to the consortium level, but not listing call numbers means the user has two options: SMS or paper and pencil.

Re: Printing from the Catalog

The way the interface works right now we don't have access to what the patron was seeing, as no matter what we are talking about we are dealing with a record bucket. When we email we are using the bucket owner as the source of the email address. As we aren't in the catalog anymore (this happens in A/T) we can't use the catalog helpers either.

I still think the better solution is going to be to make the catalog more easily printable, which I think is a good idea in general.

Alternatively, for call numbers, we can duplicate the "Text" link into "Print/Email/Text" and leave the rest of the citation stuff as bib level without having call numbers involved at all.

Assuming we do that the bib level citation stuff is probably fairly easy, provided we know what citation formats we want and how to build them. We can dump random data into A/T events (texting without being logged in does that, for example) and while we can't load random objects from the template we can look at the values passed in (and it looks like this is safe for batches, like combined emails). Thus a citation format flag would be fairly easily coded into the templates, provided we are willing to break old templates to do so.

I would recommend on that front that we pick a limited set of citation formats (the most common ones, probably) and create secondary print/email links for the extra ones. Using a similar trick to the Add to My List stuff we can get a popup menu with all the supported citation formats fairly easily without using too much extra space.

Note that we do *not* have access to all of the bib helpers that TPac has access to while we are in the A/T layer (despite using the same basic syntax as TPac templates) so we would either need to write new versions of the ones we need or do things without them.

Re: Printing from the Catalog


Thanks, Elizabeth for the concise summary. That's exactly what I was getting at. Yes, the Boston Globe, EBSCO, and several of the other common databases our patrons frequently use have some way of allowing the user to print relevant information in either brief or full formats.

For the catalog, the most common use case would be a patron who selects several items during a catalog search, say a bunch of books on the Holocaust. Some are fiction, some nonfiction, some adult, some YA.  They then want to print out a quick list to take to the shelf to retrieve the items. It's essentially like creating a pull list, and although it would be nice to have more sophisticated control over the formatting, the most crucial element is the call number. It would depend on whether a patron wanted only the local call number, or all the call numbers systemwide (which seems less likely), but as you mention, at this point they have no option other than SMS or writing by hand. Our old Millennium system had a rudimentary way to select brief or full record printing, although it was pretty bad.

Another use case would be a staff member who wants to print a list of records for a patron. For example, a patron wants a list of all of our Louise Penny titles, not audio, but hardcovers, paperbacks, and large print. She just wants a list of what we own with the call numbers so she can hang onto it and use it for reference when she comes in to browse. As it stands, there is no easy way for us to print that out. Staff would certainly have more options available (buckets, e.g.) than a patron would, but even staff should not need to be doing that much work for a quick list that can be created on the fly in the OPAC.

Exporting the data via CSV is simply not practical for most libraries. First, the majority of patrons (indeed many library staff as well) would have no idea what that was. Second, many libraries have catalog workstations that would not have the necessary software accessible to allow a patron to export and use CSV, and third, it really shouldn't be necessary to export a CSV file and manipulate it in Excel just to get a list of a few call numbers. That should really be part of the interface somehow.

Re: Printing from the Catalog


We included this idea in our March 2014 RFP, but did not receive any quotes. One potential vendor indicated that this would be a large-scale project. I am investigating it further to see if we can investigate implementing it in smaller steps.

Re: Printing from the Catalog


I have moved this idea to Planned development. We have contrated with Equinox to create technical specifications for this project.