webclient: No visual cues to indicate that bills are for items currently checked out, lost or long overdue

[Kathy Lussier]

In the xul client, colors are used in the bills tab to indicate if the charge is for an item that is still checked out to the patron (red), is set to lost (dark red), or is an overdue (orange).

Similar visual cues are needed in the web client.

[Michele Morgan (mmorgan)]

Confirmed. The color coding is important to help staff quickly distinguish between overdue fines and replacement charges.

[Kyle Huckins (khuckins)]

I'm taking a look at this, and the way the grid is set up, I'm not seeing any simple ways to handle this well. The grid generates quite a bit that we don't seem to have access to editing in such a way that mimics how well the XUL client color codes rows. One idea is to mark particular fields with the background color on particular fields, however it risks looking like an ugly mess, since it doesn't fill up the entire field, only the content block within the field.

[Kyle Huckins (khuckins)]

I'm attaching a couple of screenshots - one of them being an example of what we want to do, the other being an example of what's possible. "What we want" was done through Chrome's dev console. "What's possible" is an example of what's currently possible with the grid service.

[Kyle Huckins (khuckins)]

The problem we're running into here is that we have no control over the eg-grid-rows or even the eg-grid-cells, only the content of the cells, making it particularly difficult to make the edits needed.

It was brought up in a conversation with Kathy Lussier that a visual column could work here, where we would put an icon that displays based on the item's status of being checked out, lost, or overdue.

[Kathy Lussier (klussier)]

I've polled some people here.

1. There is a general preference here to add highlighting to all the displayed cells in that row. The concern is that if we highlight just the one cell, it's easy to lose track of which row is highlighted as the eye moves across to the other fields.

2. I still like the idea of the icons in addition to the color-coded cues. It adds a bit more accessibility for those who have trouble distinguishing among colors and can be an option if people decide to turn the color highlighting off locally.

I was looking at the glyphicons we use in other parts of the client, and was thinking the following might work:

http://glyphicons.com/

glyphicons-alarm for overdue
glyphicons-question-sign for lost
glyphicons-exclamation-sign for long overdue

[Kyle Huckins (khuckins)]

There's a basic branch pushed here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/khuckins/lp1635386-visual-cues-for-bills-item-status

It contains classes for the requested colorings for cell content, as well as a new column for the billed item's status.

Steps for further development:

In staff/circ/patron/bills.js, under $scope.gridControls's instantiation(at the time of this post, the line is 181), it's possible to access and modify information in the item represented on the grid, but prior to that, I'm unsure of where it's initially being brought in.

1. Get the item status to be available. This may be fairly difficult, as this grid in particular has their item abstracted out, and $scope will not save us here.

2. Overdue: Create a new Date(); and compare it to item.circulation.due_date.

3. Checkout/Lost/Long Overdue: Needs access to the target_copy's status. This is currently not reachable, but if someone can find where the xacts are being fetched for this particular grid(it isn't in this controller, or the billing service), it should be possible to flesh the status out from the circulation's target_copy.

4. Once those are available, it should be a matter of using the ng-class attribute to check for those states and apply the content highlight classes. For the icons, adding a <span> with the above ng-class attribute checking for states will apply the above glyphicons, or any other icons requested.

[Michele Morgan (mmorgan)]

I actually like glyphicons-clock for overdue billings a bit better than glyphicons-alarm.

In #3 above, should we be looking for the target copy's status? For overdue billings, the item could have been returned and could be in almost any status not at all associated with the circ that generated the billing.

Can we get what we need from the stop fines reason from the circ?

[Kyle Huckins (khuckins)]

+1 to glyphicons-clock for overdue items.

That's a good point. I was reading into the task being if the current state of the item is one of those defined, but if it's in a circ to another patron, or a new circ to that particular patron, there'd need to be some extra checks involved that would bog things down a bit. Stop Fines Reason might be the way to go here.

[Kathy Lussier (klussier)]

It looks like stop fines reason is what's currently used in the xul client. I don't know if it's helpful, but here's the commit that added styling for the lost and long overdue items. The styling for overdue items was already available - http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=081880142353b99a4e90d7fbb9e9407dabffb9a8

