Obscure quick search behavior in Start11 v2

from Stardock Forums

I've had a strange issue that haunted me for weeks now: I quickly type "<win>cal<enter>" to run calculator, and instead I get VSCode.  Each.and.every.time.

After playing around with it for a while, it looks like Start11 is doing several things with its quick search (not the actual search thing, just the quick typing of some name) that are extremely counter intuitive / annoying / non-customizable (so each and every one of these is a bug IMO):

  • Apparently it is looking for whatever I entered as a substring of any word.  I would very much like to make it do only prefix-searching.
  • Also apparently, it is looking in the full paths of things to run, and I would very much like to make it consider just the executable name at the end of the path.
  • The search probably sorts the results using something silly like an alphabetical order of paths or whatever.
  • Once a non-default selection is made for some search, it becomes the default for that search forever (until a different one is explicitly chosen).

Here's how all of that leads to a disaster:

  • Clear the search history
  • Enter "cal" -- for some reason, it shows OneDrive???!!!
  • Do that quickly enough, and you learn to never use the search since it starts random crap.

This is exactly where I was -- only I somehow probably chose VSCode and then "cal" quickly got married to it.  Had I known that this marriage happened, I would of course arrange for a different one, but I didn't, and I suspect that many people would not guess that too.  Why are VSCode/OneDrive in the results? -- Because their executables have "local" in the path (verified by continuing the search with "local\prog" for vscode and "local\mic" for onedrive).

Again, this is just the quick search -- after a bad association is made I'm in a strange world where "cal" runs vscode, yet a search for "cal" tells me that calculator is the best match.

Why are the above four bullets bugs? --

  • Searching for any substring rather than a suffix makes no sense at all (but see below).
  • Searching through the full path includes random junk -- for example "cal" matches "local" which appear in a bunch of executable paths and is a surprising result.  I'm guessing that people who install some app called "rogue" wouldn't be happy with getting a long list of irrelevant apps when entering "rog" (since it matches "program files").
  • If, for whatever reasons, you disagree with the above and insist on searching any substring and the full path, then at least sort the results in a way that makes more sense.  I think that it's obvious that if I enter "cal", then I'm waaaay more likely to want calculator or calendar, rather than some random app that is in "appdata\local".  A prefix should score a higher position in the list of results, app name should make it even higher than that.
  • Setting a default is counter intuitive in a world where people are used to and expect a fuzzy search.  At least add a knob to disable this (but also please fix the above).  The knob would also have a side effect of letting people who bother looking at the settings know about this behavior.

 

start menu products
4,709 views 5 replies
Reply #1 from Stardock Forums Top

Hello,
I have forwarded your problem/question to Stardock Support Team for their assistance. Please keep an eye on this thread for any updates. We appreciate your feedback and patience.

Basj,
Stardock Community Assistant

+1 Loading…
Reply #2 from Stardock Forums Top

Once an app is run for a given search term it is given higher points.  This is done because often people really want something which would not be the default for a given term.  This is not a bug.  The OS also does this.  You would be equally annoyed if there are two shortcuts which match cal for example (calculator and calendar for example) and you wanted calendar and it was never the default.  By factoring in your choice the app adapts to your needs.

Substring searching is an interesting one.  Win10 does not do this which means a search for SVN will not produce results for VisualSVN which isn't ideal for a user either.  I think it is something of a user preference thing.  Substring matches are given a much lower weighting than other matches.  So SVN.exe for example would get more points than VisualSVN.  We have modified search in a future S11 build to give weighting to end of word matches too and downweight mid string matches further.

As for the sort order, it is based on search points calculated using the a number of values.  A-Z isn't one of those factors unless terms end up with identical points.

During investigation I did confirm the path is incorrectly being used.  It was supposed to be using the first subfolder only as an additional weighting factor, but was including the full path instead.  This has been addressed for the next build and thank you very much for reporting this to us.

I suspect the issue with the path is whats been causing you most trouble as the normal substring matching is extremely low weighting and is liable to only show up if you have no other results.  The folder name code does use substring matching but the weighting should have been reducing the impact so better matches were well above them.  The weighting of these has been tweaked a bit now.

The path is an important factor to a degree as for example a search for Visual Studio code by searching for VSCode would not match by default as the shortcut is Visual Studio Code and the exe is code.exe.  But the folder it is contained within is VS Code which can be used as a match.

I am a little confused about the reference to quick search as the item run when you press enter will be the item selected in the search results.  So what you see on the screen should reflect what is run.  If this is not the case for you then a video showing this or screenshots would be most helpful.

I would expect to see the above changes in an updated 2.07 beta (not the 2.07 build from yesterday) soon.

WindowBlinds - Free yourself of the default settings, customize your desktop.
Reply #3 from Stardock Forums Top

I'm happy to hear that there's a weight system -- it didn't seem to me like there is one given that the default no-search-history for "cal" found onedrive instead of calculator where it's both a non-prefix and a path part, so I'd expect calculator to be much higher...  I'll wait for the fix then.

As for the "quick search", it might be a confusion of terms on my part -- I meant that all of this is happening when I just hit the windows key and type stuff rather than use the search icon.

A screen recording.

Reply #4 from Stardock Forums Top

Beta has been updated with some potential fixes. For details, please see

https://forums.stardock.com/526650/get;3924003

Thanks for the feedback, elibarzilay.

Sean Drohan
Stardock Product Lifecycle Manager

Reply #5 from Stardock Forums Top

Thanks!  -- My bandwidth is kind of limited, so I'll try it out when it propagates to a new version...