UI Responsiveness (UXPROD-828)

[STRIPES-693] FOLIO on tablet and iPad Created: 03/Aug/20  Updated: 30/Sep/20  Resolved: 30/Sep/20

Status: Closed
Project: Stripes
Components: None
Affects versions: None
Fix versions: None
Parent: UI Responsiveness

Type: Bug Priority: P1
Reporter: twliu Assignee: John Coburn
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: Microsoft Word FOLIO test_10.5in Apple iPad_ 2020.7.23(1) (1) (1).docx     Microsoft Word FOLIO test_10.5in Apple iPad_ 8.21.2020.docx     PDF File FOLIO test_10.5in Apple iPad_2020.7.23.pdf     Microsoft Word FOLIO test_10.8in Huawei_2020.7.23(1) (1).docx     PDF File FOLIO test_10.8in Huawei_2020.7.23.pdf     JPEG File IMG_A98C39BB4027-1.jpeg    
Issue links:
Relates
relates to STCOM-659 Safari on * and Chrome on iOS shows "... Closed
Requires
is required by UXPROD-2611 FOLIO | Tablets | Responsive UX - Q3 ... Closed
Sprint: stripes-force 98, stripes-force 97, stripes-force 95, stripes-force 96
Development Team: Stripes Force
Affected Institution:
SHL
Epic Link: UI Responsiveness

 Description   

Problems are identified when access folio on tablets and iPads. Some information is hidden. Some buttons and dropdown lists are not responsive.

Story should focus on the following Shanghai Public Library needs for this sprint. FYI John Coburn

1. Their top concern is the compatibility of circulation-related functions on mobile devices. It would be awesome if we can solve this part first.
2. Target devices currently include iPad 2019 10.2in and Huawei tablet MatePad Pro 10.8in.



 Comments   
Comment by John Coburn [ 17/Aug/20 ]

Dropdowns not closing - I believe we've resolved this issue now with a recent update in dependencies. Continuing to address table displays and general responsive display.

Comment by twliu [ 19/Aug/20 ]

John CoburnIs there a site where we can test it? The Shanghai team reported they didn't see it resolved on the current demo site.

Comment by John Coburn [ 21/Aug/20 ]

For anyone who might be watching this issue, https://folio-testing.dev.folio.org/ is where the most up-to-date code can be seen.

Comment by LSP-刘梦洁 [ 24/Aug/20 ]

Here is the latest test document FOLIO test_10.5in Apple iPad_ 8.21.2020.docx .

Comment by Khalilah Gambrell [ 25/Aug/20 ]

John Coburn , is LSP-刘梦洁 feedback regarding Invalid date related to this story STCOM-659 Closed ?

Comment by Zak Burke [ 26/Aug/20 ]

Khalilah Gambrell, John Coburn, FOLIO test_10.5in Apple iPad_ 8.21.2020.docx says the browser is Google Chrome, but STCOM-659 Closed is specifically about Safari. While pursuing STCOR-442 Closed , I yanked a bunch of i18n-related polyfills out of bundle in the belief that Chrome supports all the necessary APIs, but I don't know if this is true of Chrome for iOS. I typically use https://caniuse.com/#search=Intl.Date to help assess this kind of thing, but Chrome on iOS isn't listed there.

But as I think through this, the polyfills in question are for pluralization rules, relative time format, and display names (country, currency, language). The display glitch here isn't about relative time format, which almost makes me wonder if Chrome-for-iOS suffers from the same bug as Safari, and that this is basically the same as STCOM-659 Closed . One thing they/we could try to assess this is restoring the commented-out polyfill lines and testing the display. If that works, well, then we're back to a "how do we shrink our bundle?" problem. If it doesn't, then the scope of STCOM-659 Closed just became much greater and the solution is probably to export our own i18n components through stripes-components, passing 99% of props straight through to react-intl, except for time-stamps, which we have to reformat in order for react-intl to handle them correctly.

Comment by John Coburn [ 27/Aug/20 ]

I agree, Zak Burke, I think we do need such a component. I'm not sure iOS Chrome is even free of the issue.

Comment by Zak Burke [ 31/Aug/20 ]

John Coburn is correct that Chrome on iOS also suffers from STCOM-659 Closed . On the one hand, implementing the fix in stripes-componentss and changing UI apps' imports is likely easy. On the other, there are >175 places where it needs to be changed and that's a lot of scut work.

Should we configure stripes-components to re-export all the react-intl components (do we want them all, or just the date/time related components?) right now so we can code all new work to import from @folio/stripes/components? That would prevent us from accumulating additional debt, though that's probably a minimal concern.

Khalilah Gambrell, do we have a sense of the priority of this issue?

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