Seems like a lot of things can cause this issue, additional hard-drives that are in sleep state, networked drives in sleep, internet search.
It's actually a tough design choice with any multi-channel search: Do you start displaying results from the first sources available or do you wait until all sources have reported in?
If you wait you get latency, but if you try to stream results the order/top result can change which is jarring to the user and creates UX race conditions.
Index the installed apps in the start menu search and make these appear in the search result.
I want to be able to press Win-key -> type "fi" -> press nter to open Firefox.
On MacOS and all Linux distros I`ve every tried, it works flawlessly.
For other (more advanced) search mechanisms, implement these in a designated search option in the taskbar, startmenu, standalone etc.
This means that Microsoft needs to abandon Bing and whatever telemetry they can gather from the user in the start menu search making this unlikely to be the reality going forward.
You return whatever results you can before the user perceives a delay. If you think a web search or slower search is useful (it isn't) then add a button to expand the search such as "Search the web for ${search term}" or "Continue this search in Explorer".
mulmen's laws of UX design:
1. It is never ok for the user to perceive input delay.
2. There must be no compromise in service of law #1.
3. Your UX improvement is a regression until proven otherwise.
4. To change the UX you must first destroy something you love.
> For any UX/UI designer out there a delay is perceived when it is greater than 200ms. Those are milliseconds.
Delay is perceptible at around 10ms, and considered tolerable for generic apps (not realtime games, obviously) to about 100ms, and that's been established for quite a long time. 200ms is...too much.
>Do you start displaying results from the first sources available or do you wait until all sources have reported in?
In the strongest possible sense: Neither, ever. You can not treat instant results and un-cacheable delayed results of unknown quantity/size as the same element of UI. It's a fallacious premise. (Sorry to sound aggressive.)
Microsoft developers found a way to do it, without having to make any compromises or impact user-visible performance in any way.
Their brilliant trick to achieving this -- wait for it, it's so simple -- was nothing more than simply... sitting in the same building that Bing is served from! With a mere 1ms latency over 100 Gbps fibre from their office to the Bing servers, there's no pesky latency or packet loss to interfere with the instantaneous UX response times and deterministic behaviour.
Those pesky users are just "whining" and need to learn to sit at Redmond, just like they do.
It's actually a tough design choice with any multi-channel search: Do you start displaying results from the first sources available or do you wait until all sources have reported in?
If you wait you get latency, but if you try to stream results the order/top result can change which is jarring to the user and creates UX race conditions.