[Kyle Huckins (khuckins)]

After a good couple weeks on my own time of studying grid.js closely, I have an idea that could prove my initial findings on the row colorization incorrect. I've pushed up a WIP commit to my branch which includes a basic implementation of the requested row colorings. Currently this affects all grids, and shouldn't be taken as a solution in and of itself. It is simply a function that needs to be replaced with a new optional parameter to eg-grid, currently titled "rowClass." rowClass will allow you to pass along a function or a string, and will be applied to each cell in the grid, bypassing the previous problem of only being able to affect the cell's content.

[Kyle Huckins (khuckins)]

I've pushed another commit on top of the previous commit, implementing the above mentioned egGrid parameter. Attached is a screenshot of a patron with two bills - one for an item marked as lost, the other for an item currently checked out.

All that should be left now is some styling changes to cover the text color and selected rows, and also applying the classes to the index and checkbox columns.

[Kyle Huckins (khuckins)]

I've amended all my commits - this should function as expected. Any community feedback on this would be appreciated, there's one portion that I'm not 100% sure on - I'm checking to see if the item is checked out by making sure circulation.stop_fines isn't set to CHECKIN, and checking to see if circulation.due_date exists.

Now what it needs is the glyphicon support - for some reason it hasn't been behaving as I'd expect it to with the code in place. While it *should* work, it doesn't seem to be displaying the glyphicon. I've attempted moving it over into a function and calling that through ngClass, but no luck.

To summarize the above comments, this adds a fairly sizeable but necessary feature: egGrid now has an optional parameter rowclass. rowclass works by passing through an object containing a function, rowClass(item). This function will apply specified classes based on logic relating to the item passed in. An example of usage(and the primary functionality of this issue) is in bills.js $scope.colorizeBillsList.

Dumping all this information here to see if there's any feedback regarding this approach, if it seems sane or if there's something I'm overlooking

[Kyle Huckins (khuckins)]

Alright, this should cover what was discussed on the task and the comments. Branch has been updated(Here to avoid scrolling through the comments: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/khuckins/lp1635386-visual-cues-for-bills-item-status) and rebased to the latest master. I've attached an image as an example of the latest update.

Changes since the last update:

- rowclass parameter has been changed to cellclass, for consistency with how it's utilized.
- statusicon parameter has been added to eg-grid, containing an object with a function and a boolean. The boolean determines if a new column, "Status Icon," should display, and the function puts out a small template for glyphicons to display.
-statusicon has been implemented for the patron bills list, and will display a relevant glyphicon for each mentioned status.

[Kathy Lussier (klussier)]

This looks great Kyle! Thanks so much for your work on this.

I found a few issues while testing the latest code:

- The background colors for the rows on Lost and Long Overdue items change as expected. However, when those items are subsequently checked in, the background colors continue to display. In the xul client, the background colors stop displaying once the item is checked in. With your branch, this behavior is working correctly for overdue items.

- When the overdue items are checked in, I would expect the overdue icon to no longer display. My expectation is the same for lost and long overdue. The icons continue to display.

- If you click the option to Configure columns, the new status column messes with the alignment of the other column controls.

- I saw this on one record I tested, but not another. I pulled up the 6 Month Overdue Mark Long-Overdue action trigger and ran barcode CONC4000077 through the test to mark it long overdue. In the Concerto dataset, this barcode is checked out to Edward Lopez (99999376669). When I checked his bills tab, the color changed as expected, but I noticed there were two icons in the status column - the one for overdue and the one for long overdue. I would expect only one icon to display at a time.

Thanks again Kyle!

[Kyle Huckins (khuckins)]

Hey Kathy, I've amended and these should be resolved now. Thanks for all the feedback!

[Mike Rylander (mrylander)]

Kyle,

