The results are in! Nearly 5,000 voters weighed in on the last poll to decide if the off-screen "drawer" navigation style that has swept mobile design is appropriate for larger screen ("desktop") designs. You could answer:

• It's not good on any site.
• It can be good on any site.
• It's good for mobile sites, but not desktop sites.

Only 10% of you were of the opinion that the off-screen nav isn't a good idea on any design. So the vast majority approve of it at least on small screens. The remaining 90% were fairly evenly split. By a nose, at 46%, you voted that off-screen nav can work on any design, making it the most popular choice. 44% said it's only appropriate on mobile sites.

Here's a visual breakdown:

See the Pen GtCqp by Chris Coyier (@chriscoyier) on CodePen

Personally I'd lean toward the pragmatic. I know I asked for you to vote without any context of a particular design. That's just to get a general gut instinct and sense of the community vibe around this idea. But I'm sure most of us make real life decisions, especially design decisions, based on the real facts in front of us. If a drawer made a ton of sense on a large screen desktop site design, we'd probably go for it. But of course this idea was born from the reality that small screens are small and moving navigation away from the primary screen gives us more real estate to work with and bigger tap areas in both places. So to put it on a large screen design where that isn't as much of an issue, might be weird. But then again, possibly less and less weird over time as mobile designs dominate what people interact with.

Poll in the sidebar another day or so before the next one goes up. Check out the polls archive for full, real time results for this and all past polls.

Poll Results: Off Screen Navigation Use on Mobile/Desktop is a post from CSS-Tricks

There's so much goodness happening on the web and as it continues to evolve, it's important that talented individuals step up into leadership roles to help shape the future of web development. And doing this isn't an easy task. Not only do you need to have the technical chops to help define new techniques and paradigms or create the next great technology, it's equally important to be able to effectively convey your message in a passionate and credible fashion so that your peers respect your direction.

Lea Verou is one of these new breed of leaders who is helping to push the web forward through her technical savvy and profound love for web standards. She's developed quite a following and her live coding sessions at major conferences are a thing of legend.

We had an opportunity to find out more about her in this Q&A.

I’m Lea Verou and I’m a web designer/developer and web standards geek (sounds like an AA introduction, doesn’t it?). I’ve created several open source projects such as Prism, a syntax highlighter used in A List Apart, Smashing Magazine, WebPlatform.org, MDN and other big websites, Dabblet, an interactive code playground, or -prefix-free, a JavaScript library that lets authors forget about vendor prefixes and code to the future standards. I’ve also come up with and published several CSS techniques, such as using CSS gradients to create patterns. I’m currently employed by W3C, although I’ve announced that I’m leaving at the end of July to pursue other challenges, such as writing and designing my first book.

Not really, to be honest. I still do my thing, make stuff and put it out there in the hopes they will be useful for someone. I still speak my mind about the technologies and best practices I like and those that I don’t. Whoever wants to listen to me, it’s their call. I’m not going to censor myself because of the number of people who are following me. That would be counter-intuitive, since being myself made these people follow me in the first place.

I think both browser makers and the WG (working group) have realized that vendor prefixes, although good in theory, do not work in practice. So, the way to go right now seems to be browsers implementing experimental features under a setting instead of behind a prefix. That way, developers will not start using it in production, forcing the WG to get stuck in early iterations, as was the case with vendor prefixes.

There’s no single cause, but I believe a big part of the blame lies with developers. Although we’ve endured the pains of a browser mono-culture before, we did not learn much. IE6 used to be really cool stuff 12 years ago you know, just like WebKit is today. I can see the CSS WG being at fault too, for not realizing the issues with vendor prefixes early on, which turned web development into a popularity contest. Last but not least, the WebKit team shares some part of the blame, as they shouldn’t have implemented non-standard CSS features to get ahead in the browser game.

I’m sure you are aware of the old project management triangle paradigm: Something cannot be fast, high quality and cheap, you need to pick two. I believe this applies to designing APIs as well. Budget is limited, as there are very few people paid to work on standards. So, basically, designing new features can either be fast or high quality, but not both. We can see the former when browsers decide to innovate: Usually, even when the original ideas are good, they are poorly thought out, since they were designed in the vacuum of a single company (examples: Drag and Drop API, -webkit-gradient()).

When the standardization process is followed through, features can be very high quality in the end, at the cost of taking a long time to be finished. Several parties with different interests need to reach consensus, a full test-suite needs to be written, it needs experimental implementations and several iterations based on implementor feedback. All of this takes time, but keep in mind that once a feature enters the open web platform, we’re stuck with it for years, if not decades. Therefore, it pays off to invest that kind of resources in to it, and to be patient. Short-term pain for long-term gain ;)

