- this feature has now been tagged with a LC priority, and I tag you here, while this has been discussed at several occations in the App Interaction SIG.

Adding Mike Taylor's note from 2018

"We are interested in cross-module search: that is, a whole-system search facility where you could search for smith and find a patron called John Smith, a library administrator called Jane Smith and a book written by Kim Smith. (I believe this is in Filip's UX plans.)

How can such a thing be implemented? Each searchable UI module will need to register its searchability somehow, and present an API that can be invoked to enable it to search its own objects (patrons, administrators, books, whatever) on behalf of another module.

How can the results of such a search be presented? The multi-search module can't possibly know how to render results of many different types – especially as the set of types might change as different UI modules are added. So each searchable module will need to present an API for displaying an object. (Or perhaps the response of the module's search API will be a list of rendered components that can be directly integrated into the multi-search results.)

So it's starting to look like we might want to formalise the notion of a "searchable" module. If we do that, are there other such interface properties that we might also want to formalise? Will we need a notion analogous to Java's interface that UI modules can implement, just as Okapi modules do?

Filip raised the question of how to handle the display if the UI has multiple modules capable of handling the same kind of object? He gave the example of a regular Bib module, but also a specialist module for editing MARC records. If multi-search finds a bib record, should it use the Bib module or the Users module to display the result? What about when the
user clicks through the full record: which module should get control? Filip's favoured approach is that each kind of object has something like a MIME Content-Type associated with it, and part of the user's personal configuration is his preference for which application should be used to handle each content type – much as one sets such preferences in MacOS.

If the display of a multi-search module includes components rendered by other modules, how often should be the same be true in other situations? I raised the example that the Users module's UX mockup shows loans: should these be rendered by the Users module (which would then need to know the details of the Loan web-service and the structure of the objects it returns) or by the Loans module? (I favoured the latter, but the majority in the meeting favoured a monolithic Users application that knows all about loans.)

This issue is a placeholder for discussion with no expectation that we will implement anything soon: it's more that we want to be careful not to make any design decisions that will preclude our doing this later."

Good.
I think the current Universal Search paradigm includes settings, at least as an ambition. Going forward there might be a few settings...
iOS, Windows, IntelliJ, Visual Studio, etc

Yep, I would assume you could also search tags using the universal search box. Not as sure about settings, but I don't see why not. Most of those things will have search capabilities of their own (e.g. User search within Users app, Tag search within Tags app) but the Universal Search app is a single search box that searches everything.

What about searching for tags? Settings?