Universal Search App
(UXPROD-858)
|
|
| 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: |
|
||||||||||||||||||||
| 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. |
| 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 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. |