Webstaff UI issue in the volume/copy editor

[Jane Sandberg]

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

[Andrea Neiman (aneiman)]

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 (sandbergja)]

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)]

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 (sandbergja)]

That seems like a good solution!

[Jason Etheridge (phasefx)]

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

[Jason Etheridge (phasefx)]

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.

[Jason Etheridge (phasefx)]

This is where I'm at at the moment:
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=9a67a0078fb001385990742c2301e7929cb918a0

[Jason Etheridge (phasefx)]

New commit at
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/lp1739087_volcopy_x_cn

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.

[Jason Etheridge (phasefx)]

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

[Jane Sandberg (sandbergja)]

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

[Jane Sandberg (sandbergja)]

P.S. Here are two explanations of WCAG 1.4.1:
* https://www.w3.org/WAI/WCAG21/Understanding/use-of-color
* http://accessibility.psu.edu/color/colorcoding/

[Jason Etheridge (phasefx)]

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

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/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
    open-ils.cat.asset.volume.fleshed.batch.update

    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.

[Jason Etheridge (phasefx)]

ah, wrong ticket! durn bookmarks :)

[Elaine Hardy (ehardy)]

Tested on https://tiffany-master.gapines.org/eg/staff/

Works as expected. When adding new call numbers and/or items, whether holdings on a library exist or not, the input well at the call number editor is highlighted in green and surrounded by a dashed line. The highlighting and line are not present when a call number and/or item is being edited.

Tested in both Chrome and Firefox.

[Elaine Hardy (ehardy)]

I have tested this code and consent to signing off on it with my name, Elaine Hard and my email address, <email address hidden>.

[Galen Charlton (gmc)]

Pushed to master, rel_3_5, and rel_3_4. Thanks, Jason, Jane, and Elaine!