Duplication on Demand: What works best for you?

We designed KLAS' Patron Centric Cartridge functionality to provide library staff with the ability to quickly select and reproduce a specific set of books onto a cartridge for a specific patron.

While this works well for many libraries, we know this is not the best option for ALL organizations. In fact, we identified at least three different workflow options in our the "Duplication on Demand: What works best for you?" Key Notes blog post .

We need your input as we move forward with creating additional duplication-on-demand functionality within KLAS to questions such as:

1. Do any of these workflow options appeal to your organization and how it operates more than another?
2. What considerations do you think need to be made for each?
3. What specific challenges and / or benefits do you think you may see from operating under each?

In connections with Drea's question 2, something that has come up in our discussions here is the matter of cartridge labels.

Scenario 1, with each cartridge paired to a specific patron, allows cartridges to be labeled with that patron's name. However, that may not scale as more patrons are served using PCC (especially those patrons that like to come and go frequently, or who will only be on the service for a short time).

How important is cartridge labeling to your patrons? What is the value of having patron-specific information on the cartridge label, vs having generic PCC labels?

Option 2 ("cartridges that are loaded with titles based on a single patron's preferences but are not tied to one in particular. Rather, whichever cartridge is available at the time is loaded with the patron's books") would be ideal for our situation, especially as we look forward to scaling up our duplication-on-demand services to service a large number of our patrons. As Patrick20k mentioned, this would free up the cartridges to be usable as often as possible, which is an important consideration when we look at the difficulties involved in procuring cartridges, labels, and containers. Under Option 1, patrons who are short-term or vary in their active status would lead to either a "dead" cartridges that sit labelled and unused, or lead to staff having to make the a judgement call on whether to transfer the cartridge to another patron (and the need to print a new cartridge label for it, which again, are difficult to procure and should not be wasted).

Option 3 ("cartridges loaded according to inventory") would have a niche but still valuable application for serving monthly book clubs (when we would 30+ copies of a single title) or to load with seasonal titles (everyone wants Christmas stories around Christmas).

1. A single cartridge tied to a single patron which is reloaded with books for that patron each time it is returned.
MM: We finally got this PCC service working using green cartridges we purchased from Northstar as we, like many other libraries, have had nightmares getting the freely provided by NLS peach cartridges to work with PCC. Customizeable cartridges by patron is a great way to go, and we'd like to see KLAS keep this option in addition to providing option 2 (see below). We are firmly convinced that the Scribe or "KLAS DOD Machine" independent of NLS is a counterproductive miscalculation despite the amazing efforts of James and Craig to invent it. Perhaps they can find another use for the Scribe unrelated to the idea of a KLAS/NLS API strategy using NLS furnished duploication equipment.

2.Cartridges that are loaded with titles based on a single patron's preferences but are not tied to one in particular. Rather, whichever cartridge is available at the time is loaded with the patron's books.
MM: This is the NLS model currently being rolled out with Web READS and is what NLS has designed, a free Duplication Station that they will offer to all network libraries for $0 (absolutely free) within 6-9 months. Therefore, it is only logical that KLAS would work directly with NLS so that KLAS software can communicate directly with the NLS Linnux based stand alone duplicator NLS will be distributing for FREE soon. . In other words, duplication on demand not tied to specific patrons is the NLS strategy, so why not adopt it and make it easy on all of us


3.Cartridges loaded according to inventory (Examples: The Harry Potter Series, Nonfiction titles added in the last 30 days, 1 year of Southern Living)

MM: We already do this anyway and I'm sure we'll continue the practice.

Some questions we have as we prepare to move forward with providing additional duplication-on-demand functionality within KLAS are:
1.Do any of these options appeal to your organization and how it operates more than another?

MM: We want both PCC and DOD using equipment provided by NLS.

2.What considerations do you think need to be made for each?

MM: Others have weighed in on this and there are obviously pros and cons for each. Once again, give us both.

3.What specific challenges and / or benefits do you think you may see from operating under each?

MM: Challenges are the lag time for KLAS to make a decision and for NLS to finish the WEB READS pilot and pivot to KLAS libraries. The latter will happen. Not so sure about the former.

