Design & Implement Search Algorithm Selection UI

[tpendragon]

As part of the Search & Race work a number of options for algorithm changes were proposed - AI based, recency based, and perhaps others. However, each of those algorithms have a variety of trade offs that may not be the best solution for the research the person is trying to do. Therefore, we'd like to provide a way for researchers to select which algorithm they want. This gives us the benefit of being able to provide a less harmful default at some point, and also lets us get feedback on the results from users as they can compare algorithms against one another if they'd like.

We'd like this solution to be reusable in any of our discovery platforms. We can implement in Blacklight, but clearly document how that implementation works in case we need to re-implement in other non-blacklight solutions.

Steps to Implement

• Find and define all the ways we could switch search relevancy in the backend and define them here #3745
  • Options
    • Special request handler in Solr
      • We think this would be more powerful.
    • Send a bunch of arguments in every query (weightings, filters, etc.)
• Define how to set up two choices in test and development environments such that they don't reflect in staging/prod. #3746
  • I need a way to add an algorithm that's only in test/development, and document that.
  • Also will need a way to add fixtures that will reflect algorithm changes.
• Wireframe an interface for switching algorithms. #3747
  • Answer the question - where do we want to add this? The search bar? Where sorting is? Both?
  • What motivates a user to see and interact with the algorithm switcher?
    • "Not seeing the results you want? Try this!"
  • Add user stories here. Is this something we expect naive searchers to do, or more experienced searchers, do we want people to discover this feature fast or just be available and offer instruction so it's there?
  • How do we name the algorithms in a way that makes sense?
  • Wireframe some options here and pick one.
  • Just something to switch between and communicate which is in use.
• Implement interface (frontend) for switching algorithms #3748
• Would a help page allow for more explanation? The algorithms, the names, that kind of thing.
  * Can we articulate what the current algorithm does?
  * Can we provide some method of previewing two different modes?
  * Can we surface the score of the two algorithms without showing both results? Some way to compare algorithms?
• How should algorithm switching be implemented such that it goes into the code base? #3749
  • Connect with DACS to see what they think. Is it okay if it lives in Orangelight if it's not utilizing a new algorithm yet?
• Algorithm selector should set a query parameter (in url) that gets passed around. #3750
• Answer some functionality questions (Given the answers, this is implemented via a query param):
  • If I switch to a new algorithm, and open a new tab, and search, what algorithm does it search? The default.
  • If I switch to a new algorithm, then in the same tab go back to the home page and do a search, what algorithm does it use? The default.
  • If I edit the query after doing a search and switching the algorithm, what algorithm does it use? The new algorithm.
  • If I select a new facet after doing a search and switching the algorithm, what algorithm does it use? The new algorithm.
• Implement an example algorithm w/ swapper #3751