cuelang.org: allow an author to pre-populate a search box with a specific tag

[jpluscplusm]

What page were you looking at?

https://cuelang.org/examples/shortcodes/search/

What version of the site were you looking at?

cue-lang/cuelang.org@b24925a

What did you do?

I wanted to place a search box at /docs/reference/modules/ to display a list of all pages tagged with modules.

What did you expect?

That the search shortcode would allow me to pre-populate a search query with a tag, or some specific term.

What did you see instead?

I could only pre-populate a content type.

[Wies-UsMedia]

@jpluscplusm For this feature, would you prefer to see the pre-selected tags as unchangeable by the user, similar to content type? Or would you prefer the user being able to modify the selected tags?

[jpluscplusm]

@jpluscplusm For this feature, would you prefer to see the pre-selected tags as unchangeable by the user, similar to content type? Or would you prefer the user being able to modify the selected tags?

Summary

I'd opt for both the pre-selected search terms and tags to be modifiable by the user, with the only hard requirement being that they should be able to be added to. If the implementation is made significantly simpler by ruling out modification of pre-selected tags, then that option is also fine. I don't feel we want to block the modification of pre-selected search terms.

---

@Wies-UsMedia The rationale for a content type being unchangeable when set was that the search box was being presented inside a specific content hierarchy, and it would feel odd for a user to be presented with the "wrong" content type when its such a fundamental part of the hierarchy. Each page's URL has (more or less) the content type baked in, and if it were possible to copy and share a URL that clearly lived inside content-type A, but which displayed search results for content-type B, then we felt it would potentially be confusing.

I think this issue's use case is different. Or, at least, the risk of confusion is significantly reduced. Sure, we could have a search widget under a /docs/concept/all-about-foo/ hierarchy that initially presents tag foo, but if someone shares a URL with a q query-string that deselects foo and selects bar, then that feels like less of a problem.

My sense is that both a pre-set tag and search string should be editable by the user - unless that's much more complex to implement.

I think my only "must have" is that search terms and tags, when pre-set, should be able to be added to by the user. In other words, if a user is presented with a pre-set search widget for tag:foo "CUE bar baz" that displays 50 search results, we want them to be able to refine that list by adding more search terms and/or tags. If they can't remove the pre-set values that that's not a big problem - please be guided by the implementation challenges, there. I've just tested on the site, and tag:foo tag:bar contains an implicit logical AND (not OR) between the terms - which is compatible with this, to my mind.

[JorindeUsMedia]

Thanks for clarifying @jpluscplusm

Todo Us Media:

• Add option to add Tags (multiple I think to be flexible, so an array) to the search shortcode (optional field)
• Get the tags from the shortcode in the layout and/or js and preselect them before sending the search request to algolia.
• Algolia should now return results with the right content type & tags filters on. User can manually deselect tags after if they want to.

estimate: 2-3 hours

[jpluscplusm]

Reopening to reflect that predefined search text still needs to be considered.

[JorindeUsMedia]

Reopening to reflect that predefined search text still needs to be considered.

@jpluscplusm Do you mean if you manually add it to the url? The shortcode does not support adding a predefined query text at the moment.

If you mean via the url: http://localhost:1313/examples/shortcodes/search/?q=schema
I have no way of knowing if this is the first time you 're on the page with the search widget or if this url is the result of removing tags. The url is where we keep the 'state' of the widget. Right now we're not keeping track anywhere if the update of the url is caused by manually changing the filters or clicking a link on a docs page.

For instance:
I go to this page https://cuelang.org/examples/shortcodes > the predefined tags get selected and added to the url.
Result: https://cuelang.org/examples/shortcodes/search/?q=%20tag:encodings%20tag:%22commented%20cue%22
I now search for another term, lets say 'schema'. The urls gets updated and the page reloads with cause the search to trigger:
https://cuelang.org/examples/shortcodes/search/?q=%20tag:encodings%20tag:%22commented%20cue%22%20schema
I now remove the predefined tags, the url gets updated again:
https://cuelang.org/examples/shortcodes/search/?q=schema

So I can't decide when there is just a text query in the url but no tags: add preselected tags. Because that means that in the case above that there's no way of removing the predefined tags because they would get added again when no tags are present in the url.

[JorindeUsMedia]

Just discussed with jonathan. I've misunderstood the question.
What was missing from this issue is that we've now added the option to add predefined tags to the search shortcode but not yet the option to add a predefined text query. Jonathan will create a new issue for that one.

[jpluscplusm]

Closing as discussed with @JorindeUsMedia.

I've opened #3566 to track the predefined-search-text issue - but this additional feature will need to prove its necessity a few times before we'll choose to implement it.