Description
When the user has set a very large system text-size setting, the layout can change pretty dramatically. For example, compare (on iOS):
| No scaling | Largest setting |
|---|---|
 |
 |
Apple's Human Interface Guidelines say:
Prioritize important content when responding to text-size changes. Not all content is equally important. When someone chooses a larger text size, they typically want to make the content they care about easier to read; they don’t always want to increase the size of every word on the screen. For example, when people increase text size to read the content in a tabbed window, they don’t expect the tab titles to increase in size. Similarly, in a game, people are often more interested in a character’s dialog than in transient hit-damage values.
This seems like sensible advice. Here is what's needed to complete this issue:
- Set the system text size to be very large
- Go through all UI areas of the app
- Wherever you see less-important content where we can save space by clamping to a max scale factor, do so.
In my "largest setting" screenshot above, the "Mark all messages as read" button seems like a great candidate for this treatment. It's huge at that size. The content in the message list is important and (usually) new/unfamiliar, so it definitely deserves higher priority for readability. I think the compose-box inputs, especially the content input, are also higher priority than the mark-as-read button. (It should be reasonably easy to know what message you'll be sending and where.)
For how to implement the clamping, start by reading these docs: MediaQuery.textScalerOf and TextScaler.scale and the scaler-clamping logic we've already implemented for emoji reactions.
Metadata
Metadata
Assignees
Type
Projects
Status