web client: Need ability to add volumes from the bib record

Bug #1502292 reported by Kathy Lussier on 2015-10-02
This bug affects 36 people
Affects Status Importance Assigned to Milestone

Bug Description

In the current client, most of our libraries are able to quickly add volumes/copies from the bib record by clicking the "Add Volumes" link from the record summary pane.

A similar option is not available in the web client. Instead, the user must go to Holdings View, click Action Items, and click to add volumes and copies. For staff that needs to perform these actions over and over again during a given day, the extra time to catalog each item adds up.

The cataloging workflow needs to be as streamlined as possible so that materials can be cataloged quickly and available for use by our users. The addition of any steps to this workflow will be a barrier to get staff buy-in to moving to the web client.

I would like to advocate for including a quick option to add volumes directly from the bib record. My suggestion is to add a button with the Add to Bucket and the Mark For: buttons (see screenshot.)

In order to get this option restored, we do need to hear from catalogers that it is important to their workflow. Please add your comments here if it is important to your workflow or let us know if there is any reason you think the option should not be included.

Thank you.

Kathy Lussier (klussier) wrote :
Mary Llewellyn (mllewell) wrote :

It is important to the workflow for the libraries at Bibliomation. We want to see the Add Volumes link in the Web Client, too.

Heidi Reed (hreed) wrote :

Not having the quick link would significantly impact my workflow and we are a small library, I do all the cataloging, so I would be wasting valuable time with those extra steps.

Chris Muller (cmuller) wrote :

Please keep the Add Volumes link!

Gary M Kendall (gkendall) wrote :

Yes!!!! Please keep the "add volumes" link!!! It much easier than having to click extra steps

Rogan Hamby (rogan-hamby) wrote :

I have to echo the above sentiments.

Manuel King (manuelking) wrote :

Please keep the "Add Volumes" link. Don't make our work more difficult by adding extra clicks. Thanks!

Holli Jayko (hjayko) wrote :

Please KEEP THE ADD VOLUMES LINK in the web version of Evergreen!

Beth DuPuis (bdupuis) wrote :

Oh please... I am begging! We need that add volume link in the bib record. I add A/V materials daily and that button should be gilded with gold. Without it I would be bogged down and unable to link as many items as I currently can get to between desk times.

Shirley Waite (swaite) wrote :

Not having an "Add Volumes" link would be a HUGE step backwards. Please include this link in the web version.

Lynn Floyd (lfloyd) wrote :

This is my here here, about adding this.

Charlene Deam (charlenedeam) wrote :

Please keep the Add Volumes Link.

Please don't make things more difficult, we need the "Add Volumes" link.

Sarah Childs (sarahc) wrote :

Yes, chiming in that retaining the Add Volumes link is important for workflow. Next to the Add to Bucket and Mark Record buttons makes sense to me, although people are used to it being next to the top where it says "Record Summary," so that seems like it would be fine also.

Kathy Pellerite (kpellerite) wrote :

In my opinion, software upgrades should be made with the intention of "improving" functionality for their intended users. Removing the "add volumes" link would introduce unwanted complexities to the cataloging workflow. Please keep this shortcut.

Beth Willis (willis-a) wrote :

The absence of the Add Volumes button is glaring. I think that the added clicks to create new volumes will significantly impact the workflows of our member libraries.

Susan Lucier (slucier) wrote :

Please keep the add volumes link. We are a small library and I do all the cataloging. The addition of extra steps to the cataloging process would significantly impact my work flow.

Changed in evergreen:
status: New → Incomplete
Kathy Lussier (klussier) on 2015-10-13
Changed in evergreen:
status: Incomplete → New
Susan Mulry (smulry) wrote :

Please prioritize the "add volumes" link. It is much more efficient to have the ability to click on the viable link. Reducing the number of steps to a click to get to the command for adding volumes equals additional productivity in all our workflows. Thank you for consideration!

Debbie Roy (daroy) wrote :

Please keep the add volumes link. Having this link helps to make our workflow more efficient.

Lynn Clermont (lclermont) wrote :

Please prioritize the "add volumes" link.

description: updated
Changed in evergreen:
assignee: nobody → Victoria Lewis (vlewis-q)
Grace Dunbar (gdunbar) wrote :

To be clear, the description of how volumes are added is written in such a way as to make it seem excessively more complicated than it actually is.

