JOURNAL CHECK-IN WITHOUT THE FUSS MAKING A SINGLE TASK ORIENTED APPLICATION by Kasper Løvschall
ABOUT ME Civil engineer and self-taught developer Working since 1998 in a research library First as a development consultant and subject specialist (physics and energy technology) as well as subject coordinator of the STM area Today mostly in library IT with a pretty solid understanding of the internals of our business We are three people at the library working with library IT as our main focus (university IT is centralised)
FINAL THOUGHTS This project has been a success … really! Get your in-house competences into play Use your domain knowledge – it is where you shine! You must build on top of your competences from project to project You will have to take some chances Agility is also knowing when to quit, rethink, and EXIT You will probably never know the service life of your product – cope with it! Reclaim library IT
ABOUT JOURNAL ISSUE CHECK-IN Journals or periodicals are typically publications published in a regular schedule
ABOUT JOURNAL ISSUE CHECK-IN The “volume” typically refers to the number of years the publication has been circulated E.g. if a journal began its publications in 2010 it would be at volume 7 as of 2016
ABOUT JOURNAL ISSUE CHECK-IN And “issue” typically refers to how many issues this journal has been published during that year (volume) Weekly for Donald Duck (52 issues) Biweekly, monthly, quarterly, yearly, etc. for others First item of a volume would then be issue 1
ABOUT JOURNAL ISSUE CHECK-IN Many libraries use a subscription agent It acts as a intermediary between library and publisher “A kind of a PO Box” … with additional services
ABOUT JOURNAL ISSUE CHECK-IN When an issue arrives at a library it has to be checked-in to the ILS It is typically identified to the user by the year, volume and issue It is then set as available in the catalogue Check-in can include cataloguing and barcode labelling etc. It is now ready for circulation (if allowed)
ABOUT JOURNAL ISSUE CHECK-IN A “publication pattern” represents the publishing behaviour of a journal within a given year It can be used in an ILS to prepopulate which issues will arrive at the library and approximately when Borrowers can place a request on an item ahead of publication (if allowed) Some libraries use it, others don’t
A BRIEF HISTORY OF BARCODE LABELS
Barcodes straight from a roll of preprinted labels
Swets then became our subscription agent
And … Swets went out of business
LM Information Delivery became our new subscription agent and subcontracted the barcode labelling to another small, Danish company
As of January 1st subcontractor cancelled the contract and it all looked as if we were going straight back to this…
SOLUTIONS TO THE PROBLEM 1.Changing our subscription agent 2.Going back to the old work flow of manually labelling and checking-in issues into the library system It is time consuming and resources are sparse But … it has a proven track record of success 3.Try to come up with a technical solution that could at least offload some of the work Does have a bit of uncertainties when it comes to: can it be done, will it work, and how long will it take? But … you can take up solution two until three is ready…
WE CHOSE SOLUTION 3 And today with the help of nuKardex barcode labels look like this
MAKING A SINGLE TASK ORIENTED APPLICATION We can get our “library development stack” into play We can fully focus on a single task (journal check-in) We can aim at getting the workflow as smooth as possible We can get a “one-size fits one only” solution
SO… WHICH ELEMENTS DID WE HAVE IN OUR “STACK”? A web browser
SO… WHICH ELEMENTS DID WE HAVE IN OUR “STACK”? A barcode label writer with a JavaScript API
SO… WHICH ELEMENTS DID WE HAVE IN OUR “STACK”? A library system with a RESTful API
SO… WHICH ELEMENTS DID WE HAVE IN OUR “STACK”? Experience with a web application framework (server side) Experience with library client-server development in Perl
SO… WHICH ELEMENTS DID WE HAVE IN OUR “STACK”? Experience with a responsive HTML, CSS, JS framework based on Bootstrap (client side)
SO… WHICH ELEMENTS DID WE HAVE IN OUR “STACK”? Experience with the JavaScript library jQuery (client side)
SO… WHICH ELEMENTS DID WE HAVE IN OUR “STACK”? A previous web app designed for check- in use from LM Info
RETHINK THE WORKFLOW Agile is good …but it is great to have kind of an idea of where you are heading
RETHINK THE WORKFLOW So … We sat down “user” and “developer” to figure out What was the ideal solution and most optimal workflow for the user What was possible technology-wise How could we make it optimal for both parts How could the user interface design help the workflow
BRIDGING THE GAP Migrate our subscription list from LM Info And have some kind of subscription management feature
BRIDGING THE GAP Locating the correct journal title and selecting the right issue Barcode printing was a requirement
BRIDGING THE GAP Automatic check-in to the ILS Publication schedule was re-implemented and can be fetched via the ILS API (sorting out already checked-in issues)
BRIDGING THE GAP Automatic journal issue claims
BRIDGING THE GAP Reprint worn out barcodes
THE FINAL QUESTION How long did it take to build? Development did take a month or so – on and off
FINAL THOUGHTS This project has been a success … really! Get your in-house competences into play Use your domain knowledge – it is where you shine! You must build on top of your competences from project to project You will have to take some chances Agility is also knowing when to quit, rethink, and EXIT You will probably never know the service life of your product – cope with it! Reclaim library IT
THANK YOU