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

As of January 1, 2018, we are no longer providing support for Typecast. Our apologies for the inconvenience. Thank you.
« Back to Blog

Designing for Moments With Media Queries

on Thursday 1st of May 2014

Designing Moments

Today Jordan Moore helps us look at common design patterns with new eyes and shares some media queries you can use to improve mobile experiences

Consuming content on the web is like entering the fog of war we see in video games—that enforced lack of situational awareness that encourages the player to move into unmapped areas of the screen to discover what’s there. Our designs are rarely experienced as a whole either; they’re consumed in parts depending on the size of the viewer’s device. We scroll into the unknown to reveal content and gain an awareness of the overall context. On larger displays this reveals itself fairly quickly. On smaller displays, however, the fog presses upon us, and each part is a ‘moment’ on the user’s screen.

By reassessing the patterns we implement, we can better customize these moments, improve how visitors use and consume our clients’ content on small displays, and make the contexts clearer.

The shape of moments on the web

A moment is essentially what a user sees at that particular point in time. But it’s different to the so-called ‘fold’. The main difference is that the fold is static—a stationary point along the y-axis. A moment moves. It’s dynamic. And it doesn’t exist fleetingly like the fold. A moment exists at any point on the screen at any point in time. As you read these words, it’s unlikely that many people will be experiencing this moment in exactly the same way you are right now.

Momentary breakdowns

Moments need to make sense in the context of the visible space and in relation to the surrounding document.

Stacking navigation vertically pushes important content out of sight and impairs the user

Tabbed content and navigation are good examples of when the meaning of a moment breaks down because of reduced visible space. A wide viewport allows for tabs to be displayed horizontally and the corresponding content to remain visible beneath. Whereas a narrow space tends to force us to stack the tabs atop each other, pushing the content out of sight. The problem in this scenario is that the content that changes as a result of pressing the tab is often unseen after the event. The entire moment is occupied by one component of the system and the value for the user is impaired.

Don’t get me wrong. It is harder to give a complete picture within a confined space, but there are ways we can tell the viewer more to help them make sense of the moment.

Plan and scrutinize

First off, make the best design decisions for the given situation by breaking down layouts and identifying potential moments. This helps us imagine what that moment looks like at its worst and what it looks like in ideal conditions.

Fluid single column layout

These are the sort of sketches I do to identify potential moments in different states during wireframing

Planning early for the various states in which a moment might exist lets us forecast potential difficulties and find solutions more effectively. Solutions should be challenged with questions such as:

  • Does this moment make sense when breakpoints change?
  • How should this moment adapt to protect the integrity of the content?

To protect content, turn to media queries

Ethan Marcotte recently stated that we should use media queries to defend the integrity of our content, and I agree.

They provide us with a native tool to guide content from the confined conditions of small screens through to those spacious displays that allow for more affordances in regards to composition.

Here are a few ways I use media queries to improve common mobile design patterns.

Turn to your x-axis

When we consume content on the web, we move the viewport down the page to bring the content up into the viewable area. Why shouldn’t we do the same along the x-axis? Looking at our tabs and navigation examples from earlier, both can be improved using off-canvas solutions that stack elements horizontally instead of vertically.

Animation showing overflow pattern

Try this overflow pattern I built in CodePen for tabs and navigation

See the Pen Overflow Tab Navigation by Jordan Moore (@jordanmoore) on CodePen.

Resize your browser and scroll in the frame to try this overflow pattern for tabs and navigation. See the CodePen.

In my design solution (which you can see in CodePen), the attribute of note is the white-space: nowrap property applied to the unordered list, which prevents its child elements from wrapping when they hit the edge of the container. This allows the list items to continue beyond the canvas. The overflow: auto property makes the unordered list scrollable when the canvas becomes too small to display all of the list items at once. The final property of note is -webkit-overflow-scrolling: touch which enables momentum scrolling, making it feel more native to devices running webkit browsers like Safari on iOS and Chrome on Android.

Also, the CSS gradients tip off users that they need to scroll to reveal additional content, but disappear when they aren’t needed. Lea Verou produced a great tutorial documenting the technique on which this approach is based. CSS gradients are generally seen as a progressive enhancement, but the catchment area for this pattern (mainly mobile devices) has considerable support for the properties.

Now we have a solution that doesn’t compromise the integrity of our content, and it helps provide users with a clearer view of the context for the moment they are experiencing in our design.

Image galleries

Images are greedy elements, and they have a big impact on a web page. They leave a large footprint in the overall page weight (usually outweighing other resources), adversely affect the load speed of the page due to need to load an extra resource for every image in the document, and are such a concern in responsive design that new elements are being tabled to manage their weight. In small screens, they occupy so much real estate that they can’t be missed—particularly where a sequence of images is necessary.

