Bug 26130 - opacbookbag 'Cart' confuses patrons - add optional name alternatives?
Summary: opacbookbag 'Cart' confuses patrons - add optional name alternatives?
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement with 15 votes (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-03 17:56 UTC by Elaine Bradtke
Modified: 2020-11-02 15:12 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Elaine Bradtke 2020-08-03 17:56:55 UTC
This is in reference to the  'Cart' - short term list making facility in the OPAC.  It is useful for making lists, to download a bibliography or to print out, or e-mail.  But especially now that our building is closed, patrons are thinking that it's a way to order materials (similar to holds, which we don't use).
'Cart' has transactional implications - people are used to seeing it in online shopping sites. If you put something into a cart and finish the ordering process, you expect to receive it.

While 'Cart' may work in some libraries, it doesn't work everywhere. It's also ambiguous with cart used elsewhere in Koha.
Would it be possible to either have a short pull down menu of names for this feature in the opacbookbag setting, or the ability in System Preferences to name it ourselves, or, change the name to something more logical.
Some ideas: 'My List'  'Temporary List' 'My Shelf' and whatever happened to 'Book Bag'?
Comment 1 Owen Leonard 2020-08-03 18:35:24 UTC
(In reply to Elaine Bradtke from comment #0)
> If you put something into a cart and finish the
> ordering process, you expect to receive it.

When I add something to my cart on a shopping web site I don't end the process there. I know that if I want to receive my selections I have to check out. The same is true for the cart in the OPAC, but I'm assuming the problem is that the patron doesn't know what the end result is. I say this because if this understanding is true, the problem is not the term "cart" but the the experience of the user after something has been put in the cart.

At my library we offer the cart feature in the hopes that it will be used like a shopping cart, where the end result of the process is that the selected titles can be put on hold. To me this is the analogue to online shopping's "check out" process.

> While 'Cart' may work in some libraries, it doesn't work everywhere. It's
> also ambiguous with cart used elsewhere in Koha.

Where in the public interface do we use the term "cart" to refer to something else?

> whatever happened to 'Book Bag'?

We stopped using "Book Bag" because nobody knew what it meant!

For what it's worth, I think the solution to the cart feature being confusing may be, for some libraries, to disable the feature. I say this not because I'm trying to shut down conversation about it but because I think it's important to consider that the feature may not be useful to every library regardless of what it's called.
Comment 2 Elaine Bradtke 2020-08-03 18:50:18 UTC
I'm reporting what happens in our library.  
The cart feature has been disabled, because a number of patrons who used it recently (during closure due to Covid-19) were expecting to receive the items they had placed in the cart. Even our new Library Director thought it was confusing.

In the library (when it's open) the cart is how patrons prepare a list of items they want retrieved from the stacks and remote storage.

We do not use holds (where cart does lead to eventually receiving something).

The difference in libraries and users who use Koha is vast, which is why I asked for options.

Cart is not used elsewhere in the OPAC, but in the staff interface.
Comment 3 Andrew Fuerste-Henry 2020-08-03 20:53:40 UTC
We relabel this for a fair number of libraries using jQuery, which takes a lot of code as the cart gets linked all over the place (you can see it here: https://wiki.koha-community.org/wiki/JQuery_Library#Rename_the_Cart)

A syspref in which one could give a name to be used instead would be handy!
Comment 4 Katrin Fischer 2020-08-05 11:57:23 UTC
(In reply to Andrew Fuerste-Henry from comment #3)
> We relabel this for a fair number of libraries using jQuery, which takes a
> lot of code as the cart gets linked all over the place (you can see it here:
> https://wiki.koha-community.org/wiki/JQuery_Library#Rename_the_Cart)
> 
> A syspref in which one could give a name to be used instead would be handy!

Sorry to jump in... but I'd like to veto a pref, because it won't be translatable. We support over 100 libraries in over 20 countries currently which makes collecting and adding translations with jQuery pretty nightmarish.

I like the idea of a pull down, because that way we could keep translations in the templates. Or a way to add translations of course that is accessible to the libraries easily.
Comment 5 Katrin Fischer 2020-08-05 11:58:45 UTC
> Sorry to jump in... but I'd like to veto a pref, because it won't be
> translatable. We support over 100 libraries in over 20 countries currently
> which makes collecting and adding translations with jQuery pretty
> nightmarish.

To explain, they all offer more than 1 language for the OPAC.
Comment 6 Elaine Bradtke 2020-08-12 16:11:45 UTC
One option might be a message bubble that appears on mouse-over.  If this were html that could be edited in System Preferences, it would make it possible for each library to explain how 'cart' is used.
Comment 7 Caroline Cyr La Rose 2020-10-15 17:02:03 UTC
Just chiming in to say that I've had a couple of libraries ask me to turn the feature off for the exact reasons Elaine mentioned in the bug description.

I think the evolution of the internet has made it so that the term "cart" means something specific (e.g. transactional) in the mind of users and the cart in Koha is not that specific thing.

I don't know if the solution might be to change the name or to simply turn the feature off. With so many libraries using Koha I doubt that we can arrive at a consensus. 

I know I'm not offering much in terms of solutions, but I just wanted to say that Elaine's users are not the only ones who are confused by the "cart". For now, for my clients at least, turning off the feature was sufficient and it isn't something they miss...
Comment 8 Martin Renvoize 2020-10-15 18:55:36 UTC
Can we not get the best of both worlds here?  Somewhat like we do for account debit and credit types.. i.e. a drop-down that comes with a set of default values which we can put in the templates to allow for easy translation and a final fallback to a custom freetext description preference for libraries that really want a custom name for it and aren't worried about a multi-lingual opac?
Comment 9 Katrin Fischer 2020-10-15 19:28:36 UTC
It might be not quite that easy :( 

In some languages (German of course...) the words need to change their endings dependent on their grammatical position (I cannot really explain that well) in a sentence. Also words may have a "gender" that influences the other parts of the sentence (German, Spanish, French, Russian ...?). So it's not an easy find and replace action. We'd have to take a closer look at the sentences containing the word cart now:

Stole this from bug 26439, but can use to demonstrate the "gender" bit:

-        var MSG_BASKET_EMPTY = _("Your cart is currently empty");
Ihr Korb ist aktuell leer. (cart) ('male')
Ihre Büchertasche ist aktuell leer. (book bag) ('female')
-        var MSG_RECORD_IN_BASKET = _("This item is already in your cart");
Dieser Titel ist bereits in Ihrem Korb.
Dieser Titel ist bereits in Ihrer Büchertasche.
-        var MSG_RECORD_ADDED = _("This item has been added to your cart");
-        var MSG_NRECORDS_ADDED = _("%s item(s) added to your cart");
-        var MSG_NRECORDS_IN_BASKET = _("%s already in your cart");
-        var MSG_NO_RECORD_SELECTED = _("No item was selected");
-        var MSG_NO_RECORD_ADDED = _("No item was added to your cart (already in your cart)!");
-        var MSG_CONFIRM_DEL_BASKET = _("Are you sure you want to empty your cart?");
-        var MSG_CONFIRM_DEL_RECORDS = _("Are you sure you want to remove the selected items?");
-        var MSG_IN_YOUR_CART = _("Items in your cart: %s");
Titel in Ihrem Korb: %s
Titel in Ihrer Büchertasche: %s
-        var MSG_ITEM_NOT_IN_CART = _("Add to cart");
Dem Korb hinzufügen
Der Büchertasche hinzufügen
-        var MSG_ITEM_IN_CART = _("In your cart");
-        var MSG_RECORD_REMOVED = _("The item has been removed from your cart");
Comment 10 Katrin Fischer 2020-10-15 20:12:55 UTC
What I am trying to say is that just replacing the word will not always work, we'd have to repeat the sentences with the different options so the other words of the sentence can be adapted if necessary.

Not:

Add to %s

But:

Add to cart
Add to book bag
...
Comment 11 David Cook 2020-10-16 03:37:02 UTC
I just looked at my local public library, which uses an Australian non-Koha LMS, and they use "Cart" as well.

Although there is an inconsistency in their system, because sometimes I see a heart (<3) icon and a label of "Wishlist". 

Looks like maybe they have the same problem as Koha libraries ;).
Comment 12 David Cook 2020-10-16 03:40:06 UTC
Personally, I sometimes think that we should consider using tokens in the Template::Toolkit templates and then have files that map the tokens to the translation. 

You see this all the time in Java applications. It's common to have "messages.properties" or "messags_en.properties". For example: https://github.com/keycloak/keycloak/blob/master/themes/src/main/resources/theme/base/email/messages/messages_en.properties

I imagine that it would require a fair bit of work, but it might meet everyone's needs?
Comment 13 Katrin Fischer 2020-10-16 10:03:55 UTC
(In reply to David Cook from comment #12)
> Personally, I sometimes think that we should consider using tokens in the
> Template::Toolkit templates and then have files that map the tokens to the
> translation. 
> 
> You see this all the time in Java applications. It's common to have
> "messages.properties" or "messags_en.properties". For example:
> https://github.com/keycloak/keycloak/blob/master/themes/src/main/resources/
> theme/base/email/messages/messages_en.properties
> 
> I imagine that it would require a fair bit of work, but it might meet
> everyone's needs?

You might want to have a look at bug 26392 and join the discussion there. But I am not sure how it would help the specific case here? (interested to learn tho) The problem here is a bit specific as we are trying to figure out how to best way would be to have different translations for the same language.
Comment 14 David Cook 2020-10-18 23:30:43 UTC
(In reply to Katrin Fischer from comment #13)
> You might want to have a look at bug 26392 and join the discussion there.

Bug 26392 is... well I don't like it at all. I can't see people actually using it. And if they're forced... then dev times will go up or devs might not happen at all?

> The problem here is a bit specific as we are trying to figure out
> how to best way would be to have different translations for the same
> language.

Ah, that is an interesting idea. That actually fits more with the idea I described rather than the one used in Bug 26392 (and all that other I18N module stuff I'm seeing). If we used a token/msgid like "cart.nickname1" = "Cart", "cart.nickname2" = "Bookbag", or whatever... you could have a dropdown system preference to choose the "nickname" code (e.g. nickname1, nickname2, etc) that you want to use, and then build the token string and pass that off to the I18N system that fetches the translation from a dictionary. 

You can see that idea a bit in https://metacpan.org/pod/Catalyst::Plugin::I18N with the following construct:

# MyApp/I18N/i_default.po
msgid "messages.hello.catalyst"
msgstr "Hello Catalyst - fallback translation"

[% l('messages.hello.catalyst') %]

(Of course, I think putting a .po file in a module lib path is horrifying, but a person wouldn't have to do that.)
Comment 15 Katrin Fischer 2020-10-19 01:15:06 UTC
(In reply to David Cook from comment #14)
> (In reply to Katrin Fischer from comment #13)
> > The problem here is a bit specific as we are trying to figure out
> > how to best way would be to have different translations for the same
> > language.
> 
> Ah, that is an interesting idea. That actually fits more with the idea I
> described rather than the one used in Bug 26392 (and all that other I18N
> module stuff I'm seeing). If we used a token/msgid like "cart.nickname1" =
> "Cart", "cart.nickname2" = "Bookbag", or whatever... you could have a
> dropdown system preference to choose the "nickname" code (e.g. nickname1,
> nickname2, etc) that you want to use, and then build the token string and
> pass that off to the I18N system that fetches the translation from a
> dictionary. 

The problem was pointed out in comment#9 - the term is not only used as a single word, but also in some sentences. And in these cases, it might not be an easy search and replace action, as surrounding words need to be changed as well.

I believe what you suggest there is not so different to the new mechanics/workflows we have with the I18N code.
Comment 16 David Cook 2020-10-19 01:48:32 UTC
(In reply to Katrin Fischer from comment #15)
> The problem was pointed out in comment#9 - the term is not only used as a
> single word, but also in some sentences. And in these cases, it might not be
> an easy search and replace action, as surrounding words need to be changed
> as well.

Ah, I hadn't thought of someone trying to search and replace all instances of cart, but I see now why a person would want to. The advantage of the token model would be that you could cluster all your strings together, so that a translator could just focus on translating "cart" in context across a range of strings while on one screen, but that might just be me being overly optimistic too. 

> I believe what you suggest there is not so different to the new
> mechanics/workflows we have with the I18N code.

Could be! After doing a bit more reading, I think I have more reading to do.