Comment 5 for bug 1152863

Thanks Dan and Thomas!

I'll share the coding concerns with the developers, if they haven't seen them already.

Dan, you asked the question of whether we could just teach students AND = && / OR = || / NOT = -

The answer I've received repeatedly from our academics is 'no', and I can see their point. If it were just a matter of teaching NOT = -, there would be no problem as this has become a de facto standard on the Web. Using && and || is just not intuitive. In the case of the latter, you might need to first start the lesson by making sure everyone knows where the pipe key lives on the keyboard.

AND and OR (or whatever their equivalents are in other languages) are intuitive because they have real meaning in the language that the user speaks. You make the valid point that there might be frustration because the same search strategy doesn't work in the basic and advanced search interfaces. However, on the flip side, there might also be the frustration that the more intuitive operators can be used in all of the electronic resources provided by their library except the catalog.

You also suggested that we focus on giving the advanced search box the ability to nest Boolean queries. This focus was actually how we started thinking about the project. I looked through other search interfaces for examples on how we could support more complex nesting without adding further complication to the interface. While we had some ideas of ways to support more complexity in the nesting, each of these ideas seemed to further complicate the advanced search interface, making it more confusing not only for those who might want the complex nesting, but also for those who might just use the advanced search interface to add more limiters to the search.

Ultimately, my team here believed that manually entering complex Boolean queries with the more intuitive operators was more straightforward than improving the GUI to support the more complex nesting.

I'm not saying it's a perfect solution, and we certainly were open to working with the community to support the best implementation. However, when I posted a message about the project to the general list last month, the only feedback I received was a question regarding the release that would see this new feature and an e-mail about ongoing work for an Evergreen add-on search option that would also support traditional Boolean operators - http://markmail.org/message/n7j2s363jsj6asgp.

My hope was that if there were any concerns about this approach being "weird," that I would have heard it at that time BEFORE the coding had begun. If I had received this type of feedback at that time, I could have delayed the start of coding and then explored alternate approaches with the community. Given the feedback that I received, I assumed that people either a) liked the approach, b) didn't care or c) saw the bit about there being a setting to disable it and mentally made a note to disable it when the time came.

I hope you can understand that, at this point, we are limited in our ability to make major changes to those larger implementation details. If the additional config.tt2 options to identify limiters on the Boolean search tab are introducing too much complication, we can look into removing them. I just need to run it by a few folks here to make sure I'm not missing something. However, we just don't have the resources to start from Square 1 again.

Kathy