Making SDL Tridion World look better on mobile devices using responsive design

Responsive design is a technique to make your existing web site suitable for a broader range of devices by having it respond to the media it is displayed on. This article looks at how we made SDL Tridion World better looking on mobile devices by employing responsive design techniques.

Since you are reading this article on SDL Tridion World, you are clearly aware of this site and its purpose: making great content about Tridion available to everyone. The amount of content available has steadily grown since the site's creation in 2008. But you may have noticed that some other aspects of the site have not always kept pace with the times.

How does the home page look on an iPhone?

When I started this project, this is how the home page of this site looked when opened on an iPhone:

Responsive design 1 - original home page

For a site that was designed before browsing the web on mobile phones became as prevalent as it is today, the design held up quite well on such a small screen. Initially none of the content was readable, but the layout of the design was maintained. And by a simple double-tap on one of the sections of the page, the browser would zoom in and show the text in a more readable size.

Responsive design 2 - home page zoomed

That a site that was designed without mobile devices in mind retains its look and feel so well on such a small device is a testament to the versatility of HTML and the inventiveness of the makers of mobile browsers.

But if this is the way our web site looks and works on the average mobile device, we can't expect visitors to interact with them happily. Sure, they might use the site to find that one fragment they know they need right now. But they'll never even consider consuming full articles on their mobile device. The best we can hope for is that the visitors will find the article they need on their mobile and then simply email the link to themselves for reading it on their desktop.

Let's face it, this site was designed for desktop resolution. Making the same content consumable on mobile devices requires re-thinking and re-building: it requires treating the mobile phones as a new channel. Then we can create separate templates for mobile, ensuring that the design fits perfectly in the smaller screen. Right? Well...

Treating mobile as a new channel is certainly a valid approach and will probably result in a separate design that is very much tailored for mobile devices. But in many organizations it will take significate time to add a new channel to a site. And even in a company that creates the world's leading Web Content Management Solutions it isn't always easy to find people with the necessary skills and enough available time to add such a channel to the site.

So recently I was having a discussion with Ian Truscott about what we could do "cheaply" to improve the experience of visiting SDL Tridion World from a mobile phone. We gave ourselves just one day to improve the experience for mobile visitors. We knew that creating a perfect experience would be out of reach in such a time frame, but what could we do at least make things better?

How should it look on an iPhone?

If you look at the screenshot we started with:

Responsive design 1 - original home page

You can see that it has two main content columns and a sidebar taking up the horizontal space. If we would instead just show a single column we could increase the font size to be readable without the visitor first having to double-tap on that column. To accomplish this we can just put the two content columns under each other.

The sidebar we will put under the content. But since the sidebar was quite narrow, it looks a bit weird.

Responsive design 5 - sidebar stacked under content

So instead of showing the sidebar as a column of items, we switch it to a more fluid layout - fitting as many items per line as can fit and wrapping to a new line when needed. Browsers are very good at this type of layout, since it how they also treat the running text in paragraphs.

Responsive design 6 - sidebar fluid under content

Now this is starting to look more like it. We have all content and the sidebar in one long column. If we can lay out our site like this for visitors coming from a mobile device, the content will be readable without them having to double-tap a section to zoom in.

What is responsive design?

But how can we accomplish this new design? Doesn't this require a whole new set of templates? Or at the very least making the existing templates aware that the user is visiting from a mobile device?

As it turns out, the answer these last two questions is "no". Back in 2010 Ethan Marcotte posted an article on the respected A List Apart site where he described targetting portions of a CSS file at devices with specific characteristics, using a feature called "CSS3 media queries". The history of CSS3 media queries goes back all the way to early 2001, but somehow they didn't gain much traction until recently - probably in part due to improving support by modern (and especially mobile) browsers.

Marcotte calls this principle "responsive design" - you create a single design that automatically adapts to devices with various resolutions based on CSS3 media queries.

What does a media query look like?

You've probably used media-types to select specific CSS files for specific media types in your HTML:

    <link rel="stylesheet" type="text/css" href="core.css" media="screen" />
    <link rel="stylesheet" type="text/css" href="print.css" media="print" />

Or inside the CSS file with something like:

    @media print {
        /* style sheet for print goes here */
     }

Media-queries allow us to expand this selection mechanism with queries for specific device characteristics. This means that we can target devices with a specific maximum width:

    @media screen and (max-device-width: 320px) {
        /* this styling only applies to devices with a maximum width of 320px */
     }

Note that even though we're talking about targeting mobile devices here, you can also use media-queries to target regular browser sizes.

    @media screen and (max-width: 962px) {
        /* this styling only applies when the desktop browser is less than 960 pixels in width */
    }

