Usability Fallbacks

I’d like to introduce the concept of the usability fallback to you. The redesign of my site prompted me to think about web design approaches again and I’m going to share my thought process. There are a couple of things I learned, too.

My new design is based on the idea of giving the content center stage and imbuing it with a sense of device agnostic functional minimalism.1 Since I wrote the previous post I have updated the design to address the fact that people will get to see the content via different technology in different browsers. Now there are contingency mechanisms in place that should afford all users at least the basic experience of seeing the content and being able to navigate it.

However, unlike the concept of graceful degradation or progressive enhancement, a usability fallback does not aim to create the most pleasant experience possible for each browser. Quite on the contrary: I think graceful degradation is a cancer to the web2 and I find it a defensible compromise only for a select set of scenarios, which really only should concern professional web designers working to meet specific project constraints. Building a personal online presence is not one of those scenarios.3

As for developing my online presence, I did take care to start from a straightforward markup4 so that the site remains functional even in unstyled form. In fact, I serve a blanket CSS5 to old versions of the Internet Explorer for emphasis, courtesy of Andy Clarke.

But let’s take a look at the user experience available to standard compliant browsers. First, I need to address the design objective:

Create a minimalist theme that puts the content first and adapts to different viewing scenarios, providing a solid reading experience both on a big screen and handheld devices.

I decided that staying true to the premise meant to hide the navigation (and other secondary information), make it stay out of the way until needed. This is also a sensible approach for presenting content on mobile devices where space is at a premium. Hence my header only features a collapsed navigation, my name and information about the theme of the content, the latter of which translates into a navigation cue because I structured my online presence into five thematic sections.

The interaction element that would expand collapsed information should follow a familiar paradigm, because in user interaction familiarity trumps everything. I went with the good old button metaphor and created a button scheme that features subtle feedbacks on hover and click or touch, picking up the color that also distinguishes my links (another familiar interaction element) from regular text. Along with the texture of the site the buttons should be subtle, yet inviting to the touch.

The navigation button features a nautical steering wheel that alludes to the theme of my whole online existence; exploration. Moreover, the icon6 is also a metaphor for navigation in the first place, and on both accounts it follows popular convention to be put into the header. The whole setup of the collapsed navigation is meant to entice interaction and providing feedback about what happens. Once the button is clicked the rift that separates the header from the content opens to reveal the navigation. Thus the subdued fundamental meta information about the content in the header (its purpose and my authorship) along with an option to navigate the content amalgamates into a thematic statement.

I’m not going to go into the theory of responsive design that informed how I make my content adapt to different reading contexts7 but rather focus on the interface design choices and technical solution for the minimalist header-navigation hybrid. I wanted to rely on CSS only to make the interface work because I firmly believe that for the web to progress as a whole it needs to adhere to standards, one of which is to relegate information about the form of the content to style statements. So to create a collapsed segment in my information flow that would only become visible upon user interaction I relied on inspiration from Darren Collins about pure CSS clickable events.

The Code

For my conceptual model I modified Darren’s solution and used the skeuomorphic reference of a surface that separates to reveal a second layer beneath, pushing the content downwards as the rift widens. So here’s a minimal code example for you to peruse before I discuss how it translates into usability fallback properties that are contingent on the kind of technology the code is displayed on.

<header id="header">
    <h1>Jakob Jochmann</h1>
    <div class="rightheader">
        <span>home</span>
    </div>
    <span class="expandsign"><a href="#footer">Navigation</a></span>
</header>
<nav id="topnav">
    <div class="expandwrap">
        <div class="expandtrigger" onclick>
            <span class="button"></span>
        </div>
        <div class="expand">
            <div class="expandcontent">
                <span><a href="#">link1</a></span>
                <span><a href="#">link2</a></span>
                <span><a href="#">link3</a></span>
                <span><a href="#">link4</a></span>
                <span><a href="#">link5</a></span>
            </div>
        </div>
    </div>
</nav>

Note that there is a link in the header called navigation that points to the footer in the same document. Clicking on it will get you to jump down to a second navigation at the bottom of the page, a redundant mirror of the original navigation that is not collapsed. This will become our fallback for non-standard browsers that do not support the intricate use of CSS of the expanding navigation:

