[OPEN-ILS-GENERAL] ***SPAM*** Re: Proposal to remove some advanced search options from the catalog

[Benjamin Kalish]

I agree that these confusing options should not be presented in the OPAC,
but that the ability to use the syntax should remain.

That said, the punctuation dependence that Kathy describes sounds like a
bug to me. If it is the intended behavior, then why? And if it isn't it
should be fixed.

Benjamin Kalish
Forbes Library / 413-587-1012 / bkalish at forbeslibrary.org

Currently reading:* 2001: A Space Odyssey by Arthur C. Clarke* and *1Q84 *by
Haruki Murakami
Just Finished: *The Ghost of the Mary Celeste* by Valerie Martin

On Mon, Sep 29, 2014 at 1:13 PM, Kathy Lussier <klussier at masslnc.org> wrote:

> Hi all,
>
> I wanted to float an idea to the community. I spent a little time this
> morning looking at a bug submitted earlier this year regarding the Matches
> Exactly search option in the advanced search screen -
> https://bugs.launchpad.net/evergreen/+bug/1267129. After thinking about
> the problem, I came to a conclusion that I've drawn on similar occasions
> when looking at previous problems with exact match searching that has since
> been fixed. Overall, I think this search option along with, to a lesser
> extent, the Starts With search option, is more likely to cause frustration
> for users than to solve any search problems.
>
> I'm curious to know if others have found the same problems in their
> libraries and, if so, if there is any willingness in the community to
> remove those options in the advanced search screen to save frustration on
> the part of users.
>
> My reasons for removing them are below:
>
> 1. The intent of this search option is to perform a left- and
> right-anchored search on the search terms. The entered search terms need to
> exactly match the index as it appears in the relevant metabib table. If
> doing a title search, you need to enter the entire title including 245a and
> 245b. I believe most users are unlikely to know what the subtitle is for a
> book and a. The re more likely to enter just the words that are in 245a.
>
> 2. Right now, there is a bug with Matches Exactly. As of now, if you enter
> the following terms in the search box:
>
> the joy of cooking
>
> the system will retrieve anything that begins with "the", ends with
> "cooking" and also contains the words "joy of" in no particular order. I
> just conducted a matches exactly search for the help today and, in addition
> to retrieving "The Help" it also retrieved a record for "The Berenstain
> Bears hurry to help." The fix for this particular issue is fairly easy, but
> the fix also means that the Matches Exactly will become even more
> unforgiving than what I outlined in #1 above. Punctuation will matter more.
> In addition to entering all of the words in the 245a and 245b, the user
> will also need to know where to add punctuation. From what I can tell, this
> isn't consistent for all punctuation. In looking for the title "The assist
> : hoops, hope, and the game of their lives" the following search works:
>
> "^The assist hoops, hope, and the game of their lives$"
>
> but these searches do not work:
>
> "^The assist : hoops, hope, and the game of their lives$"
>
> "^The assist hoops hope and the game of their lives$"
>
> It looks like the user needs to know that the colon should be removed, but
> the commas should remain.
>
> 3. The "Starts With" search is a little more forgiving since a user is
> more likely to know the start of a title rather than the entire string, but
> it still suffers from the problems of a user needing to know what
> punctuation should be entered (or not entered) for the string that they
> type. Since it is a search that uses left-anchoring, it also does not
> ignore non-filing indicators, which is something that users sometimes
> expect it to do. Note: I was the person who added the "Starts With" search
> to Evergreen, mainly as a way to ameliorate the issues we saw with the
> "Matches Exactly" search. Now that Browse search is available in the
> catalog, I don't think this particular search is necessary on the advanced
> search screen anymore.
>
> 4. In a standard Evergreen installation where no custom indexes have been
> added, both of these search options will probably fail for a keyword
> search. This happens because, by default, there is one keyword index (the
> blob) where all of the indexed terms for the record are stored, and there
> is no way any user could know all of the terms that are stored there and
> their proper order. If they are entering a title, they are more likely to
> have successful Starts With keyword searches because the title seems to be
> the first thing that starts off the blob, but if the user were entering any
> other terms (author's last name?) for a Starts With keywords search, the
> search will fail.
>
> Rather than present a search option to our users that has a higher
> likelihood of leading to unsuccessful search results than our other search
> options, I would like to see if there is willingness in the community to
> remove these options in the next (March/April) release of Evergreen.
>
> Please feel free to share any feedback you have to this idea.
>
> Thank you!
> Kathy
>
> --
> Kathy Lussier
> Project Coordinator
> Massachusetts Library Network Cooperative
> (508) 343-0128
> klussier at masslnc.org
> Twitter: http://www.twitter.com/kmlussier
> #evergreen IRC: kmlussier
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20140929/11d5363a/attachment-0001.htm>