Error getting theme layout

Performance Considerations of Adaptive Design: Part 1

Posted @ 2:11 pm by Amadeo Donofrio | Category: Creative Design, Strategy, User Experience | 0 Comments

Everybody wants a flexible or ‘responsive’ UI these days. As the proliferation of smart phones and tablets are on the rise, it’s becoming not only the trendy thing to do, but a vital method to remain relevant. I’m assuming you’re already familiar with my colleague’s blog post where he highlights compelling statistics supporting the mobile usage growth trend. If you haven’t already read his post, I recommend you do so before continuing with this article. The methodology of building a UI that is not just flexible, but also lightweight under the hood is still evolving. If you’re considering adaptive design for your website, and you’re concerned with site optimization, you may want to consider the following.
 

Terminology

Many people use the terms “responsive design” and “adaptive design” interchangeably, while others profess deep philosophical differences between them. Flame wars are presently under wage in forums and blogs across the internet on this subject. In my opinion, there is no correct answer, but for the purposes of this discussion we need to agree on definitions.

Definition: Responsive Design

Ethan Marcotte, from A List Apart, first published the notion of responsive design on May 25, 2010 in his article “Responsive Web Design”. Marcotte defines responsive design as CSS used to scale images and content areas, as well as media queries that target specific viewports (browser window size). Note his bold position below.

“We can design for an optimal viewing experience, but embed standards-based technologies into our designs to make them not only more flexible, but more adaptive to the media that renders them. In short, we need to practice responsive web design.”

Definition: Adaptive Design

Aaron Gustafson authored a book called Adaptive Design in 2011. In it, he likens adaptive design to progressive enhancement.

“The idea of starting from the ground up to rebuild their output mark-up, images, and CSS is daunting at best. In many of these cases, it is preferable to keep the current design built for desktop displays and simply “adapt” it for varying contexts.“

When we ‘adapt’ an existing web property to support multiple contexts, we practice adaptive design. The methods used to achieve this can include responsive design techniques (media queries, flex width columns, image scaling), but it can also employ client and server side logic to adjust content delivery and layout. Furthermore, this is a continuous process, because the web itself is continuously changing as are the needs of its users. Try to think of adaptive design as a holistic philosophy which may include responsive techniques.
 

The Performance of Multiple Layouts

With the recent introduction of the iPad mini, I’ve already started hearing clients ask for iPad mini responsive states. My recommendation is always to support three, and only three target contexts (desktop, tablet, and mobile) for a few reasons. Firstly consider that for an additional optimized target context, you will spend approximately 0.5x times the cost for each creative design, user experience, engineering, and QA. Secondly, the popularity of the 7-inch tablet may suggest we introduce a fourth target context, but what comes next? The Samsung Galaxy Note 2 is 5.5 inches which is right in between the iPad mini and the iPhone. Should we consider further dividing the mobile audience into large and small sizes? Going down that road is a slippery slope and the difference between large and small tablet context, or between large and small mobile phone context is not significant enough to necessitate an optimized layout for each. Thirdly, each layout context is driven by custom CSS and markup, which must be delivered to the user whether they see it or not.  Extra code means more data to parse and slower page loads. This is the opposite direction we want to go in.

Rather we should design our UI to be flexible in width (up to a maximum of 1240 pixels wide for desktop) with key break points for tablet and mobile. In this way our content is always presented at optimal width on smaller hand held devices. Take a look at this example we did for our client, Fox Sports.

 

fox sports image 1

 

In this screenshot above, we are browsing with a viewport of 1400 pixels wide. Note that gradient banner of the header extends the full width of the browser, and the content is bound to a content area of 980 pixels.

 

Fox Sports image 2

 

Because we understand that in January of 2012, 85% of desktop users had monitors with resolutions higher than 1024 pixels, we can safely assume a viewport of 1024 pixels or is a handheld device. In this client’s case, the navigation is driven by a CMS and we do not have control over how many links appear in the main navigation. Because we have to support what we can’t anticipate, at this point we move all of the navigation into a single drop down with an action icon to toggle visibility. This design choice is flexibly supported by all mobile contexts. Note we’ve also compressed some of the partner links in the top right corner.

 

Fox Sports Image 3

 

In this screenshot above, the viewport is at 850 pixels wide. You’ll note that we still maintain the three columns, but the center content is scaling down in width with CSS. This layout supports both small and large tablet contexts.

 

Fox Sports Image 4

 

At 768 pixels, shown in the screenshot above, we shift to standard tablet optimized view. The left rail is now absent and the logo has decreased in size. The background header gradient has scaled down in width too. This CSS trick uses the background-size property to scale the background image width to 175% of its original. This layout is supported by small tablets, and large tablets in the portrait orientation.

Fox Sports Image 5

 

We assume anything under 675 pixels to be a mobile phone, and present it with this optimized single column view. In this screenshot above, at 500 pixels you’ll note the additional partner links in the header are now also suppressed, and the sign in links have moved up to the top right. This layout is specifically optimized for phones, but if you had a really small tablet (less than 675 pixels wide) you would see this too.

 

Fox Sports Image 6

 

This last screenshot above is at 338 pixels wide. Note the content still scales to the full width of the viewport, as evidenced by our header, which breaks to new lines automatically. This flexible mode supports the wide variance of phone screen resolutions. Viewports smaller than 338 pixels are not supported by this UI and would experience a horizontal scrollbar.

As is evidenced in the above six examples, flexible layouts can support a wide variety of use cases, but we optimized the development process by targeting three key breakpoint states during our user experience exercise. In this example, less is truly more.
 

Summary

With so many different devices in the handheld ecosystem, it’s easy to get carried away and try to design a custom solution for each. By maintaining no more than three individual (yet flexible) layouts, you are well on your way towards optimizing your markup, and your development cycle. However, when you consider the size of content delivered by your web app for each context, it’s clear we can further optimize. In part two of this article, we consider different approaches that address the performance issues of a flexible user interface for your web application content.

 

Author: Amadeo Donofrio is a Front End Technologist, working with SolutionSet since 2006. He leads the User Interface Engineering team for the Social Business Practice.

Leave a reply

Error getting theme layout