The styling in this section will only be applied to browsers that have a width less than 962 pixels. Since the original SDL Tridion World site was designed for a fixed width of 962 pixels, the browser will start showing a horizontal scrollbar when the window width becomes less than that. So by using a media query to capture this condition, we can apply some additional styling to our design and make it response to the limited space it has available.

How can we use media queries to implement the design we want?

First off we need to move the sidebar down once it doesn't fit anymore. Since the site was designed for a 960px width, we will do this as soon as the width becomes less than 962 pixels.

    @media only screen and (max-width: 962px){ 
        /* Make the main wrapper just fit the available width */
        #wrapper {
            width: auto;
        } 
        /* Make the header and subheader make the available width */
        .headerBar {
            width: 100%;
        }
        #header, #mainNav, #innerMainNav, .innerHeaderBar {
            width: auto;
        } 
        /* Move the right sidebar down to the end of the main content */
        .banners {
            float:none; 
            width: auto;
        } 
        /* Make the footer fit the available space */
        div#footer {
            width: 100%;
        }
    }

As you see we also remove the 962 pixel contraints from the header, footer and the wrapper of the main content and tell all those elements to just fill whatever space is available.

With the banners moved to the bottom, we still have to make them use a horizontal/fluid layout instead of their usual vertical/stacked look. We do that with:

    .banners .boxContainer {
        float: left;
        width: auto;
    }

If you look closely at the original screenshot you will also see that there is a system menu to the right of the header. This too causes a fixed horizontal width, so we move the menu under the header image and switch it to a horizontal layout.

    /* Move the system nav menu into a line of its own and do a horizontal spread instead of a vertical one */
    #systemNav {
        clear: left;
        float: none;
        width: auto;
    }
    #systemNav li {
        display: inline-block;
        width: auto;
    }
    #systemNav li.login span {
        padding: 0px;
    }
    #systemNav li.login a, #systemNav li a {
        width: auto; /* there are 6 items in the system nav menu, let them figure out amongst themselves how wide to be */
    }

Although the menu is not as pretty as the original design made them, I'm not completely unhappy with this result. And if we now resize a browser window up and down you can see the rules being applied and the layout responding to the available space. Pretty neat!

Responsive design 6 - sidebar fluid under content

Now how do we get the two content columns stacked?

The design now looks good until we get down to about 760 pixels in width. At that time the two columns of article introductions don't fit anymore and it becomes time to implement part 2 of our design: make the content columns stacked.

    /* the default CSS is based on a fixed 963px width - these help it work from a width lower than 764px */
    @media only screen and (max-width: 764px){ 
        /* We no longer have space for a two-column layout, so switch to a single column */
        .content, .content_600, .content_300, .contentblock {
            width: auto;
        }
        .ColumnSeparator {
            display: none;
        } 
        .headerMovie img {
            width: 90%; // the header image is 675x145, so scale down
            display: none;
        } 
    }

As you see the original design had clear classes for the two columns (.content_300), their containers (.content and .content_600) and the separator between the columns (.ColumnSeparator). All we have to do is to remove the separator and tell the content columns to fall back to their natural behavior: fill the available space. The browser will do the rest for us.

Responsive design 7 - narrow browser shows single column and resized banner

As an extra step I resized the header image a bit here, since it started eating up more space than is available. In fact, if you check the CSS that we've put on the real web site, you'll see that we apply the same techniques at multiple stages as you're resizing the browser window: we resize certain elements, relayout others and hide some that either make no sense anymore or simply can't be made to fit.

What is the difference between max-width and max-device-width?

So if you were to reproduce the responsive design we have done so far and open the result on an iPhone you'll notice that... it doesn't work. Somehow the browser on the iPhone doesn't apply our carefully crafted styling, even though Safari on a desktop applies it perfectly. So was all our work for nothing then?

It turns out that mobile browsers have a nice little trick to ensure that most non-mobile-optimized web sites show up reasonable well: they lie about how many pixels they can display. In fact that is why in our initial screenshot the site showed up pretty much as it was originally designed (although unusably small): the mobile browser just pretends that it can fit 960 pixels onto its tiny screen and then crams them into the available space by zooming out far enough.

