Inventory (UXPROD-785)

[UXPROD-1316] Format and print of spine labels Created: 08/Nov/18  Updated: 08/Aug/23

Status: In Refinement
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Inventory

Type: New Feature Priority: P2
Reporter: Charlotte Whitt Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: Honeysuckle-2020-spillover, call_number, cap-mvp, metadatamanagement, po-mvp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File Skärmavbild 2020-07-24 kl. 09.59.13.png     PNG File Skærmbillede 2020-02-03 kl. 21.47.04.png     Microsoft Word TAMU Spine Label Printing.doc     PNG File image (9).png    
Issue links:
Defines
is defined by UIIN-1183 SPIKE. Review ExLibris/SpineOMatic's ... Open
is defined by UIIN-1221 Connect UChicago's Spine Label Progra... Draft
is defined by UIIN-1182 SPIKE. Review UChicago's Spine Label ... Blocked
Relates
relates to UIIN-220 Item record. Print of spine label Draft
relates to UIIN-1167 Settings. Inventory > General > Spine... Draft
relates to UIIN-1168 Settings. Inventory > General > Spine... Draft
Potential Workaround: HK - Workaround, I've seen libraries switched to materials pre-processed from the jobber and resort to MS Word or some other tools for the few items that can't be purchased in that manner. But if library gets the majority of it's physical items from a soource that can't provide this?
Release: Not Scheduled
Epic Link: Inventory
Analysis Estimate: Small < 3 days
Analysis Estimator: Charlotte Whitt
Front End Estimate: XL < 15 days
Front End Estimator: Niels Erik Nielsen
Front-End Confidence factor: Medium
Back End Estimate: Medium < 5 days
Back End Estimator: Niels Erik Nielsen
Development Team: None
PO Rank: 129
PO Ranking Note: CW: This is a Go live requirement from all libraries except Chalmers and Lehigh. Aligned the PO ranking with the Calculated Total ranking.
Cap Plan Fix Version (DO NOT CHANGE): R2 2021
Rank: Chalmers (Impl Aut 2019): R5
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R3
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R1
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R2
Rank: Grand Valley (Full Sum 2021): R4
Rank: hbz (TBD): R1
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R3
Rank: Leipzig (Full TBD): R1
Rank: MI State-Lib of MI (Sum 2021): R2
Rank: MO State (MVP June 2020): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R1

 Description   

Purpose:
Definition: A Spine label is a small typed or printed label affixed to the lower spine of a book or other bibliographic item at the time it is received and being processed, getting ready for circulation. The spine label is displaying the location symbol and call number, for use in re-shelving and to assist the user in retrieving the item from the shelf once the call number has been found in the library catalog. The printed label is typical printed on a special printer for labels, e.g. XXX or by using a special print application, e.g. SpineOMatic which is a Windows application.

Overview: The system will need to have a way to take call number info, location info, and possibly other parameters, and generate spine label print files in the format the library needs, and then send that print file to a printer. This will be covered in Inventory. Usually libraries don't store the formatted spine label data in their database, just the underlying data that is used to format the spine label, E.g. GOBI does a lot of formatting for shelfready customers.

To do: Capture the need to be able to format and print spine labels from FOLIO cataloging records:
Following task/requirements is needed:

  1. define what data do we need to capture to produce the spine label
    • exactly how the call number should be stacked
    • whether leading decimals are removed in 1st Cutters for LC/NLM numbers
    • how any prefixes or suffixes are determined and formatted (all caps, space before or after the call number)
    • whether those prefixes/suffixes are location based, or based on something else (e.g. oversized or format designations)
    • whether copy numbers are required - hopefully not
    • how volume/enumeration is handled for items in sets and serials
  2. configure the label (text and size) on the Settings page: Settings > Inventory > Label printing
  3. configure the output format of the label on Settings page: Settings > Inventory > Label printing
  4. interaction with a configurable third-party print solutions and send a file as input to that third-party solution

