Responsive web design

Responsive web design (RWD) is a website design approach that recommends building a single website that adapts to all devices and platforms. This avoids the duplication of effort involved in building separate desktop and mobile websites. A website built to RWD principles uses floating content elements, an adjustable page layout, and dynamically resized images to accommodate various viewport sizes and device capabilities. In other words, the site responds to the user's requirements.

The Magnolia Standard Templating Kit (STK) implements the RWD principles. A website built with the STK can deliver a browsing experience that works well on desktop browsers, smartphones, tablets and other types of clients. In this article we look at how the RWD technology is built into the system.

Designing for many devices

Research into mobile device use on the Web shows a large gap between supply and demand. More consumers use a mobile phone than a computer to access the Web. At the same time, few websites are actually completely mobile compatible.

Largely this is due to complexity. Designing for desktop alone is complex. When you include mobile it becomes exceedingly complex. There are many factors to take into account:

• The number of Web enabled devices on the market increases.
• Different devices have different capabilities.
• Smartphone models are upgraded rapidly but older phones still need support.
• Old browsers in corporate environments don't support recent functionality.
• Compared to fixed data connections, mobile networks tend to be slower and often have a measurably higher latency. This can lead to long retrieval times, especially for lengthy content and navigation between pages.
• Mobile users have different interests to users on fixed or desktop devices.
• Mobile users have to pay for bandwidth.

Year 2011 was commonly recognized as the year of mobile commerce in Web design circles. The rapid and extensive adoption of mobile devices to access the Web really hit the mainstream. This forced the design community to come up with better ways to build websites.

Origins of responsive web design

Much debate followed about best practices for designing mobile websites. Ethan Marcotte proposed that addressing browser capability, screen sizes and orientations by creating flexible, fluid and adaptive websites was the answer. This approach, known as responsive web design, seemed to overcome most challenges in most circumstances.

Today, RWD is considered a best practice. Google and Bing endorse it and Google uses it on their own pages. W3C opposes the idea of creating separate mobile and desktop versions and advocates that any web page should have one set of HTML available at one URL, implicitly endorsing RWD. New articles in support of responsive web design appear on the Web daily. One commentator describes it as the "new black".

Benefits

Responsive web design offers the following benefits:

• You can start from an existing desktop website and adapt what already works rather than start from scratch.
• The need to maintain multiple sites is eliminated. This can be a dramatic cost-saver.
• All renditions of the site are available at the same URL. This is good for search engine optimization.

How Magnolia uses responsive web design

Magnolia implements the principles of RWD in the Standard Templating Kit. Web pages rendered with the system are compliant with HTML5 and CSS3. Content is abstracted from presentation and fed from a single back-end. You can serve multiple devices without unnecessary replication.

A website built with the STK uses a flexible grid. For desktops browsers, the design adapts dynamically to the viewport. Below is the Standard Article page from the demo-project sample website at screen widths of 1200, 1024 and 768 pixels. Note how the extras and promos areas float from the top right to the bottom. This is an example of reorganizing page elements to fit the viewport.

The same reorganization takes place when the site is viewed on a smartphone. Content that does not work well on the small screen or is not of interest to smartphone users is either left out or reformatted. An iPhone user sees a minimized, modified version of the site.

Here are the two layouts side by side. Note how the navigation is pushed down in the smartphone layout, giving preference to the main area which typically has the most important content such as the story of a news item. This has the benefit that the important content is displayed "above the fold". The phone user can see it in the first screenful without having to scroll. The promos area is left out altogether in the smartphone variation. The red line is an approximate viewport size.

Technology

Responsive web design relies on three technical ingredients to detect the requesting device's capabilities and adapt the design accordingly:

• CSS media queries detect the type of device and the viewport size.
• Flexible grids allow page elements to float, reformat and reorganize depending on the viewport size.
• New variations of images are generated on-demand to fit in the available space.

These mechanisms implement the basic tenet behind responsive web design: that it is better to design one website that adapts to the ever-increasing number of devices than to create many disconnected designs. Each device is treated as a facet of the same experience.

CSS media queries

