Posts Tagged: typography

Typecast

Almost any modern web designer now has to decide between potentially thousands of custom web fonts. To rapidly prototype different combinations in the browser, even with good front end development chops, can be pretty time consuming.

Typecast is a web app that tries to address this problem. You get a much more visual, WYSIWYG interface for trying out font combinations, but with the advantages of actual font rendering in the browser. I don’t see a personal need for the app given the cost ($29 a month isn’t a minor expense) and considering at my day job we’re mostly focused on Proxima Nova. But especially in an agency environment, this could be a huge time saver.

Design lessons from Gmail web app

Mobile designer Rakesh, writing on his own blog Radesign, gives the GMail mobile app a visual makeover. I’m not crazy about everything he does (most notably, making unread titles blue), but if anything, Rakesh illustrates some great guidelines for general readability and contrast. It’s applicable equally to both native mobile app design and the web.

Leaning into longform

This is one of the best articles regarding web optimization for long form reading I’ve read in a while. Lots of great tips: don’t break page flow between articles, test how the typography looks on multiple devices and much more.

Prototyping responsive typography

Designer Viljami Salminen:

As I earlier in that article wrote, typography for the Web is really hard to design anywhere else than inside the browser. This is today even more true than it was a year ago. Typography prototype tries to solve this by doing the hard choices before jumping to other design tools like Photoshop.

Viljami really has a great point here. I’ve seen way too many projects backpedal when a font was decided on that looks awesome in Photoshop, only to fall apart in actual browser usage in the middle of a development cycle. But it’s more than face selection, it’s also issues of size and scale, also briefly touched on in this post.

Typeplate

I found the details here a bit overkill – something about the amount of mixins dependencies gives me some mild concern about code bloat. But once I started paging through the raw CSS logic there’s a lot of great ideas here, from a non uniform line height to not using pure black and a custom look for ampersands.

ScreenFonts: Zero Dark Thirty, The Impossible, On The Road, Django Unchained

The FontFeed‘s Yves Peters looks at typographic choices made on poster art for recent Hollywood releases. Interesting to see the ubiquitous Helvetica Neue put to both great (Zero Dark Thirty) and not so great (Django Unchained) use.

Picking web fonts

As designer Oliver Reichenstein wrote years ago, 95% of web information is text. Text has to look good, and the right font face is a big part of that. But given the virtually infinite set of web fonts to pick from, where do we start? Here’s a few recommendations from what I’ve learned.

Decide on a font face for dominant content first

I split web typography into three categories: body, headline and accent text (i.e. everything that doesn’t fit neatly into a standard headline plus paragraph flow.) In the early stage of web design one category tends to dominate overall textual content; in almost all cases it’s the body text. Decide the right font face for this category first. This decision makes the rest of your font selections easier; by then you’ve already settled on a font on a your users will interact with the most.

The body font trumps readability above all else

Great web text is aesthetically pleasing and matches the creative style of the site or application behind it. None of that matters if the body font face, the workhorse of web text, is hard to read. Check out body text samples on multiple browsers, multiple devices. How is the font hinting? Be sure to check out samples on IE8 and IE9, where poorly hinted fonts often fall apart. Generally when I’m stuck between two body font faces I’ll go with the more readable option.

Single font face web designs are underrated

There’s a reason many very well designed sites and apps stick with one font; multiple font faces need to contrast against each other to play well. Also every font you add has to match the site’s mood or style. That can generate a lot more research and testing. When in doubt, or if design time is limited, stick with a single font face and play with font weights for proper contrast.

There is no one “proper” base font size

I still see web guides recommending a single font size as a base for body text like 12px or 14px. Times have changed: there’s a huge range (desktop, tablet, phone) in web connected devices, some of which appreciate a slightly bumped up font size. Custom font faces often look best one or two pixels bigger or smaller than you might first expect. Experiment. When debating between several sizes, pick one that fits roughly 45 to 75 characters per line (including spaces) to maximize readability.

Jason Santa Maria – ‘On Web Typography’

I really enjoyed watching Jason’s talk. He starts out illustrating how the right font face matters. Pay special attention to last twenty or so minutes where he runs through a few quick tips on font selection (e.g. when in doubt between two font sizes, bigger is better.)

Fonts in use: Medium

FF Meta and Myriad makes for a a pretty rare web pairing (for that matter, Myriad solo is pretty underutilized), but Ev Williams’ Medium does the job right.

Sub-pixel text rendering

From Mac/iOS app developer Bjango’s blog, a solid primer on why sub-pixel antialiasing – still fairly common on Chrome and the PC world – is on its way out. This part really surprised me:

WebKit on OS X disables sub-pixel antialiasing when animating, often resulting in a visual glitch when it starts and stops, unless standard antialiasing is set using CSS. OS X disables sub-pixel antialiasing when using CoreAnimation’s layer backed views.

Now I know why some of my CSS3 font animations can run a bit off; turns out it was for good reason.