Documentation:



 Comments   
Comment by Cate Boerema (Inactive) [ 29/Jul/19 ]

Hi Charlotte Whitt can you please give this a PO rank?

Comment by Cate Boerema (Inactive) [ 19/Sep/19 ]

Charlotte Whitt this is assigned to Core Functional for cap-mvp. Do you expect it to be dev-ready soon?

Comment by Cate Boerema (Inactive) [ 23/Sep/19 ]

Charlotte Whitt and lew235 do you expect the data to be displayed in the spine label to be the same as what's being discussed for call number block? Based on my reading of the above description, it sounds like they will be different (as spine labels need to display location, for example).

Does spine label data need to be configurable? If so, this might be best implemented similar to staff slip with the ability to add tokens. Thoughts?

Comment by Cate Boerema (Inactive) [ 14/Jul/20 ]

Current thinking is that FOLIO can integrate with Chicago's spine label tool which alleviates the need to build a FOLIO-native spine label feature for MVP. Given that, per cap planning group discussion, I am removing the Q3 fix version from this feature.

Charlotte Whitt, I think you wanted to do a spike to have CF think about what it would take to rebuild the Chicago tool in FOLIO. Happy to bring that spike into a sprint this quarter.

Comment by Charlotte Whitt [ 14/Jul/20 ]

That spike is already written and linked to this issue - please see: UIIN-1182 Blocked , Cate Boerema

Comment by Cate Boerema (Inactive) [ 14/Jul/20 ]

Perfect. Thanks Charlotte Whitt. I assigned it to Core Functional so it will appear in our backlog. Let's bring it up in an upcoming grooming meeting.

Comment by Charlotte Whitt [ 14/Jul/20 ]

Sounds good

Comment by patty.wanninger [ 22/Jul/20 ]

Voyager libraries might be using VGER Spine, a program created by Gary Strawn at Northwestern. UA depends heavily upon it. Maybe add to the list of 3rd party products that can be adapted. https://library.queensu.ca/techserv/cat/Sect09/vgerspin.html

Comment by Jenn Colt [ 22/Jul/20 ]

Hi Patty- that's what Cornell uses as well. We've documented this a few times.

Comment by Charlotte Whitt [ 24/Jul/20 ]

Hi patty.wanninger and Jenn Colt - connection with Gary Strawn's tool is already listed under phase 3. Thanks for the feedback, that shows that we're on the right path for what we'd like to implement long term :

Comment by Jenn Colt [ 27/Aug/20 ]

Is there an estimate of when phase 2 or phase 3 would happen?

Comment by Cate Boerema (Inactive) [ 12/Oct/20 ]

Charlotte Whitt, should this feature be marked complete?

Comment by Charlotte Whitt [ 12/Oct/20 ]

Hi Cate Boerema - No the work is not complete, and we'll have to continue the work with release in Iris. I'll split the feature, when I get an update on what work we need to continue work on, wrap up, etc.

Cc: Jon Miller

Comment by Cate Boerema (Inactive) [ 12/Oct/20 ]

Is anything going to be released as part of Honeysuckle? If not, you can just mark this as a spillover, rather than splitting.

Comment by Ann-Marie Breaux (Inactive) [ 23/Nov/20 ]

Hi Charlotte Whitt This says R1 2021. I'm assuming this is for Part 1 of the work, connecting to the Chicago tool. Do we expect that will be done in R1 and that other libraries will be able to use the Chicago tool as well?

cc: Anya patty.wanninger Molly Driscoll Kyle Banerjee

Comment by jackie.gottlieb@duke.edu (Inactive) [ 22/Apr/21 ]

