We're currently using prefixsearch with the following params

const params = {
    action: 'query',
    prop: ['description', 'pageimages', 'pageprops'].join('|'),
    piprop: 'thumbnail',
    pilimit: 15,
    ppprop: 'displaytitle',
    generator: 'prefixsearch',
    redirects: true,
    pithumbsize: 64,
    gpslimit: 15,
    gpsnamespace: 0,
    gpssearch: term.replace(/:/g, ' ')
  }

I think we stole it from the Android or iOS app. It works well for "zeroing in" on an article using part of the title but it's not a search like our users are expecting. We would like to cast wider and always have some results even if the relevance is getting low.

@EBernhardson do you have any recommendation about which search api/params would serve us better here? thanks!

Prefixsearch does exactly what it says, it searches for prefixes. If you want to use fulltext search, its something like:

{
  "action": "query",
  "list:" : "search",
  "srsearch": "my words to look for",
}

I suspect though that this is already known, and was decided to be not fit for purpose. Could you expand on this?

Yes, using Prefixsearch was on purpose but I didn't know srsearch was fulltext. We'll try it out in the app. I guess I could have read the docs.

In T268751#6656273, @SBisson wrote:

Yes, using Prefixsearch was on purpose but I didn't know srsearch was fulltext. We'll try it out in the app. I guess I could have read the docs.

Using prefix search will always treat the input as a prefix, the underlying data structures that allow the prefix search to efficiently look for fuzzy matches mean it can only ever start a search from the first character and proceed forward one character at a time (think of it like a DAG of utf8 codepoint transitions).

The srsearch parameter is only valid against list: search or generator: search, which triggers the fulltext search functionality.

I would generally suggest you implement something similar to what the website's do, for consistency of UX (although I'm certainly no UX expert). On the website both actions are used, depending on context. When the user is typing the content is sent to prefix search. The intent here is to complete the query prefix the user has provided. When submitting we first perform a near match search(srwhat: nearmatch provided to list: search). If the near match returns a page we take the user directly to that page and skip the search results page. If the near match fails we perform a full text search and show the results.

I would generally suggest you implement something similar to what the website's do, for consistency of UX (although I'm certainly no UX expert).

this is what we are doing now, but
it has a slight difference in the KaiOS search result (pilimit gpslimit set to 15)

Web Search	KaiOS Search (same as Mobile Web Search)

@AMuigai Could you tell us some of the search term example?

In T268751#6672318, @hueitan wrote:

I would generally suggest you implement something similar to what the website's do, for consistency of UX (although I'm certainly no UX expert).

this is what we are doing now, but
it has a slight difference in the KaiOS search result (pilimit gpslimit set to 15)

Web Search	KaiOS Search (same as Mobile Web Search)

That's only the first stepof the mobile interface, where we attempt to expand the query prefix into a full query. The nearmatch and fulltext search is what happens when the search string is submitted as the fulltext search query, on mobile the user is sent here for the nearmatch and fulltext stage: https://m.mediawiki.org/w/index.php?search=cat

Thanks @EBernhardson

This is useful! I don't know there is the addition query after the submission in mobile web page until your comment here!

the request url : https://en.m.wikipedia.org/w/index.php?search=bread+recipes&title=Special%3ASearch&profile=default&fulltext=1&ns0=1

It has the result we are looking for, but it seems like it doesn't come from the public api, is this only available within mediawiki? (UPDATE: I have found the answer from the previous comment)

In T268751#6656036, @EBernhardson wrote:

Prefixsearch does exactly what it says, it searches for prefixes. If you want to use fulltext search, its something like:

{
  "action": "query",
  "list:" : "search",
  "srsearch": "my words to look for",
}

My bad, I didn't reach this comment before, i think this is what we are looking for, let me try more on it.

https://en.m.wikipedia.org/w/api.php?action=query&list=search&srsearch=bread%20recipes&format=json

The differece between mobile web and kaios is no submit button (same to ios)

what I suggest :

1. do the prefix search first, once receive no data from prefix then do the fulltext search
2. do the fulltext search when prefix search result was given only few (exact number to be confirmed)

Note: currently there isn't search indicator, having another search api request require more time from the user side given the slow connection.

UPDATE: After a speak with Stephane, let's try with the fulltext without prefix for our initial test.

(PR https://github.com/wikimedia/wikipedia-kaios/pull/298)

@hueitan the PR is still a draft but this task is in "code review". What's the status?

something doesn't look quite right here, look at the "page description" (line under the title of the page in the search page) comparison between kaios and mobile web

kaios before this task	kaios after this task	mobile web

What we are showing on the second line is not page description but a snippet showing where the search term was found in the article.

this is expected behaviour to show snippet in the description line.