CSS media queries is an extension to CSS3 that allows you to control how page elements are rendered on different devices. Media queries are always used in conjunction with media types. The media type identifies the device. The media query is a logical expression that evaluates to either true or false.

Here is an example of a media query:

only screen and (min-width: 1200px)

The query targets the media type screen which is intended for desktop browsers. The expression evaluates to true if the website is viewed with a browser where the viewport size is very large, 1200px wide or more. When true, a style sheet that optimizes the experience for a wide, cinematic screen is applied.

In Magnolia, media queries are configured in a theme. The media attribute contains the media query and the link attribute the style sheet that is applied when the expression evaluates to true. Here is an example from the pop theme. Pop includes several style sheets. The wide sheet that is expanded in the screenshot show the media query and a link to the associated style sheet wide.css. Note how the link property contains just a reference to the style sheet. The actual sheet is stored in the resources workspace. You can edit it in Templating Kit > Resources.

Magnolia ships with a basic collection of style sheets targeted at different media types:

• styles is the basic style sheet that optimizes the experience for desktop browsers
• print is intended for printed documents and the print preview mode.
• wide is for wide screens. It displays the promos area since there is more screen real estate.
• small is for narrow screens. The main area displays two columns of teasers instead of three.
• ie6 is a specialized CSS only used for Internet Explorer 6.
• ieStyles includes styles for IE7 and IE8, applied with a conditional comment.
• mobile is for smartphones and other handheld devices, see also Device Detection

In addition to the basic set, you can create your own stylesheets. Define matching media queries if you need to render content for other types of devices such as Web-enabled TVs.

Magnolia uses conditional comments to overcome the limitations of legacy browsers. The ie6 and iestyles configuration nodes have an additional attribute conditionalComment that contains a statement that is interpreted by Microsoft Internet Explorer. Magnolia uses them to provide and hide code to and from Internet Explorer.

In the page HTML, the media query and the style sheet link are rendered as a link element inside the head.

<head>
   <link rel="stylesheet" type="text/css" 
      href="/demo-project/resources/templating-kit/themes/pop/css/wide.css" 
      media="only screen and (min-width: 1200px)">
</head>

Typically you will find several link elements like this on the page. The style sheets are loaded incrementally. The basic styles sheet contains a lot of style information that is used on all devices and viewports. The more specific sheets loaded later such as wide define only additions and exceptions.

Here is the viewport comparison again, this time with the style sheet name included.

Here is an example of what happens in the style sheet. The stage area is a large box on the home page that displays teaser images in a paging carousel. The style sheets resize the containing div element to accommodate different viewports. On the smartphone channel the stage area is disabled, meaning it is not rendered at all. Consequently, no stage styles are needed in mobile.css.

styles.css

#stage {
  position: relative;
  overflow: hidden;
  margin: 0 auto 20px auto;
  width: 940px;
}

small.css

#stage {
  width: 700px;
  overflow: hidden;
}

wide.css

#stage {
  width: 1180px;
}

JavaScript

JavaScript is responsible for client-side functionality such as teaser paging, menu animations, mouse gesture support and Google Analytics. JavaScripts are referenced in the same way as style sheets: a link to the script is in the theme configuration while the actual script is stored in the resources workspace.

The difference between CSS and JavaScript is in the loading mechanism. Scripts are aggregated. This means that an aggregator script loads multiple device specific scripts. From responsive web design viewpoint this has the benefit that only relevant scripts are loaded. For example, when the site is requested with a mobile device, only scripts that make sense on mobile are loaded. A phone user is not burdened with unnecessary code. The aggregator scripts themselves are minimal, they do not lengthen page load times.

JavaScript for desktop browsers and mobile devices is loaded using three main aggregator scripts:

• (mobile-)scriptloader-libraries.js loads the jQuery core library and jQuery UI libraries. The libraries provide a skeleton for JavaScript functionality.
• (mobile-)scriploader-plugin.js loads jQuery plugins such as social and Google Analytics. Plugins take advantage of the base functionality provided by the libraries.
• init-(mobile-)behaviour.js initializes the scripts in the right order so they don't conflict. The init script is the place where you should customize behavior such as teaser paging.

