The Wild World of Responsive Media

The Wild World of Responsive Media
By Will Thomas

Content is the key to any website. Without meaningful, reliable and easy-to-access content, a website is just a collection of shapes and colors. Great for an art project – not so great as a resource. But content doesn’t just revolve around text. Font choice, size and color make a huge difference on a user’s experience with the written word; but a key to the overall takeaway value from a website comes from the right combination of text and media.

Users of the web aren’t what they were a decade ago, or even 5 years ago. The proliferation of fast, inexpensive wireless networks; mobile devices with immense computing power; and the overwhelming demand for tablets have forced the web to change venues. Or, at least, get a little bit more flexible with how it is formatted.

Gone are the days of the Yahoo Geocities-styled, flashing colors, morphing cursor, marching ants and terrible gradient background single page website. Today’s web is [predominantly] clean, clear and accessible on a variety of devices. This is where the term responsive comes in.

A responsive website, at its most basic, is a site in which the aspects of content, layout and navigation remain similar, yet vary depending on the viewing platform.

EXAMPLE w/ Screenshot: uses responsive techniques to tailor its content to display well on different devices.

More than just creative reordering of text boxes and font sizing go into a properly responsive site. Since the content is more than just textual, images, videos and even ads must be taken into account.

Dynamic Fonts

To begin understanding scalability of content, however, the most fundamental place to begin is with the text itself. For a news website, making sure that a user can read the written word the journalists have crafted is important, whether it is on a desktop computer at home, a laptop at work, or a mobile phone or tablet in between.

Font sizing on the web has two major groups: Static and “Dynamic”. Static sizing is exactly as it sounds; no matter what, a static unit remains the same regardless of the viewing platform. Some common examples of static font units are pixels (px) and points (pt). They both operate similarly and representation a fixed size. For instance, a font size of “12px” will display as twelve pixels on every screen. In a perfect world, where devices are standardized and twelve pixels display the same way on every screen this is not a problem. That perfect world doesn’t exist.

It comes down to the fact that different screens have different pixel densities, meaning one screen with given dimensions may have more pixels per inch than another screen with the same dimensions.

EXAMPLE w/ Graphic: Over time, Apple has similar screen dimensions on its iPad models, but with varied pixel densities. Early iPad models had a resolution of 1024×768 pixels @132 Pixels Per Inch (PPI). Later models with the same size screen have a resolution of 2048×1536 pixels @ 264 PPI. The new iPad Mini uses a screen of smaller dimension with the same resolution as the early larger models, but with an intermediate pixel density of 163 PPI.

It’s easy to see how a font displaying at twelve pixels (or similarly with points) would display differently depending on particular iPad model. Given this restriction, developing a website with static font units is a death knell. Thanks to the constant advancement of web technologies, there are solutions to this issue.

The easiest way to go about minimizing cross-platform/cross-device issues relating to font size is to use one of two units: Percent (%) or Ems (em).

These units rely on the relationship between at least one other fixed sizing somewhere else on the page. An initial font size (let’s say 12px) may be set for the large-format version of a page, perhaps in the body class of a CSS style sheet. By doing so, the base unit (em or percent) is set to twelve pixels. Larger text can then be coded as anything larger than 1em (using decimals) or 100% (using percentages). Smaller text can be coded similarly.

For example, the body text set at 12px could be coded as 1em or 100%. Headings could then be coded as 1.5em or 150%, depending on what works for the page.

EXAMPLE: body { font-size: 12px}…h1 {font-size: 1.5em}…OR…h1 { font-size: 150%}

The flexibility of this kind of coding allows for different style sheets or different media queries to simply change the initial font sizing for the page (ie. the body { font-size: __px } tag) and the relationship between the rest of the text on the page will remain the same. Headings will still be roughly the same size difference from body text, etc.

It must be noted, however, that pixels are not the only units that can be used in as the basis by which the other units are related. All the units have a rough equivalent, 1em = 12pt = 16px = 100%. Many designers will set the body font size as a percent and use ems to scale from there.

Other options exist, such a JavaScript libraries and other such plugins, but none are as simple as using dynamic units.

In addition to font sizing, it is important to consider the font face used to display the content. The use of various devices with different fonts installed adds to the difficultly of uniform display of text. One way around this issue is through the use of embedded fonts. Using the @font-face CSS code, or an online font library like Google Web Fonts adds a bit of load time to a page but reaps many benefits of cross-device display conformity.

Dynamic Images

In the world of the responsive web, images are one of the biggest pains when it comes to sizing. How does a designer maintain the use of a text-content-related image on a page that may be viewed on a hundred different devices with varying screen sizes and resolutions?

Well, the first and easiest test is to make sure that the image is important and adds meaning to the content no matter what device displays it. Once that first test is passed, it is important to make sure that that image is of a widely compatible format, such as JPEG or PNG. If the image is still deemed worthy of display, chances are it will find itself living in a DIV. An easy way to keep images behaving nicely with their parent DIVs is to utilize CSS’s “max-width” function. Using “max-width”, an image with a dimension of 800×600 pixels is only allowed to display at its full size if the DIV in which it is contained is large enough.

This method is especially handy when DIV dimensions are coded using percentages of a given screen. Simply put, if the desktop version of a site has a container DIV with a width of 960 pixels, the 800×600 pixel image will display at its full size. If that page is designed to scale when the window is smaller, lets say 500 pixels in width, the entire image will still load inside the DIV instead of getting cropped; it will simply display at a smaller dimension.

This is the simplest way to make sure images remain responsive, but it does not account of every issue. For instance, a mobile device using a 3G connection does not load image-intensive pages as quickly as most wired or WiFi connected desktops. It may be important to consider loading a smaller resolution (and therefore smaller file size) image when a page is viewed on a mobile device.

A good way to get around this problem is through the use of the “adaptive-images.php” script. It uses a modified .htaccess file to force web browsers looking for images to load to use the supplied .php function instead. It finds the appropriately sized image from the server and displays it. The best part is it doesn’t require you to re-code any of your existing HTML/CSS. Using PHP and a bit of JavaScript, Adaptive Images uses the original high-resolution image and creates/links to smaller versions by itself. This is a modification of Filament Group’s content-aware image function, but is a bit more straightforward and simpler to implement. The major drawback is that you need PHP running on your server. It also won’t work with content delivery networks. A ColdFusion version of Adaptive Images is also existence, but if you’re still using CF you’ve found your first problem.

Dynamic Video

In many ways, it makes sense to think that scaling a video player in a responsive website would work in much the same manner as an image. This is both true and false. True HTML5 video will indeed scale like an image, using the appropriate HTML or CSS code.

EXAMPLE: HTML – OR CSS – video { width: 100% !important; height: auto !important;}

That is great if you are using HTML5 video. Not only will it display in most modern browsers and on most computing platforms and mobile devices, but it will also scale like an image. The issue rears its ugly head when you start dealing with video hosted by YouTube or Vimeo using an iframe.

That’s where jQuery comes in. It allows you to remember the aspect ratios of the videos that are loaded on a page and when it is rescaled, the videos are scaled accordingly to fit the given width of the parent element.

If you have the ability and bandwidth to host HTML5 compliant video on your server, do it. If not, the JavaScript solution will work, even if it is a little clunky.

All in all, responsiveness is crucial in any site that is intended for widespread use. Any site that is worth using is going to have some kind of multimedia as part of its content. Such content isn’t outrageously difficult to set up correctly and will provide a much more rewarding user experience.