@Arian_Bozorg, work cannot begin on this until the open questions are addressed. moving it to the top of the product backlog in the meanwhile.

Specifically

1. Do we commit to creating a unique LOD component library which we will need to maintain and does the WMF understand/agree with this decision?

2. Is the dot team responsible for implementing the missing menu heading or will the DS team at the WMF manage this?

The final open question (1 or 2 components?) is one the team would need to discuss with a designer.

@Sarai-WMF, would you be able to give insight on the current open questions?

Open Questions

• Ownership/maintenance: The scoped TypeaheadSearch pattern will be built using the combination of the Codex components Select and TypeaheadSearch, but it won't be introduced into the Codex library. We need to decide if this element would belong into a potential library of "LOD components" (see T338631)

Based on the discussion in the Wikidata leads sync, let's add the new component to a library of "LOD components" and Wikidata will implement the Select Menu Header element.

Regarding the pending open question:

Should this be implemented as two separate components instead of a composite component? Possibly we would then need to only inject the select/menu into vector and could reuse the existing typeahead search component

Unfortunately, I cannot recall the factors that made it sound feasible to implement only the select and combine it with the existing TypeaheadSearch (I believe that's what this question is about?). Looking at the component again, and considering its logic (the interaction between the select and TahS, the ability to use prefixes), it would appear that the element should have its own API. I believe that, ultimately, developers might be able to provide better insight here, but the creation of a new ScopedTypeaheadSearch that combines Select + TahS and adds the necessary adjustments sounds more logical.

On the other hand, I'm noticing that the prototype linked in the task's description really has very limited interaction, and that it can potentially be confusing (it was created to cover just specific usability testing scenarios, and the search bar only takes the word "sport" – triggered by the key "s" – as an input). The component specs only define the interaction in big strokes, so let me quickly outline here the use cases/scenarios that I would have documented at the time:

1. Selecting a scope using the dropdown, then entering a value in the search bar: This would make the TypeaheadSearch component display suggestions for entities with a matching name or alias (same as current behavior), but also only which type corresponds to the selected scope (i.e., only matching Items, Properties, Lexemes or Entity Schemas are displayed as suggestions based on the users' selection and input).

2. Entering a value in the search bar, then changing the scope using the dropdown: The suggestions' menu is closed given that the users are interacting with a different element, but the value they inputted is preserved. When users focus on the search bar again, the menu will display suggestions that match the preserved input, but within the new scope they just selected.

3. Pressing enter or clicking the "Search" button, instead of selecting the first match displayed by the scoped menu (i.e., as in Wikipedia), takes users to the Special:Search page.

3a. If the input has a value, then results matching that value and the entered scope are provided:

3b. If no value was inputted in the search bar, then an empty Special:Search page [1] is loaded. For comfort, we could adjust the value of "Search in" to match the current search scope:

4. Users can use the prefixes corresponding to each type (Q:, P:, L:, E:) to scope their searches: As specified in the designs, 4a. The value of the scoping select should be updated to match the prefix entered; 4b. If the value of the select is modified after a prefix has been inputted, then the prefix is treated as plain text. Users would have to clear/delete their input to conduct prefix-based search again.

[1] Please note that, currently, Wikidata's Special:Search page appears to display a bug. The namespace "Property" is included by default within the "Search in" parameters. On the other hand, the scope appears to be ignored when a search is conducted.

notes from a discussion on 2025.01.17:

questions & ambiguities

• Where should this show up? Just Wikidata? Or any mediawiki with wikibase installed?
  • probably any wiki where enableEntitySearchUI is true. We need to confirm whether this is intended
• This epic doesn't currently cover the rollout process
  • need to decide whether we want a feature flag
  • we'll also probably need to notify the community, and have a plan for this
  • in the rollout process, we'll need to consider the (possible) impact on other wikis
• What should happen in a non-js context?
• Do we want to develop in situ or as a standalone?

other notes

A sketch of what we're thinking:

<ScopedTypeaheadSearch>
  <ScopeSelect />
  <CdxTypeaheadSearch />
</ScopedTypeaheadSearch>

For a first milestone: create an MVP. This is to be a standalone html page with some vue components, and it is not intended that we'd merge this.

Where should this show up? Just Wikidata? Or any mediawiki with wikibase installed?
This will be implemented initially on Wikidata and we will discuss with Cloud and Suite for how / when they would like to add it
This epic doesn't currently cover the rollout process
The rollout process is:

• Announce the new feature to the community
• Release on Test and Beta
• Wait two weeks for any feedback
• Make any necessary changes
• Announce that the feature will be released on Wikidata
• Release on Wikidata

need to decide whether we want a feature flag
Yes we would like to have a feature flag

What should happen in a non-js context?
There is currently no parity in a non-js context, so this can remain as is

Do we want to develop in situ or as a standalone?
This may be more of a dev question, I am not sure of the implications here.

What should happen in a non-js context?
There is currently no parity in a non-js context, so this can remain as is

Based on how the current TypeaheadSearch is implemented, we might have to deal with this question. It starts off as html elements styled in Codex styles with css. When someone clicks into the input box, the full Codex component gets mounted, replacing the simple html/css version.

If we only change which component gets mounted and change nothing about the base html/css, there will be an awkward moment when the scope selector jumps into existence. I assume we'll want to avoid that.

We'll need to decide how to go forward:

1. Implement a non-js version of the component with the same styling, which can do a scoped search without the "typeahead" interactivity
2. Do the Vue component mounting earlier, maybe on page-load, rather than waiting for the user to interact with it. However, it is not clear to me whether this would entirely fix the UI-jumping problem. I also assume there's a performance penalty for loading the full component on every page load, regardless of whether it will be interacted with.

I'll caveat all this to say that I'm new to frontend work here, and there's certainly a lot I still don't understand. So there could be something simple that I'm missing. However, I suspect that getting a basic html/css version of the component working is a subset of the work for the fully interactive js version.

The spec includes searching by prefix, for example. typing P: should select the Property scope. I haven't been able to find documentation though about what all the prefixes are and how they map to the scopes. A couple questions:

• Is this use of prefixes for limiting a search already implemented, or is that being introduced in this epic?
  • If yes: Where can we find a list of prefixes that are already in use?
  • If no: What prefixes *should* be used? Are there any language-considerations for choosing these? (for example, the word for "Property" certainly doesn't start with "P" in every language)

cc: @Arian_Bozorg for the product perspective

It’s already implemented for Special:Search (but not for the “live” search results from the search bar – that part would be new to the scoped version). Special:Search supports any namespace or namespace alias (see Special:NamespaceInfo for namespaces or API for the aliases), but my guess would be that we only support the single-letter namespace aliases for entity namespaces (configured here): P for Properties (example), L for Lexemes (example), E for EntitySchemas (example). (Or should we also support the full namespace names?)

Yes, that's right. As Lucas said we already support this in Special:Search, but not type-ahead. As some editors are used to this pattern we wanted to support their current workflows.

The namespaces will be supporting are:

• P: for Properties
• L: for Lexemes
• E: for EntitySchemas

Hm, but how should this feature behave out of the box on an unconfigured Wikibase? The namespace aliases won’t even exist there. And what about other entity sources, e.g. federated properties?

I think one viable option would be:

• The scopes are automatically detected: one per entity type that’s stored on the local wiki in a separate namespace (in the main slot?). No scopes for sub-entity types (forms and senses), probably.
  • But I guess we still need a way to override this in production, because EntitySchema is not a real entity type yet, so any autodetection based on the EntitySourceDefinitions will not include it. Bleh.
• The prefixes / namespace aliases (P, L, E) would have to be manually configured (config option defaults to “empty”): without them, you can only switch the scope using the select, not by typing into the search input.

how should this feature behave out of the box on an unconfigured Wikibase? The namespace aliases won’t even exist there. And what about other entity sources, e.g. federated properties?

I think given the lack of usage of federated properties the latter is probably not an issue. For how it should work on other Wikibases I'd guess @Anton.Kokh / @jon_amar-WMDE would be the people to have opinions. My person, very uninformed, opinion is that we'd want to keep this feature having very similar behaviours by default on all wikibases.

@LarissaHonsek and @Arian_Bozorg - I noticed some differences between the Figma file and the prototype (linked in the description above), and it's not clear which one we should follow.

Figma: the component doesn't have a "Search" button. It's just the scope dropdown and the text input:

Prototype:

• initially, on load, there is no search button
  
• when hovering over the component, a search button appears. After clicking into the element, the button remains:
  
• there's a ? icon next to the search input. Hovering over it shows information about prefix searching. This wasn't described at all in the design file, and we haven't implemented this on the engineering side
  

Current Implementation: Search button is always shown. There is no ? icon and associated tooltip

Questions

• Should the component have the Search button always? never? only when the component is hovered or active?
• Should the info tooltip about search prefixes be added? If so, we'll need design specs for it.

Search button

I can clarify that the behavior displayed by the component in the prototype (where the Search button appears on hover) corresponds to the original TypeaheadSearch behavior in Vector 2022. This is not the behavior displayed by this element in production anymore, so I'd recommend discarding that option.

As to whether the ScopedTahS should display a Search button by default or not (which can be defined using TahS' useButton property), I for the life of me cannot explain nor recall why there's an inconsistency in the designs. There are two options: a) we decided to remove the button to simplify and avoid redundancy (after all, in Wikidata, pressing 'Enter' has the same effect as using the 'Search' button, although the later also offers direct access to Special:Search), or b) it's an oversight. I'd tentatively would assume the latter, based on the fact that those v1 specs are the only ones missing the default button, and that there aren't any research findings nor notes justifying the removal of said element. I still find this quite odd, though, and would take it as an opportunity to decide whether you want to simplify the main search component instead of taking a more conservative approach.

Prefixes tooltip

We originally decided not to communicate the availability of the prefix search mode to all users to avoid confusion. We wanted to cater to this more advanced search method, but make sure to prioritize the dropdown selection approach.

If your team (that still feels weird to write!) decided to provide a similar help element, you need to know that Codex just released a Popover component, which would really reduce design and implementation load.

Updated the demo wiki based on the code currently on master: https://patchdemo.wmcloud.org/wikis/a5ddef352e/