Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PowerToy Run: Unexpected priority of search results for "term" #3559

Closed
RWeigelt opened this issue May 22, 2020 · 14 comments
Closed

PowerToy Run: Unexpected priority of search results for "term" #3559

RWeigelt opened this issue May 22, 2020 · 14 comments
Assignees
Labels
Issue-Bug Something isn't working Priority-0 Bugs that we consider release-blocking/recall-class (P0) Product-PowerToys Run Improved app launch PT Run (Win+R) Window Resolution-Fix Committed Fix is checked in, but it might be 3-4 weeks until a release. Run-Results (Programs) Issue with program search in PowerToys Run
Milestone

Comments

@RWeigelt
Copy link

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

@crutkas
Copy link
Member

crutkas commented May 22, 2020

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

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

@crutkas crutkas added the Product-PowerToys Run Improved app launch PT Run (Win+R) Window label May 22, 2020
@crutkas crutkas added this to the v1.0 Release milestone May 22, 2020
@crutkas crutkas added Run-Results (Programs) Issue with program search in PowerToys Run Issue-Bug Something isn't working labels May 22, 2020
@RWeigelt
Copy link
Author

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?

@anirudhvee
Copy link

Yes this is the same issue.

@crutkas
Copy link
Member

crutkas commented May 29, 2020

@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

@crutkas
Copy link
Member

crutkas commented May 29, 2020

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

@alekhyareddy28
Copy link
Contributor

@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?

@crutkas
Copy link
Member

crutkas commented May 29, 2020

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

@alekhyareddy28
Copy link
Contributor

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.

@RWeigelt
Copy link
Author

@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.

@jyuwono jyuwono added the Priority-0 Bugs that we consider release-blocking/recall-class (P0) label May 29, 2020
@alekhyareddy28 alekhyareddy28 self-assigned this Jun 5, 2020
@alekhyareddy28 alekhyareddy28 added the Resolution-Fix Committed Fix is checked in, but it might be 3-4 weeks until a release. label Jun 5, 2020
@Blueric
Copy link

Blueric commented Jun 9, 2020

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.0\powershell.exe -NoExit -Command "& { Import-Module Appx; Import-Module .\AppxDebug.dll; Show-AppxDebug}"

Comment: Microsoft Visual Studio Debuggable Package Manager PowerShell Session

@alekhyareddy28
Copy link
Contributor

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

@Blueric
Copy link

Blueric commented Jun 9, 2020

@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.

@alekhyareddy28
Copy link
Contributor

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

@crutkas
Copy link
Member

crutkas commented Jun 30, 2020

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

@crutkas crutkas closed this as completed Jun 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug Something isn't working Priority-0 Bugs that we consider release-blocking/recall-class (P0) Product-PowerToys Run Improved app launch PT Run (Win+R) Window Resolution-Fix Committed Fix is checked in, but it might be 3-4 weeks until a release. Run-Results (Programs) Issue with program search in PowerToys Run
Projects
None yet
Development

No branches or pull requests

7 participants