Here’s a couple of suggestions for making it better:

Swipe/Touch Gestures

The idea here is to make the center panel swipeable to reveal the menu and extra panels on small screens. This would be fantastic and I even tried doing this using a jQuery Swipeable Plugin but that would add a lot of complexity to the demo. Once you add touch events to an element it’s hard to get a natural page scroll right. I wanted the code to be simple and approachable.

Button icons

For the two “buttons” that show up on small/medium viewports, it would be nice to replace the text with some icons. Perhaps arrows that show that a panel is supposed to be a toggle. Possibly using an icon font set.

Thanks to all those who wrote me. See the demo for what it is and think about making it your own on your next responsive project. Also, I love my job.

The Off Canvas pattern for multi-device layout takes advantage of space off the screen to keep content or navigation hidden until either a larger screen size allows it to be visible or a user takes action to expose it. This pattern is showing up in a few separate mobile Web site designs and native mobile applications.

I wanted to know how this could work in the browser.

After a quick back and forth with Luke, I fired up TextMate and started to see what was possible with this kind of thinking. I wanted the code to be simple and use very little javascript. Ultimately, I ended up using a bit of jQuery to change class names and created css for each panel layout variation. A few detailed suggestions from Luke made it all the better.

Off Canvas is the multi-device web layout pattern demo I came up with to show off the technique. I think it’s a fantastic example of what can be done with responsive web design.

For the first time I found a use for the data- attribute. I was able to store page data in a variable and echo into the data attribute in the footer. Passing this variable into my ajax function, I could bring in the appropriate content tied to that page.

Here’s some things I learned:

• mustache.js templating
• MD5 Message-Digest Algorithm
• Reverse GeoCoding Zipcode via php proxy

Enter Fusion Tables

We had all of our location data already marked up on a different site so all I needed to do was parse through it and put that data into a new Google Fusion Table. Once the table is made public, I can map out the data onto a map. This makes it very easy to edit the data in the cloud and keep the map updated. Details on how to set up a new google Fusion Table layer can be found at the Google Code docs for the Maps api.

The locations map I made for AgriLife has 4 different layers that I’ve sorted by a “Type” column I added to the table.

Each layer has a corresponding legend item with a checkbox to toggle that particular layer.

I’d like to keep a record of these front page layouts in code and as an image gallery somewhere on my site. But for now here’s the first one.

Rethinking the Slideshow

We need a new way of thinking about featured content. If you think about the small screen first, thumbnails with titles are a great way to display featured content on mobile phones. The links of those thumbnails and titles follow to the appropriate page by default with no large images in the markup. We can then use those thumbnails as navigation when we scale up to larger screens and conditionally add our large slideshow images—adding onclick event handlers to the links making them change the large images. I’ve built a simple demo to show how this could be done. Check it out and make sure to refresh after resizing through the media query.

I’d like to think that there are endless possibilities for this type of conditional slideshow. Breaking out of the old standard way of designing sideshows and featured content. I hope there are designers out there that run with this and create light weight, flexible user interfaces.

The Basic Javascript

I need to give a lot of credit to Jeremy Keith for this idea as it is the same thinking he had for his 24Ways.org article Conditional Loading for Responsive Designs. In my demo, I don’t use a javascript library and tried to design a simple slideshow with the least amount of code possible. It may not support older browsers but this technique is more of a way of thinking rather than some code you can use as is. All the parts are there to make your own. Fork it on GitHub.

Below is a snippet of the javascript that does the conditional loading. The idea is to grab the big slideshow images if the slideshow container has a display:block css declaration.

//wait for the document to load
window.onload = function () {

  // get #feature-container that holds our big images
  var feature = document.getElementById('feature-container'),

  // get the style value of display on our big images container
  display = window.getComputedStyle(feature,null).getPropertyValue('display');

  // if the #feature-container display value is block
  if (display == 'block') {
    //we are wide enough to pull in the big images via ajax
    // get images and markup via ajax
  }
}(this);

That’s not really what I want to talk about. I want to talk about designing for the web.

Today I responded to a tweet by Ryan Plesko about using a fixed navigation on single page sites. Ryan tweets:

When designing a single page website consider fixed position navigation. Otherwise your menu is meaningless after the first click.

I agree. Ryan is absolutely correct. The best design decision you could make with a single page site navigation is to make the navigation fixed to the screen so the user can have access at any point on the page.