p.s. The opinions expressed here are my own or those of my CA1A staff and do not necessarily reflect the opinions of other network libraries.

1. I prefer scenario 2 for the reasons previously stated especially the fact that it is NLS supported in multiple ways including the supply of cartridges and labels.
2. I do not think labeling will be an issue as some patrons are already getting magazines with generic labels. It will also eliminate the problem of the wrong cartridge in the wrong case.
3. I do think we would use both scenarios 1 & 2.

Mike--

I want to thank you for your post, and the questions you raised. We've been asking for questions, asking for feedback, and your post certainly provided both, so thank you very much. I'd have liked to answer sooner, and plan to answer even more completely later, but right now I need to get the ball rolling.

First of all, let me make it clear--- we will be adding support for Gutenberg from KLAS. Time will tell if Scribe has any purpose beyond being a valuable testbed for our duplication efforts, but we have certainly heard loud and clear that you all want us to integrate KLAS with Gutenberg.

However, in order to be able to do this, there are some foundational parts that must be in place first. The biggest and most important of them is what we are calling the "Duplication Queue". The Duplication Queue is just what the name implies-- a prioritized list of titles to be duplicated to cartridges. We are adding to the nightly routines to make sure every patron's Duplication Queue is automatically filled with books that the patron would want. This automatic selection will function with similar rules as the current nightly auto-select to allow KLAS to pick books to be added to the duplication queue, but with a few very important differences from what nightly currently does.

1. The duplication queue will be books that the system has selected in advance
   • the system re-fills the queue the night after a patron receives a duplicated cartridge
   • Once titles are on a patron's duplication queue, entries can be added, re-prioritized, or deleted whenever you want. This will allow the RA's (or the patron themselves) to modify the items queue as they want--- like you can adjust the items in your NetFlix wishlist
2. The selection of items in the duplication queue will be based on the full BARD collection, not just the titles you have available in inventory (which is how the current nightly programs operate)
   • We are basically needing to create a process very similar to our nightly selection routines, but with some significant differences. The two processes are having to be somewhat aware of each other, and make sure they don't step on each other's toes. (for a simple example, if a patron returns a cartridge and is now due for service, we don't want both systems sending both a book from inventory/turnaround as well as a cartridge from Duplication on Demand.) Weaving these systems around each other is the cause of much of the difficulty in the Duplication Queue.

Having the automated selection of books for the duplication queue is a huge step. It takes away the current need to manually click the "Serve Patron" button, and pick the books that will be written to a cartridge. Having a manual step to select books would severely hamper the ability for Duplication on Demand to scale to support a collection-free workflow.

I realize that the Scribe feels like it's counterproductive, but it's really not. The software on the Scribe itself is remarkably simple. It's the Duplication Queue, and the automatic filling of the queue that's taken months and months of effort. (As a matter of fact, the software driving the Scribe is complete except for final tweaking to make sure it's tied in with the KLAS Duplication Queue properly.)

Once we have completed the Duplication Queue, then choosing what system you use to actually write the cartridges will be up to you. I expect that most libraries will choose Gutenberg. It's an amazing opportunity that NLS is offering to all the network libraries. Who wouldn't take advantage of the offer of a free computer, and NLS taking on the responsibility of providing and supporting your mailing card printer??

There are lots of questions that we need to answer. We'll be providing more details as soon as we can.
Mike-- Hopefully in the next day or so, I'll be able to at least answer some more of the questions you pose in your message.

Stay tuned.

--James--
James Burts
Executive Vice President
Keystone Systems, Inc.

James, thanks so much for your articulate response and rationale for how you are proceeding in regard to the NLS DOD model. I look forward to your next post addressing my and others' questions. Have a nice weekend.

James:
It occurs to me that the DOD discussion may prove relatively focused with reasonably prompt response (e.g. a work day or two), if comments are concise and limited to a few questions per post. With that approach in mind, I am wondering how many weeks or months you would expect the full development and execution of the "Duplication Queue" in relation to KLAS/Gutenberg to take. Also, do you know how WebReads has been handling its own "Duplication Queue" type concern?