{"id":3385,"date":"2013-05-09T09:26:52","date_gmt":"2013-05-09T09:26:52","guid":{"rendered":"http:\/\/blog.cloudfour.com\/?p=3385"},"modified":"2016-07-08T22:25:44","modified_gmt":"2016-07-08T22:25:44","slug":"behavioral-breakpoints","status":"publish","type":"post","link":"https:\/\/cloudfour.com\/thinks\/behavioral-breakpoints\/","title":{"rendered":"Behavioral Breakpoints: Beyond Media Queries"},"content":{"rendered":"

Recently, Cloud Four dev Matt Gifford built a slick, responsive off-canvas<\/a> navigation enhancement for a project (we’ll be releasing the core code shortly, so keep an eye out for Matt’s post about that!).<\/p>\n

The project followed the off-canvas menu metaphor for handling navigation on narrow screens. The baseline, mobile-first layout keeps the navigation out of the way\u2014initially as footer nav with a button-ish jump link, then progressively enhanced to convert the link into a trigger element for the off-canvas menu\u2014while a media query for wider screens formats the navigation on-screen.<\/p>\n

A sketch of this layout adaptation:<\/p>\n

\"offcanvasmenu-states\"<\/a><\/p>\n

In the past we’ve approached implementation of this as:<\/p>\n

    \n
  1. Implement a baseline CSS layout that has a menu button.<\/li>\n
  2. Use a CSS media query to adapt the layout for wider screens, hide the button, reflow the nav.<\/li>\n
  3. Use JavaScript, often bound on window.resize, to check media query applicability and adapt behavior accordingly (sometimes alternately handled by looking at the width of the viewport and comparing it to media-query-defined widths).<\/li>\n<\/ol>\n

    Bolting on Behavior<\/h4>\n

    Often by the time we get to the behavior implementation of our sites and apps, the process involves bolting on JavaScript as a follower of the CSS-based breakpoints that we’ve generated during the design process. We define the visual<\/em> breakpoints of our stuff and the JavaScript is expected to use those to indicate how it should behave.<\/p>\n

    So we bump into things. We want the JavaScript to “know” about the breakpoints defined in CSS, and which media queries are presently active. This leads to heartache, and also some pretty clever hacks. We use matchMedia (or a polyfill to support same) to determine whether a particular, specific media query is active.<\/p>\n

    Thus: duplicating media queries in two places (CSS and JavaScript), a situation that makes a whole lot of us twitchy. I have definitely fantasized about future CSS module spec revisions that allow for naming and scoping of media queries, to make stuff like this better.<\/p>\n

    But hold on a minute. What are we trying to accomplish here? Does CSS really hold a monopoly on breakpoints? Should our behavioral components be entirely beholden to the specific formulae of our visual layouts?<\/p>\n

    (Re-)Defining Breakpoints<\/h4>\n

    But why is the breakpoint for menu\/navigation behavioral adaptation entirely linked to a CSS concern? Could there be better indications in the browser that the behavior change is appropriate, beyond a CSS media query or screen width? And, in that case, what does<\/em> define the breakpoint?<\/p>\n

    This sort of thing was already on my mind when I started reading Stephen Hay’s<\/strong> excellent new book, Responsive Design Workflow<\/a><\/em><\/strong>. And Stephen is thinking about these things, too\u2014except he’s already a lot further along!<\/p>\n

    <\/a><\/p>\n

    Stephen’s way of defining a breakpoint is: “the points where certain aspects of a website or web application change depending on specified conditions<\/strong>.”<\/p>\n

    No mention of CSS there\u2014because the picture is bigger than that. As Stephen continues on to say, “[a]nother reason to consider a more full definition of breakpoints is that CSS is not the only method used to implement changes when a breakpoint has been reached.”<\/p>\n

    Exactly!<\/p>\n

    Breakpoint Graphs<\/h4>\n

    To express and plan breakpoints, Stephen advocates the use of breakpoint graphs, an adaptation on bullet graphs he’s invented to communicate both visual and behavioral aspects of breakpoints.<\/p>\n

    Along the “qualitative” axis (horizontal in these examples), one charts a scale. Often, this is a range of screen width resolutions\u2014the way we tend to think about responsive design and breakpoints.<\/p>\n

    Using the process from above, we might have a breakpoint graph that looks like this:<\/p>\n

    \"first-graph\"<\/p>\n

    Thus, we’ve expressed that we have a breakpoint at 40em that alters the page layout.<\/p>\n

    But Stephen’s graphs go further than this visual design element. Using qualitative “bands,” Stephen’s graphs can communicate behavior or other aspects, like so:<\/p>\n

    \"graph-2\"<\/p>\n

    This is starting to move toward thinking about behavioral changes as well as visual ones, expressing explicitly that we want to adapt navigation behavior, but the breakpoint is still owned and defined in terms of the CSS breakpoint: 40em. So it’s natural that we’ve been creating media queries:<\/p>\n

    @screen only and (min-width: 40em) {}<\/code><\/p>\n

    and the JavaScript corollary<\/p>\n

    if (window.matchMedia( \"screen and (min-width:40em)\" )) { }<\/code><\/p>\n

    Behavioral Breakpoints<\/h4>\n

    Looking at breakpoints in such a clear way inspired me. I’d seen the screen-width-resolution-style graphs before, but the qualitative dimension was new and exciting. In fact, it frees us from tying our breakpoints to a visual or CSS source at all.<\/p>\n

    What is the breakpoint, in the case of the navigation menu example here?<\/p>\n

    When implementing the navigation behavior, Matt chose to use the state of the triggering button as the indicator for which kind of menu behavior to apply. Button extant and visible? Convert the navigation behavior to the corresponding off-canvas menu. Button gone? Deactivate the off-canvas menu and use on-page navigation. Matt does this by observing the state of that button and reacting accordingly, not by duplicating or checking on the status of the CSS media query that put it there in the first place.<\/p>\n

    Building Behavior into the Process<\/h4>\n

    A behavior-centric breakpoint graph for this could look something like this:<\/p>\n

    \"graph-3\"<\/p>\n

    where the breakpoint is the state of the trigger button<\/strong>. Yes, the state changes at 40em as a result of a CSS media query, but it’s the state we care about, not the media query<\/strong> (or window width) that did it.<\/p>\n

    Stephen’s book does an excellent job of pushing the notion that behavior needs to be a part of our responsive design processes, integrated and partnered with visual design, not just adjunct to or beholden to it. Breakpoints span various aspects of the overall experience, and I’m glad Stephen helped me really understand this.<\/p>\n

    Thanks!: my gratitude to Stephen Hay<\/a> for his personalized help in making breakpoint graphs, Matt Gifford<\/a> for the off-canvas menu idea that got me thinking and Tyler Sticka<\/a> for a bit of sketching help and proofreading.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

    Recently, Cloud Four dev Matt Gifford built a slick, responsive off-canvas navigation enhancement for a project (we’ll be releasing the core code shortly, so keep an eye out for Matt’s post about that!). The project followed the off-canvas menu metaphor for handling navigation on narrow screens. The baseline, mobile-first layout keeps the navigation out of […]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[233,240,3,241],"tags":[],"class_list":["post-3385","post","type-post","status-publish","format-standard","hentry","category-css","category-javascript","category-mobile-web","category-rwd"],"acf":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/cloudfour.com\/wp-json\/wp\/v2\/posts\/3385","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cloudfour.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cloudfour.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cloudfour.com\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/cloudfour.com\/wp-json\/wp\/v2\/comments?post=3385"}],"version-history":[{"count":0,"href":"https:\/\/cloudfour.com\/wp-json\/wp\/v2\/posts\/3385\/revisions"}],"wp:attachment":[{"href":"https:\/\/cloudfour.com\/wp-json\/wp\/v2\/media?parent=3385"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cloudfour.com\/wp-json\/wp\/v2\/categories?post=3385"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cloudfour.com\/wp-json\/wp\/v2\/tags?post=3385"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}