Looking at the code, I have a couple style requests at a glance -- could we rename "cellclass" to perhap "rowClass" ("row-class" in the markup) since it's row oriented rather than cell oriented, and "statusicon" to, perhaps, "statusCell" (aka "status-cell") since I can certainly see something like this being used for things other than icons. In particular, I'm thinking of a meta-status column for holds or acq lineitems based on various fields within a grid item. (Note: while we've not been 100% consistent about it, we have tended toward separating words in an angular scope variable with -'s (and camelCasing in the JS).)

We might also want to disassociate the class names used here for row highlighting from the grid infrastructure itself by removing the 'eg-grid-cell-" prefix on the class to make it clear that those style additions are not really grid-global, but specific to the billing grid use case and can be a template for future styling rather than a restricted set that one must choose from.

Thanks, this looks good!

[Kyle Huckins (khuckins)]

Hey Mike,

I've committed the style requests - I left the status-cell related class additions as is, but that's a quick change if desired.

[Kathy Lussier (klussier)]

This looks good to me. I've signed off on Kyle's changes, but I added a commit to tweak the colors that are used to provide enough contrast to meet WCAG AA guidelines. The red and dark red colors are similar to what is used in the XUL client. The orange is significantly lighter since it was difficult to provide good contrast with the darker orange color.

The only color combination that is still failing to meet WCAG AA is the blue links on any background color. However, we will get adequate contrast for those links if we address bug 1746365.

[Kathy Lussier (klussier)]

I'm also targeting this change for 3.1. I'll let the 3.0 release maintainer decide if this missing xul feature is a bug fix that's worth backporting.

[Kathy Lussier (klussier)]

Bah! I forgot the post to the working branch. Sorry for all the noise!

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1635386-visual-cues-for-bills-item-status-signoff

[Kathy Lussier (klussier)]

Adding a screenshot of what a bills screen looks like with a combination of overdue, long overdue, and lost items with a selected and unselected row for each status. This screenshot is on a system that contains the branch from this bug as well as bug 1746365.

[Dan Wells (dbw2)]

Okay, I have reviewed this branch, and overall, it is very close to ready. I have one small thing, one maybe thing, and one potentially larger thing to mention.

1) (small) There is still a stray 'statusicon' test in one template. I am wondering if we should fix that, or get rid of that test/style entirely (not 100% sure why we need the custom class for that column yet).

2) (maybe) As shown in Kathy's screenshot, we are attempting to "darken" rows when selected, but this gets pretty hairy fast, with no less than 4 different potential shades of red (and 2 shades of orange, for that matter). At that stage, it is hard to argue that the colors remain functional. What do folks feel about using the blue select color globally regardless of original row color? It is easy to visually understand and will work everywhere forever. In my view, if I've selected something, I've already evaluated it, and it is more important from that point forward to see what I've selected than to see a color hint about the row data. Thoughts? We could also consider fancier forms of universal highlight (border-color, glow, shadow, etc.), but we aren't close to there yet.

3) (potentially larger) This branch is going to conflict and interact with bug #1746824 in interesting ways. I *think* we should consider keeping both, as one applies a class across entire rows based on actual row data, while the other applies classes to individual columns based on the general shape of the data class. Do folks agree with this summary? If so, we may want to tweak the two variable names to clarify this complementary relationship.

[Kathy Lussier (klussier)]

Addressing your question from #2, one thing to remember is that, by default, the client automatically selects all of those rows when you load the bills interface. There is a library setting to change this default, but I don't know how much use it actually gets. To see the colors, then, the user would need to deselect the rows, which, I think, would defeat their purpose. When adjusting the colors, I did toy with the idea of not using different colors to distinguish between selected and deselected rows. I know it's better UI to have that visible cue that a row has been selected, but, in this case, it might be overkill.

FWIW, I don't think a patron record is likely to come across such a visual cacophony on an individual record as is seen in this screenshot. There are many Evergreen systems that have not enabled long overdue processing, and the mix of all the statuses and all the selection states is unlikely.

I do know our libraries want to see a distinction between what is lost and what is overdue. Back in the days when the same red color was applied to both (this was before long overdue was added), there was a lot of confusion over the use of the same highlighting for transactions that were in completely different states.

#3 - That distinction works for me. I know our people were very happy when Kyle found a way to apply a style to an entire row.

