gutenberg-mobile

gutenberg-mobile copied to clipboard

Describe the bug It was reported in 4363115-zd-woothemes that enlarging the text size using iOS's Dynamic Type is not being applied on the app's editor.

To Reproduce Steps to reproduce the behavior:

1. Go to iOS Settings > Display & Brightness > Text Size, change the text size to a larger font size.
2. Open the WordPress mobile app > My Site > Blog Posts and select a post to edit.
3. Notice the text in the editor is still in the original size.

Expected behavior The user expects the editor's text changes to align to the iOS's Dynamic Text setting.

Screenshots

The screenshot was taken in the app's editor when iOS's text size setting changed to the largest size.

Smartphone (please complete the following information):

• Device: iPhone SE
• OS: iOS 14.8 (and iOS 15)
• App version: 18.3

I spent some time researching this issue. I did not arrive at a solution, but wanted to share my findings.

Findings

There are areas within the editor that already support Dynamic Type, but it is largely outside of Aztec Rich Text blocks. The editor UI driven by React Native within WordPress/gutenberg adapts to a user's Dynamic Type setting. However, there are several places where maxFontSizeMultiplier is utilized limiting the maximum font size allowed. There is room for improvement in the form of removing usage of maxFontSizeMultiplier and/or addressing layout issues when larger accessibility font size are used.

Basic Dynamic Type support for Aztec Rich Text blocks was added in https://github.com/wordpress-mobile/AztecEditor-iOS/pull/858. However, subsequent changes in https://github.com/wordpress-mobile/AztecEditor-iOS/pull/1345 may circumvent the original work in some contexts (e.g. block themes where individual block font sizes are set).

Next Steps

• Determine — from a UX design perspective — how Dynamic Type and block theme font sizes should coincide. The former is an accessibility feature for the app user/author, the latter is a design tool that ultimately impacts the site reader. Is it appropriate to merely combine the two values? This may result in some really large text in the editor.
• Expand our usage of UIFontMetrics so that we appropriately scale the base font size for a given Rich Text block.
• Refactor so that Rich Text blocks adapt to updates to the Dynamic Type setting without a need to close and re-open the block editor.

Related

• UIFontMetrics
• https://github.com/wordpress-mobile/AztecEditor-iOS/pull/858
• https://github.com/wordpress-mobile/AztecEditor-iOS/pull/1345
• https://github.com/wordpress-mobile/gutenberg-mobile/issues/605#issuecomment-641894958
• https://github.com/WordPress/gutenberg/issues/37995

Determine — from a UX design perspective — how Dynamic Type and block theme font sizes should coincide. The former is an accessibility feature for the app user/author, the latter is a design tool that ultimately impacts the site reader. Is it appropriate to merely combine the two values? This may result in some really large text in the editor.

This is definitely a tricky question, should the accessibility have more precedence than the content format? After testing other editors, I see in some cases the content format takes precedence, although, for example, Google Documents combine the two values (i.e. Text size specified by A11y and font size). Probably the latter makes more sense, although as you mentioned, it might lead to situations where the text is too big.

Probably [combining accessibility and content format values] makes more sense, although as you mentioned, it might lead to situations where the text is too big.

I agree combining the values is likely the most expected from a user experience. We would need determine a way of displaying the content in a manner that is helpful. I.e. a font size so big that only a single character fits on each line is not that helpful IMO. Maybe we combine the values up to a certain maximum to avoid extreme outcomes?

Now that the editor is incrementally supporting display of font size formatting, I wonder if it makes sense to display a notice if post content has font size set and the device is using scaled text. Maybe merely making the user aware of the context is enough to empower them to take any action they deem appropriate?

Note Both your device and the post content have font size/scale settings enabled currently. This may result in unexpected font sizes while editing the content. [Tap to Disable Scaled Text for this Editor Session]

I agree combining the values is likely the most expected from a user experience. We would need determine a way of displaying the content in a manner that is helpful. I.e. a font size so big that only a single character fits on each line is not that helpful IMO. Maybe we combine the values up to a certain maximum to avoid extreme outcomes?

I totally agree, in case we combine the values, it would be helpful if we set a limit on both sides, i.e. have a minimum and maximum font size.

Now that the editor is incrementally supporting display of font size formatting, I wonder if it makes sense to display a notice if post content has font size set and the device is using scaled text. Maybe merely making the user aware of the context is enough to empower them to take any action they deem appropriate?

Note Both your device and the post content have font size/scale settings enabled currently. This may result in unexpected font sizes while editing the content. [Tap to Disable Scaled Text for this Editor Session]

That's a good idea, we'd need to figure out when and how the notice would be displayed, but this would definitely be helpful to the user 👍 .

Following https://github.com/WordPress/gutenberg/pull/57339, initial support for Dynamic Type will be introduced in 24.0, due to be rolled out to users on January 22nd. I've also created a task list at https://github.com/WordPress/gutenberg/issues/57354 to follow up on enhancements, including enforcing a max/min size, refactoring RichText to automatically update, and reviewing other areas of the editor. I'll close this specific issue as we now have initial support and will track iterations elsewhere. 🙇‍♀️