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

[Lazar, Alexey Vladimirovich]

Hello.

A feature that is unavailable is more user-friendly than a broken feature that is available. A broken feature is a broken promise to the user. Without a feature being available there is no promise to the user and a nonexistent promise cannot be broken, so to speak. 

Of course, frequently it is impossible to thoroughly test a feature during development and production use is needed as the next testing phase. In this case, production users really become beta-testers which is totally fine, as long as they know that and expectations are adjusted accordingly.

A while back I worked on a project called Class Schedule Builder (www.mnsu.edu/schedule). Our team knew that in addition to potential issues with front-end code and browser support we had some instability with the back-end data source, which could become unavailable any time for reasons outside of our control. So, we needed to make the schedule builder available, but also to set user expectations appropriately. I suggested using a beta-badge, which was popularized at that time by various Google's beta-websites. After some initial laughs the team agreed and we went live with it. (Unfortunately, that beta-badge is still there, but that’s a different story.)

I am not suggesting necessarily that the Matches Exactly search option should get a beta-badge, but something like that is certainly a way to adjust user expectations accordingly. (Could be added straight to the Evergreen logo, to cover for ALL the bugs, right? ;)
 
A bit off-topic maybe, but here is an example of a search that allows wildcards and also has a highly-usable set of instructions: http://onelook.com/. Perhaps the Matches Exactly search option on select could pop-out a little how-to table on the side that would list some of the possible search examples, and also maybe a couple of examples of what is currently known not to work. In theory, this would allow users to continue using the parts of the feature that do work, while setting expectations accordingly about what’s currently broken.

Otherwise, it would be better to remove the option altogether, perhaps moving the interface to an unlinked (but documented) location, like http://ecrl.mnpals.net/eg/opac/advanced?pane=beta, or something like that.

Aleksey


On 2014-09-29, at 12:13 , 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
> 

Aleksey Lazar
IS Developer and Integrator - PALS
http://www.mnpals.org/