I will still be involved in the CSS WG as an Invited Expert. The WG voted on it in a recent telcon and I was happy to see several people in support and nobody against it. :) In fact, I will be able to devote more time to it now, since I expect to have more free time in general, and having worked at W3C gives me a unique perspective and insight into the standards process.

I have several safeguards preventing me from messing up. I keep my code examples concise, showing only what’s needed. This also helps the audience understand, as the code is small enough for them to process. I believe that as the number of lines in a code sample grows linearly, understanding decreases exponentially. Most importantly, I practice a lot. I might not practice the delivery of the talk, but I always practice the live coding several times, even when I’ve given the talk before. Also, even if I mess up, which has happened a couple times, the audience is so glad to see the result gradually build up in front of them instead of being presented with a screenshot, that they can be incredibly forgiving of missteps. If something does not work, I will spend a few seconds trying to fix it and if I can’t, I will explain what was supposed to happen and move on.

I often see people ruining live coding presentations by showing too much code, with too many distractions (e.g. a full IDE around it and having to switch windows to see the result) and long delays trying to debug their code when something goes awry. All three are very effective in getting the audience to lose focus. However, done right, live coding can be a great teaching aid and make a talk more engaging and fun.

My two biggest interests since my preteens were design and programming. So, when I started making websites, I was studying the languages involved, as much as studying graphic design principles. I fell in love with CSS because it felt like a bridge between the two, which is why I specialized in it.

Regarding resources, I was always the type of person that learned through reading and practicing (in that order). I would read an entire book and then build something that helps me put what I learned into practice to create something that I wasn’t able to before. I don’t learn easily from lectures, and I even glided through university (Computer Science) studying on my own, rarely attending any lectures. However, this greatly depends on the person, I know some amazingly skilled folks who absolutely hate studying on their own without anyone teaching them. I think that’s why I tried to take a different approach in my own talks, because I find conventional lectures so damn boring and hard to follow, except for the rare case where the speaker is as funny as a stand-up comedian (and while I like to think I have a good sense of humor, I’m by no means on that level).

More About Lea

Thank you Lea for taking the time to chat with us. To get to know more about Lea and her work on standards and web development, be sure to visit her website and follow her on Twitter. Also, if you have an opportunity to see her speak in person, definitely jump on it. Her list of past and future events can be found on Lanyrd which also link to videos of her previous presentations.

Of the many factors that must be considered in Web design, emotional interaction is an important, but frequently neglected, component. In the real world, we experience the sensual interaction of design all the time. Reflect for a moment on the emotional engagement of slipping behind the wheel of a powerful luxury car: the welcoming embrace of the driving seat, the tactile experience of running your hands over the leather on the steering wheel, the subtle gleam reflected in the controls.

There is no technical requirement for any of these finely crafted details: The vehicle would perform equally well without them. Yet this singular focus on sensual and emotional engagement is what separates luxury goods from all others and what inspires deep loyalty from customers.

This drive for emotional design can be discovered in the most surprising places. Take the power light on the next to last-generation Apple MacBook. The company deserves credit for helping thousands of users avoid entanglements with power cords though the MagSafe connector, but the deeper emotional intimacy is held in the tiniest of details: the power status light on the front of the laptop. When in sleep mode, the light pulses, and not randomly: It does so 10 times a minute, the breathing rate of a resting human being.

The blink rate of Apple’s MacBook in sleep mode falls within the average breathing rate of a resting adult. (Image source: Michael Stillwell)

To take another example: The front of a car is not two headlights and a grill. It is a face, one with its own character and communication. Look at cars and vans marketed to suburban mothers, on which lines tend to be round, curved, welcoming and friendly.

The front of the vehicle often demonstrates the neotenic effect: We regard “eyes” (headlights) that are larger than the body as being cute, safe, loveable. Compare this to the visual communication of vehicles marketed to men, particularly sports cars: Those lines are angular and aggressive, right down to the slitted eyes.

Note how a sports car’s front interacts with you on an emotional level. (Image source: GabboT)

Designing For Emotion

We can strive to achieve the same emotional engagement on websites — a promise to delight, surprise and affect users without resorting to manipulation or being too saccharine. While the digital realm lacks many sensual cues, it is possible to impart an emotional experience through a careful selection of color, stroke and typography.

CSS transitions help us to make interactions more human: Rather than flicking from one state to another, we can ease the motion of an element over a few hundred milliseconds to make a website feel more inviting. Paradoxically, the same techniques can also make a website feel faster, especially if we use the opportunity to preload content.

In creating such experiences, we must avoid the mistakes of the past: The engagement should encourage the visitor to explore the website, but should never hide important components such as navigation. Rewards for exploration should be a treated as a bonus, rather than a required interaction. Any information shared should also be accessible to those who don’t have the time or ability to use the interface.