So our media query for max-width doesn't return us the value that we expect. It instead gives us the width of the so-called layout viewport, which on most devices seems to be somewhere between 850 and 980 pixels. Luckily there is also a property called max-device-width that tells us how many pixels will actually fit on the device. So if we add a filter for that property to our media-queries, we can make the CSS rules apply to both the smaller desktop browser and the mobile screen:

    @media only screen and (max-width: 962px), only screen and (max-device-width: 962px) {

Why is the text so small?

With all those rules in place the design on the iPhone looks quite similar to what we originally had in mind. The main remaining problem is that the text is so excruciatingly small that we still have to double-tap to be able to read it.

As it turns out this is caused by the same distinction between the layout-viewport and the visual device viewport that we just spoke off. Since the mobile browser still pretends that it is a 900 pixel device, the font sizes that were quite reasonable on desktop screens are being sized down to about a quarter of their size. No matter what your age and whether your screen is hi-dpi, you won't be able to read the majority of the text.

In our case I've solved this by simply inflating the fonts a bit and by applying some webkit font tricks in other places:

    @media only screen and (max-device-width: 360px) {
        .BreadCrumb, .BreadCrumb a {
            -webkit-text-size-adjust: 200%;
        } 
        * { font-size: 110%; }
        .content p { line-height: 100%; }
    }

I must admit that I am not too happy about this part of the solution. It feels more like a hack than I'd like it to.

One thing that is not a hack and in fact that might work pretty well on pretty much any website has to do with the code samples in some of the articles on SDL Tridion World. When you start making your browser window smaller (or watch them on a phone), the code does not wrap and thus is the thing that keeps your pages very wide.

Responsive design 3 - wide page due to <pre> block

There is a little known value for the white-space property that can keep the good stuff (a line break is shown whenever your text contains one), but also makes the lines wrap when it is needed.

    .contentblock pre {
        white-space: pre-wrap; /* To prevent code blocks from making the other text ridiculously small */
    }

Now if only the browser would show a little "continuation marker" at the end of every line that it wrapped, things would be peachy.

Responsive design 4 - <pre> block tamed with pre-wrap

Aren't introduction texts a bit long for a phone screen?

As you probably realized by now making your design responsive by using media-queries is a relatively easy way to get some extra mileage from your existing single design. It is however not a magic bullet that can replace everything else you have been doing.

no changes to the content

If you now visit the home page on your iPhone, you'll see the single colunm layout and the text will be quite readable. But this only makes it more obvious that the amount of text is quite large for such a small device. Where having a 100-150 word introduction is quite acceptable when you target a desktop, a 20-30 word introduction is better suited for mobile phones. You'll also notice that some of the titles don't fit on a single line.

Although neither these problems makes the site unusable, it is a well-published fact that you simply should be more selective in the amount of content you show to a mobile visitor. And that is something where responsive design can't help you. So if you get a chance: allow for multiple introductions for varying lengths in your content model. Then your responsive design (or simply your regular template) can select the content length that best fits the visitor.

one size doesn't fit all

A responsive design is (currently) always applied in the browser of the visitor. So it is that browser that decides to apply certain styling that will lay out certain sections differently or that will effectively hide complete sections from the screen to make things clearer. But since all content is served as a single HTML file, all those sections will still be downloaded to the browser only to be hidden there. Visually the result will be exactly as expected, but we end up wasting bandwidth sending content that is never displayed.

These things get even worse when you start considering large images. We may use CSS to resize those image to fit better in the layout we have in mind for the mobile screen. But that just means that we download a large image and display it at a lower resolution, wasting bandwidth. Given that mobile users are typically on lower bandwidths than are common on desktop environments, the overhead may be even more noticeable.

Still... there isn't a lot we can do about this using our responsive design techniques. And since we didn't make any changes to the HTML of the site, those additional sections were always being served to mobile visitors to this site.

Wrap-up

Using the steps described so far, we've improved the mobile usability of a site that was designed for pre-mobile consumers by employing responsive design techniques. The improvements were accomplished without changing the original HTML, so without a huge risk of breaking the site on existing devices. Although we identified certain shortcomings of these techniques, the fact that they can be applied to an existing site may make this approach relevant for your site too.

Responsive design 1 - original home page    Responsive design 8 - final home page
The home page before and after the changes we describe in this article

What more can we do?

In an ideal scenario you would combine server-centric solutions and client-side responsive design to get the best of both worlds. The server-side could be used to select the best matching HTML from the available categories. That way you could have one HTML with "desktop content", one with "phone content" and maybe even an intermediate for "tablet content". You could then use the responsive design techniques we demonstrated here to tweak each design to the specific device/browser size it is displayed on. And as a final step you could use a media transcoding server to ensure you always serve the media in a size that fits perfectly in the space available in your design on the specific device.

Where can I learn more?

There is so much to say about responsive design for mobile devices. We've really only scratched the surface in this article. If you want to learn more and get a deeper understanding of how this works, you really should read the following articles:

 

About the Author
Frank van Puffelen
Technical Director

Frank joined SDL in 2004 and as a principal developer worked on many of the company's releases until the end of 2012. He is now the technical director of ZyLAB USA.

ZyLAB