Idea: "Accepted results"

[nilshoerrmann]

I'm not sure how to phrase this better than having "accepted results", but I often search for the same terms in the panel. Especially, when I'm dealing with large collections of pages where using the section navigation is cumbersome. In these cases, I have a keyword that I enter again and again, still the result list doesn't adapt to this repetition.

It would be interesting, if this plugin could integrate some kind of "accepted result list" which would be used to prioritize and highlight certain results in the UI. With "accepted results", I refer to previous search results I actually clicked on – like an additional, personalized result index.

I know this feature might raise privacy concerns. But it could be an optional pro feature for the panel only and could use localStorage. This feature would certainly not be for everyone, but at least for me personal, an optical clue saying "you already chose this result before"* would be very helpful.

---

* It's a bit like how :visited links work, just more in the sense of :found.

[nilshoerrmann]

Not very beautiful, but something like that:

Moving those results to the top would even be better.

[distantnative]

I like the idea... basically it'd be training the search what results are more likely to be the correct ones.

Implementation I have no idea yet.
Probably doesn't make sense just to count in general what result has been chosen, but this might need to be tied to the search term... and then to be smart about that one.

Seems like a big undertaking for some later time.

[nilshoerrmann]

I thought about tracking search terms and chosen results and using the click count to weight those results.

Say I twice clicked result Z and once Y, I‘d like to see the results ZYABCD…

[distantnative]

Yes, but it wouldn't be great if it only remembers that for the exact search term, e.g. zeit - you would want that to also go into the ranking of zei and zeitspr - which makes it very difficult (touching machine learning grounds).

[nilshoerrmann]

The additional index could look something like this:

{
  "zeit": {
    "url": "texte/zeitsprung", 
    "count": "5"
  },
  "reise": {
    "url": "texte/...",
    "count": "1"
  }
}

Yes, but it wouldn't be great if it only remembers that for the exact search term, e.g. zeit - you would want that to also go into the ranking of zei and zeitspr - which makes it very difficult (touching machine learning grounds).

Couldn't that be done using the same fuzzy search that is searching the main index? Just looking at the previous search terms in this case?

It's more about being clever and pretending machine learning ;)

[distantnative]

You mean the same sqlite vodoo that I already don't get (only somehow get it to work)? XD

Making it fuzzy (which is so much vodoo itself) bears at least one bigger problem.
Given

zeit:
  id: 7
  count: 1
zeit: 
  id: 8
  count: 3
zei:
  id: 7 
  count: 4
polizei
  id: 99
  count: 10

If we now start typing a new search, with the term zei and make a fuzzy lookup on that table. We of course want to get a count of 5 for the id 7 and 3 for id 8. So we have to search fuzzy among the terms combine counts for results with the same ID.... but we actually wouldn't like to get the polizei one in there... but it will appear due to the fuzzy search

[nilshoerrmann]

Maybe for this feature, fuzziness is not that important at all. It's more about matching words. So if I enter zei I would expect zei and zeit from your example in the "accepted results". polizei will be in the normal search results nonetheless.

So matching "accepted results" could work like "typed term is start of stored string".

[nilshoerrmann]

So if I entered olizei, no "accepted results" would be shown, only the default search results.
It's not about replacing the existing search but about enhancing the result list.

[nilshoerrmann]

To simplify this, whitespace could be ignored.

[distantnative]

Trying to capture some thoughts on this here:

Things to consider:

• Is this something centrally stored for all users (then we could use the same sqlite) or rather only per user?
• If per user, storing it on the server starts to get into privacy policy territory (creating a search history)
• One could use localStorage for this feature. However, then all the additional logic needs to implemented in JS/Vue and kind of disconnected from the rest of the plugin.
• The feature then also would only be available to the Panel search, not the PHP search.
• Using localStorage has the issue that we disconnect results from the actual data which might have changed or even got deleted. How to deal with that?
• Can we manually remove an entry form the learned list?

The last points really makes me doubt that localStorage is valid option here. So we would need to get the list from the backend - then it'd probably only make sense to offer this feature for the SQLite provider. And to make it an aggregate across all users. But how useful is it then still?

Ways to go about it:

• If a search result gets clicked on, store somewhere a row with search term, model id and count - if existing, increase count
• When searching - in addition to the normal search - look through this table if any of the table entries has the current search term as prefix (term*). We can only do a lookup from the very beginning. Makes it dumber than the actual search.
• Display any matches from this table above the results of the actual search.
• Shorten the actual results to match the configured Panel search result limit again.

[nilshoerrmann]

I'd like the idea of it being stored globally because this most likely will improve the result list over time (more users building the same suggestion list). For privacy reasons, it would be great thought, if this feature could be disabled generally in the configuration.

Can we manually remove an entry form the learned list?

Maybe some ideas:

• The plugin could store the recommendations in a separate SQLite database so that the data could easily be erased manually by deleting the database file.
• The plugin could bundle two fields the developers can add to their panel pages, one to clear all recommendations and the other to clear the recommendation for the current page.
• The plugin could provide site and page methods to clear recommendations for the given context so that developers can handle deletion themselves, e. g. by using the Janitor plugin.

[distantnative]

If it uses SQLite, we can also add to hooks the default to remove entry when the page gets deleted or so at least.