Here is a clear breakdown of how you add volumes in the XUL client:
Step 1 – Perform a search for the record; view results.
Step 2 – Select a specific record. You are brought to the record detail page.
Step 3 – Click on Add Volumes. A separate tab opens where you can add a volume/item.

Here is a clear breakdown of how you add volumes in the web client:
Step 1 – Perform a search for the record; view results.
Step 2 – Select a specific record. You are brought to the record detail page.
(In the web client, you are brought to a record detail page with 7 sub tabs (OPAC view, MARD Edit, MARC View, Monograph Parts, Holdings View, Conjoined Items). You can set (and change) which sub tab is your default. Holdings View is the recommended default for staff who predominantly add copies/volumes.)
Step 3 - Right click on the row you want and select Add Volumes and Copies from the context menu.
A separate tab opens where you can add a volume/item.

Step 3 for the web client does involve "an extra click" from the way the current interface is designed. However there are numerous places in this interfaces where options have been streamlined in a way that will save users clicks and present more useful information. I'd like for the community to consider the overall design rather than narrowing in on specific buttons/displays/actions that we've come to rely on. Feature parity is meant to ensure that no functionality will be lost, not that the workflow won't change.

I would like to point out that the available screen space in the web client is more limited that the XUL client. In asking people to consider overall design I am asking that people realize that there are no UI design guidelines or gurus in the Evergreen community. If every staff member who performs a common action gets enough of their peers to clamor for a link/button to be placed prominently on a screen there is no committee to say "no". And that's, in my opinion, a contributing factor in how the XUL client ended up with it's Frankenstein-ish appearance. I'm just stating for the record that this is a slippery design slope.

There are inherent differences in how software interfaces are designed depending on the platforms and delivery mechanisms they use. There are necessarily going to be design changes as we move from the XUL client to the web client. And just because the mechanism of accessing the tool or action has changed, that doesn't mean that the software is losing functionality... it just means it's different.

Kathy Lussier (klussier) wrote :

Thank you for the feedback Grace. I do understand that workflows can change while keeping functionality the same, and I do appreciate the effort the developers have gone to so far to streamline workflow in other places. In particular, I think workflow is much better for those libraries that frequently add multiple copies at one time. For our catalogers, they won't see the benefit of those improvements as much as others because we mostly have single libraries that are adding one copy at a time. But I think it's great that other libraries with different workflows will see some improvements here.

When we went through the steps for adding volumes, we both missed one key component. Before clicking to add the volumes to a record, catalogers must first make sure the record matches the item that is in their hand. This is why we DON'T recommend that our catalogers default to the holdings view. If they do so, they won't be able to see the ISBN to verify that it matches. They don't have the opportunity to look at page counts, which is also another factor they in verifying that the record is correct. In a large consortium where we have many, many folks adding copies, it is imperative that we encourage best practices such as this one to minimize mistakes.

I do agree that we need a style guide, especially now that the web client is so far along and we can see where particular problem points may be. As you know, I've done my best to try to bring UI expertise into this community. I'm willing to work with others to develop one, though I can't really take the lead. However, the fact is, we don't have one now, and we need to make decisions based on what fits into the design and also provides good workflow for our users. In suggesting a location for the button, I suggested a place where there are buttons performing similar functions. I understand that more buttons may be added to this area as we bring acq and serials into the mix. However, I still think we can make room for an "Add Volumes" action without turning the web client into Frankenstein. If not, I'm open to other suggestions.

I also want to point out that I was asked to get community input into this decision by filing this LP bug. Yes, much of the feedback has come from Massachusetts folks at both C/W MARS and NOBLE. But we also heard from people at Bibliomation, SC LENDS, and Indiana. It may not got high use everywhere, but its use is certainly widespread.

It looks like Victoria is willing to do the work, and I really hope we can get some consensus that whatever she comes up with can make it into the web client.

Mary Llewellyn (mllewell) wrote :

I want to echo what Kathy said about the default tab view. To default to the Holdings View is not a good option for the reasons Kathy cited. Our librarians need to see the bibliographic description to determine if the record is the correct one for adding their holdings. Ideally, having the link to Add Volumes/Copies from the OPAC view so that it directly opens the Volume/Copy editor is a great time saver, one that many of us greatly wish to see carried over to the web client.