A series of images might occur in the form of an image gallery, or a set of thumbnails. As with tabs and navigation, our instinct leads us down the y-axis in a long trail of full-width images stealing the moment for themselves. Furthermore, when the images aren’t related to the primary content, but are (for instance) thumbnails for related articles complete with titles, dates, and meta data, this stacking can create a large break after the article and push more relevant content further away from the heart and soul of the page (like comments relating to the piece).

Adopting a horizontal scroll pattern CodePen example

See the Pen Overflow Image Gallery by Jordan Moore (@jordanmoore) on CodePen.

Adopting a horizontal scroll pattern on image galleries keeps images accessible AND relevant content ‘in the moment’. See the CodePen.

Perhaps image galleries and related content should compromise their hold on the content’s vertical rhythm and should be consumed in a horizontal scroll pattern to make more of that moment. It’s certainly worth considering. The important thing is to try and avoid letting content push other relevant and valuable content further into the fog of war.

Carousel content

Carousels appear to solve a lot of common web design issues—they can group related content, reduce the need to stack similar content (and consequently delay access to relevant content), and they can make a layout look a bit more ‘lively’ (keeping those executive stakeholders happy). But on closer inspection, carousels are a cumbersome design pattern riddled with potential pitfalls.

In most cases they require additional scripts to work. I’m always wary of patching behaviour that otherwise can’t be achieved naturally on the web. Bending the web to work in new ways requires valid reasoning, and in my opinion carousels don’t offer enough benefits to justify forcing the web to move in this manner.

Carousels can fail because:

  • additional JavaScript resources are required to display the carousel;
  • when JavaScript isn’t present, the fallback layout isn’t ideal; and
  • they usually impose new UI elements in order to navigate the panes, so users must learn new behaviors in situ.

Overflow carousel CodePen example

See the Pen Overflow Carousel by Jordan Moore (@jordanmoore) on CodePen.

Carousels are cumbersome, but using the x-axis lets us show grouped content even when space is tight. See the CodePen.

Brad Frost has written an analysis of The Overflow Pattern that studies the different methods of displaying content shaped for carousels. Central to his analysis is the scrollable x-axis approach, which we’ve covered. We’re starting to see examples in the wild of websites opting to let users scroll along the x-axis when there isn’t enough available space to show all of the grouped content.

Polygon's desktop carousel

Polygon's mobile carousel

Polygon uses horizontal scrolling to gracefully offer readers additional content on small screens without sacrificing primary content

One such example is Polygon—a gaming website designed and built by the talented Vox Media design group. The featured stories at the top of the page are displayed in a grid when there is enough room to display all of them at once.

But when their isn’t, they’re stacked horizontally to allow the user to scroll to a story at their own pace without any new UI elements to learn, controls to adhere to, or any behaviors outside of the web’s inherent capabilities.

The folly of sacrificing control for convenience

With responsive web design, we are finally witnessing a manifestation of John Allsopp’s Dao of Web Design—a web where content strives to adhere to the inherent ebb and flow of the web.

As we ride the wave of the responsive dip we have witnessed innovation and errors in how content is treated. Perhaps the overzealous desire to put things into set boundaries have led some to make questionable decisions. One of these is repurposing the <select> element for navigation and leaving it to the device to do the heavy lifting in regards to the UI and interaction design.

Content suffers when it’s stuffed into boxes (or form elements) that show little regard for typographic characteristics like leading and line-length. The <select> element is a solution chosen out of convenience rather than necessity—it side-steps the bigger problem.

Mikkel Bo Schmidt recently authored a detailed case study of why Tradeshift ditched the <select> element in favour of a solution geared towards complementing their content requirements. His walkthrough shows how the shift has allowed for richer, more appropriate interactions and is a compelling argument for the innovation that’s possible when we work to solve the root problems rather than repurpose old components beyond their intended use. It’s a really interesting read.

Content is still king

When content breaks or fails due to forced layout constraints the results are obvious and hard to ignore. Coding bugs and design flaws can creep under the radar, but a content bug is laid bare for all to see. Content issues are entirely preventable, particularly where containers are concerned.

On a multi-device web, we need to do everything in our power to safeguard content from every inevitability. Designing for moments honors content as the crux of a website’s value. And by using media queries (here’s all of mine), I believe we can scale those moments gracefully—making small adjustments that make reading as comfortable as possible within the allocated space.

A big thanks to our guest author Jordan Moore for today’s post. You can find more from Jordan on his blog and Twitter. Guest authors are paid for their contribution, and all opinions are their own.

Type on Screen

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

Hook me up!


blog comments powered by Disqus