I certainly agree with this one, and I’m trying to think about how it might best be implemented without having to add a whole, complex UI/preferences area to set e.g. default search options per-type or something. This recent response seems to be related:
What I am starting to see is an increasing value from having more options on the Search dialog, but also some ways of either setting Defaults (per-user), or simply remembering previous settings…
So here are some thoughts on adjustments to the Search process that might at least address part of your request, and possibly others:
- Differentiate between regular (e.g. Ctrl-K) Search and other types of searches, e.g. Create Entity From In-Line Text Search (CEFITS for short
)
- There is already a difference between search dialogs in the text you see in the input field, which differentiates them, so maybe it’s already handled on the back-end
- Allow selection of multiple Types in search filtering
- I’m pretty sure this is a prerequisite for any solution to the entity proliferation problem in search, right?
- I don’t think it’s reasonable to try to precisely target only the Type you want to link to from every potential context - that suggests a whole, complex UI to handle it, which I’m trying to avoid.
- Once you have differentiation of search contexts, you can try to do more intelligent things with each context for search.
- What if we had an option (toggle) on the Search dialog for “CEFITS” that would limit search results to types that have a direct relationship with the current entity’s type?
- And/or a toggle that references a simple stored list of any types that were linked to from CEFITS in the past for that type (regardless of formal inter-type relationships, i.e. the option mentioned above) and filters to only those types?
- Provide an option (another toggle?) either on the Search dialog itself, or in user Preferences to “start with last search settings” or something. Or perhaps a toggle that is “Save as default search filter for this context” or something.
- Consider making it contextual per-“area”/search method, as above, so that Ctrl-K and CEFITS searches can have different saved filter starting points.
Some of those may be good or bad ideas. Maybe all are bad. But in general I am just advocating for the idea of adding some more explicit control to the Search UIs, but trying to avoid option proliferation. In the fullest expression of the ideas above, you’d end up with I think only 3 extra toggles, which I think would bring a lot of additional benefit, at least for certain users/approaches.
The main alternative I can think of would be something like a user preference area with either a series of toggles for every type (big UI, cumbersome), or maybe some kind of multi-select with Type search to select only those types users wanted to be enabled for search by default. I think my proposed option above could accomplish similar results for a majority of cases, even though it is less precise, while also being more nimble/fluid, exposing the options more to make them more discoverable, etc. Basically I am interested in what would be a “good enough” solution to the problem without being over-engineered.