Skip to content

Responsive

Breakpoints

A rolling discussion tonight regarding media queries (breakpoints) and the units to use. em, px, rem? This (zellwk.com/blog/media-query-units) article suggests that em behaves the most consistently across all browsers, but then digging into the comments, there’s a counter argument for px.

I like to use em/rem for elements that are truly relatively scaled. So things like borders and absolutely positioned elements I generally stick to px units.

Personally, I prefer px. em and rem are both relative units, units that scale based on font-size set by the user (or defaulted in the browser). Now take mobile: what if the user is using enlarged fonts. If the media queries (breakpoints) are also scaled because of the units used, how will that impact mobile?

Feels like I need to experiment more around this, but to quote a colleague…

just do what you want and let the browsers deal with the headache

…which frankly, sometimes is a good call.

Responsive navigation UX experiment

Mobile navigation frequently consists of a burger menu placed in the top right of the viewport. But consider this: a user with a large phone using just one hand, can their thumb stretch that far? This is particular issue on the larger format phones such as an iPhone 7 Plus.

Some of the UX niggles in mobile navigation:

  • Awkward one handed navigation
  • Fiddly menu and links
  • Inappropriate menu items for context of device
  • Little room for styled menus or call to actions

The following experiment explores an alternative to the hamburger menu, with a focus on improving the UX. I’m using a tiny bit of JavaScript to handle the mobile navigation toggle, but the layout is entirely through CSS.

Screenshot of mobile menu opened (links to demo CodePen)
Mobile UI

The experiment

  • Move the navigation to the bottom. By placing the menu toggle where it is easily reached in one-handed use. It also keeps the navigation controls for your site close to the control UI provided by most mobile browsers (bottom of the web view).
Screenshot of mobile menu
Mobile, menu located at viewport bottom

We reposition the menu with CSS, meaning the underlying HTML document remains logically (seminally) ordered for screen readers and document parsers.

Screenshot of desktop menu
The same menu, but on a desktop

Ultimately it’ll be worth considering an additional breakpoint for portrait tablets—one that follows a more traditional burger pattern. Why? Tablets are generally not held in one hand, but the screen remains practically too small for the full extent of a desktop-ish navigation. A combination of burger + shortened desktop menu could work here, but that would require a JavaScript solution based on viewport width (which is less attractive).

  • Leave the brand where it is (top). We don’t want to waste our precious mobile screenspace, so we avoid making it “sticky” or “fixed” or anything else that obscures the content. In this example the brand is fairly large, but we should try to keep it small and out of the way. On visiting a site on a mobile, I want to know what that site is about quickly and without scrolling, so lets promote the content and not waste screen space with branding.
  • Screenshot of expanded menu
    Mobile, menu expanded

    Tiles, not links. Links can be hard to tap on a mobile. We can significantly increase the hitbox for each menu entry by making them tiles. This also provides a lot of opportunity for branding or colourful styling—but not at the expense of a clear, readable label.

  • You don’t have to show everything. I’ve noticed many mobile menus try to show all the things, which may not actually be that useful for different devices. Why not hide the menus we don’t want? In this experiment, we can tag menu elements with menu-item--hide-desktop class to hide (natch) content from the desktop. We could equally do that for mobile.
  • Don’t be afraid to repeat links, sometimes it’s fine. Here, I’ve taken what I think are the three most important menu entries and explicitly called them out as additional ’tiles’ to display along side the mobile navigation button. Quick access for the user, without distraction.

What’s next

This experiment could be taken much further if we start introducing more JavaScript. I’ve also barely touched on accessibility, but this experiment is ‘fairly accessible’. There are additional tricks that I’ll address in some future post. Best tip, fork the demo on CodePen and have a play.

View this experiment on CodePen.

Dev notes

Encountered a strange issue with Safari while building this one. An absolutely positions display:fixed element (the mobile nav, viewport bottom) was not being rendered at all. Chrome and FireFox were displaying the menu perfectly. This was due to Safari ignoring width: 100% on the menu wrapper. Replacing width with left: 0; right: 0 resolved the issue.

