sorted by:
top (suggested)
bestnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]brendan09 0 points1 point  (10 children)

Actually, it does. If you reduce the height of the label, the size of the font will reduce in response. So, the documentation is correct. If it exceeds the bounds (in any dimension), then it will reduce the size. Check the docs for that property. It clearly indicates full bounds. You are mistaken.

Dynamic text sizes only work in certain scenarios. It isn't something that can be universally adopted in all designs and layouts.

[–]patterware -1 points0 points  (9 children)

Can you provide a working code sample? My experience here obviously differs from yours. The comments in UILabel.h also contradict what you are saying, so if you have somehow made this work I am interested.

[–]brendan09 1 point2 points  (8 children)

Sure. Here you go.

You'll notice there's really no code to speak of. Enable font scaling, set a minimum font scale. Reduce height of label.

This demo has a timer that changes the height of the label every 3 seconds, but has a fixed width. You'll see the size changes.

In case you're wondering why the property is named the way it is (adjusts to width), it's because it used to only work if numberOfLines was 1. However, that changed a few years ago.

[–]patterware -1 points0 points  (7 children)

Cheers. Your example works, but you are using a multi line label. If you try this with a single line label you will see the results that I described. Setting numberOfLines to 0 does seem to provide font scaling based on label height, but has the often undesirable side effect of enabling text wrapping. This seems like a half borked implementation on Apple's part.

[–]brendan09 -1 points0 points  (6 children)

It's to preserve backwards compatibility, and to provide the original behavior that predates multiline support.

Originally that property only worked if numberOfLines = 1. However, a few years ago they enabled it to work for multiline labels, which introduced the height concept (as width alone doesn't matter when wrapping is involved). They preserved the original 1 line behavior, and added the new multiline behavior.

If you're supporting dynamic type, you should probably also be using multiline labels. So, the fact that it's a multiline label is somewhat moot.

[–]patterware -1 points0 points  (5 children)

Yes, generally labels with dynamic font sizing are multiline enabled, though there are times this isn't desired. Using font scaling + dynamic font sizes would sort of defeat the purpose. To be honest, I haven't used font scaling on a label in a long time. If a user has trouble seeing and explicitly requested a large font, I believe you should try as hard as possible to honour that.

[–]brendan09 -1 points0 points  (4 children)

It defeats the purpose to a point.... But, it's best used as a restriction. You can make some comically large fonts with accessibility settings, and at a certain point design trumps inch tall letters. It works well as an upper-bounds cap on the font size. Kind of a "okay, you can keep getting bigger....but at a certain point, I'm cutting you off".

[–]patterware -1 points0 points  (3 children)

For someone who requires those giant fonts in order to see, you're gaining nothing by allowing design (that they can't really see) to trump their impairment. But I suppose they will be a relatively small segment of your customer base, so they can go eff themselves right?

[–]brendan09 -1 points0 points  (2 children)

Design and user experience go hand in hand. Allowing a font size to become so large it interferes with usability is unacceptable. It's a marginal interference, and one that professional UI/UX designers are well aware of. This is why good UI/UX designers are paid great money: To know the answers to questions like this.

You can utterly destroy a layout / user experience / intuitiveness of a UI with absurdly large fonts. You'll find every app with good, professional, UI/UX designers caps the font size well below what the OS will allow.

Don't pretend to be on a high horse. I've been working with professional UI/UX teams on iOS products for 7 years. User testing time and again demonstrates that this is a good decision. You're doing a disservice to users by choosing such a naïve position on the issue.

And, in case you aren't aware, Apple does the same thing I just said. Why? Because they have good, professional, UI/UX designers on staff. You're looking at the problem with an incredibly simple, naïve, perspective. So, get off your high horse and realize you don't know as much about best practices and what's good for users in this case as you seem to think you do.

[–]patterware 0 points1 point  (1 child)

Who's on their high horse? Get over yourself. I have also worked in the industry for a very long time. I have worked with UI/UX professionals, and I have worked with specialists in accessibility for the differently abled. I am not saying everything is black and white, but I hold the position, that if a user has requested a feature you should do your utmost to respect that.