The aggregators load many of the same basic scripts for all devices, such as the JQuery core library, which is needed everywhere. But there are differences too. Compare the mobile and non-mobile script loaders below. Mouse, slider and date picker scripts are not loaded for mobile devices. They would be extra weight. Mobile phones provide proprietary touch controls for such actions.

The htmlHeader.ftl script includes the viewport meta tag to help mobile devices render the page at a more readable scale.

<!--[if IE]>
<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=IE7" />
<![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0" />

We update our JavaScript library constantly as new obstacles and solutions emerge. the modernizer.js script is an example of a recent addition. It takes advantage of the new capabilities of HTML5 and CSS3 where it is not supported by older browsers. This script in included in both the mobile and desktop scriptloader libraries.

Template scripts

The responsive web design approach advocates the use of a single script for all sites, enhanced by the use of CSS media queries. STK sites are based on a single template script main.ftl. This is an inclusive script that:

• Includes individual area scripts which allows:
  • Substitution of area scripts for different renditions. This option was not necessary for the example mobile channel but it could be used effectively for Web-enabled TVs for example.
  • Substitution by configuration of device and browser-specific CSS and JavaScript in the head element of the rendered page. head elements are rendered by the htmlHeader script.
• Repositioning of navigation through configuration.
• Reflowing of content through the use of div elements as wrappers. Divs are generic block-level containers that allow the content to flow depending on the screen size and ensure that the content is rendered in order of importance. Divs are also easy to style with CSS.
• Delivering content to a single URL but this is configurable.

Template configuration

The template mechanism in Magnolia goes beyond the principles of RWD. Almost everything is configurable. Here is an overview of how template configuration works:

• Template prototypecontains configuration that applies globally to all sites. The prototype configures:
  • navigation defines the behavior and depth of the default horizontal and vertical navigation menus.
  • areas contain sub nodes for each page area. The area sub nodes each link to the area templateScript and define the area behavior in the type property. There are three options: single, list and noComponent, allowing an area to contain one, a map of many, or no components.
    
• Site definitions configure variations such as the smartphonespecific site. Nodes matching those in the template prototype define exceptions at the site level.
  • navigation reverses the default navigation for smartphone. The main.ftl script reads the bottom and top properties and renders the navigation/s above the footer as opposed to after the header.
  • areas disables the promos area for smartphones.
    
• Template definitions can also define variations at an individual page template level. The stage area is enabled globally for all templates in the prototype, so we disable it here in the stkHome template for the smartphone variation.
  

Code overhead and load order

The responsive web design approach relies on a single code base to serve multiple devices. Opponents of the approach say this has two negative effects for mobile sites:

• Load order. Page elements may not be loaded in the right order of importance for the device. Mobile data and processor speeds vary by device, network, location and other factors. The source code should be ordered to generate the most important items first.
• Code overhead: Because the code takes account of all devices, mobile users are burdened with unnecessary HTML.

These criticisms may be valid in less sophisticated environments but the STK templating system loads only what is necessary for each device. The htmlHeader script renders content elements in the correct order and takes care of substituting CSS and JavaScripts before generating the HTML.

In the example below, the site is requested with the Firefox browser on the desktop. The branding area is followed by horizontal navigation because there is ample screen real estate to still show the most important content, the main area, in the same screenful.

Here the site is requested with iPhone 3.1, a smartphone. The branding area is now followed by the main content to make sure that the user can see the most important content quickly.

Channels

Channels are a core Magnolia feature that facilitate reformatting of content. In the mobile context, the device channel, configured in Channels, is used to detect page requests from smartphones through the User-Agent header.

Optimized images

Bloated image files are a drawback of the responsive web design approach. Large images are required for the desktop site to make sure they look good. On the mobile site, the large images are loaded and then reduced in the client to fit the container. This burdens the smartphone user with excessive bandwidth consumption with a corresponding loss of performance. Conversely, if you use smaller original images the desktop experience suffers as enlarged images look soft and pixelated.

Image quality and image SEO is becoming increasingly important. Google now includes images in the general search and their recent search quality updates place more emphasis on image quality. Your images can get you onto page 1 even if your text content doesn't.

Magnolia's  Imaging module simplifies working with images. You don't need to resize and crop each image for teasers and openers by hand. A single source image suffices. In very basic terms, this is what the engine does on the server side:

• Creates lower resolution proxy copies on-the-fly for each rendition of the image.
• Automatically resizes and, if instructed, crops images to fit where they are used on a page.

The result is that resized, lower-resolution proxy copies are loaded when such an image is requested. The large original images are not served to a client that cannot display them. Once created, the proxy copies are retained and cached for subsequent use. Magnolia caches image resources to improve performance. Additionally, the built-in DMS module can store the large-resolution source images as a reusable library that editors can select images from. Besides the image file, the DMS stores image meta data that the STK uses to render alt text and captions.

Image variations are configured in Themes. Here we define the target size and rules for each rendition of the image. The rules allow defining a specific width and height and cropping. Each image variation includes a CSS selector that identifies the target image or its containing element on the page. The smartphone site uses its own theme pop-mobile. It that theme we define smaller target sizes to negate bandwidth and performance issues.

Other mobile enhancements

Magnolia has a number of additional features that assist in mobile web design and development.

Mobile preview is built into the editing interface. The Preview dropdown in the top bar offers the option to preview on Desktop, Smartphone or Tablet. A simulated smartphone or tablet shows the page as rendered on these devices.

Specific pages and components can be excluded from a channel. This allows you to include different pages and components on the desktop and smartphone sites, opening up a host of possibilities. The option is available by default at the page level in all STK templates.

STK components are constantly upgraded to ensure cross-browser compatibility (including mobile), taking device capabilities into account and complying with HTML5 and CSS3 standards. For example, the  Video component primarily delivers MP4 since it is supported by most browsers but to ensure compatibility across the range the components allows you to upload additional formats.

Alternative web design approaches

Ethan Marcotte's original article Responsive web design in May 2010 led to much debate on the best way to accommodate the mobile explosion and be ready for whatever the future may bring. RWD does not fit every use case. In Web design there simply isn't a one-size-fits-all approach. Watch an interview where Ethan discusses RWD and alternatives.

There are two alternative approaches with merit:

• Mobile First proposes stripping a design to its most basic form for the small screen first and then building it up for the desktop experience. This concept is also referred to as progressive enhancement.
• Mobile First Responsive Web Design, as the name suggests, is a hybrid of RWD and Mobile First.

Many commentators refer to RWD as "graceful degradation" but the word degradation doesn't do the concept justice. Essentially, progressive enhancement and graceful degradation are two sides of the same coin; both use media queries to differentiate site elements. The real distinction is the starting point. Whether it is best to scale up from the mobile context or scale down from desktop context depends largely on what you have and what you hope to achieve.

Practicality and efficiency matter more than the approach. The different approaches are not mutually exclusive and there are use cases where one is more appropriate than the other. There seems to be is no valid reason why an optimum experience on all devices cannot be achieved. Magnolia advocates RWD because it makes more sense in more situations, but there are no limitations to using any approach within the system.

If your mobile site is more important than your desktop site and offers very different functionality and serves different user needs, it may makes sense to maintain completely different desktop and mobile sites. There are possible scenarios where this is the case, for example an ecommerce retailer may maintain a corporate information on a desktop site while offering customers buying functionality on a location-aware mobile site.

You can configure and maintain multiple sites in Magnolia. Each site can:

• Have on its own main template.
• Be served on a different URL or redirect to another URL.
• Contain different pages.
• Reuse pages from another site.
• Redirect using the Virtual URI mapping mechanism.

While the prevalent SEO view is that it is better to serve both mobile and desktop content from the same URL, the issue is debatable. Google does not penalize separate URLs. The introduction of Googlebot Mobile and Google Search for Mobile present new, different SEO opportunities. Read Mobile URL vs Single URL for a good summary of the pros and cons from SEO, user, developer and marketing perspectives.

Magnolia can even be used to feed content to a mobile app. Read how Texas State University achieved this.

Learn more

This article covers a broad range of Magnolia functionality. To learn more about these concepts see:

• Mobile
• Channels
• Device Detection module
• Stardard Templating Kit
• Extended Templating Kit
• Components
• Areas
• Dialogs
• URI mapping
• Content reuse