Recent Search prioritization makes workflow with large menu less predictable and breaks context prioritization #113302

New Issue

Simon Thommes · 2023-10-05T20:23:13+02:00

Simon Thommes commented

2023-10-05 20:23:13 +02:00

System Information
Operating system:
Graphics card:

Blender Version
Broken: 4.0
Worked: 3.6

Short description of error
Not directly a bug but a regression in terms of UX in my opinion. I talked about it with @JacquesLucke and he told me to raise it as a high priority bug to be discussed.

I'll go over my general issues that I personally have with the feature and then give some explicit examples. Then we can evaluate if all the issues can be sufficiently resolved by adjusting the heuristics or if there needs to be a different solution.

My main issue with the feature that is disrupting my workflow is that it makes using the search less predictable. As I'm not keeping track of the history of added nodes in my head, it makes it more difficult to expect a search result when typing in a certain string, as the history ranking might distort the hard heuristics of the search.

My issues lead me to the question what exactly the goal of that feature was in the first place. In my personal opinion there is an objectively sensible way to sort search results, especially if there is context information (e.g. socket type) in play. I understand that massaging all the heuristics that are used in just the right way to get that perfect every time might be very difficult, if not impossible. The solution to that issue is in my opinion:

Trying to get as close as possible to the best sorting we can tweaking the weights, also if that potentially means removing some heuristics. As long as it's understandable why a list is sorted as it is, I can expect a certain pattern.
Providing ways alternative to the search to quickly add common nodes that are part of the regular workflow
Providing ways that users can easily and dynamically create custom selections of menu entries they want to prioritize (favorites)

Some examples:

Mistyping and hitting enter will be remembered, so if you delete the wrongly added node and type the correct word, there is a good chance that the result from the wrongly spelled search pops up as the first entry, although there might be a better match by letters
A very common issue is that currently history is prioritized over context. So typing add in the link drag search will give you either Math or Vector Math, whichever was last used, regardless of the socket type.
Same for parts of names. Just adding a Vector Math node and then searching for Math will prioritize the Vector Math node over Math. Another, more drastic example is searching Instance on, adding the Instance on Points node and searching for Points after, which will prioritize the Instance on Points node again.
But the issue goes beyond exact name matches. Even just Typing Poi, I would expect Points to have a higher priority in this case, regardless of which node I added before that.

In general I think this feature is just mixing two things that should stay separate. I get the idea on paper for certain cases, but practically it leads to so many more issues that it actually solves. And in my opinion it approaches the issue from the wrong angle.

I can see a searchable menu history work in general, but imo it should be complementary and not mixed into the regular search.

**System Information** Operating system: Graphics card: **Blender Version** Broken: 4.0 Worked: 3.6 **Short description of error** Not directly a bug but a regression in terms of UX in my opinion. I talked about it with @JacquesLucke and he told me to raise it as a high priority bug to be discussed. I'll go over my general issues that I personally have with the feature and then give some explicit examples. Then we can evaluate if all the issues can be sufficiently resolved by adjusting the heuristics or if there needs to be a different solution. My main issue with the feature that is disrupting my workflow is that it makes using the search less predictable. As I'm not keeping track of the history of added nodes in my head, it makes it more difficult to expect a search result when typing in a certain string, as the history ranking might distort the hard heuristics of the search. My issues lead me to the question what exactly the goal of that feature was in the first place. In my personal opinion there is an objectively sensible way to sort search results, especially if there is context information (e.g. socket type) in play. I understand that massaging all the heuristics that are used in just the right way to get that perfect every time might be very difficult, if not impossible. The solution to that issue is in my opinion: - Trying to get as close as possible to the best sorting we can tweaking the weights, also if that potentially means removing some heuristics. As long as it's understandable why a list is sorted as it is, I can expect a certain pattern. - Providing ways alternative to the search to quickly add common nodes that are part of the regular workflow - Providing ways that users can easily and dynamically create custom selections of menu entries they want to prioritize (favorites) Some examples: - Mistyping and hitting enter will be remembered, so if you delete the wrongly added node and type the correct word, there is a good chance that the result from the wrongly spelled search pops up as the first entry, although there might be a better match by letters - A very common issue is that currently history is prioritized over context. So typing add in the link drag search will give you either `Math` or `Vector Math`, whichever was last used, regardless of the socket type. - Same for parts of names. Just adding a `Vector Math` node and then searching for `Math` will prioritize the `Vector Math` node over `Math`. Another, more drastic example is searching `Instance on`, adding the `Instance on Points` node and searching for `Points` after, which will prioritize the `Instance on Points` node again. - But the issue goes beyond exact name matches. Even just Typing `Poi`, I would expect Points to have a higher priority in this case, regardless of which node I added before that. In general I think this feature is just mixing two things that should stay separate. I get the idea on paper for certain cases, but practically it leads to so many more issues that it actually solves. And in my opinion it approaches the issue from the wrong angle. I can see a searchable menu history work in general, but imo it should be complementary and not mixed into the regular search.

Simon Thommes added the

labels 2023-10-05 20:23:14 +02:00

dupoxy commented

2023-10-05 21:09:10 +02:00

same as #113289

Pratik Borhade referenced this issue

2023-10-06 06:31:11 +02:00

Geometry Nodes (4.1 alpha) - search behaviour #113289

Pratik Borhade commented

2023-10-06 06:43:21 +02:00

I can confirm. It indeed breaks the workflow. We already have few bug reports about this: #113302, #113289
I'm not sure in which cases "prioritizing previous search result" is useful (maybe when few letters are typed).
We already store last searched entry in buffer when f3 is pressed (since many versions).

I can confirm. It indeed breaks the workflow. We already have few bug reports about this: #113302, #113289 I'm not sure in which cases "prioritizing previous search result" is useful (maybe when few letters are typed). We already store last searched entry in buffer when f3 is pressed (since many versions).

Pratik Borhade added

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Recent Search prioritization makes workflow with large menu less predictable and breaks context prioritization #113302