What are the strengths and weaknesses of dynamic responsive typography?

Question

By dynamic responsive typography, I mean a system where the type changes in real time based on an external attribute of the environment or the user, without the user explicitly setting it.

Here is an example of dynamic responsive typography, but it will only work in some browsers and you need to have a camera to see it.

For those that can't use the link, when I am sitting in my normal position, the text looks like this:

But when I move closer to the screen, the text gets smaller and looks like this:

---

@Ben Brocka initially liked the concept in UX chat - which really is the place for people interested in UX to hang out.

Answer 1

For the most part the pros/cons of this come back to the classic Adaptive vs Adaptable interface argument, where Adaptive interfaces automatically adjust based on user interaction, and adaptable interfaces allow users to manually tweak them.

A problem with this in particular is that text size is an accessibility issue. Not everyone has the same eyes, so some users will want different sizes at different distances; this may even vary based on whether they're wearing their reading glasses, their contacts or other factors.

A big problem is this idea of course kills the classic method of getting closer to text to read it. When observing users with poor eyesight, odds are you won't have to wait too long for them to hunch over or scooch closer to to the text. The adaptive text could negate the need for this of course, but the problem with adaptive systems is if it's not perfect, it gets in the way.

Adaptable interfaces, AKA Personalization is almost considered a plus in interfaces, especially considering the above accessibility concerns. So you have a development problem (why are we making it adaptive when it's already adaptable? Will most people even need to change this?) and a user problem (Dammit I was getting closer so I could read it! Don't make the text smaller!). The biggest problem to my mind is "Who moved my cheese?", AKA "Dammit where did that button go". Adaptive interfaces have a bad habit of changing interface elements just as we get used to them by shuffling menu items, list orderings or in this case, the text size.

In the standard monitor & desk set up I see little use for this; your text size is probably set properly from the get-go, and if you're getting closer to the screen you're probably trying to see things better, since there's rarely another reason for the distance between user and screen to change.

The best use I can see for a system like this would be one where either the user or the "screen" would not generally be in a consistent location. For instance, if one were playing a Kinect game where they need to be physically a certain distance from the TV. Everyone's set up is different, so there is good reason to be changing the font size regularly as the user moves.

This could even be on a projector screen or Pixelsense/Smart Wall style screen. When using these large screens a user's distance from the screen could vary by several feet, as opposed to a few inches with a phone/monitor. A plus here is that your "screen" is large, and can probably afford to skew towards large text. I see this being more useful for small amounts of large enough to read text like interface elements or on screen instructions moreso than reading an adaptive book.

Mobile I'm more on the fence about; mobile has more of a variation I could see this being both a possible hindrance and a possible benefit on mobile. But then you're back at the risky point where you have to get it just perfect or it feels like more of a burden than a help.

Answer 2

I think this kind of thing creates more problems than it solves. On web UIs I assume the user has set the browser font size to a comfortable size for general reading. I use the user set font for the bulk of the text content, i.e. the main reading font. Other font sizes used on the site are derived from the user set font (that is set with units of *em*s or %).

To try and be tricky and outthink the user....generally speaking our (UX) world isn't ready for that.

Answer 3

I see this type of responsiveness as having niche use where the user has little control over font size e.g. in an operating theatre where the surgeon is moving around the table and away from/closer to the screen

Answer 4

As a tech demo it suggests many benefits. Most of the answers here seem to be concentrating on the negative impacts of what happens when you bring the device closer to yourself, thereby decreasing the fontsize, but I believe the benefits of this system are when you come at it from the other direction - how to present content to users viewing it where their eyes are further away. (In my testing the fontsize never drops below 20px, well above the minimum suggested value of 16px (yes, px isn't really the ideal method for specifying text size for accessibility, but it's all this demo displays currently).

The default mode of the demo is Realtime. As a demo of how the system works this is the default setting, but is unlikely to be actually useful over and above a tech-demo to show how it works. Practical uses are limited here.

The more versatile options are the other two settings; OnLoad and Breakpoints

Detecting how close the user is to the screen when the site loads means the site itself is being more intelligent and can cater for how best to initially display the site / app to the user currently viewing it - for instance if this is being viewed on a smart TV where the user sits further away from the TV than a laptop user would do so it means the font-size can be larger so it is more visible from a distance.

Operating OnLoad rather than in realtime means it's less 'juddery' and just opens at a particular setting and stays as such while you use the site / app. However, the drawback of this is that detecting OnLoad means it's going to override the default font size setting put in place by the user.

Operating at set breakpoints is more in-keeping with the Responsive Design philosophy. In fact it is already in current use, albeit without camera detection in this way. For example informationarchitects.net discussed this and have also implemented it on their site - viewing the site on larger devices shows increased font-size and linespacing. As they discuss:

The size of your body text doesn’t depend on your personal preference. It depends on reading distance. Since in general computers are further away than books, the metric size of a desktop typeface needs to be bigger than the sizes used for printed matter.

I would suggest one possible use of the Breakpoints feature is that it uses the default fontsize as already determined by the user onload (such as whether they browse with increased fontsize for accessibility purposes) and then use that as the default. Once the user gets closer / further away then start detecting the proximity and adjust the font size accordingly.

Adapting the display of your application based on the screen dimensions it is viewed on is one thing, but that doesn't take into account how the user is actually looking at the device. If we can take other criteria into account while presenting content to users then it is very possible that we can find new and improved ways of doing so.

As the InformationArchitects.net article states:

“Not everything always works in your favor when you design for the screen. Interaction design is engineering: it’s not about finding the perfect design, it’s finding the best compromise.”

Sure, this camera fontsizing item isn't perfect, it's clearly only a tech-demo (all the Lorem Ipsum is a bit of a clue there) but really it's trying to think about how the user actually views the web these days. We can't always assume everyone holds their iPad at exactly the same distance from their face - some hold it like a book, some rest it on their lap, others leave it in a cradle on the table. By catering the fontsize to the user as well as the device properties is very much about putting the user first and not just assuming everyone uses everything in the same manner as everyone else.

Answer 5

Not only is this invasive, raising numerous privacy concerns it also limits user choice. We shouldn't ever do anything that removes user choice. It's also based totally on assumptions about the visual acuity of the viewer as well as their preference of text size. It isn't sensible to make assumptions.

There are tried, tested and accepted methods of re-sizing text to suit a users needs and which a user has total control over.

Answer 6

This is the first I've seen a responsive typography demo, but my initial reaction is hate. I agree almost entirely with commenter Ben Brocka. It's not clear what problem this complex technological solution is intended to solve. In almost every reading scenario I can imagine, the primary reason for leaning in or bringing the device closer to my face is to see it better. Responsive typography short-circuits that very natural instinct to move closer to something you want to see closer. It presumes an ideal apparent type size that may not suit me, and eliminates my ability to compensate.

The Kinect scenario may be one exception where you are moving in space for other reasons. But then, what is the harm is having your text behave naturally as it does everywhere else, and what is the benefit of having it scale independently from the rest of your Kinect environment?