“Hold was successfully placed” is easily confused with “Hold was not successfully placed.” Unless the user pays close attention it is easy to think it read the hold was placed when it was not.

[George Tuttle]

If “Hold was not successfully placed” is in red font, confusion would be less likely.

David Busby of Edoceo, Inc. suggested the following:
Now you can make a patch, looks like it could be as simple as a CSS update or a minor adjustment in the template file "Open-ILS/src/templates/opac/parts/place_hold_result.tt2" on line 77

<strong style="color:#f00;">

As a quick work-around.

[Jason Stephenson (jstephenson)]

I set the Importance of this bug to wishlist because it is not a failure in actual functionality, but a suggestion for an improvement in usability.

[Jason Stephenson (jstephenson)]

Myabe tihs msesgae shuold be chnaegd to raed "Your attempt to place a hold failed" in the evnet of fialrue?

I am pretty sure that the complete failure of the current language has to do with the mental phenomenon that lets your brain easily read the above sentence. As long as the first and last letters of the word are in the right place our brains can unscramble the rest very quickly so we can still read the sentence. I wouldn't be surprised, though I have no evidence, if something similar doesn't happen on the level of the sentence and words. I'll wager that many people's brains elide the "not" in the current failure message and for the most part just see "Hold ... placed." The fact that you must pay attention and concentrate to see the not in the message, regardless of color, is likely the root of the problem (and constant discussion) of the current language.

Just my 2 bits.

[Ben Shum (bshum)]

To note though, in Tpac, the hold success message is already in green. And the hold failure is noted "problem" in red with an explanation to the reason for failure in italicized black following it.

That said, green/red always ends badly with color-blind tests. So improving the wording definitely sounds like a good idea.

[Jason Stephenson (jstephenson)]

NOTE: If you want to change the language in JSPAC, then you should edit the opac.holds.failure entity in ./Open-ILS/web/opac/locale/en-US/opac.dtd.

If you want to change the language in TPAC, then you should edit ./Open-ILS/web/opac/locale/en-US/opac.dtd.

If you change either and you use languages other than the default, US English, you'll want to change your PO files as well.

Another way to make a change to the language of the message is to create a PO file for en-US and alter the string there. This works, at least for TPAC.

[Jason Stephenson (jstephenson)]

Ugh.... stupid copy/paste-o.

To change the language in tpac, I'd suggest editing a po file for your language. Otherwise you can edit Open-ILS/src/templates/opac/parts/place_hold_result.tt2

[edoceo (edoceo)]

This seems to fix the issue w/o requiring colour. Just clarifying the text

https://github.com/edoceo/evergreen-edoceo/commit/5a1e21c5baee7d37e233e8d7b1e03da9a9275a99

[Jason Stephenson (jstephenson)]

I am inclined to think that this should be handled in the translation files and treated as a local customization by different Evergreen libraries.

This bug should probably converted into a question with an answer provided on how to create, edit, and maintain customized translations.

[Brahmina Burgess (brahmina-burgess)]

We at Sitka have a local customization for this, and would like to see the change to the default text to make it upstream, so we would have fewer customizations to maintain. We are inclined to see this as a usability bug, and prefer that the default text not be confusing at the get go. If it would be possible to move forward with this text change, we would appreciate it.

[Josh Stompro (u-launchpad-stompro-org)]

We have noticed this issue also, customers think they have placed a hold when they received a failure. I also think it is a usability bug. How about adding a pair of icons to the beginning of the message also. Something like a big red X for failure and a green check-mark for success? I think that can be done via css as long as the success and failure elements are identified so they can be targeted in the css.
Josh

[Kathy Lussier (klussier)]

Brahmina,

Could you tell us what the text change is in the Sitka customization? I have no objections to making a change to the core code as long as we can get general consensus on what the change should be.

[Terran McCanna (tmccanna)]

+1 to a change in the default text AND a visual cue like Josh suggested - most people will respond more strongly to a simple visual indicator like that.

[Brahmina Burgess (brahmina-burgess)]

We have changed the text to read: "Hold was NOT placed!", but are open to variations that are equally or more clear.

[Jane Sandberg (sandbergja)]

Another possibility as far as the English-language text, since there is an area called "Problem" just below:

"There was a problem placing your hold."

I like the idea of a big red X for failure. We also have a local customization here, and it would be great if Evergreen made the success/failure clear out of the box.

I've attached a screenshot of our local customization, mainly because I think it's funny. The only requirement I had was "Make it look really ugly when the hold can't be placed", which I think I succeeded at. :-)

[Jane Sandberg (sandbergja)]

I noticed that the bootstrap opac has some special styling for hold success vs. failure. Does that improvement fix this bug?

[Terran McCanna (tmccanna)]

I would say yes - there is now a red X in a circle next to the text, so even for people with recd-green color-blindness, it should be clear. It also displays text describing the problem below it. I'll take the liberty of marking this one Won't Fix.