Let me describe ArticLib. It is a vision to share printed articles without much overhead and save paper and printer toner in the long term.
As the first idea to go into my new post category Ideas for things, it deserves to be noted that I sometimes have brilliant ideas that turn out to be not so original. I thought of and made notes about, for example, a thing that I called PocketBrain, a personal knowledge base that memorises things and helps you think as a true personal digital assistent, but then read about the Memex.
So, the idea described in this post may turn out to exist already — in fact, I wouldn’t be surprised if it did. Anyway, here goes.
Problem
In small to medium-sized offices, (academic) libraries, schools and other environments, people print stories, reference documents, research articles and other materials that do not lose their value immediately. I too print research articles, standards and reference documentation and I don’t need them all the time. Others may need the same things some other time, so why not share?
Sure, but printing an extra copy is easier than finding out I already have one, finding me (we have flex desks), disturbing me in my work to ask for the document and having me fetch it from the locker that I keep currently unneeded papers in. Besides, I may still be using it, so that my colleague needs to print after all. That’s what is already happening when nobody knows what papers I have.
Solution
In short: a paper document library (in the borrow, read, return sense) that works like a printer (in the send to printer, pick-up sense). Basic operation is just as simple: if you print something that is already in the library, you get the existing copy. If it is not available (because all copies are in use, or it wasn’t printed before) you get a fresh copy. I envision it to be a machine that is not too different from a printer on the output side (i.e. it deposits the document you ask for in a tray) and has an input that takes in document by document to store for retrieval. To make this work, some technical requirements come into play.
Determining what is in the library
Documents in the library should not be printed again – that saves the paper and toner. Libraries work with catalogues to keep track of inventory; the catalogues contain metadata to identify the holdings. The ArticLib will need to keep track of some metadata too — I don’t know yet what combination of descriptive metadata will do the trick. Just DOI or originating URL may work for scientific PDFs or very static files like standards, but dynamic working documents or blog posts that get minor corrections after a while would need to be recognised as different from the in-library version. On the other hand, a pre-print and final published version of an academic article may be interchangeable from a user’s perspective. Ideally a central catalogue can be used (a digital asset or content management system, maybe?) to check documents against, including checksums of contents to see what changed.
Checking out and taking in documents
People can be, and archivists and librarians are, good at storing and retrieving paper in ways that make the process manageable. But in a small office whose paper document library grows very slowly having a person handle the library contents would not make sense — there’s too little work for a full-time employee, but you can’t make it someone else’s side job either. Besides, interaction with a librarian to get a document is very different from walking to a printer to pick up a stack of papers. So we need a machine to handle the paper.
Handling the paper requires taking each used document in, recognising what it is, storing it in a physical place in a way that allows retrieval and retrieving it when someone sends it to the printer. Taking in documents means accepting a stack of papers that may have been stapled or otherwise bound together. Recognition may just be comparing a scan of the first (/front) page to stored front pages, or scan a barcode or QR code. The former requires that ArticLib knows what each document’s front page looks like (needs more storage), the latter needs an extra front page with the metadata and barcode/QR-code (needs more paper) or printing such a code in a small whitespace on the first page of the document (needs smart programming and space on the front page).
How to handle stacks of paper as documents, i.e. how do we keep documents together? What archivists do: they put documents in standardised containers. My first thought was to have each document come out of the ArticLib in a container too — a folder perhaps, that could also serve to carry the QR-code and metadata. But they have plenty drawbacks: extra costs, hassles, and users need to keep the paper and folder together or things will get lost. The extra front page or QR-code-in-whitespace are preferred.
Ideally, the users keep the stack of papers together and tidy while in use to enable later use. Staples are common, but using clips or keeping it in a presentation folder is also an option. The ArticLib can take in stacks stapled or unstapled, because on the back end, both the storage unit and the robot arm putting documents in and taking documents out can keep stacks together but separated from one another. Since this is only an idea, I allow myself to say testing is needed to determine the most efficient storage layout and handling procedures.
Software: printer driver
On the software side only a minor change is needed from the users’ point of view: their printer driver needs to be replaced by one for ArticLib. The software in ArticLib determines whether the document in a print job already exists in the library and forwards the job to a printer when it doesn’t.
The software could indicate whether a document is already available on paper when a user is doubting whether to print it, but this goes against the non-intrusive nature of the design.
Social requirements
ArticLib should not require completely differnt behaviour from people in the office. The only part of the cycle that is different is the part after the user takes a document out: treat the paper better for durability, and returning the paper to the machine after use.
Summing up
I had an idea for a machine that mostly acts like a printer, but comes with a library for used documents. It’s designed to not interfere with current printer use at the office, or libraries, or wherever, and just save money on paper and printer toner. I wouldn’t be surprised when it turns out to already exist in some form or another. If you have ideas to make it better, know of an existing solution, or think this will never work, please leave a comment. If you’re thinking of making money off this idea, get in touch.