Charlotte Whitt, I am working on Permissions at Duke and am not finding mention on how spine label permissions will work. Is there a plan to have a dedicated Settings > Inventory > Label printing permission or is it due to be part of existing permissions? I see it is planned to be completed for Juniper. In the coming month or so, can there be a demo/update on spine label printing AND ABLE Bindery (https://folio-org.atlassian.net/browse/UXPROD-2800) in MMSIG (lew235). This is one of those very important features that hasn't had much focus on it --at least not that I have seen. Thanks.

Comment by Charlotte Whitt [ 11/May/21 ]

jackie.gottlieb@duke.edu - yes this work is one of features in high risk for not making it into R2 2021, due to too few available developer resources.

Tod Olson Mike Gorrell and I have talked about status of the work, and what we can do/can not do in the current situation, and we will circle back to this again on Wednesday.

CC: lew235

Comment by Charlotte Whitt [ 17/May/21 ]

Status as of May 13, 2021:

Mike Gorrell 7:58 PM
@charlotte Jon Miller has finished Spine Label Printing app for UC's needs - but hasn't done any templating work that would allow others to (easily) use it. And he won't have time until July/August to turn back to that.

Comment by Jenn Colt [ 17/May/21 ]

I just updated Cornell's ranking to reflect that we are implementing SpineOMatic for now.

Comment by Erin Nettifee [ 17/May/21 ]

Hi Jenn Colt - I've never heard of SpineOMatic, interesting - is it open source? I can see the code in GitHub that specifies working with Alma. Did y'all modify the code to make a FOLIO version?

Comment by Jenn Colt [ 17/May/21 ]

Hi Erin Nettifee no, Nick Cappadona wrote middleware to turn the FOLIO json into XML spineomatic would understand and then we are using the built it SOM config.

 

And, yes! OSS: https://developers.exlibrisgroup.com/blog/SpineOMatic-Label-Printing-Software-for-Alma/

https://github.com/ExLibrisGroup/SpineOMatic

Comment by Erin Nettifee [ 17/May/21 ]

Oh, cool! It would be great if you all could share that middleware code when you're able to. I'm sure others will find it useful, esp. in terms of planning for this year and next...

Comment by Nick Cappadona [ 21/Oct/21 ]

Here's the repo for our middleware API that transforms the Okapi JSON response from /inventory/items to XML ready to be consumed by SpineOMatic.

https://github.com/cul-it/setae-api

Comment by patty.wanninger [ 21/Oct/21 ]

Thanks, Nick Cappadona!

Comment by Molly Driscoll [ 03/Dec/21 ]

Charlotte Whitt is there an anticipated release for this feature on the roadmap?

Comment by wtf [ 03/Dec/21 ]

We planned to use Nick's work for our label printing, but a web developer with us whipped this up: https://github.com/mtsu-walkerlib/folio-spineomatic just before Nick's repo was available.

Comment by Molly Driscoll [ 08/Dec/21 ]

Awesome; thanks for sharing, wtf!

Comment by Molly Driscoll [ 22/Apr/22 ]

Charlotte Whitt just wondering if there are any updates on the development timing for this feature. While there is awareness and gratitude for the other solutions offered here, I've gotten this question quite a few times in recent weeks. Thanks for any insight you can provide!

 

Comment by Charlotte Whitt [ 03/May/22 ]

Hi Molly Driscoll - no this work has not been scheduled, and no development team appointed. So no new progress to report here. Maybe the Capacity Planning Team can find someone who will pick up the task.

Comment by Molly Driscoll [ 05/May/22 ]

Thank you for the update, Charlotte Whitt!

Comment by Molly Driscoll [ 22/Jun/22 ]

Khalilah Gambrell & Hkaplanian I've had several libraries ask me about a native solution for spine labels in FOLIO - most recently Holy Family University in PA. Do we know where this falls on a roadmap?

Comment by Sarah Johnson [ 06/Apr/23 ]

Khalilah Gambrell & Charlotte Whitt I have recently had several libraries ask about generating spine labels in FOLIO. This includes Notre Dame Law Library and Douglas College. Can you share any updates on this?

Generated at Fri Feb 09 00:14:33 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.