issue #732: allows users to do a refinement search

[rzhang152]

Give users option to refine a search inside the initial search results on Dimes.

[ctgraham]

Hillel's team will be the authority, but some requests from me.

[helrond]

I have some higher-level questions about the goals of this PR (aside from the specific things that @ctgraham identified).

First, it seems like the net effect of this PR would be to remove one click at the expense of masking a lot of search functionality. Users can already get back to the previous search and refine from there by clicking on the "Back to Search" button. I'm not sure that allowing them to update the query only from within a collection view outweighs the additional complexity in code and UI that results. Our user testing indicated that users had no problem identifying and using that "Back to Search" button for search refinement.

I'm still not sold that a "search within this collection only" is a use case that we are experiencing on our end, so I think if we're going to continue to go down this road this should probably be a configurable feature. That would also allow us to do some testing before we implement to make sure this is something that works for users.

[rzhang152]

Thanks for your inputs Hillel.

I think a main purpose of requesting a search refinement feature is to provide the users with a clear picture of their current query, and an options for easily pinning down their search based on the current results they are viewing.

With that in mind, I totally agree that the minimap features allow users to easily click and jump to matches within collections. We also brought your thought and inputs regarding this request during the meeting with our Archives&Special Collections team yesterday. However, from our users' perspectives, we recognize that there are cases where they want to narrow down a search by focusing on a specific collection within the initial results. For instance, a researcher might be looking for a particular name within a specific collection of correspondence found in the search results. In addition, providing option to refine a search within search result page make it more straightforward for users to pin down their finding effectively. The refined search will be conducted on-the-fly and will not directly overwrite the query parameter until execution. This approach aims to minimize the impact on the current minimap and other complex UI features.

I also revised the code based on Clinton's and your input. Please let me know if any q or feedback.
Thanks again,

[helrond]

A couple other things, mostly very minor.

The translation for the user-facing label will also need to be added as described in the README.

[HaSistrunk]

Hi there! I'll weigh in with some feedback related to screenreader UX:

So for sighted users, the indication that a refined search has successfully completed is that they might see the minimap squares/links change, and they'll see their new search term in the input. For screenreader users, they'll submit the search and the page will reload with the focus moving to whatever record is in the url. If they've been exploring the collection, that will be somewhere in the collection context tree on the right side of the screen. The screenreader will then start from there since that has focus.

I'm open to ideas, but I'd suggest mitigating that potentially confusing pattern (that doesn't support WCAG SC 3.2.2) by adding an aria-live announcement with a message like "Links in minimap navigation have been updated to display new search results". We use an aria-live region already to tell users that collection details on the left side of the page have been updated when someone selects a new record using react-aria-live. You can see that implemented in components/PageRecords/index.js. It's not a perfect solution, but folks can at least receive some confirmation feedback after submitting a search and know to navigate back to the minimap to explore the new results.

[helrond]

I apologize for missing this earlier, but we've tried to use BEM class names so converting those here. I think I got all of them in my suggestions.

[helrond]

Hi @rzhang152 - I was just chatting with @HaSistrunk about the accessibility aspects of this PR. Fundamentally, the challenge here is that the refine search form reloads the page, which has a couple of knock-on implications related to both accessibility and usability:

• Because the page simply reloads instead of going to a search results page, it's hard for users to know what's actually changed. The aria-live implementation, at least as it is currently, won't change that because the announcement is tied to the onChange handler of the form, so every time that form value changes screenreader users get an announcement, but they don't get an announcement when the page reloads.
• Related, the focus on page reloads may not be where a user expects it to be - if a user has clicked down into a collection tree and then decides they want to do a refining search, they'll end up back at the same thing they had focused on, which may or may not have a hit associated with it.

After thinking about it, I'd like to suggest the following:

1. I don't think the aria-live approach is going to work for this use case without a lot of additional work to store the previous query and then implement a conditional to trigger an announcement when it changes. So, with apologies for leading you down the wrong path, I'd suggest removing that code. Instead I think adding some text in the refine search component which tells users how many hits are in the collection and what the query is, something like "64 hits for 'my query'" would give all users a better indication of what's actually happening.
2. The page focus could be changed by updating the target of the form to be the top-level collection rather than the object-specific URL, which would return users to the top of the collection tree. However, I think this is an area where user testing and feedback is needed - I'm not sure what users would expect exactly, and what's more or less confusing. This also has accessibility implications for folks using screenreaders.

Let us know how that sounds - we appreciate your thinking and work on this feature!