Media-queried responsive & adaptive sites afford us the ability to re-architect content on a page to fit its container, but with this exciting new potential come equally exciting challenges. Web designers will have to look beyond the layout in front of them to envision how its elements will reflow & lockup at various widths while maintaining form & hierarchy. Media queries can be used to do more than patch broken layouts: with proper planning, we can begin to choreograph content proportional to screen size, serving the best possible experience at any width.

As I step into my 3rd responsive project with Paravel, I’ve made a habit out of picking apart media-queried sites I happen across, noting how things get rearranged at various widths. At times, it seems as though all of the site architecture & planning goes out the window as content reflows. I’ve also found that what might work very well for one type of content or site might not work so well for another.

Content Stacking

This is unavoidable. Take a 4 column site at full width: as the view narrows, 4 will become 3, then 2, and 1. The most common solution is to stack them on top of each other in chunks (fig. a). Simple enough, but what happens if the first column is really tall? Is the content in column 2 less important than all of the content in 1? It probably is for something like a full-length article, but I can’t help but think that in some cases, this method throws off the hierarchy.

Another approach could be to interdigitate content by folding elements into each other as the view narrows (fig. b). In real terms, what happens if a main column is a tall grid full of product thumbnails, and the sidebar features a coupon or promotion? When those columns are combined, it might be nice to slide the promo in between two product rows instead of shuffling that important piece to the bottom of the main column.

The Content Change-up

Another thing I’ve noticed is that media queries are being used to significantly redesign pages. I’ve seen background colors change and top-level elements move from left to right. If critical thought is applied here those choices may be spot on. But what happens if a user visits at full-width one afternoon and revisits your site in the evening on a tablet, and everything looks completely different? It’s annoying—like someone rearranging the groceries in your pantry every time you closed the door. The power of media queries can be intoxicating, but just because you can doesn’t mean you should.

De-compartmentalize the Workflow

The production model of passing a site down the assembly line from design to development to launch seems to be an inefficient approach for responsive & adaptive site design. I think the Paravel method of gathering around a table & slugging every decision out until launch lends itself to the level of reiteration necessary for these projects. We’ve found that the best way forward is to pull all members of a team together to design, build, test and then evaluate in multiple quick rounds.

Of course, the alternative would be to create designs for every media query you plan to include, but that kind of thinking seems inefficient and fails to take advantage of the device-agnostic approach that responsive web design offers. In my mind, it’s best to build something that works on any possible width or device instead of something that works on all current widths and devices.

Balancing all of these new facets of the web designer’s role may seem overwhelming, but that’s the nature of the profession and one of the reasons why I love it. Honing the craft of content choreography will help us to orchestrate the best experience possible at any screen size or resolution. In time, I believe knowing what works best will become second-nature to us—just like designing progressively enhanced CSSed pages without tables or superfluous markup is now. The best thing for us to do? Practice!

Let’s face it, if your page fails to load in time, all the effort put towards information architecture, content strategy and interaction design will be for naught. During my formative front-end coding days, I did a fair bit of assuming that as Internet connections transitioned from dial up to DSL I’d be able to make compromises.  Piling sprite-less PNGs upon redundant CSS upon tons of HTTP requests became commonplace, and a few seconds for a page load seemed worth it.

Not Seconds, Milliseconds

But that’s not really how things are.  We close out the windows of tweeted links if the load bar lags.  We leave news and shopping sites early if they feel unresponsive and sluggish.  If a site is slow, the amount of time we’re willing to continue to invest decreases exponentially with every second... every millisecond. Bing and Google agree that slow pages lose users. Each company ran similar experiments where they deliberately delay server response time by a varying number of milliseconds finding that the longer users wait the less engaged they are with a page and the more likely they are to leave.

But good things come to those who wait. Right?

