Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Discussion items

ItemWhoNotes
Minute taker?

Announcements/Updates

Highlights from that meeting:

  • Google Season of Docs technical writing application accepted
  • Update from Anton about QA
  • Code of Conduct endorsement

Hoping to have Emma Boettcher join next week's meeting to review Item States

Continued Receiving discussion

Receiving discussion - review updates to Receiving App, review connections between Receiving App and Inventory, and Receiving for packages

Receiving examples:

  • Levant Pack
  • American Political Science Association Membership
  • See notes 2020-03-13

Relevant Issues

  • UXPROD-2373: Allow for the display of piece information on Holding records in inventory
  • UXPROD-1608: Holdings record, Accordion Receiving history
  • minutes of App Interaction SIG 2020-04-08

Charlotte Whitt guided the group through Inventory to show what currently displays 

  • Receiving History displays Enumeration and Chronology
  • Switch to edit mode to see this:

Image Modified

Data from the receiving app is intended to populate this

Dennis:  Small Group discussed what info should display, but the question remains - what of the piece information do you edit from the holding record itself?

CW:  This is empty shells we added while waiting for integration with the Receiving app.  We need to discuss the mechanics of how to get the data.

Dennis:  Maybe it doesn't make sense to store the info on the holding record.  Do we need to be able to edit from the Holding record?

CW:  The beauty would be if the data were maintained in the Receiving app, but it populated here (not just a link back) so that you don't have to jump between apps.  Would like to see the same "connected" functionality that's available elsewhere, such as in the Preceding and Succeeding Titles sections.

Dennis Are there situations where there wouldn't be a receiving record and you'd need to add a holding.  

Owen Stephens: What about for historic data? 

Sara: Gifts in a series - not part of receiving process .  What about standing orders? 

Virginia  At Duke we create for serials standing orders but not for monographic sets standing orders. Much of our info goes into order notes because we don't have a better place for it when we don't receive those types of orders.  Dennis - and you wouldn't want to create an item

For a monographic series or set you might have the record you have your order on, but you won't have an inventory item for the series .  Would have an order for a series you catalog the item but not the series.  Monographic volumes meet orders for serials and sets.

Sarah - you have a series title and your standing order is tied to that.  But the volumes are so distinct they stand on their own and the items live on their own with their title, contents, etc.  Containers 

Vriginia: Duke used to maintain all of the holdings info at both the series and item level, but stopped that double maintenance due to staffing.  Gets complex due to the way things are acquired and it makes it difficult to know where to store certain information during receiving since that is about the series and the individual items.

CW:  What did the small group identify?

Dennis:  Went through each data point on the piece.  The assumption was that if data appears on the holding then it's something that's been received.  It would need to be received first.  Based on that assumption there is a lot of info that doesn't need to be displayed in inventory such as received date, PO Line,  Edge case: you might want the next upcoming thing to display if its a series of things.  

  • Caption 
  • Comments from the piece 
  • Location of the piece 
  1. Stage one: getting info to the holding
  2. Stage two: deciding what displays publicly

CW:  Sounds like if the data is going to be shown in public needs to be defined at the data element level.  Theuse case for showing the next expected volume would be for a patron to put in a request for a piece that hasn't arrive yet.

Virginia:  Or to display that something is on order or is expected to come in.

Dennis:  That would likely be a separate feature to display expected pieces

Virginia: Aren't most of us doing that manually - you get a volume in that's a serial and you pay the invoice and then you add the serial volume to the holdings record. 

Kristin Martin:  If a piece comes in that gets an item record (standing record) she believes the item record for the analytic libves on the series record.  The dummy record points to it.  The challenge here is that this is hard even for us to understand.  Analytics are complicated and different institutions handle them differently.  For most of us we are manually adding the item and updating the holdings.  Don't think we need an automated solution for this.


Sara: We don't update the holding unless its non-predictive - if the sequence gets broken.  You indicate volume 1-96 and only indicate breaks.  Done manually.  Some come very much out of sequence and we don't 

From Marie Widigson to Everyone: 08:47 AM
Exactly what I thought
From Scott Stangroom to Everyone: 08:48 AM
We do at UMass S/O check in
From Scott Stangroom to Everyone: 09:01 AM
Yes, for non-predictive journal check-in, we do manual holdings updates.
From Thoele, Heather M to Everyone: 09:03 AM
Plus 1 for what Scott said

From Scott Stangroom to Everyone: 09:05 AM
You would only show gaps - v.1-45; v.52-90 is a manual thang

Kristin:  Have a lot of print journal subscriptions and its not a growing area - the current situation will only accelerate the transition to online.  The standing order analytics are very complicated, so its hard to define an automated workflow without defining the 15 variations.  Would be hard to define a pattern to be used in the majority of cases due to complexities and exceptions.  

Virginia:  We use marc holdings.  Is there a place to put staff notes about routing.?  We have traveling serials - a volume arrives and it gets sent to the main library and the prior issue gets set to remote storage.

CW - we have holdings notes which are maintained in settings to define different types of notes and can define whether it should display internally or not.

From Scott Stangroom to Everyone: 09:10 AM
mmmmmm…nooootes (said in a Homer Simpson voice)

From Virginia Martin to Everyone: 09:10 AM
:D love them notes!

Sara - Revisit discussion from above - do we need to define for each data element whether it displays publicly?  Might want to display the latest. 

CW The holdings statement is where that would be stored.  Sounds good

Kristin:  The current layout mirrors what we have now.

Viriginia:  Having a link is sufficient.

Dennis:  You will have a toggle to define whether the holding it should be public displayed or not.  Do we need to add that capability on the receiving side to indicate public display?

Kristin - yes that's what we have now

CW Where should the link back to receiving history be?  In the detail view there would be a link back to the receiving record to see more detailed data?  Dennis - it would take you back to the receiving title and you would have your list of received pieces there.  Maybe we could pop up the piece modal for the piece you indicated or you could land at the title level.  It would be more complicated to display the piece.

Virginia - would prefer to go to title level to see the whole thing - usually problem solving so want more info

Sara:  Yes, also would prefer to ber taken to the title level rather than pulling up the piece.  Often you're scrolling through and want to see how prior things looked for that series title.

Virginia: Will there be user ids on who is receiving things in the system?  We divide this work between 5 or 6 staff and want to know which person received it?

CW:  In Inventory you can see who updated the record last time.  

Julie:  But would last update date give you the history

Martina S.: Would need to be optional since we're not allowed to track or display that information

Dennis:  Is that a law?

Martina . Yes, it was in place even before GDPR

CW:  If you need to capture the last update user ID and date for each piece it would make sense to add it here.  

Image Added

Virginia: This is a nice to have - not a go live requirement.


Action items

  •