[Dan Wells (dbw2)]

Kathy, that is a very good point about #2. We can consider other options down the road, but you are right, having them all be blue isn't going to work, so let's stick with where we are.

I will get this in for the 3.1 RC.

[Dan Wells (dbw2)]

I poked at this on an off all day hoping to get it into the RC, but I think it needs more eyes now. I've refactored it a fair bit to make it simpler and more consistent. Here is the branch:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1635386-visual-cues-for-bills-item-status-signoff_refactored

working/user/dbwells/lp1635386-visual-cues-for-bills-item-status-signoff_refactored

Please see the new commit for the list of changes. Also note, it probably makes more sense if you diff the whole branch now against master (or HEAD^^) rather than looking at the commits separately.

Finally, I noticed that the colors in this branch are different than current XUL, using orange for overdues, then red for long overdue, then dark red for lost. I did not make that change, but found it very sensible, so I left it that way. I know there is an argument to be made for keeping it the same as the old client, but there is also one to made for this sort of logical progression of "reddening". If we are going to make the change, now is the time, so I left it, but it wouldn't be hard to swap them around.

[Kathy Lussier (klussier)]

I haven't had a chance to look at this, but I wanted to add a note that when I was looking at it back in February, I was still seeing red for overdue and orange for long overdue items.

[Dan Wells (dbw2)]

Kathy, I believe you, and it doesn't hurt that you have a screenshot above to prove it :) Maybe there is a missing commit out there somewhere? Or something got force-pushed over?

However it came to be, I think the conversation is worth having. I personally think the progressive scale in the existing branches posted here is more natural, and worth the small, one-time re-acclimation cost of making the switch. In the end, though, I know our staff will be pretty happy to see *any* colors for these rows again.

Dan

[Kathy Lussier (klussier)]

Hi Dan,

I'm now thinking that I changed the colors locally to match our current behavior and then forgot about this adjustment when I was putting my changes into a git branch.

My inclination is to go with the existing colors to ease the transition to the web client. It would be one less thing to learn. But I'm open to other opinions.

[Michele Morgan (mmorgan)]

Hi Dan and Kathy,

I am leaning toward the orange for overdue and red for long overdue items. In our consortium it's not uncommon for patrons to owe a large number of small fines for still checked out overdue items, but also have long overdue items, most commonly fewer in number than the overdue. The sea of red for the overdue items can make it harder for staff users to focus on the long overdue.

I'm not sure how libraries that don't use long overdue would take to the new orange color for overdue, but in our consortium, it would be helpful for staff.

Attaching a couple of screenshots. This one is the bills screen for a patron with many overdues, a few long overdue, and a lost item from the xul client.

[Michele Morgan (mmorgan)]

Also attaching a hasty mock-up of what this same bills screen might look like with the new color arrangement.

[Dawn Dale (ddale)]

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

[Kathy Lussier (klussier)]

Hi Dawn,

Do you also find the change in colors acceptable (orange for overdue and red for long overdue items)?

I would love to get more feedback on that question, not just from Dawn but from others as well, before it goes in.

Kathy

[Christine Burns (christine-burns)]

Hello

The Sitka libraries do not use "long overdue". We would prefer to use the existing XUL colour scheme

Red = overdue

Dark red = Lost

[Joan Kranich (jkranich)]

I agree with Sitka comment #34.
CW MARS also uses only overdue and Lost.

Red = overdue and Dark red = Lost is okay. The important piece is to have overdue and Lost bills color coded with different colors.

[Dawn Dale (ddale)]

We do use longoverdue but the current color scheme is fine with me. As long
as there is a difference in the colors it will work for us.

Dawn Dale
PINES Services Specialist, Circulation
Georgia Public Library Service
1800 Century Place Suite 150
Atlanta, GA 30345
404-235-7136
<email address hidden>

On Fri, Jun 1, 2018 at 9:14 AM, Kathy Lussier <email address hidden> wrote:

