Use Typecast to design for the reader by putting type first. Try it now

Design Q&A

Jordan Moore on Mobile-First Type & Layout

Tuesday 19th August 2014

Jordan Moore
In our July webinar, UX designer Jordan Moore showed us ways to improve mobile-first design by loading type faster and improving small-screen design patterns. Afterwards, he tackled some questions from the group. Here’s what he had to say.

All RWD seems to be about handling different widths, but are there any strategies to ensure that your website is also responsive between different heights (for example when you want to make sure certain information is always shown nicely on page load)?

Vertical media queries (min-heights and max-heights) aren’t as well-known or as widely-used as horizontal media queries. This is mainly because the vast majority of websites scroll up and down the y-axis and the majority of layout changes happen as a result of a variable width. Min and max-heights are written and utilized in the same way as the media queries we write for making adjustments to screen widths.

Remember, though, that vertical media queries don’t account for the browser chrome (you know, the address bar, file menus and any other additional toolbars). They just respond to the canvas height.

When you refrain from stacking navigation on mobile and instead use the x-axis, do you need to preload the page at a point that indicates the user can swipe that area? How do you clue the user in to a functionality that is perhaps not yet intuitive on mobile sites?

This is an interesting question that often arises when I talk about horizontal off-canvas techniques. It’s quite a new design pattern, but it seems to be catching on and appearing more frequently on the web.
Guardian beta site's off-canvas nav pattern
Any examples I’ve seen, like The Guardian beta and Nintendo.com, tend to let the overflow cut the content at the edge of the canvas to give the user the impression that there is something more in the space beside the edge of their device’s screen and that they can slide the content into view.

On Chrome, text flickers on every page click because it loads a standard font before fetching the web font. Is there a way to cache the font so it doesn’t need to load again?

Smashing Magazine have been conducting some interesting experiments on web font performance lately. They’ve produced a useful technique for caching web fonts using localStorage after the initial page load so that the typefaces appear quicker on subsequent page loads.

You mentioned only loading the most necessary web fonts at mobile to stay within your performance budget. How do you ensure that additional web font weights are only loaded within larger breakpoint widths?

I actually wrote an article about this a little while back for Typekit, and there are a few techniques you can use. I prefer to create two separate font kits. If you create one for a reduced connection with a really lightweight set of fonts, and then another with your full set of typographical fonts, you can alternate between the two sources using JavaScript. Jeremy Keith has a technique called conditional CSS, which helps marry JavaScript and CSS so you can set sensible breakpoints in JavaScript that relate to your CSS and load in those fonts depending on whatever breakpoint you’re hitting.

Why do you feel media query bubbling is better than using separate areas in the style sheet for specific media queries?

Media query bubbling does render as separate areas within the style sheet, but if you’re separating style sheets, or consciously creating separate areas for specific rules to live in (like at the bottom of your style sheet) I think it breaks your thinking about the element. Media query bubbling is a lot easier.
code snippet for media query bubbling
Imagine you’re working on a heading and you want to bump up the font size depending on a few different screen widths. You might say at 30ems I want this heading to double in size. I find it a lot easier to write that inline on the element rather than scroll through your CSS and try to find where the media query for 30ems is located and make that font adjustment there. It’s a quicker way of developing and works a lot better with those elusive element queries that we’re asking browser vendors to integrate.

Is there any affect on rendering performance when setting many small media query blocks?

There hasn’t been that much research or evidence on this. The only real performance concern is that with more media queries you’re going to have more lines of CSS. So it’s the file size of the CSS where the main performance concern would come from. But in terms of load and speed and so forth, it wouldn’t be any different than if those lines were additional CSS attributes.

How do you feel about dynamic font scaling using JavaScript, like setting base font size based on the percentage of the current window or parent element?

I’ve played around with things like that and have seen different demos.
Screenshot of maratz demo

I saw a pretty cool one built by Marko Dugonjić that captured the input from a webcam and was adjusting the text size based on how close the user’s face was to the screen. But ultimately I guess we like to know at what sizes our type works the best. Type is designed, after all, to work well at specific sizes, so when things round those up by decimal points, you may lose some of the legibility and crispness. So while they’re fun to play with, they’re something I tend to avoid.

What do you prefer: px, rems, or ems? And how do you preprocess these effectively without having to calculate them?

I tend to aim for responsive measurements like ems and rems, and I use a mixture of the two—choosing ems when I want to fix a font size and using rems when I want it to be a bit more dynamic. I tend to set rems because they’re relative to the root value. I’ll set the smallest font size that I want to go to on the <html> element in the CSS, and then use the <body> as one to inflate the type and make more widescale typographical adjustments—and those are the ones the ems can listen to. For example, if I set my <html> to 14px and set my <body> to 16px, and then, say, set my <h1> to 1rem, the <h1> will render as 14px, being relative to the <html> instead of the <body>.

In terms of calculating this stuff, there’s not much you can do about the math, unfortunately. It’s just one of the things we have to face up to. I know there are some preprocessors and mix-ins that let you input a pixel value and it’ll convert it to rems, etc., for you. But I haven’t explored those too much because I use inline calculation with a plugin for Sublime Text called Emmet, and it does a lot of the heavy math lifting for me.

If you wanted to load an image that’s, say, 500px wide or larger, is there a way to move away from {display:none} that is sensitive to budget?

Yes, starting from a mobile-first mentality, I’d leave that image tag empty. I’d rather leave that up to JavaScript and use something like Jeremy Keith’s conditional CSS to detect when you’re hitting that 500px breakpoint (or whichever breakpoint you’d want to introduce that image at). I talked earlier about having lots of small breakpoints when I design. When I’m doing this in practice, I still have some major breakpoints where it make sense for multiple changes to happen concurrently. So it’s a combination of the two.

What is your opinion on hiding content at different breakpoints? Good practice, acceptable, or bad practice?

In general, I find hiding content a bad practice. I suppose it depends on what kind of content it is. If it’s something that critical to UX or takes away from the context of the page, then I’d definitely say don’t do it.

Watch Jordan’s full presentation on Mobile-First Type & Layout over on our seminars page. It’s good stuff! And check out his post Designing for Moments With Media Queries for some new thinking on mobile design patterns.

Type on Screen

Get more web type tips, interviews and design gems by email

Hook me up!

Comments

blog comments powered by Disqus