But, there are technical problems when positioning elements fixed on a page when you think about touch screens and other mobile devices. Brad Frost’s video explanation covers the difficulties mobile browsers have with position:fixed. The short of it: Mobile browsers aren’t consistent with supporting position:fixed just yet. There are frameworks and libraries we can use to better the performance in popular mobile browsers but you have to ask yourself if the added weight and complexity is worth it.

I responded to Ryan’s tweet:

That’s good advice but position:fixed falls apart on touch screens.

In which Ryan defends his tweet:

I’m not suggesting the only way to do it is posttion:fixed. Responsive design should accommodate other devices.

We can design our sites to only have a fixed position navigation on “desktop” sites. What does that mean? When the viewport is greater than 960px wide? What about large touch screen devices in landscape orientation? That’s 1024px of viewport being displayed. I clarify my reasoning with Ryan:

RWD won’t help either. You still have to account for large touch screens, right? Or do you have position:fixed > 1024px only?

In terms of thinking in a more device agnostic way, this is similar to the same problem I had with designing the theme for AgriLife. This theme had to accommodate content for 700 plus sites on a network install. Not knowing what the navigation was going to be, I had to design a system that included multiple levels of drop downs shown on hover. Ultimately, the navigation fell apart on touch screens because the second level of navigation links where not accessible. I’ve since discovered a better solution to the problem.

I’d like to think there is a simple approach to the fixed position problem. Ethan Marcotte has done a great job of this on his site displaying the navigation beautifully in each section. This keeps the site light and simple with no complex javascript overhead.

Consider the fact that touch screen users are accustomed to zooming. If you take a look at the jQuery Mobile example of fixed positioned headers and footers on your mobile device, you’ll notice things get a little crazy when zooming. The Twitter mobile app does this as well (at least for Android). Web Designer Wall‘s very attractive recent responsive redesign has a fixed position navigation on the left side of the content but viewing on a large touch screen it seems a little jerky and the zooming is disabled (tested on a TouchPad). Not an ideal result for touch screen users.

We have to consider touch screens when designing our sites and craft interfaces that are device agnostic. The desktop-centric design thinking must stop if we are going to have better experiences on the web.

And I promise to make better choices.

One section of my talk details specific techniques for hiding complex navigation on small screens using a little bit of jQuery:

// Toggle for nav menu
$('.menu-button').click(function() {
	$('#access').slideToggle('fast', function() {});
});

This shows and hides the menu by adding display: none; to the element with an id of #access. (See my FlexNav demo for a device agnostic approach to complex navigation.)

Pat Ramsey brought up a good point about accessibility when elements are hidden with display: none;. Particularly when using assistive technology like screen readers.

This got me thinking about web pages that are read aloud to small screen users. Would hiding the navigation with display: none; be an accessibility issue? I hadn’t thought about that at all until Pat brought it up. Doing some initial testing on my Android powered MyTouch using the WebSpeak app revealed that it read only the structured markup and completely ignores the css all together. This is a very good thing but I need to do more testing on different platforms and assistive technology. I’m concerned that as these speech technologies become more ubiquitous on small screens I would have fallen into a very inaccessible design pattern.

Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column set in a serifed text face in a text size. The 66 character line (counting both letters and spaces) is widely regarded as ideal.

Bringhurst is talking about setting type on a fixed page. This doesn’t work with a liquid layout as the columns would get stretched at large screen sizes leaving the measure of single-columns too long. This got me thinking about the idea that the use of media queries could play a role in the resizing of text as the page widens. I think this technique could work well.

I also thought about the use of multi-columns to split the content into two columns that could be easily digestible. Bringhurst informs us on choosing a comfortable measure for two columns:

For multi-column work, a better average is 40 to 50 characters.

We could easily apply this to modern web browsers.

Then I read a piece written by Khoi Vinh. He argues the notion that columns on the web don’t work:

All of this, I would say, makes columnized text inferior to the alternative: a single column of text, scrolling from top to bottom on a page that’s as tall as is necessary to accommodate the entirety of the text. Scrolling text allows users to advance at exactly their own pace — a paragraph at a time or even a line at a time. It also lets them shoot down to the bottom of an article — or even its middle — in an instant, without the multiple clicks or repeated swipes required in paginated layouts. This is the way most digital media works and for good reason.

I completely agree.

The web is a different monster than printed media. Users are accustomed to scrolling text on the web. The native iPad apps that page horizontally feel strange to me when because I’m not allowed to scroll down when reading an article. I think the idea and experience is novel but awkward.

I’m not sure how this will play out but I do know, just as Luke Wroblewski says, I’m betting on the web as a platform.