Responsive Typography(informationarchitects.net)
informationarchitects.net
Responsive Typography
http://informationarchitects.net/blog/responsive-typography/
15 comments
> I think the 'most people can't...' is off slightly because good vs bad is purely a personal, instinctive thing.
Typography is not subjective. That non-experts are unable to distinguish between good and bad typography is simply a consequence of the fact that “incompetent people are inherently unable to judge the competence of other people” [1].
[1] http://news.yahoo.com/people-arent-smart-enough-democracy-fl...
Typography is not subjective. That non-experts are unable to distinguish between good and bad typography is simply a consequence of the fact that “incompetent people are inherently unable to judge the competence of other people” [1].
[1] http://news.yahoo.com/people-arent-smart-enough-democracy-fl...
>This is no criticism, but for an article on responsive type/design seeing the page being slightly off in terms of fluidity made me smile. Try resizing the article down as narrowly as you can, for me it brought up horizontal scroll bars.
As it should. Adaptive page design is about adapting to different screens, and their design works from an iPhone to a 27" Mac.
It's not about never showing scrollbars when you make the screen narrower than the intended width.
Really, what should they do, show a one-word, long narrow column of text to avoid showing scrollbars?
As it should. Adaptive page design is about adapting to different screens, and their design works from an iPhone to a 27" Mac.
It's not about never showing scrollbars when you make the screen narrower than the intended width.
Really, what should they do, show a one-word, long narrow column of text to avoid showing scrollbars?
Good criticism, maybe I was unfair but resizing a browser pane to the width of a mobile device brought up scrollbars which was unexpected.
Sorry if this is a little off-topic, but I thought I’d mention it in case anyone’s curious...
The behaviour of CSS3 media queries is a little counter-intuitive (he said, politely) in this respect. The widths you match against in a media query explicitly include the width of any scroll bar[1], yet in general you have no way to control or even determine the width of such a scroll bar. That means if you write responsive CSS to match a mobile-friendly width of w pixels in a media query and then style your content to use the entire w pixel width you might expect to have, you can wind up with a horizontal scroll bar if your content is more than a screen long and your browser displays a vertical scroll bar that eats into the available width.
Mobile devices typically work around this by not displaying scroll bars full-time anyway, but if you resize a typical desktop browser window to the same size as the screen on a mobile device, you will sometimes get surprising results. The adjustment can be relevant if you’re designing wide layouts to take advantage of modern widescreen laptops as well, though at those resolutions you might be less concerned about leaving a few pixels spare in the width to allow for a vertical scroll bar that might appear.
[1] See http://www.w3.org/TR/css3-mediaqueries/#width
The behaviour of CSS3 media queries is a little counter-intuitive (he said, politely) in this respect. The widths you match against in a media query explicitly include the width of any scroll bar[1], yet in general you have no way to control or even determine the width of such a scroll bar. That means if you write responsive CSS to match a mobile-friendly width of w pixels in a media query and then style your content to use the entire w pixel width you might expect to have, you can wind up with a horizontal scroll bar if your content is more than a screen long and your browser displays a vertical scroll bar that eats into the available width.
Mobile devices typically work around this by not displaying scroll bars full-time anyway, but if you resize a typical desktop browser window to the same size as the screen on a mobile device, you will sometimes get surprising results. The adjustment can be relevant if you’re designing wide layouts to take advantage of modern widescreen laptops as well, though at those resolutions you might be less concerned about leaving a few pixels spare in the width to allow for a vertical scroll bar that might appear.
[1] See http://www.w3.org/TR/css3-mediaqueries/#width
Just FYI, I read this article on a mobile device and did not see scrollbars.
I have an awed respect for iA's unrelenting attention to detail here, but ultimately, I believe it shouldn't be the responsibility of the type designer to grade typefaces to different display contexts.
This is a runtime problem. Designers need more control over the antialiasing algorithms used by the output medium.
This is a runtime problem. Designers need more control over the antialiasing algorithms used by the output medium.
I don't think it's that simple.
Check out any high-quality font recently released by Adobe, like Garamond Premier Pro. It comes in different "optical sizes", one for small print, one for slightly larger print, one for regular body text, one for large display sizes, etc. This is in addition to light, regular, semibold, and bold weights for each optical size. Type designers have been doing this since 500 years ago, and digital types are just beginning to catch up. You can't have one font that looks exactly the same in all media, all antialiasing algorithms, and all sizes and resolutions.
Most people don't even notice, but serious type designers care about these subtle differences. Besides, antialiasing alone won't solve this problem as long as screens vary greatly in pixels per inch. No matter how good your antialiasing algorithm is, text at 96ppi is going to look different from the same text at 326ppi. Just like text printed on coarse paper will look different from text printed on glossy paper.
Check out any high-quality font recently released by Adobe, like Garamond Premier Pro. It comes in different "optical sizes", one for small print, one for slightly larger print, one for regular body text, one for large display sizes, etc. This is in addition to light, regular, semibold, and bold weights for each optical size. Type designers have been doing this since 500 years ago, and digital types are just beginning to catch up. You can't have one font that looks exactly the same in all media, all antialiasing algorithms, and all sizes and resolutions.
Most people don't even notice, but serious type designers care about these subtle differences. Besides, antialiasing alone won't solve this problem as long as screens vary greatly in pixels per inch. No matter how good your antialiasing algorithm is, text at 96ppi is going to look different from the same text at 326ppi. Just like text printed on coarse paper will look different from text printed on glossy paper.
Optical size variants (the size at which the text appears in your field of view, and its size relative to other type in a layout) are different from DPI variants or paper coarseness variants, though.
Paper coarseness variants will generally be designed around the physics of ink, to trap it in the junctions of small letterforms and prevent ink bleeding. Optical sizes tend to be more about the relationship between headline and body, with things like tighter standard kerning, taller x-heights, and so on. A DPI variant should only concern itself with aliasing, and aliasing is a render-time issue. You can design a typeface to counter this from the foundry side, but a more sustainable solution would be to counter it from the software side.
Paper coarseness variants will generally be designed around the physics of ink, to trap it in the junctions of small letterforms and prevent ink bleeding. Optical sizes tend to be more about the relationship between headline and body, with things like tighter standard kerning, taller x-heights, and so on. A DPI variant should only concern itself with aliasing, and aliasing is a render-time issue. You can design a typeface to counter this from the foundry side, but a more sustainable solution would be to counter it from the software side.
You're right, they're different. I was just pointing out examples where foundaries produce variations of the same typeface to account for differences between media.
Anyway, as long as such differences exist, I don't think we'll be able to convince type designers to disregard them. They want their fonts to look perfect now, they're not going to wait for smartphone manufacturers to catch up, and they already have the skills and tools to produce subtle variations of their typefaces.
A truly sustainable solution would be for every reading device to have 300ppi+ screens so that it doesn't really matter how you shade the last subpixel. Until we have that, leaving optimization to perfectionist type designers seems to me like a better stopgap measure than trying to standardize on one or another antialiasing algorithm across vastly different platforms.
Different vendors like Microsoft and Apple use antialiasing algorithms that are not only technically different but also based on different UI paradigms. (MS emphasizes crispness whereas Apple emphasizes preserving shapes.) Neither is obviously superior to the other, and the choice is to some extent a matter of taste. So it should be the designer's prerogative to decide whether to follow either paradigm or to disregard both and enforce his own aesthetic tastes.
Anyway, as long as such differences exist, I don't think we'll be able to convince type designers to disregard them. They want their fonts to look perfect now, they're not going to wait for smartphone manufacturers to catch up, and they already have the skills and tools to produce subtle variations of their typefaces.
A truly sustainable solution would be for every reading device to have 300ppi+ screens so that it doesn't really matter how you shade the last subpixel. Until we have that, leaving optimization to perfectionist type designers seems to me like a better stopgap measure than trying to standardize on one or another antialiasing algorithm across vastly different platforms.
Different vendors like Microsoft and Apple use antialiasing algorithms that are not only technically different but also based on different UI paradigms. (MS emphasizes crispness whereas Apple emphasizes preserving shapes.) Neither is obviously superior to the other, and the choice is to some extent a matter of taste. So it should be the designer's prerogative to decide whether to follow either paradigm or to disregard both and enforce his own aesthetic tastes.
And in the mean time, designers take theses things into their own hands...
And in the mean time, designers take theses things in their own hands...
I think we may have too many senses for the word "design" floating around because this remark reads like an oxymoron: "This is not a design deficiency of the typeface. It was simply not designed to work as body text for big body text sizes and dense screens."
I like the idea of "grades" because it seems abstracted somewhat from the device's details, but the fact that Retina displays are different in portrait and landscape mode is worrisome. I wonder how this concept is going to scale as new devices with weirder resolutions come out.
I like the idea of "grades" because it seems abstracted somewhat from the device's details, but the fact that Retina displays are different in portrait and landscape mode is worrisome. I wonder how this concept is going to scale as new devices with weirder resolutions come out.
"This is not a design deficiency of the typeface. It was simply not designed to work as an end table."
I think the two senses of "design" are confusing the issue. If he's absolving the typographer for not accounting for retina displays, fine, but it sounds to me like he's absolving the typographer for making a poor decision with an after-the-fact assertion that it was intentional. I don't think intending for something to suck is an adequate excuse.
Title fonts can be a lot weirder than body fonts. If tweaking it to look good at smaller sizes made it look crappy at large sizes, that was an acceptable tradeoff at the time.
Modern fonts, particularly at least OpenType, can embed different information for different sizes pretty easily. If this problem could be solved by using a more modern font format and better quality fonts, that seems like a better approach.
It's not just Retina horizontal and vertical. It's high and low pixel density, grey scale rendering, clear type.... etc etc
Also which subpixel arrangement is in use. And ambient lighting conditions. And (and this is a big one that no one seems to talk about) reading distance.
The choices they posit, for precisely the same LCD panel are going to change depending on whether it's held in the hand at 20cm or stuck to the dashboard of a car 70cm away.
Basically, I don't think this is solvable. It's cute, and within reason (e.g. for an application designed to read prose text on a known set of devices) maybe it's worthwhile. But the problem is just too hard for a general solution.
The choices they posit, for precisely the same LCD panel are going to change depending on whether it's held in the hand at 20cm or stuck to the dashboard of a car 70cm away.
Basically, I don't think this is solvable. It's cute, and within reason (e.g. for an application designed to read prose text on a known set of devices) maybe it's worthwhile. But the problem is just too hard for a general solution.
Resolution on a laptop screen doesn't mean shit, what you need is effective pixel density and that's going to vary too much. I don't know of any browser that communicates "hey I'm a 15" screen and my resolution is AAAAxBBBB and my user sits CC" away from their screen on average" Of course with an iPhone/iPad you can do a bit more generalization but not for laptop screens.
This is the premature optimization of design.
This is the premature optimization of design.
If you read the article you'll see that they're only sending their custom font to OSX. PCs get Georgia. On OSX, resolution is enough to determine pixel density at the granularity they need because of the limited number of products Apple has [1].
So they have successfully achieved their goal.
It's not a goal I would set out to achieve, but to each their own.
1. Notice that both Air models have high(ish) DPI resolutions that are unique in the history of Apple products.
So they have successfully achieved their goal.
It's not a goal I would set out to achieve, but to each their own.
1. Notice that both Air models have high(ish) DPI resolutions that are unique in the history of Apple products.
Except my 15" macbook has the same resolutions as 17" macbook from 2008 and the 20" Cinema display and 20" iMac.
The current 17" macbook has the same resolution as the 23" Apple Cinema HD display and 24" iMac.
What happens to my mac mini which is running on my 23" 1920x1080 NEC Multisync? What about when I hook it up to my TV? Will it think it's the 21.5" iMac?
What about my dual monitor setup on my Macbook pro (15" 1680x1050 & 24" 1920x1080)?
What about everyone else using some variety of monitor setup with their mac?
Maybe they could try a "Optimized for viewing on Apple hardwear (and only apple hardwear) made after 20XX and at a distance XX" except for these maybe these models:" disclaimer.
The current 17" macbook has the same resolution as the 23" Apple Cinema HD display and 24" iMac.
What happens to my mac mini which is running on my 23" 1920x1080 NEC Multisync? What about when I hook it up to my TV? Will it think it's the 21.5" iMac?
What about my dual monitor setup on my Macbook pro (15" 1680x1050 & 24" 1920x1080)?
What about everyone else using some variety of monitor setup with their mac?
Maybe they could try a "Optimized for viewing on Apple hardwear (and only apple hardwear) made after 20XX and at a distance XX" except for these maybe these models:" disclaimer.
Dude. Way too much pedantry. They are experimenting. If they get it right on your screen you get a more precise rendering of the font, if they don’t you get a slightly suboptimal rendering, but that’s the same result you'd get with a generic font.
An old saw on the topic of scan conversion in computer graphics, but I'll reiterate. The computer industry needs to use conventions that render graphics using physical dimensions. A 12pt typeface should be the same physical size regardless of the size and dpi of the display.
I refuse to believe the horse is out of the barn on this one.
I refuse to believe the horse is out of the barn on this one.
That's just wrong. Pick a font more or less suitable for all the devices and use it. New ipads and iphones will be out in a year, then what? Throw in another couple of fonts? Any project larger than one-page personal blog is destined to turn into nightmare.
Also, add some fonts for android devices, why not? Pentile displays should get their optimized fonts as well.
Also, add some fonts for android devices, why not? Pentile displays should get their optimized fonts as well.
I realize how bizarre this must sound, but my first reaction upon visiting that page was that the font was just too large to read comfortably. It only takes a quick ^- ^- to remedy, but it's an amusing counterpoint to all the recent frustrations with sites that insist on using 10pt fonts.
Yeah, I've noticed this on a couple of sites too, particularly the default Octopress theme which (like this site) sets the text size on the body to a bit over 1em, and I don't understand why anyone would do this; what platforms are they developing for, where the default font size is too small? Obviously, better to have the fonts too large than too small, though.
You are just used to very small type.
http://informationarchitects.jp/blog/100e2r/
http://informationarchitects.jp/blog/100e2r/
No, I'm used to 1em being a reasonable size for body text - the text at that link says as much, but for some reason sets its own body text to 1.3 times browser default. I don't particularly object to it, I'm just curious as to why they think the browser default is too small.
"... they look too bold on high resolution screens (MacBook Air) and they look okay on Retina displays (next MacBook Pro)"
I wonder if this is assumption based on rumors and extrapolating iPad 3 display behavior, or these guys actually got their hands on the next-gen MacBook Pro.
I wonder if this is assumption based on rumors and extrapolating iPad 3 display behavior, or these guys actually got their hands on the next-gen MacBook Pro.
Love the website design.
I really appreciate their attention to details. iA writer is a good example. Simple and flawless, however, I cannot recommend it to hackers since the functionalities are quite limited. Sometimes I use it for taking quick notes and that is it.
I really appreciate their attention to details. iA writer is a good example. Simple and flawless, however, I cannot recommend it to hackers since the functionalities are quite limited. Sometimes I use it for taking quick notes and that is it.
>> Simple and flawless, however, I cannot recommend it to hackers since the functionalities are quite limited. Sometimes I use it for taking quick notes and that is it.
The "flawless" sounds a bit contradictory seeing how you follow up the statement with some arguable flaws.
I've always thought iA writer's simplicity was a gimmick. The whole notion of "distraction free writing" as a quick cure for the user's inability to focus is a hard promise to deliver on.
The "flawless" sounds a bit contradictory seeing how you follow up the statement with some arguable flaws.
I've always thought iA writer's simplicity was a gimmick. The whole notion of "distraction free writing" as a quick cure for the user's inability to focus is a hard promise to deliver on.
well, I do not count missing features as flaws. what I mean by flawless is that iA writer does well on what it is supposed to do.
> I cannot recommend it to hackers since the functionalities are quite limited.
Come on, iA Writer is not competing with Emacs.
Come on, iA Writer is not competing with Emacs.
That "N minutes left" div popup is so annoying that I stopped reading the article.
Responsive typography is no solution—the client side has to improve and it is improving already:
Just use -webkit-font-smoothing: antialiased (which iA totally missed in their article) and fonts look again right in Chrome and Safari
Just use -webkit-font-smoothing: antialiased (which iA totally missed in their article) and fonts look again right in Chrome and Safari
[deleted]
A typographer, talking about screen density, and clarity on his blog using a serif font. Oh, the irony.
Do you have a point to make or is is this a display of faux-superiority from someone who actually hasn't got anything to say or any way to back up their insinuations? And you don't know what irony means either.
Empirical results are ambiguous, mostly pointing in the direction that there is no difference in readability between serif and sans serif fonts – and those are often very old studies, done on very old hardware with very low resolutions.
As should be obvious from the Website, iA are also huge fans of and advocates for large font sizes, in this case their body text is over 20 pixels in size. Any aesthetic issues (smushed and blurry serifs) are not really a problem at that size. 10 pixel Times might look ugly (even though it might be as readable as 10 pixel Arial) – its details a blurry mess – but if there are more pixels to work with that’s no problem – especially not with that many more pixels.
Looking at the font, it’s also obvious that it’s supposed to work at the still relatively common low resolutions of, say, laptop screens. Its shapes are relatively simple, the amount of detail is relatively low. It’s only a small step up from the very simple (and also gorgeous) Georgia.
Because of the aforementioned aesthetic problems with serif fonts (blurry serifs at small sizes on low resolution displays) not using a serif font might be a good rule of thumb if you are clueless about typography, but it doesn’t make any sense to adhere to that if you actually know your way around.
And even if you are clueless there is nothing wrong with using something simple and very optimized (also beautiful) like Georgia.
As should be obvious from the Website, iA are also huge fans of and advocates for large font sizes, in this case their body text is over 20 pixels in size. Any aesthetic issues (smushed and blurry serifs) are not really a problem at that size. 10 pixel Times might look ugly (even though it might be as readable as 10 pixel Arial) – its details a blurry mess – but if there are more pixels to work with that’s no problem – especially not with that many more pixels.
Looking at the font, it’s also obvious that it’s supposed to work at the still relatively common low resolutions of, say, laptop screens. Its shapes are relatively simple, the amount of detail is relatively low. It’s only a small step up from the very simple (and also gorgeous) Georgia.
Because of the aforementioned aesthetic problems with serif fonts (blurry serifs at small sizes on low resolution displays) not using a serif font might be a good rule of thumb if you are clueless about typography, but it doesn’t make any sense to adhere to that if you actually know your way around.
And even if you are clueless there is nothing wrong with using something simple and very optimized (also beautiful) like Georgia.
Barely related: I loved the old website so much. RIP informationarchitects.jp ;(
EDIT: I think the 'most people can't...' is off slightly because good vs bad is purely a personal, instinctive thing. Everyone can feel a typeface that they like, and what works for them, but there's an entire collective of people who genuinely think Comic Sans is the perfect font for pretty much everything. Which for them it is, same as the lovers of Helvetica and so.