arclight icon indicating copy to clipboard operation
arclight copied to clipboard

Add autocomplete to search within this collection form

Open jkeck opened this issue 7 years ago • 8 comments

Broken out of #244

#342 configures the autocomplete functionality for the search boxes that appear around the site generally (and are not context aware, per the Blacklight functionality).

The Search within this collection search box on the Collection detail page seems like it would be intended to be context aware (although I could be wrong about that, so that's a question for @anarchivist and @ggeisler).

If it is not intended to be a context aware autocomplete, then we can simply add the following snippet to the search form.

data: {
  autocomplete_enabled: autocomplete_enabled?,
  autocomplete_path: search_action_path(action: :suggest)
}

Otherwise, we may need to look into ContextFiltering. Theoretically we can set a field that we could filter against based on a cfq value we send in.

According to the documentation:

"AnalyzingInfixLookupFactory...currently support this feature, when backed by DocumentDictionaryFactory"

However; in my experimentation so far, whenever I added a DocumentDictionaryFactory, I stopped receiving any suggestion results (which is probably more my lack of familiarity on how to implement both).

jkeck avatar May 17 '17 22:05 jkeck

Another data point here... When you're faceted on Level, for example, the suggestion is not context-sensitive, so when you select a suggestion that's from a component:

screen shot 2017-05-17 at 3 15 26 pm

you won't find any results even though you took the suggestion, because you're Level facet is set to Collection

screen shot 2017-05-17 at 3 15 47 pm

but as expected if you clear the Level facet, the suggestion works fine.

screen shot 2017-05-17 at 3 19 56 pm

drh-stanford avatar May 17 '17 22:05 drh-stanford

@drh-stanford yes, that's what I mean by "are not context aware" above. Please note: this is how the functionality works in Blacklight itself.

jkeck avatar May 17 '17 22:05 jkeck

I'm not sure if this can be resolved until the other "Search Within" discussion is complete https://github.com/sul-dlss/arclight/issues/245

mejackreed avatar May 18 '17 19:05 mejackreed

As @mejackreed said, we might want to discuss this within a larger discussion about "search within" but my take is that when you are searching using the main menu-based search box (as opposed to the "search within this collection" search box), the search should not be context-aware. I believe this means the example @drh-stanford provided is the expected behavior (as @jkeck said).

I think it would, however, be preferable that the "search within this collection" search box is context-aware and only providing suggestions from the current collection. Both because a) in this context the user is intentionally searching within the current collection, and b) we aren't displaying explicit search constraints as we do for normal search results. Without the explicit search constraints it won't be nearly as clear to the user why searching on a term that they know exists results in zero hits (i.e., with normal results the displayed constraints make it more clear that the search is using both the search terms and the facet value(s) you've previously selected).

ggeisler avatar May 18 '17 20:05 ggeisler

@ggeisler 💬

As @mejackreed said, we might want to discuss this within a larger discussion about "search within" but my take is that when you are searching using the main menu-based search box (as opposed to the "search within this collection" search box), the search should not be context-aware. I believe this means the example @drh-stanford provided is the expected behavior (as @jkeck said).

I think it is fine for main search box to not be context aware for the scope of this ticket. It feels like "nice to have" functionality, but I'd probably be inclined to scope this ticket more tightly in the interest of delivering.

I think it would, however, be preferable that the "search within this collection" search box is context-aware and only providing suggestions from the current collection. Both because a) in this context the user is intentionally searching within the current collection, and b) we aren't displaying explicit search constraints as we do for normal search results. Without the explicit search constraints it won't be nearly as clear to the user why searching on a term that they know exists results in zero hits (i.e., with normal results the displayed constraints make it more clear that the search is using both the search terms and the facet value(s) you've previously selected).

👍 I also think this may be useful think about future potential ways to provide context-aware autocomplete down the road, even though I feel like it's out of scope for now.

anarchivist avatar May 19 '17 00:05 anarchivist

If we do consider making the main menu search box context aware, I'd like to involve @jvine in the conversation. It's not obvious to me that that is the right thing to do, even in the longterm.

I also think we need to talk more if we are going to implement search within on the collection detail page and not make that search box context-aware. If we don't, the user could see suggestions that aren't in the collection the user is currently examining, select one of those suggestions, and get zero hits. As I said above, unlike the regular search results UI, here that user will have no visible indication of why the suggested term produced zero hits. I agree this might be acceptable for now, but it might also be confusing enough that we shouldn't implement search within until we can do it as designed.

ggeisler avatar May 19 '17 15:05 ggeisler

I would be strongly in favour of suppressing auto-complete on the search-within box rather than provide suggestions that are not scoped to the current collection, even as a short-term thing.

jvine avatar May 19 '17 17:05 jvine

@jvine I think that's fine for the time being.

anarchivist avatar May 19 '17 20:05 anarchivist