Powertoys: PowerToy Run: Unexpected priority of search results for "term"

Created on 22 May 2020  路  14Comments  路  Source: microsoft/PowerToys

Environment

Windows build number: 18363.778
PowerToys version: 18.1
PowerToy module for which you are reporting the bug (if applicable): PowerToys Run

Steps to reproduce

  • Alt + Space
  • Type term

Expected behavior

"Windows Terminal" (which has "term" in it) should be ranked higher than "Character Map" (which seems to be shown because of the "ter M")

Actual behavior

"Character Map" is ranked higher than "Windows Terminal"

Screenshots

image

Issue-Bug Priority-0 Product-Launcher Resolution-Fix-Committed Run-Results (Programs)

Most helpful comment

@alekhyareddy28 : Taking the space into account sounds good!

Two remarks:

  • Without any prior knowledge I never would have expected that the file description matters at all. This is why I - with experience with how e.g. ReSharper matches Intellisense - falsely assumed that "ter m" was a match (i.e. I had the wrong mental model). I'm not saying that searching the file description is is a bad feature. Not at all, it can lead to some good hits when I don't know exactly what to search for. The problem in this case is that the search results do not give me the reason why this item is shown. Which makes it even harder to understand when such a search result gets a high priority.
  • Highlighting matched characters would greatly improve the experience with search terms of three or four characters, where unexpected matches (like "CharacterMap) just happen.

All 14 comments

weird, i don't see this on my comptuer.

charmap.exe is the exe so that can't be causing the match as well.

I noticed this behavior in 18.0, but before I got around to filing a bug report, the update to 18.1 happened (which restarts PowerToys automatically). When I saw that the issue with "term" still occurred, I explicitly shut down PowerToys and started them again.
Is it possible that some kind of cache file left over from 18.0 influences my 18.1 results?

Yes this is the same issue.

@RWeigelt Just realized why i wasn't getting this. I was looking for the native, built in app, not
https://www.microsoft.com/store/productId/9WZDNCRDXF41

@alekhyareddy28 this could be why. Exe name / file description property is "CharacterMap."
image

@crutkas, yes I think you are right. I shall look into the exact scores in more detail tomorrow. However, I was wondering if we want to give the description the same importance as the name and executable name. Right now we are taking a max of all the three values and sorting based on that. I was thinking we should probably give more weightage to the name, followed by exe name and then finally the description.

So if we have two results with scores for name, exe name and desc as {55,30,12} and {45,30,65}, we would want the first result to show up rather than the second because the name seems to be a closer match. However, rn we are just taking the max so the second result would be higher in priority. Probably something like compare the name scores, if both are the same, go to exe scores, if they are the same then go to the description. Any thoughts?

I think like if query starts with the name, it should be a higher score. Term here should be ranked higher since it is the start, not a fuzzy

So I looked at the scores, Windows Terminal gets a score of 75 and CharacterMap gets a score of 91. This is because the score is inversely proportional to the string length and the index of the first match which is 8 for terminal and 6 in case of characterMap. However, we are not considering that the character before the matching index is a space. So instead of taking 8 as the first index, it should rather be 0 because it starts with that. With that change the score of terminal increases way more than that of CharacterMap.

@alekhyareddy28 : Taking the space into account sounds good!

Two remarks:

  • Without any prior knowledge I never would have expected that the file description matters at all. This is why I - with experience with how e.g. ReSharper matches Intellisense - falsely assumed that "ter m" was a match (i.e. I had the wrong mental model). I'm not saying that searching the file description is is a bad feature. Not at all, it can lead to some good hits when I don't know exactly what to search for. The problem in this case is that the search results do not give me the reason why this item is shown. Which makes it even harder to understand when such a search result gets a high priority.
  • Highlighting matched characters would greatly improve the experience with search terms of three or four characters, where unexpected matches (like "CharacterMap) just happen.

There is a similar issue when searching for "power". The first match is rather odd, followed by better matches. I have it set to show 6 matches). (Using 0.18.2)

  1. Debuggable Package Manager
  2. PowerPoint
  3. PowerToys (Preview)
  4. Windows PowerShell (x86)
  5. Developer PowerShell for VS 2019
  6. Windows PowerShell

Powertoys-Run-Search for Power

Looking at the shortcut for Debuggable Package Manager...

Target: C:\Windows\SysWOW64\WindowsPowerShell\v1.0powershell.exe -NoExit -Command "& { Import-Module Appx; Import-Module .\AppxDebug.dll; Show-AppxDebug}"

Comment: Microsoft Visual Studio Debuggable Package Manager PowerShell Session

While matching applications, we take the exe name as well into consideration. However, in PR #4020 this was taken care of so that Debuggable Package Manager is not above Powershell. That being said since power is a strong match in powershell.exe it will still show up.

image

@alekhyareddy28 I suspected that was the case. I'm just not sure it's always the best move.

As I think through how I would use this feature, and how I currently use the WIN-Launch and Win-Run tools, I see competing priorities that somehow need to be reconciled since this power toy feature seems to be blending the two existing tools to an extent.

If I'm trying to launch a program that is likely on the start menu or in the list of programs, I generally will know it by its name, not the executable name. This also goes for shortcuts. In these cases, the executable name is much less important.

If I'm trying to launch a command-line tool that may not have a shortcut or menu item, then I probably know it by the executable name and that should be given priority.

There are a number of other competing cases as well, like currently running apps, frequently used apps/commands, etc.

Given all of that, if I had to choose between giving executable name priority, program name priority, or giving them equal weight, I think I would come down on the side of giving priority to program name over executable name. Especially since that is what seems to be shown in the results list, regardless of what matched.

@Blueric, agreed. We are working on that prioritization. However, it may not be ready by 0.19. Thank you for your feedback.

Fixed in 0.19.0, please visit https://github.com/microsoft/PowerToys/releases/ for the latest release

Was this page helpful?
0 / 5 - 0 ratings

Related issues

amorenew picture amorenew  路  3Comments

aminya picture aminya  路  3Comments

SWinxy picture SWinxy  路  3Comments

smz picture smz  路  3Comments

patware picture patware  路  3Comments