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.