[UXPROD-2695] Display Rounded Result Counts in Apps Using SearchAndSort (Inventory and Requests) Created: 29/Sep/20  Updated: 04/Feb/21  Resolved: 07/Dec/20

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: None

Type: New Feature Priority: TBD
Reporter: Cate Boerema (Inactive) Assignee: Cate Boerema (Inactive)
Resolution: Won't Do Votes: 0
Labels: elastic-search, result-count, search, searching
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File Skärmavbild 2020-08-17 kl. 15.55.00.png     Text File total-complete-only.txt     Text File total-core.txt    
Issue links:
Blocks
is blocked by UXPROD-2623 Wait for POC of Elastic Search - Roun... Closed
Cloners
is cloned by UXPROD-2702 Display Rounded Result Counts in Apps... Closed
Front End Estimate: Small < 3 days
Front End Estimator: Zak Burke
Back End Estimate: Small < 3 days
Back End Estimator: Bohdan Suprun (Inactive)
Estimation Notes and Assumptions: BE: All the logic is handled by RMB, CF team will only migrate to the proper version of the RMB and update interface versions.

FE: I am hopeful that this will simply be a matter of reading one or two new properties in the result set and changing the wording in the translation but I'm not sure how easy/onerous it will be to thread a new isEstimate property all the up through all the layers or if we simply apply that logic at the very top layer based on the size of the record set :/
Development Team: Prokopovych
PO Rank: 97
PO Ranking Note: 2020-10-05: Setting high PO rank, as this is necessary to complete the work Core Platform has started in UXPROD-2623
Rank: Chicago (MVP Sum 2020): R2
Rank: Cornell (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: GBV (MVP Sum 2020): R3
Rank: TAMU (MVP Jan 2021): R2

 Description   

Purpose: The scope of this work is to display the rounded result counts in "core" apps using the SearchAndSort component (i.e. Inventory and Requests). Other apps that use SearchAndSort (e.g. Courses, Licenses and Agreements etc) will be able to make use of the work done in the component BUT they will need to their own RMB upgrades first.

A separate feature will be created for apps using the SearchAndSortQuery component: UXPROD-2702 Closed

This work will be done by Core Functional after Core Platform has developed the infrastructure as part of UXPROD-2623 Closed

Description of work:

The totalRecords search result hit count number returned by RMB is precise if totalRecords is below 1000 and it is only an estimation if totalRecords >= 1000 (details).
The front-end currently displays "8081 records found" for estimations.
This is misleading (false precision).

"about" should be prepended for >= 1000.

The number should be rounded for >= 1000.

Algorithm for the front-end:

if totalRecordsEstimated is true
  print "about " + totalRecordsRounded
else if totalRecordsEstimated is false
  print totalRecords
// totalRecordsEstimated is undefined until all back-ends have upgraded RMB,
// handle this gracefully for folio-testing:
else if totalRecords < 1000
  print totalRecords
else
  print "about " + totalRecords + " (upgrade back-end for rounding)"

Story outline:

  • Upgrade Inventory to RMB containing fix
  • Upgrade Requests to RMB contsining fix
  • Display rounded result counts in SearchAndSort

Scenarios:

  1. Scenario
    • Given a result count is estimated (current understanding is that result counts above 1,000 are estimates)
    • When displayed in FOLIO
    • Then:
      • Result count should be preceded by "about"
      • Result count should be rounded using the "Rounded to first digit" method
      • For example:
        • Estimated result count from Postgres = 32351
        • Displays in FOLIO as "about 30,000 records found"
  2. Scenario
    • Given a result count is NOT estimated (current understanding is that result counts under 1,000 are exact)
    • When displayed in FOLIO
    • Then:
      • Result count should NOT be preceded by "about"
      • Result count should NOT be rounded
      • For example:
        • Exact result count from Postgres = 845
        • Displays in FOLIO as "845 records found"

Story outline:

  • Upgrade Core modules using SearchAnndSortQuery to latest RMB
  • Display rounded result counts in SearchAndSortQuery

Background Discussion:

  • Three rounding proposals were considered
  • Option B, "Round to first digit" was selected

Details on Rounding Options Considered:

3 rounding proposals are in the comments of MODINVSTOR-468:

A) Round to magnitude:

about 10,000 (3,000-29,999)
about 100,000 (30,000-299,999)
about 1,000,000 (300,000-2,999,999)
about 10,000,000 (3,000,000-29,999,999)

B) Round to first digit:

about 2,000 (1,500-2,499)
about 3,000 (2,500-3,499)
about 4,000 (3,500-4,499)
about 5,000 (4,500-5,499)
about 6,000 (5,500-6,499)
about 7,000 (6,500-7,499)
about 8,000 (7,500-8,499)
about 9,000 (8,500-9,499)
about 10,000 (9,500-14,999)
about 20,000 (15,000-24,999)
about 30,000 (25,000-34,999)

C) Round first digit to 1, 2 or 5:

about 2,000 (1,500-3,999)
about 5,000 (4,000-7,999)
about 10,000 (8,000-14,999)
about 20,000 (15,000-39,999)
about 50,000 (40,000-79,999)

This issue is about deciding whether there should be a FOLIO standard for rounding, and if yes, which to choose, and whether the front-end or the back-end should round the number.

Proposed API as of July 28, 2020

If the back-end rounds it should also provide to original (non-rounded) estimate, for example

totalRecords: 1431
totalRecordsRounded: 1000
totalRecordsEstimated: true

No rounding is needed for an exact number:

totalRecords: 1509
totalRecordsEstimated: false

https://github.com/folio-org/raml/blob/raml1.0/schemas/resultInfo.schema needs to be extended accordingly.



 Comments   
Comment by Cate Boerema (Inactive) [ 30/Sep/20 ]

Making an exception and carrying over rankings when splitting this feature from UXPROD-2623 Closed , as that is really an NFR which supports this feature. Hopefully that's okay with folks.

Comment by Cate Boerema (Inactive) [ 30/Sep/20 ]

Zak Burke and Bohdan Suprun could you please provide high-level estimates for this feature? If you think more stories are needed than what I have listed in the "story outline", please let me know.

Comment by Bohdan Suprun (Inactive) [ 30/Sep/20 ]

Cate Boerema,

It is 3 days, all the logic will be part of RMB, Core Functional will have to update modules to proper version of RMB and update versions of the API.
Note: Requests and inventory are served by separate backend modules, so we have to migrate two modules here.

Comment by Cate Boerema (Inactive) [ 07/Dec/20 ]

Closing as Won't Do because Elastic search should offer exact hit counts, thus obviating this issue

FYI Charlotte Whitt

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