The mobile web: Not that scary

Recently we were tasked with taking on the Thomson Reuters Olympics website which involved many intricate components including the task of developing a mobile specific theme for their android users and other non-iOS devices (iOS got a separate app). I was quite excited for this task, as it stepped away from the idea of responsive design and instead focused on a lightweight mobile specific theme and content. There is still plenty of debate whether a website should be responsive for all the devices it’s viewed on, or if a theme specified for a medium is appropriate.

Mobile vs. Responsive

In the case of Thompson Reuters Olympic website, it was determined that a mobile specific theme was a better solution than creating a responsive website. The desktop theme has a plethora of widgets in the right rail which wouldn’t translate well to the mobile theme, so the plan of action was to create a single content region with a listing style layout. Although the website is built on the Omega theme at its core, (which is mobile first/responsive), it was primarily used for its HTML5 abilities, built-in grid system, and region configuration. This proved to be a great time saver for the mobile theme with most of the legwork already completed with Omega’s default settings.


Although the ultimate goal of this theme was to address users on a mobile platform, responsive design was found not to be the correct solution. The amount of content displayed would have hindered a responsive layout and experience, so it was better to have a streamlined solution and go with a mobile theme.

The mobile theme came together quite nicely with content being placed inside of the main content region and stacked vertically. Custom mobile tagged contexts were used to place the blocks in the appropriate order in accordance to the comp, (more on this later). The custom contexts allowed us to place only the content that was useful rather than serving the user all the content and hiding it via CSS, thus avoiding increased http requests and overall load time.


Using Custom Tagged Mobile Contexts

Going back to the custom tagged mobile contexts, there were a few technical challenges which lead us to that solution. The first challenge was the obvious problem of having completely different layouts for the desktop and mobile versions of the site. Creating a separate set of contexts tagged with ‘mobile’ enabled us to place content blocks in the regions that we needed them to be in. The second and more difficult challenge was the complex and multiple layers of caching in place at various levels of the project; Acquia, Akamai and Varnish. Even with the ability of creating a different set of contexts for mobile, there was still a high chance that mobile users would be served the desktop context sets just because of the caching. Switching contexts at the drupal level was not an option because of this factor.

The final solution, by Team Architect: Tobby Hagler, was brilliant and simply elegant: Akamai was already setup to do redirects to ‘m.’ urls for mobile devices. In knowing that fact, Tobby created a patch for context that would detect the domain (in this case ‘m.’) and call the mobile tagged contexts in the DB and turn those on rather than the desktop context set. Et Voila: a mobile site with the exact content that you want. So rather than device detection, this is a domain detection scheme where we already know the domain will be device specific with ‘m.’.

Mobile web doesn’t have to be a daunting task by any means. With the proper game plan, it can actually flow together quite nicely. Unfortunately there can always be the curve balls that come into play. Even with reading countless articles on creating mobile specific and responsive websites, sometimes it comes down to the core pieces of the web that give us the biggest headaches. In this case, cache didn’t make the world go round, but proved to be a fun challenge to overcome.