Surprise In Boxes

(Please see the demo at “Hover Effect on Images From Different Directions Using Pure CSS,” on CodePen.)

One way to design for emotional surprise and stimulation might be to present different panes of information according to the way the user hovers over a responsive image. For this example, I’ll use a photo of the spiral galaxy NGC 1309, added to an HTML5 page:

    <img src="ngc-1309.jpg" alt="">
    

(Note that I’ve intentionally left the alt value of the image blank. We’ll return to that attribute shortly.)

The information panels are created from four span elements, with the entire group wrapped in a div tag that includes a class:

    <div class="multi-hover">
        <span>Spiral Galaxy NGC 1309</span>
        <span>Approximately 120 million light years from Earth</span>
        <span>Home to several Cephid variable stars</span>
        <span>Member of the Eridanus galactic cloud</span>
        <img src="ngc-1309.jpg" alt="">
    </div>
    

We’ll write the CSS transition code sans vendor prefixes: Internet Explorer 10 does not use prefixes for animation, Firefox no longer requires them, Chrome is not far behind, and a piece of JavaScript magic such as Lea Verou’s -prefix-free will take care of those browsers that still do.

    .multi-hover {
    	position: relative;
    	font-family: Orbitron, sans-serif;
    	max-width: 500px;
    	line-height: 0;
    }
    
    .multi-hover img {
    	max-width: 100%;
    }
    
    .multi-hover span {
    	position: absolute;
    	width: 100%;
    	height: 100%;
    	line-height: 1.5;
    	font-weight: 100;
    	text-align: center;
    	box-sizing: border-box;
    	font-size: 3em;
    	transition: .3s linear;
    	color: white;
    	padding: 15%;
    	opacity: 0;
    }
    

The CSS takes advantage of the rule that absolutely positioned elements inside relative containers will be transformed relative to their parent. Because the image determines the height and width of the div, the span elements will always be exactly the same size, protected from growing further by the use of box-sizing, max-width and line-height: 0. In this example, I’m using Orbitron by The League of Moveable Type as an appropriate typeface.

Next, locate the span elements, so that each lies just over the inner edge of the image. We’ll do so by writing offsets from the containing div in percentages, to keep everything responsive:

    .multi-hover span:nth-child(1) {
    	top: 0;
    	left: 90%;
    	background: hsla(0,70%,50%,0.6);  } /* right panel */
    
    .multi-hover span:nth-child(2) {
    	top: -90%;
    	left: 0;
    	background: hsla(90,70%,50%,0.6); } /* top panel */   
    
    .multi-hover span:nth-child(3) {
    	top: 0;
    	left: -90%;
    	background: hsla(180,70%,50%,0.6); } /* left panel */  
    
    .multi-hover span:nth-child(4) {
    	top: 90%;
    	left: 0;
    	background: hsla(270,70%,50%,0.6); } /* bottom panel */
    

As you’ll see in a moment, the order of the panel declarations matters. The result looks something like this:

Positioned span elements with text. (Large view)