Grace Dunbar (gdunbar) wrote :

I understand your position.
As we all know, I'm not the ultimate arbiter of what functionality goes into Evergreen. ;-)
My comment on this thread was just me stating my opinion and thoughts on this issue. However, I do think that my opinion is as valid (but certainly not more valid) as any other user and lover of Evergreen. I think it's important to have honest and open discussions and my comment was just intended to provide an alternate viewpoint and some food for thought.

Janet Schrader (jschrader) wrote :

Any action that requires opening a menu to select a choice is really 2 clicks and not 1. You need to first click on the Actions menu to get the drop-down and then a second click to choose "volumes and copies" under Add. Right now because of the way the choices are listed it also requires scrolling. I think the menu choice may be re-ordered so I'm not overly concerned about that right now.
I have my default view set to MARC view because I want to see the bib record before going to holdings to get to the Actions menu so I have 3 clicks after I find the right record: 1.) holdings 2.) Actions 3.) Add volumes copies.

Victoria Lewis (vlewis-q) wrote :
Changed in evergreen:
assignee: Victoria Lewis (vlewis-q) → nobody
tags: added: pullrequest
Janet Schrader (jschrader) wrote :

When you say directly from the bib record what exactly do you mean? Will the button or link be available on any view like the "Add to bucket" or "Mark for" menu buttons?

Victoria Lewis (vlewis-q) wrote :

I added the 'Add Volumes' button to the record summary pane.

modified: Open-ILS/src/templates/staff/cat/catalog/t_catalog.tt2
modified: Open-ILS/web/js/ui/default/staff/cat/catalog/app.js

I developed on branch collab/gmcharlt/webstaff-sprint2-sprint3 working/collab/gmcharlt/webstaff-sprint2-sprint3

Kathy Lussier (klussier) on 2015-12-09
Changed in evergreen:
status: New → Triaged
importance: Undecided → Wishlist
Jason Stephenson (jstephenson) wrote :

Since the sprint2-sprint3 branch was rebased and merged to master today, Victoria's branch has conflicts when merged. I took the library of rebasing her branch on master and pushing to a collab branch:



The rebase was clean so I didn't modify anything.

Kathy Lussier (klussier) wrote :

Thanks for working on this feature Victoria! I've been waiting for the sprint2-sprint3 branch to be merged before testing it. Now that it's been done, I've had a chance to look at it.

Overall, it looks good, but I saw a couple of minor issues. I think they are all things that were added to the sprint2-sprint3 branch after you did your initial work.

1. When I click the add volumes link, the call number owning library defaults to the workstation OU, as it should. However, the copy's circulation library is Unset. This should also default to the workstation OU. I believe the display of the circulation library was just recently added to this interface.

2. When I add the volumes from the holdings view, the volume classification field has a default that is one of the following: 1) the default that is set in the new defaults tab of the copy editor or 2) the one that is set as an OU setting. If both are present, 1 overrides 2. In my case, we had an OU setting that identified Dewey as the default class scheme. When I used the "Add Volumes" button, the default did not display for the classification field. When this button is used, the classification defaults will need to be set as described above.

3. When using the "Add Volumes" button, the call number field is not automatically populating with the call number that is stored in the bib record. Once again, the code to do so in the web client was added after you originally did the work on your branch.

Thanks again!

Kyle Huckins (khuckins) on 2016-11-16
Changed in evergreen:
assignee: nobody → Kyle Huckins (khuckins)
Kyle Huckins (khuckins) wrote :

I'me made a slight rework of this to address the issues brought up. The branch can be found here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/khuckins/lp1502292-add-volumes-from-bib-record-rework

Now all fields should auto populate as expected, and as a slight simplification of the previous code, the Add Volumes button will now work like the Add Volumes action if volumes are selected in holdings maintenance.

Changed in evergreen:
assignee: Kyle Huckins (khuckins) → nobody
Kathy Lussier (klussier) wrote :

This works well for me. I've signed off on it and pushed it to the sprint 4 collab branch (sprint4-merge-nov22) for future inclusion the next time the collab branch is merged.

Thank you Kyle and Victoria! You've made many catalogers very happy!

Changed in evergreen:
milestone: none → 2.next
status: Triaged → Fix Committed
Changed in evergreen:
milestone: 2.next → 2.12-beta
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments