search

johnjung / bmrcportal

GNU General Public License v3.0
1 stars 1 forks source link

Search query highlights in results #149

Open MomoMoses opened 2 years ago

MomoMoses commented 2 years ago

I had thought this was in the original spec. Discussion may be needed to re-evaluate and decide. Also, perhaps more user research.

johnjung commented 2 years ago

If you can find this in the original spec we can consider it a bug- otherwise we can label this as an enhancement and find a time to schedule the work.

MomoMoses commented 2 years ago

this was issue #20 in the spec GitHub repo

johnjung commented 2 years ago

I think we should schedule this as an enhancement, not a bug, because we should consider the interface more holistically before adding this. In addition to these links we may want to add a search box to allow users to search within a specific finding aid. If we do that we should consider this in the context of the other types of search that are available on the site ("search website" and "search member collections".) If we don't add that search box specifically, just adding "previous" and "next" links as discussed in https://github.com/MomoMoses/portal-specs/issues/20 may not make sense.

Here are some notes about how different finding aid interfaces approach this issue. I used a list of good interfaces from https://github.com/johnjung/bmrcportal/issues/66 to find examples.

https://explore.chicagocollections.org/

The CCC uses a large search box at the top of the screen to allow searching across collections, labelled "Search", that is not present in the finding aid view. In the left navigation of a finding aid view, there is a search box labelled "Search Within" that allows for searching within a specific finding aid. When a user executes a search there, search terms are highlighted in the document but there are no "previous" or "next" links.

This site does not include a search box to search the website itself.

https://archives.library.wcsu.edu/caoSearch/

Connecticut's Archives Online uses a single search box box with a pulldown to search "all collections" or "this collection". Searches of "all collections" and "this collection" both return to the main SERP- search results in the finding aids themselves are not highlighted. This system also does not allow searching the website itself.

https://archives.chipublib.org/

The CPL's system includes a search box that allows users to "Search The Archives" on https://archives.chipublib.org/. That search box disappears when you visit a search result page- it is replaced by a small "Search within results" search box in the left sidebar. Within a specific collection it is again replaced by a search box with slightly different styling- this one is labelled "Search Collection". They don't put more than one search box on a page, but the position and styling changes of each search box seem a bit haphazard. The search box on the finding aid itself returns to the main SERP- search results in a specific finding aid are not highlighted.

This site also does not include a search box to search the website itself.

https://vaheritage.org/

Similar to the CPL, but with different positioning. The search box that allows users to "Search Finding Aids" is centered on the screen. On a SERP the search "Within Results" is in the right sidebar. Finally, with slightly different styling, a search box to "SEARCH FINDING AID" is also located in the right sidebar.

When a user searches within a specific finding aid, a small arrow appears next to "7 occurrences of [search term]." This arrow is an anchor leading to the first search result in the document. Each search result in the document includes "next" and "previous" arrows to cycle through the document itself.

This site does not include a search box to search the site itself. It does include "previous" and "next" links, but here those links are joined by a search box that specifically allows site visitors to search within a specific finding aid.

Summary

Before implementing this feature, we should produce a mockup of the feature within the context of the finding aid viewer. We should spend some time researching or brainstorming alternate approaches, and we should consider user testing our solution to be sure we're not creating any new problems. We should be sure that the solution works well on small screens like mobile devices and for assistive technology like screen readers.

MomoMoses commented 2 years ago

Good idea! Ok, I've finally gotten a chance to cogitate on all your great examples and discussion. I agree. Adding something like this willy nilly could cause more UX problems than it solves. Viz, the issues with variable styling you mention above -- cognitive load anyone!?