Tuesday 19 March 2013

Fluid, Adaptive, or Responsive?

As a web developer, I'm starting to have more and more conversations about responsive websites. The term is being used as a catch all similar to how same people are using the term html5. Some people mean a fluid layout, others mean an adaptive layout, and (I think just by chance) some people really do mean a responsive layout. There are plenty of blog entries out there already that talk about these, so my thoughts after the jump are more about crystallising my own understanding rather than adding anything new to the definitions.


Fluid

Fluid grid based layouts have been around for a while. They didn't originally have much to do with the multi-device driven web world that we live in today. It was more about the various screen resolutions that people had with their desktops and laptops.

A fluid grid sets elements on the page to a relative size, rather than an absolute one. This allows elements to grow and shrink so that no matter what size your screen is the main content is always X% of your screen width. You might have added a maximum width to ensure that those lucky few with big monitors didn't see your whole paragraph of text on one line, but that was about it.

Unlike with the methodologies below, there is no distinct difference of presentation between screen sizes. The content is the same, displayed in the same way, just maybe wrapped around and under (which of course could look ugly on extreme screen sizes).

Adaptive

I used to think that responsive was a subset of adaptive, and then I thought of adaptive as a subset of responsive. Now I don't think either one is a subset of the other. They share some similarities, but neither fully incorporates the other.

Unlike fluid, there are multiple styles that are triggered at defined resolutions (known in the biz as breakpoints). Elements are fixed, so content doesn't move around in an unexpected or unintentional manner between those breakpoints. This can mean that you end up scrolling if your screen falls inconveniently between two breakpoints.

Adaptive allows for the original html document to be manipulated by JavaScript by adding and/or removing elements. Don't want that secondary menu at the top? Delete it! Add another one to the bottom where it distracts less from the content you really want your visitors to consume, or just forget it altogether.

Between breakpoints behaviour of the elements may change. On a larger screen the menu may have secondary levels that fly out when hovered on, but if the user has a smaller screen they probably don't have hover capability so you'll need to tweak that functionality so that they still have a comfortable user journey. The behaviour doesn't necessarily need to change because of device capabilities, but it is something that you should definitely be considering. For example, you may want to employ some server side technology to serve media in a format that's optimised for the device and screen size

I've read many blogs where people equate adaptive design to progressive enhancement, and I can see where they are coming from. This methodology is more about targeting devices and making the experience of the site good no matter how the user is interacting with it.

Responsive

Responsive designs should be built so that the site is the best that it can be no matter which device a user visits the site on, or which way around they're holding it. The design should contain breakpoints in the same way as adaptive does, but in between those breakpoints the site resizes itself fluidly in order to optimise for resolutions in between the breakpoints that weren't thought about or weren't even used when the site was designed or built.

From a technology perspective the developer gets to flex the very best of their html and css skills. There's no manipulation of the original document by either the removal or addition of elements using JavaScript. The core behaviour of the site remains the same, but can (and should) be styled to be more accessible for the user on any particular device.

Media (video, images, etc.) need to be flexible and scale based on the screen size. This and other scaling can be achieved easily. Support for this exists across all mobile browsers. At last, we don't need to worry if our code will be interpreted in the way we wanted it to be, and Old IE doesn't even get a look in...

There are polyfills to plug in all the gaps for older browsers, or you could have some default styling that you either build upon or inject a link to with JavaScript if the browser doesn't support media queries. Check out Can I Use for details.

No comments:

Post a Comment