Part IV – Bringing the Content to Design

Before bringing the content to design, we need to think on two separate issues, which are shared between the technical aspects of the Responsive Web Design and the design being oriented and guided by the previously defined Content Strategy.

We must decide: « What do we display? » and « How do we display it?»

Depending on the context, here are some of the key behaviors which interact between RWD and content strategy. These must occur, depending on the device and the context, without affecting the completeness of the content:

• The font size should be adapted depending on the screen size, large type for big screens and smaller type on small screens, to give more visibility,
• Depending on the device type, the font family must respond to a better readability, usually serif for printing destination, and non-serif for screen,
• The menu bar and the navigation tools must be reduce to an icon on a small device, and completely removed when printing,
• In a more general way, when printing the content, we need to remove all unnecessary parts of the page, like the footer, the navigation tools, the animations, and we need to be sure to not over-use colors that will consume too much ink, and think that most users can print in black and white,
• When displaying images, their size have to be adapted to the screen’s resolution depending on the displaying screen: is it a Retina screen or high definition or a traditional 72 ppi screen,
• Whenever data sheets and large tables have to be displayed on small screens, we definitely need to rethink their display,
• Web, mouse, and multimedia teach us the hovering state. Sometimes that display has crucial information and a mechanism to redistribute it, depending on the device, which must be applicate,
• We need to remove the large galleries of images that are bandwidth greedy when viewed from low connection networks, or displayed on devices which are low battery power, or beeing a screen reader,
• Think in terms accessing the necessary information and navigation tools when content is viewed from a screen reader,
• Set an editorial direction which provides your content in a genre: masculine, feminine, both? Do we use acronyms? Rely heavily on schema? All this, of course, in a concern of accessibility and presentation,
• Always provide not only subtitles but also a transcription when using video. Think also of the establishment of cue-points,
• Provide multiple pages, and interactive forms, which can be adapted to the platform of distribution between screen and mouse, touch and smartphone, and braille, voice, or printed documents
• Build the text breakpoints. They, they are dependent on number of characters per line, device orientation, user experiences and preferences, not on pure technical landmarks,
• Regarding technical breakpoints, we must include the technical aspects of the linked contextual use, like low battery level, low bandwidth connections, the sun or strong light, reflections on the screen, the geolocation of the user, and the relay obtained by a third party operator. In short all these technical aspects are not directly linked to the device itself,
• The major point with a large amount of content is to avoid anything being downloaded without being absolutely necessary to the use. We need to think how to replace each element that is not necessary for the specific use, or be displayed by the device, as an alternative solution,
• The final aim is that action, interaction, and information shouldn’t be blocked, or driven by a different use-case. just because the user visits the page, or uses the content, from a different device.

The list does not stop here, but it allows us to consider and better understand the necessity of this previously discussed content strategy whenever we consider a web design’s responsive appearance.

How to Programmatically Port and Handle Content?

A pure code-approach is not the goal of this series. I invite you to join us in another place, where we can study each technique vertically through dedicated training to better explore what these tools are and how to use them.

The point here is to focus on each tool’s families that can help us to better handle the RWD techniques:

• The Media Queries themselves link different CSS files depending on the context, and the type of device and its capabilities,
• Combine the page’s Media queries. Use strategies for major content breakpoints and sub breakpoints to split between layout displays, and eventually load new complementary content,
• Multiple source assets correspond to various image qualities and sizes, using the srcset=”” attribute,
• The new tag <picture> can also help us, as the previous item, on presentation strategies,
• The native support for JavaScript statement, matchMedia() can interact with the data, depending on the device, and that allows us to load only usable datas using AJAX’s techniques,
• The use of many Shim and Polyfills to replace the shortcomings of some old browsers,
• Use a JavaScript mechanism to serve infinite scrolling. That way, when on low bandwidth, we can load the bare displayable necessities, thus avoiding loading what will not be seen,
• Revisiting the accordion mechanism that could load data on-demand without changing the page, depending on the bandwidth,
• Optimize the website in: subsetting fonts when possible, compressing data on the server side, concatenate and minimize scripts, and CSS, removing all unused line of code and comments, using CDN when needed, batching all the image file in the reduced-size process,
• Optimize the management of cache. This often refers to the Service Worker API that will help us to minimize the use of bandwidth and data transfer when using the same device and resizing windows,
• If possible, get analytics for your target audience to help in prioritizing approaches,
• And as many of the above points refers to the use of Javascript, we definitely need to provide an alternative use based on the <noscript> tag.

And now?

This final installment of the four part series, concerning the implementation of a responsive approach is now complete. Remember that the use of the RWD must go through a content strategy, with a strong consideration for the context of the use, and not rely on a pure technical approach.

The main objective of this series was to lead us to think and ask ourselves the right questions on how to succeed more easily in this type of implementation for all our projects.

I hope that this will provide you with tools you need to be for or against this exploration of RWD and I invite you to continue this thread on a forum, providing comments of any other project you have.