Universal Search App (UXPROD-858)

[UXPROD-919] Universal Search App (Search Across Apps) Created: 13/Jun/18  Updated: 05/Feb/24

Status: Open
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Universal Search App

Type: New Feature Priority: P3
Reporter: Cate Boerema (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: LC5, crossplatform, loc, metadatamanagement, requires-discussion, round_iv, search, search_enhancements
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to UXPROD-2591 Elasticsearch Open
relates to UXPROD-911 Files App Open
Requires
is required by STRIPES-212 Cross-module search Closed
Epic Link: Universal Search App
Front End Estimate: XXL < 30 days
Front End Estimator: Jakub Skoczen
Front-End Confidence factor: 30%
Back End Estimate: XXL < 30 days
Back End Estimator: Jakub Skoczen
Back-End Confidence factor: 30%
Development Team: None
Kiwi Planning Points (DO NOT CHANGE): 1
PO Rank: 37
PO Ranking Note: CB: Leaving ranking at calculated
Rank: Chalmers (Impl Aut 2019): R4
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: FLO (MVP Sum 2020): R4
Rank: GBV (MVP Sum 2020): R2
Rank: hbz (TBD): R2
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R4
Rank: Leipzig (Full TBD): R2
Rank: Leipzig (ERM Aut 2019): R4
Rank: MO State (MVP June 2020): R4
Rank: TAMU (MVP Jan 2021): R4
Rank: U of AL (MVP Oct 2020): R4

 Description   

App for searching across all FOLIO record types via a single search box (e.g. search users and items).

http://ux.folio.org/prototype/en/search?view=full



 Comments   
Comment by Theodor Tolstoy (One-Group.se) [ 20/Jun/18 ]

What about searching for tags? Settings?

Comment by Cate Boerema (Inactive) [ 20/Jun/18 ]

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.

Comment by Theodor Tolstoy (One-Group.se) [ 20/Jun/18 ]

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

Comment by Khalilah Gambrell [ 09/Jul/19 ]

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."

Comment by Charlotte Whitt [ 20/Jul/23 ]

Martina.Schildt - 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.

Generated at Fri Feb 09 00:11:27 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.