> ** Changed in: evergreen
> Assignee: (unassigned) => Kathy Lussier (klussier)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1635386
>
> Title:
> webclient: No visual cues to indicate that bills are for items
> currently checked out, lost or long overdue
>
> Status in Evergreen:
> Confirmed
>
> Bug description:
> In the xul client, colors are used in the bills tab to indicate if the
> charge is for an item that is still checked out to the patron (red),
> is set to lost (dark red), or is an overdue (orange).
>
> Similar visual cues are needed in the web client.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1635386/+subscriptions
>

[Kathy Lussier (klussier)]

Since opinions seem to be split on this question, I created a new working branch, still untested, that restores the previous color scheme, but also changes the class names to ones that are based on the status of the particular row rather than on the color that's being applied. This should make it easier to customize the colors as it only requires editing the CSS for that class. You certainly could have done so with the last branch, but there's nothing more confusing then applying an orange color to a class with the name 'red' and vice versa. It also acknowledges that there may be other ways, aside from color, that people may want to style these rows.

As a follow-up, I will also add documentation that shows how to customize the colors used for these rows. I was going to incorporate it in the above branch, but then I realized we still haven't done documentation on the web client Bills interface, so it will take a little longer than I initially anticipated. I can commit to working on this once I have access again to a server that has the above branch.

New working branch is at

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1635386-visual-cues-for-bills-item-status-refactored-restore-colors

[Dawn Dale (ddale)]

That sounds like a good idea to me. Thanks, Kathy!

Dawn Dale
PINES Services Specialist, Circulation
Georgia Public Library Service
1800 Century Place Suite 150
Atlanta, GA 30345
404-235-7136
<email address hidden>

On Fri, Jun 1, 2018 at 10:36 AM, Kathy Lussier <email address hidden> wrote:

> Since opinions seem to be split on this question, I created a new
> working branch, still untested, that restores the previous color scheme,
> but also changes the class names to ones that are based on the status of
> the particular row rather than on the color that's being applied. This
> should make it easier to customize the colors as it only requires
> editing the CSS for that class. You certainly could have done so with
> the last branch, but there's nothing more confusing then applying an
> orange color to a class with the name 'red' and vice versa. It also
> acknowledges that there may be other ways, aside from color, that people
> may want to style these rows.
>
> As a follow-up, I will also add documentation that shows how to
> customize the colors used for these rows. I was going to incorporate it
> in the above branch, but then I realized we still haven't done
> documentation on the web client Bills interface, so it will take a
> little longer than I initially anticipated. I can commit to working on
> this once I have access again to a server that has the above branch.
>
> New working branch is at
>
> http://git.evergreen-
> ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/
> user/kmlussier/lp1635386
> -visual-cues-for-bills-item-status-refactored-restore-colors
>
> ** Changed in: evergreen
> Assignee: Kathy Lussier (klussier) => (unassigned)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1635386
>
> Title:
> webclient: No visual cues to indicate that bills are for items
> currently checked out, lost or long overdue
>
> Status in Evergreen:
> Confirmed
>
> Bug description:
> In the xul client, colors are used in the bills tab to indicate if the
> charge is for an item that is still checked out to the patron (red),
> is set to lost (dark red), or is an overdue (orange).
>
> Similar visual cues are needed in the web client.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1635386/+subscriptions
>

[Dan Wells (dbw2)]

Kathy, I love the idea of meaning-based CSS names, so that's a great improvement. Thanks for doing that!

This color discussion has stirred up some additional thoughts about how we approach such decisions as a community, but this bug tracker isn't really the best place for such a discussion, so I'll probably try to post that to the list.

Is it alright to get this pushed in as-is, or would you prefer I wait for your documentation?

[Kathy Lussier (klussier)]

I think it can be pushed as is. I should be able to get the documentation done before the next maintenance release. Thanks Dan!

[Dan Wells (dbw2)]

Other than the class-name changes, we've run this in production for a few months now, and it seems to work as intended. Pushed to master and rel_3_1. Thanks, all!

P.S. Looking at this fresh again, I am wondering a bit about the "rowClass" name and structure, and if we should clean that up a bit more before spreading to other grids. That's just inner workings, though; I will make another bug for those thoughts.