It’s tempting to want to build in enhancements-- if all those extra layers of functionality make a site more interesting, so what if they add to load times, right?  I’m not so sure.  Is it wise to assume that these features are something users will happily wait for? Users don’t crack open their browser thinking, “I can’t wait to experience the Acme Company’s website.”  They’re thinking, “I want to find a product / service / answer as quickly & easily as possible.” Waiting for content online isn’t about patience, it’s about simplicity. John Maeda sums it up brilliantly in his Laws of Simplicity (#3)

No one likes to suffer the frustration of waiting. Thus all of us, consumers and companies alike, often try to find ways to beat the ticking hand of time. We go out of our way to find the quickest option or any other means to reduce our frustration. When any interaction with products or service providers happens quickly, we attribute this efficiency to the perceived simplicity of experience.

We are building websites and creating user experiences for human beings.  More likely than not, that ‘good thing’ the user is waiting for isn’t your website-- it’s family dinner, time with their kids, or a few extra minutes of sleep.

We Are Presenters

But our job isn’t binary.  Unlike UPS or FedEx, whose job it is to get something from point A to B, web builders aren’t charged with just delivering information, but presenting that information through design.  Imagine a site like CampaignMonitor without its unique style, layout and imagery.  The design makes it easier to learn about the service, saving users time and effort. The balancing act here is to think critically about the graphics, scripts and code we’re serving to our users.  There’s an economy to it-- a give and take that shouldn’t be considered mid-process, but from the get-go.

The How-To

I’ll be the first to admit I’m no expert; nor do I consider myself a shining example of best practices.  Thankfully, Dave Rupert has been waving the page speed banner at Paravel for quite some time.  He’s led the way in changing the way we plan, design and code for web projects from the beginning to prevent users from having to wait to find & load content. Here are some resources & tips Paravel has found handy over the months/years. Whether you choose to lessen textures, simplify a design, and/or even swap images in favor of CSS3, that’s up to you. As we’ve found, little shifts, baby steps, can lead to a lot of gradual improvement over time. The most important thing one can do is to view a site visit not only as an impression or a page view, but also as a small part of someone’s day.

Resources

• Web Performant WordPress: 5 steps to a faster website from Dave Rupert
• Firebug: Firefox plugin for performance analysis
• Yslow: Firebug plugin from Yahoo that grades your page speed
• Google Page Speed: Evaluate website performance via Firebug
• Which Loads Faster: Pages compete in your browser for quickest load
• WP Super Cache: If you run WordPress, you need this.

Image Compression & Sprites

• Image Optim: A simple drag & drop for images, reducing disk space
• Smush.it: Batch shrink images while retaining file structure
• SpriteMe: Automatic image sprites and CSS for everyone!
• Specify Image Dimensions: Part of a Google article about optimizing browser rendering

Efficient CSS

• Minify CSS: Compress CSS & JS
• Efficiently Rendering CSS: Solid tips for how to keep your CSS lean & mean
• CSS Sprites Workflow: Chris Coyier’s implementation workflow

A few days after Steve Jobs announced the release of the iPad, I read that in Apple’s Reference Library: Preparing Your Web Content for iPad, and started to realize the drastic implications the evolution of multi-touch would have on interaction design. Anything we design for the web that requires a hover state has an uncertain future and could be subject to serious usability issues.

The Touch-Screen Boom

If you think this is something that can be addressed later, when multi-touch “catches on”, consider this: as of June 22, 2010 Apple has sold 3 million iPads in 80 days, 1.03 million touch screen phones are sold per day, and companies like Dell and HP have been developing & releasing touch interfaces for tablets and laptops for quite a while now.

The Hover Crutch

Hover states are everywhere. I don’t think I’ve ever written a stylesheet or designed a site without putting a significant amount of thought into how they should behave. As users, we’ve been conditioned to rely on hovers states to trigger changes in link color, reveal action items, and navigate through multiple tiers of a drop-down menu. Sliding our mouse pointers across a page to reveal hidden clickable points of action has become an automatic addition to our web browsing skill-set. As designers, we’ve turned to hover states to accommodate extra content and allow visual aesthetics to trump usability. Like it or not, those days are over and the interactions we design are going to have to stand on their own two feet.

I believe that in most cases, the best solution isn’t pursuing alternatives such as multi-touch hovering technology, trying to adapt hover-dependent designs, or transforming your website into an iPad/iPhone application. Instead of adding scripts, kilobytes, and billable hours to treat symptoms, I think the focus should be on simplicity and bullet-proof user experience design. In line with Luke Wroblewski’s statement that we should start designing for the web mobile-first, I propose that we should be designing for Multi-Touch first, and moving forward, we can only afford to add hover states as enhancements only.

Try to Avoid

• Hyperlinks that aren’t 100% obvious
• Javascript tooltips that show important information or metadata
• Displaying action items on hover. Examples I’ve seen typically involve edit / delete items.
• Displaying graphics in a less-than-ideal state until hovered: all those semi-opaque or black & white screenshots and photos that only display full color when covered by a cursor
• Drop-down menus. While some of these can be revealed on click or tap, be sure the user has cues that show those options.
• Focusing too much on hover dependent CSS3. I know it’s a bit of a heartbreaker, but while these have always been seen as enhancements, we’re going to have to settle with the fact that multi-touch users won’t be seeing our fancy transitions.

How do we adapt?

More often than not, making adjustments won’t be a quick or a simple process. The more layers of interaction a site has, the more work is going to have to be done to address usability issues. I’ve noticed that a few of my favorite sites have already taken a variety of steps to provide some fixes.

Show everything.

Prioritize your content, and if you’ve been hiding things behind hover states, make room to display them. The WordPress admin posts screen is a great example of this. Normally, action items are only visible on hover, but if you login with a touch device the links are always displayed.

Utilize tap to reveal a hover state.

Depending upon the implementation, this can be risky; Amazon has done fairly well with this method for their category-based shopping navigation. The paneled list and orange arrows help to make those areas clearly tappable. Another example can be found in Basecamp’s edit and delete controls for to-do lists, milestones, and files. When you hover over one of these the action items appear. For touch-screens they’ve built a javascript popup that works fairly well once you’ve figured it out. The problem is that users get no cue that tapping the to-do text is even an option, and I can’t help but think a solution similar to WordPress would have worked better. That being said, I’d happily pay a few extra pennies per month to get a mobile version of Basecamp.

Build specifically for touch-screen devices

and take advantage of native device controls, gestures and popovers. Touch-screen apps for Twitter and Gowalla play a key role in their overall success and are probably used more than the websites themselves. I use the Netflix iPad app regularly, but in many cases it feels like a hover-dependent website dropped into an iPad viewport. Currently, if you’re browsing instant titles and want to add something to your queue by tapping, you’re looking at a 3 step series of taps instead of an instant hover reveal option with a point-and-click interface. If you’re going to build specifically for touch, you’ve got to follow through.

Wait for touch hover technology.

I’m not convinced this would do anyone any good. It may be exciting to see what Cypress has come up with, and to know that Apple has applied for a patent for a proximity sensing touch-screen, but this does worry me. I’d hate to see us revert to our old shortcuts and make user experience sacrifices just because the technology is in place. Plus, we’re going to look like a bunch of idiots who are afraid to touch our smart phones & iPads. On the bright side, Phil Dunphy would love it!

We’re going to be OK.

Ultimately, I think seeing hover states fade away will make the web a better place. There never has been any substitute for concise content, clear interaction, and simple design. If we focus on core elements that make browsing the web great, our sites will function properly no matter how people use them.

Part of user-experience design is considering how elements on a web page compete for attention. We spend so much time prioritizing the prominence of items within a page while making little consideration for what else people are doing. What if users rarely devote 100% of their attention to a web page? To learn more, I surveyed 83 of my closest friends on their browsing habits:

What does this mean?

To me, this just confirms what we’ve always known. People don’t browse in a vacuum. We’re mid-conversation, getting off the bus with battery life & email notifications blinking at us web browsers. My Paravel cohort recently tweeted:

The less your design competes with itself, the less you compete with everything else

This high level of competition for attention is something web designers must always have in mind. Keep things simple. Present users with one idea at a time and while you’re at it, go ahead and make that button 20px larger.

So, an organization spends tens of thousands of dollars to build a website upon a full-access Content Management System (CMS) platform. Over the coming months every department head is issued an administrative login, which is passed on down the line to other employees. Pretty soon, 50 people have updated the website adding page upon page with 50 different writing styles and 50 different online agendas. 12 months later, the organization is left with a mangled site map and is forced to hobble along for years until they can afford to begin the process again. What a sad, yet common, story.

Don’t Blame The CMS

This is an expensive problem that has less to do with breaking down a CMS from admin screen to home page, and more to do with what role an organization expects the CMS to play in managing content. A CMS is a tool for providing an efficient method for updating content without extensive HTML coding skills. A CMS will not consider your business plan, site map, or how new content will effect user experience. A CMS, no matter how powerful or user friendly, does not justify dropping the task of managing the website on the edge of an employee’s already full plate. Organizations must recognize that someone or some department must be put in place with the authority and time to make decisions about what does & doesn’t belong online. After all, it’s people that power websites.

A Tailored Approach

Many CMSs give admins the ability to create pages whenever and wherever they want via standard issue templates. It is an easy solution during buildout, but it leaves the site map completely vulnerable to rogue, unlinked pages. This disrupts the overarching navigation and user experience. It’s like adding a room to a floor plan without considering doorways, or how it flows with the rest of the house. Additionally, all the web pages start to look the same-- a bland array of words within a boxy page frame and site masthead. Instead of multipurpose page creation, why not provide tailored methods of updating specific content? Paying close attention to the way items like news posts, events or catalog items are updated and displayed creates a truly dynamic site in both form and function.

Content, Managed

Think of your website not as an online archive or a repository for all your data, but as an experience. It isn’t the amount of content that makes your site valuable, it’s how easily users are able to access the content they’re looking for. If organizations, web designers and developers work together to develop a CMS strategy that considers what happens before and after admins login to make updates, websites will continue to look great & function properly, organizations will save money, and users will be able to spend less time weeding out broken, unusable websites.