To clip the outside edges of the panels, use overflow: hidden on the containing div:

    .multi-hover {
    	position: relative;
            overflow: hidden;
    	font-family: Orbitron, sans-serif;
    

Now, the result appears like this:

The colored sections we can see for now will function as the “hit areas” of our panels. Increasing the size of these areas will increase the panel’s ability to respond to quicker and broader mouse movements, but will also increase the overlap between them, making it more likely that a different panel will be activated than the one expected.

Finally, we’ll hide the panels entirely by setting their opacity to 0 and moving them on hover, taking advantage of the fact that transparent elements still respond to mouse events.

    .multi-hover span {
    	position: absolute;
    	width: 100%;
    	height: 100%;
    	line-height: 1.5;
    	font-weight: 100;
            z-index: 2;
    	text-align: center;
    	box-sizing: border-box;
    	font-size: 3em;
    	transition: .3s linear;
    	color: white;
    	padding: 15%;
    	opacity: 0;
    }
    
    .multi-hover span:hover {
    	opacity: 1;
    }
    
    .multi-hover span:nth-child(odd):hover {
    	left: 0;
            z-index: 3;
    }
    
    .multi-hover span:nth-child(even):hover {
    	top: 0;
            z-index: 3;
    }
    

The odd and even declarations set each panel to the opposite side of the box, positioning them entirely over the image and completing the design. Note that this interface pattern requires exploratory mouse movement from the outside of the box inwards to activate each panel; alternately, a completely “in box” exploration model could be created by lowering the z-index of the :hover states to 1.

Accessibility Testing

Making the panels invisible brings up the issue of accessibility. Partially sighted users might be able to see and interact with the panels, but blind users obviously will not.

Screen readers treat such content as being truly “invisible” (leaving them, therefore, unread), depending on the context; content that is set to display: none is usually left unread, for example. However, opacity does not trigger this behavior. On a Mac, you can easily test this by activating VoiceOver and having it read the page we’ve created in the browser:

• Command + F5 to start VoiceOver,
• Control + Option + A to read Web page content,
• Command + F5 to stop VoiceOver.

You’ll hear the span content being read in the order that it appears on the page; all that’s missing is a description of the image at the end:

    <div class="multi-hover">
    <span>Spiral Galaxy NGC 1309</span>
    <span>Approximately 120 million light years from Earth</span>
    <span>Home to several Cephid variable stars</span>
    <span>Member of the Eridanus galactic cloud</span>
    <img src="ngc-1309.jpg" alt="Photograph of NGC 1309">
    </div>
    

Note that this only treats the visual aspects of accessibility. There are other important areas (cognitive, motor and language) that I will leave unaddressed in this example for the sake of space but that have been detailed by other Smashing Magazine authors.

Adding Touch Support

The majority of mobile devices that depend on touch interfaces do not support a pure “hover” state: An element is either “in touch” or not. With rare exceptions, there is no registration of a fingertip being just above the screen of a mobile device. A brief touch might be interpreted as a hover event by mobile browsers, but this behavior is not perfectly predictable. As such, our interface will not work on most tablets or phones, at least as it currently exists.

To solve this issue, we’ll add a little JavaScript (by way of jQuery) to the page:

    <script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js">
    </script>
    <script>
    function is_touch_device() {
      return !!('ontouchstart' in window) 
          || !!('onmsgesturechange' in window); 
    };
    
    $(document).ready(function() {
      if (is_touch_device()) {
        $('span').unbind('mousenter mouseleave touchend touchstart');
        $('span').bind('touchstart', function() {
          $('span').removeClass('hover');
          $(this).addClass('hover');
        });
      }
    });
    </script>
    

The JavaScript applies a class of hover to any span element that is touched. So, we just need to alter our CSS declarations to make this class equivalent to the :hover event:

    .multi-hover span:hover { opacity: 1; }
    .multi-hover span:nth-child(odd):hover { left: 0; z-index: 3; }
    .multi-hover span:nth-child(odd).hover { left: 0; z-index: 1; }
    .multi-hover span:nth-child(even):hover { top: 0; z-index: 3; }
    .multi-hover span:nth-child(even).hover { top: 0; z-index: 1; } 
    }
    

Note that in the mobile version, the extended panel goes “under” the level of those that are retracted, allowing them to be tapped.

Disengaging the copy controls on handheld devices might also be wise. This is not some futile pursuit of DRM, but a practical response to the fact that longer touch times on mobile devices can bring up copy prompts that could get in the way of the user interface:

    .multi-hover span {
      -ms-touch-action: none;
      -webkit-touch-callout: none;
      -webkit-user-select: none;
    }
    

This user interface pattern of exploration on a mobile device may now be described as “tap on edge.” This could be further enhanced by increasing the overlap of the original position of the span elements in an @media query to provide larger hotspots, making the panels easier to activate, along with further improvements for smartphones. This code is not the only way to achieve this effect either: Ana Tudor has written an alternative technique using CSS transforms and SASS.

Conclusion

Crafting an element of surprise on Web pages can raise visitor engagement without obfuscating important content, sidelining mobile visitors or disadvantaging users who require accessibility features. Naturally, this must always be balanced with the need to guide users through the website: Visitors will only be surprised by the effects described here if they explore the page for themselves, or are led to it. How much users should be led and how much opportunity they should be given to discover a delight on their own initiative is a central question of user experience design.

(al) (ea)

© Dudley Storey for Smashing Magazine, 2013.

Namebox is a simple service created by designer Drew Wilson to help you sell your unwanted and/or unused web domains. It’s free to use and is built to make listing your domains quick and easy.

For those of you that are unfamiliar with Drew and his work, he’s well renowned for building his own products from start to finish all by himself, and Namebox is no exception. In fact, in this case, he built the whole thing in just two days! That includes doing everything from the design to writing the front and back end code as well as writing the copy.

Not only is the speed at which the site was built impressive, but also how quickly it began to take off. Within the first 24 hours there was 15,000 visitors, 800 sign ups, and over 2,100 domains listed.

Whether you’re looking to buy or sell a domain, I highly recommend that you check it out.

What do you think of Namebox? Will you be using the service to sell your unwanted domains? Let us know in the comments.

FLATPAD: A Twitter Bootstrap-Friendly UI Design Bundle – only $9!