Cloud Four Blog

Technical notes, War stories and anecdotes

Fixed and inflexible

Even before smartphones came along and dashed any hope for a 960-pixel-wide web, designers and organizations have struggled with the challenge of prioritizing and composing content that scrolls. Our screens act like windows to content of variable size and scale, demanding an awful lot of abstract thinking to design for. Sometimes we’re successful, revising content, designing modern day deliverables and embracing compromise like we know in our hearts we should. Other times, we convince ourselves that we can predict this inherently unpredictable medium, making decisions that age quickly and poorly by prioritizing the window instead of the content.

Most recently, I’ve noticed a sharp uptick in the number of requests I receive to explore fixed-position (aka “sticky”) interface elements. Fixed elements are positioned relative to the viewport instead of the page, allowing them to maintain position even as the document scrolls. Some of the most popular sites on the web employ “sticky” menus, and with good reason… when applied thoughtfully, they can yield substantial usability improvements.

But when fixed positioning is used without care, restraint or precision, it can have disastrous consequences. Here are some of the reasons why.

We can’t predict how much space we have.

Our industry has a nasty habit of quietly embracing display resolution “standards” that are mostly fantasy… design decisions are a lot easier if you assume all devices are 320 pixels wide by 480 pixels tall (and users never turn them sideways). The inconvenient truth is that display resolutions vary wildly. Each additional “sticky” element increases the risk of obscuring the page content mostly (or entirely) for some users… in which case the page might as well not exist at all.

We can’t get those pixels back.

Fixed elements aren’t just “prominent,” they photobomb the interface, robbing focus and attention from what really matters — the content! Before you make something “sticky,” consider reevaluating the element’s importance relative to the entire page (instead of on its own merits).

It makes scrolling tougher.

As evidenced by the years-long debate over “The Fold,” the fear that users won’t know (or lack willingness) to scroll persists to this day. When that fear is real, then fixed positioning is a godsend, ensuring the visibility of content regardless of scroll position.

But those fears don’t mesh with reality very well.

Today’s users are so familiar with scrolling that most mobile browsers will hide the scrollbar entirely. “Sticky” elements complicate matters by reducing or obscuring the scrollable area, forcing the user to swipe more carefully to avoid accidental actions.

Ironically, our desire to alleviate the supposed “difficulty” of scrolling may make scrolling that much more difficult!

It can slow everything down.

Users care about speed. But speed isn’t all about navigation… there’s also the overall speed of the experience. Fixed positioning can result in strange browser-specific quirks or even costly repaints, potentially counteracting any efficiency you might have gained.

It may not actually work.

Mobile websites share a lot of their design vocabulary with native mobile apps, where fixed headers, menus and tab bars are commonplace. This makes it easy to forget that fixed positioning as we know it is relatively new to the web, and often unreliable.

“Sticky” headers, footers and navigation flourished in the 1990s, often implemented using frames. When frames fell out of fashion in the early 2000s, most browsers did not support fixed positioning using CSS. In the absence of frames, position: fixed or consistent, intuitive JavaScript, fixed positioning became just another discarded Web 1.0 trend… at least until CSS support arrived in IE7.

But smartphone browsers have historically not supported position: fixed as predictably as their desktop counterparts. It was entirely absent from mobile Safari prior to iOS5, and largely unusable in Android browsers prior to Honeycomb. To this day, behavior can be inconsistent across platforms. To quote Brad Frost in his excellent post on Fixed Positioning in Mobile Browsers, “‘support’ isn’t exactly binary.”

Since you can’t rely on support for fixed positioning, you’ll need to make sure your experience works without it anyway. Which begs the question…

Why position: fixed at all?

I believe there are plenty of interface elements that benefit from fixed positioning, provided they follow a few best practices:

  • The “sticky” element is clearly more important than everything else on the page.
  • The footprint of the element is modest enough that it does not obscure too much of the page content (even in landscape).
  • Any efficiency gained from the element’s consistent availability is significantly greater than any lost as a result of the element’s inclusion (due to performance, obscuring of page content, etc.).
  • There should only be one “global” (navigation, tab bar, etc.) and one “temporary” (modal, dialog, etc.) fixed-position element on-screen at any one time.
  • Fixed positioning should always be an enhancement. Your interfaces should never rely on it.

If any of these considerations completely upend your design aspirations, you may want to rethink your user experience with less rigidity. As John Allsopp so aptly put it fourteen years ago, “The journey begins by letting go of control, and becoming flexible.”

9 Comments on “Fixed and inflexible”

  1. Robert says:

    This article was of great interest to me as I’m currently designing a mobile web app and decided to go with a fixed position header. I needed to position my logo and a menu button on opposite ends of the header and fixed positioning presented fewer problems than floats. It would have been helpful to us “noobs” if you had briefly mentioned what the alternatives to fixed positioning are. Otherwise, it was a good article.

  2. DrMcCoy says:

    Slightly related, but sometimes, people also seem to forget that a user might view stuff at different resolutions at different times.

    I had this problem with the Coverity Scan (a static analyzer) interface. The main view has two sidebars, one left and one right, both resizable. Only that suddenly, the side bars were completely gone. Not even the resize handles were visible.

    That threw me for a loop for quite a while, until I remembered that I looked at it on a wider display previously. Turns out, it remembered that and remembered the side bar positions. Now on a smaller display, it moved the side bars off the screen edges. Funnily, not even resizing the browser helped. I had to muck about with Firebug to get them back.

  3. Gabriel says:

    Great post !
    Although it is focused on the usability of fixed elements, I wonder if you have any opinion on the technical workaround I’m using, which is to simply position containers absolutely relatively to the viewport.

    Let’s say you have this template :

    A top bar

    Content …

    And this Sass code :

    $topbar-height: 40px;

    .topbar {
    position: absolute;
    top: 0;
    left: 0;
    right: 0;
    height: $topbar-height;
    }

    .content {
    position: absolute;
    top: $topbar-height;
    bottom: 0;
    left: 0;
    right: 0;
    overflow: scroll;
    }

    The topbar will be fixed at the top and the main content will scroll as expected from the bottom of the topbar to the bottom of the viewport.
    Scroll is inside the .content div and not inside the body.

    I’ve found it works really well even in old devices (Android 2.x). The major caveat being you must have a fixed height in the topbar.

    Is there anything wrong with this approach ?

    • Tyler Sticka says:

      I’ve used this approach myself, and sometimes it works well. The tricky part is going to be that .content element. overflow: scroll feels really janky on iOS. A common solution is to enable momentum scrolling for iOS, but that comes with its own baggage (flickering elements, inability to manage the scroll position consistently, etc.). I’ve also found this solution more difficult to work with for responsive projects (as opposed to mobile-only). As with anything, YMMV.

      • Gabriel says:

        Thanks for your feedback. Yes the momentum scrolling works well but I wasn’t aware of flickering or scroll position management issues, do you have any link showing these side effects ? I didn’t experience any even with a wide and complex list in the scrolling area.

        • Tyler Sticka says:

          There’s a good post showing the webkit overflow flicker in action here, though the author’s solution isn’t always viable if you need to do something like animate the page container as the user moves between views.

          For scroll position management, try setting the scrollTop of .content on iOS when the container hasn’t finished momentum-scrolling completely. The value of scrollTop doesn’t update as quickly as the scroll animates, so you get some strange behavior. Also, if you manage to restore the user’s ability to quickly scroll back to the top of long pages in iOS, please share your technique, because doing things this way always kills that feature for me.

  4. Sean says:

    Love your comparison between unnecessary modals/fixed elements and photobombs. I never thought about it quite like that, but the shoe totally fits! Good read.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>