/* 
EXPAND
*/
.expandwrap {
    width: 100%;
    margin: 30px 0;
    position: relative;
}
.expandwrap:before {
    float: left;
    display: block;
    content: "";
    margin-bottom: 90px;
}
.expandwrap:after {
    content: "";
    display: block;
    clear: left;
}       
.expandtrigger:after {
    content: "";
    display: block;
    border-top: 1px solid #AAA;
    border-bottom: 1px solid #FFF;
    width: 100%;
    height: 1px;
    position: absolute;
    top: 80px;
}
.expand {
    position: absolute;
    width: 100%;
    margin-top: -60px;
    height: 0;
    overflow: hidden;
    transition:         all .4s ease-out;
}
.expandwrap:active .expand, .expandwrap:focus .expand {
    height: 130px;
    position: relative;
}
.expand:hover, .expand:active, .expand:focus {
    height: 130px;
    position: relative;
}
.expandcontent {
    height: 50px;
    padding-top: 10px;
    padding-bottom: 10px;
    margin-top: 80px;
    background: #DDD url(/background.jpg) repeat;
    border-top: 1px solid #AAA;
    border-bottom: 1px solid #FFF;
}
.expandcontent span {
    text-align: center;
    display: block;
    float: left;
    width: 15%;
    margin: 0 2.5%;
}
.expandsign {
    position: absolute;
    font-size: 20px;
    top: 48px;
    animation:          vanish 6s 3s 1 alternate ease-out forwards;
}
.expandsign:after {
    content: " ☛";
}
@-webkit-keyframes vanish {
    0%  {
        opacity: 1;
    }
    30% {
        opacity: 0;
    }
    100%{
        opacity: 0;
        -webkit-transform: translate(-10em, 0);
    }
}

The use of empty :before and :after floating elements wrapping the collapsed navigation allows our expansion to push down the content while it opens up. This maintains the skeuomorphic illusion of a widening rift. Margins and absolute positioning allow us to turn the whole header area into a target area for clicks, which is great because we can leverage user expectations about a blog header often being a link to the starting page.8 Even if a user does not click on the button, but rather anywhere in the header does the :active and :hover solution trigger the expanding navigation.

That is all nice and well for browsers that support all the modern CSS powering the design. But for browsers that do not support the CSS we must include another way for users to get to the navigation. This is where the .expandsign comes in. For one, it vanishes in all modern browsers that support animation, leaving the header to be clean as was my original intention. Secondly, the animation is yet another cue that alerts the user to the fact that there is something worth interacting with in the header area.

For browsers that do not support modern CSS the .expandsign takes on a different function entirely. It does not animate out and thus is the one element in the header that bears the salient properties of a link. Its color makes it stand out from all the other elements. Furthermore the text clearly states that it is a link to the navigation that is otherwise missing from the header, because the button has no function in these browsers. The button instead is being demoted to a decorative element, retaining the meaning of a logo in the header. The functionality of the navigation is preserved because of the solid fallback navigation in the footer that also sports a link to get the user back up to the start of the page.

Clearly this is an inferior user experience compared to the one in modern browsers, but that is the point of my fallback. It maintains functionality at a level that is still consistent with user experience, alleviating my pain to provide labor intensive maintenance for browser quirks or resorting to JavaScript solutions to replace standard protocol.

I did employ two hacks though, to make the CSS work for mobile safari. I think I can justify them with the fact that potential clients of mine are highly likely to use iOS devices. More importantly, so am I. The whole design language is meant to translate well into a touch paradigm after all. Furthermore the hacks are easy for me to maintain and monitor, should mobile safari change behavior—right now, it does not, by default, respect :active pseudo styles. I did not know this when I created the design at first, you can probably imagine my dismay. Thankfully Alex Gibson provided me with the solution once I could locate the problem.

    <!-- Add touchstart event to make mobile Safari respect :active pseudo style. -->
    <script type="text/javascript">document.addEventListener("touchstart", function() {},false);</script>

From there I also worked my way around another iOS quirk that is probably related to text selection. All :active triggers render inoperable once the viewport moves. As you can see in the HTML above I added an empty OnClick event to the trigger to remedy this behavior.

And with that last hack I got the usability of the site to the point I am comfortable with. I hope you are comfortable as well and that perhaps you may learn a bit from my struggles. All that’s left for me to do is go back through some old posts of mine and make the embedded material compatible with the new, responsive design. Thanks for sticking with me!


  1. device agnostic in the sense that the content dictates the breaking points for responsive design. As I’ll explain in this post in more detail, I specifically did not aim to make the content look the same on all devices. ↩︎

  2. Unless you absolutely must provide a pleasant experience on the outdated technology of legacy browsers because you know for a fact that your audience will need to be enticed into call-to-actions on software they are locked in to, you should not aim to fix the brokenness of obsolete browsers. Because if you do, you effectively perpetuate a fundamental brokenness of the web experience itself. This matters to all of us. The web is not just for web designers. It is quite obvious from the evolution of the internet that there are severe socio-economic costs involved with maintaining broken communication channels. ↩︎

  3. There is a draft called “Why You Should Care about the Web” sitting in my pipeline in which I’ll explain the problem of perpetuating broken technology on a more theoretical level. Along with the reasoning why I went through the hassle of investing considerable effort into writing my own design as someone who is not a web designer. I also touched on the issue before in the black box fallacy of web design↩︎

  4. the html code that gives your browser information about the content and its structure ↩︎

  5. the Cascading Style Sheets instructions that tell your browser how the content structure is to be displayed ↩︎

  6. using a character rather than an image is a nice bonus for scalability ↩︎

  7. have a look at the iA article Responsive Typography ↩︎

  8. That is a bit of a fallback already, because Opera, of all modern browsers, apparently has some issues with the z-index and the active state. I consider this a bug and rely on the actual fallback I installed for other broken browsers to remedy the problem. ↩︎

blog comments powered by Disqus