Webstaff UI issue in the volume/copy editor

Bug #1731370 reported by Jane Sandberg on 2017-11-10
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Dan Wells

Bug Description

In the Volume/Copy editor, it's hard for users to tell what volumes/copies already exist, and which are in the process of being created.

I just worked with a member of our staff who was trying to add a volume on a bib record for which a volume already existed. Instead of doing this:
1) Open the bib record.
2) Press "Add Volume"
3) Check the pre-populated call number and add a barcode
4) Fill out the item-level data and hit "Save and Exit".

They were doing this:
1) Open the bib record.
2) Press "Add volume"
3) Seeing the call number (which happened to be the same as the existing call number) and assuming that that entry referred to the copy we already have in the system. They assumed that the barcode field was empty due to a bug in the Web client, rather than being a totally new copy.
4) Pressing the "Add volume" button again and becoming frustrated when the "Save and Exit" button didn't work.

Looking at the interface, there's no way I could possibly fault them. I've attached a screenshot, in which I challenge folks to try to guess whether this is a new volume/copy or an existing one.

I'm not sure what the best UI intervention might be, but I'm looking forward to lots of great ideas from our brilliant community. :-)

Jane Sandberg (sandbej) wrote :
Remington Steed (rjs7) on 2018-01-19
tags: added: usability
Elaine Hardy (ehardy) on 2018-01-24
Changed in evergreen:
status: New → Confirmed
Andrea Neiman (aneiman) on 2018-01-26
tags: added: webstaffclient
Andrea Neiman (aneiman) on 2018-04-24
tags: added: cataloging
Andrea Neiman (aneiman) wrote :

Jane -- does the work on bug 1739087 provide enough of a visual cue here? New vols/copies will have the x next to them for removal before saving; if you are editing you should not see the x.

Jane Sandberg (sandbej) wrote :

Thanks for making this connection, Andrea! I think that the X doesn't really intuitively indicate that it is a new volume/item, so I don't know if it would help with the confusion my colleague experienced. Unless catalogers are specifically trained to look for the X, I could still see them seeing a new volume/item and understanding it as an existing one.

Mike Rylander (mrylander) wrote :

Hi Jane,

Would having, say, a light green background on volume (and copy) rows in the top area that are not yet represented in the database work? That should be doable with CSS and a check of the data in question.

Jane Sandberg (sandbej) wrote :

That seems like a good solution!

Jason Etheridge (phasefx) wrote :

I added an extra commit on top of my sign off branch for bug 1739087 that tries to address this

Jason Etheridge (phasefx) wrote :

A little more work is needed with this; if you add a new copy to an existing call number, the new copy row isn't styled.

Changed in evergreen:
assignee: nobody → Jason Etheridge (phasefx)
Jason Etheridge (phasefx) wrote :

New commit at

Even though the top two commits will pick cleanly to master, they still rely on Cesar's work for bug 1739087, so the preceding 3 commits are also needed (so, the top 5 commits in the branch).

Let me know how it looks.

Changed in evergreen:
assignee: Jason Etheridge (phasefx) → nobody
Jason Etheridge (phasefx) wrote :

And those 3 are in master now, so adding pullrequest for the top two commits.

tags: added: pullrequest
Andrea Neiman (aneiman) on 2018-09-14
Changed in evergreen:
milestone: none → 3.2-rc
Changed in evergreen:
milestone: 3.2-rc → 3.2.1
Jane Sandberg (sandbej) wrote :

This is great, Jason! I realized that only using the green color to indicate new-ness would violate WCAG 1.4.1, so I added one more commit to your collab branch. That commit adds a dashed border and a brief explanation for screen reader users.

Here is a re-based version of that branch: collab/sandbergja/lp1739087_volcopy_x_cn_rebased

Here is the link: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/sandbergja/lp1739087_volcopy_x_cn_rebased

Dan Wells (dbw2) on 2018-10-23
Changed in evergreen:
assignee: nobody → Dan Wells (dbw2)
Changed in evergreen:
milestone: 3.2.1 → 3.2.2
Changed in evergreen:
milestone: 3.2.2 → 3.2.3
Jason Etheridge (phasefx) wrote :

Dan, I didn't catch that you were still assigned to this ticket. I've pushed a working branch that implements the behavior Mike proposed: collab/phasefx/lp1731370-callnumber-edit


commit bc7391c584320d063b769b364daae7d043a1d46e

    LP1731370 Webstaff UI issue in the volume/copy editor

    This patch tweaks the behavior Cat.pm's fleshed_volume_update, aka

    Previously, if a volume label was edited, all items attached to that
    volume would be essentially affected. Now, if only a sub-set of items
    for the original volume being edited are being edited along with the
    volume, then a new volume is potentially created instead, leaving the
    original volume (and its unedited copies) untouched.

    Auto-merging of volumes may still happen in both of these scenarios.

Changed in evergreen:
assignee: Dan Wells (dbw2) → nobody
Jason Etheridge (phasefx) wrote :

ah, wrong ticket! durn bookmarks :)

Changed in evergreen:
assignee: nobody → Dan Wells (dbw2)
Changed in evergreen:
milestone: 3.2.3 → 3.3-beta1
Changed in evergreen:
milestone: 3.3-beta1 → 3.3-rc
Changed in evergreen:
milestone: 3.3-rc → 3.3.1
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers