1. JOURNAL CHECK-IN WITHOUT THE FUSS MAKING A SINGLE TASK ORIENTED APPLICATION by Kasper Løvschall (kl@aub.aau.dk)

2. 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)

3. 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

4. ABOUT JOURNAL ISSUE CHECK-IN Journals or periodicals are typically publications published in a regular schedule

5. 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

6. 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

7. 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

8. 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)

9. 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

10. A BRIEF HISTORY OF BARCODE LABELS

11. Barcodes straight from a roll of preprinted labels

12. Swets then became our subscription agent

13. And … Swets went out of business

14. LM Information Delivery became our new subscription agent and subcontracted the barcode labelling to another small, Danish company

17. As of January 1st. 2016 subcontractor cancelled the contract and it all looked as if we were going straight back to this…

18. 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…

19. WE CHOSE SOLUTION 3 And today with the help of nuKardex barcode labels look like this

20. 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

21. SO… WHICH ELEMENTS DID WE HAVE IN OUR “STACK”? A web browser

22. SO… WHICH ELEMENTS DID WE HAVE IN OUR “STACK”? A barcode label writer with a JavaScript API

24. SO… WHICH ELEMENTS DID WE HAVE IN OUR “STACK”? A library system with a RESTful API

25. 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

26. SO… WHICH ELEMENTS DID WE HAVE IN OUR “STACK”? Experience with a responsive HTML, CSS, JS framework based on Bootstrap (client side)

27. SO… WHICH ELEMENTS DID WE HAVE IN OUR “STACK”? Experience with the JavaScript library jQuery (client side)

28. SO… WHICH ELEMENTS DID WE HAVE IN OUR “STACK”? A previous web app designed for check- in use from LM Info

29. RETHINK THE WORKFLOW Agile is good …but it is great to have kind of an idea of where you are heading

30. 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

31. BRIDGING THE GAP Migrate our subscription list from LM Info And have some kind of subscription management feature

32. BRIDGING THE GAP Locating the correct journal title and selecting the right issue Barcode printing was a requirement

33. 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)

35. BRIDGING THE GAP Automatic journal issue claims

36. BRIDGING THE GAP Reprint worn out barcodes

37. THE FINAL QUESTION How long did it take to build? Development did take a month or so – on and off https://commons.wikimedia.org/wiki/File:20090529_Great_Wall_8185.jpg

38. 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

39. THANK YOU