This experiment is reliant on flexbox (display: flex) support in your browser. These days that covers most browsers, but if you do need to support older browsers, consider adding a fallback to CSS tables.

Responsive modal dialogs

Screenshot of modal dialog masking content
Modal window with full-viewport mask

A super simple responsive modal window with minimal JavaScript.

  • Mobile friendly (mobile first, natch!), fills the viewport on mobiles
  • Keyboard navigable
  • Marked up for accessibility
  • Masks the content on desktop

Particular attention here on the accessible aspects of modal markup: aria-labeledby, aria-describedby and the toggling of aria-hidden on show/hide.

Basic modal markup with these aria properties:

<div class="modal"
 data-modal="dialog1"
 role="dialog" 
 aria-labelledby="modal-label"
 aria-describedby="modal-description"
 aria-hidden="false">

Then matching elements inside the modal itself:

<h2 id="modal-label">
 My modal title
</h2>
...
<p id="modal-description">Modal description</p>
Screenshot of modal dialog filling viewport
Fills viewport on smaller devices

A demo can be found on CodePen.

Scaling content with CSS vw units

Screenshot of desktop with content scaled
Desktop with scaled content

While experimenting with a new Pattern Library based workflow and I put together something to play with scaling content based on css vw units (viewport width) and full-page splashy design.

All it takes is…

font-size: 10vw;

…and the browser will calculate the size on the fly. There are 4 related properties, vh, vw, vmin, and vmax which can be used to scale most content base don the dimensions of the browser viewport. These units are percentage of viewport size, so 10vw == 10% of the viewport width.

  • vh = % of viewport height
  • vw = % of viewport width
  • vmin= whichever of vh or vw has the smaller size*
  • vmax= whichever of vh or vw has the larger size*

* As of Jan 2017, Microsoft Edge browser doesn’t support vmax, but you are safe to use vh/vw in all modern browsers

You can see the page in action here: spacegirl.co.uk or check out the source on GitHub here: spacegirl-patternlibrary.

Menu positioning

Screenshot of mobile first design
Mobile menu

This bare bones experiment also deliberately puts the navigation elements at the bottom of the page on mobile—in theory closer to the users thumb. This was sparked from a discussion at the studio this week over mobile menus. The ubiquitous hamburger menu feels increasingly unwieldy UX as we become more attached to our mobile devices, especially phones. The thumb reach from the bottom of an iPhone 7 Plus to the top right corner (traditionally where the burger menu resides) is a stretch for me. A struggle for folks with smaller hands, which could results in phone-fumble annoyance. There are solutions—more app-like behaviour (think iOS apps, icon bars), tile menus, InstaGram style slide-in/out menus to name a few—but there’s the risk of user confusion. People are used to burger menus, even if they don’t have the most elegant UX. Food for thought (hmm, burgers).

 

Mobile-first responsive tables with CSS

Here’s a rehash of an experiment I did a while back with responsive tables. The goal is to make style a table ‘truly’ mobile first, while maintaining semantic HTML.

Update

The initial demo was using min-width to handle the breakpoint which resulted in overly complicated CSS. This second demo reworks the CSS to use a max-width based breakpoint instead. It allows the table to naturally return to a table-like layout after the breakpoint is hit.

Screenshot of mobile first table
Mobile first (max-width)
Screenshot of desktop table (using max-width)
Desktop

Updated demo (CodePen): codepen.io/shellbryson/pen/yggOME

Git: github.com/shellbryson/codetips-responsive-tables

Original demo

Starting with mobile, we unwrap the HTML, turning each of the table elements into blocks that we can easily position.

We use the a data-attribute on <th> cells in the table body as hidden content for smaller screens (the default view as we’re mobile-first).

Screenshot of mobile-first table
Mobile first

On desktop, we use a breakpoint to give the table HTML elements back their proper display property values and hide our hidden content (data-attribute) titles. Our friends here are:

display: table-header-group;
display: table-row-group
display: table-row;
display: table-cell;
Screenshot of desktop table
Desktop table

A CodePen can be found here (resize your browser to see the responsiveness).