I'm not a fan of the badge idea, but I like the idea of the explanatory box that pops up when when an experimental feature is selected and the a special beta page for such features, whether linked or unlinked, could be useful. (It might actually be more useful linked, especially if there was also a link to a way of reporting bugs on that page.)
Benjamin Kalish Forbes Library / 413-587-1012 / [email protected] 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 6:12 PM, Lazar, Alexey Vladimirovich < [email protected]> wrote: > 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 <[email protected]> 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 > > [email protected] > > Twitter: http://www.twitter.com/kmlussier > > #evergreen IRC: kmlussier > > > > Aleksey Lazar > IS Developer and Integrator - PALS > http://www.mnpals.org/ > >
