LibrarySites.Banner

The Presentation Strategy of Launch Sitecore

In my role, I speak to customers every week.  One question that comes up often is "Can we use Responsive Web Design (RWD) with Sitecore?"  The answer is simply yes, but the next question I like to ask is "Why do you want to use it?"  This can create a lot of answers, but they come down to a few real reasons.

One of the main reasons is that they want a mobile site.  While RWD does help with varying screen sizes, there are a lot of ways to have a mobile site without it.  The problem is that too many CMS tools do not properly separate content from presentation so having a dedicated mobile site means double the maintenance.  With Sitecore you can have multiple presentation options with the same content by using multiple logical devices.  

The advantages of RWD are less code to manage and less content maintenance.  The disadvantages are slower page loads especially on mobile devices and an increase in development due to testing.  Taking this into account when developing Launch Sitecore, we decided to try to get all of the advantages of RWD and the advantages of separate code bases using Sitecore's multi-device support.  Now that the code is finished, we would like to share our strategy.

A Single Content Tree

We have a single content tree with no device specific nodes.  This allows each piece of content to be managed one time for all devices.  The presentation code will take of the presentation of the content, but an edit for the full site is automatically an edit for the mobile site because the content is shared.  This is the same benefit you have with RWD. 

Content Tree

Separate Layouts for Each Device

This is where we are not using RWD in order to decrease our testing time and in an effort to increase performance especially on the mobile site.

We have a separate layout for each device which allows us to have dedicated CSS for each device as well.  The layout doesn't show any content though.  It simply displays the shell of the page along with the navigation.

We also have separate presentation details for each device.  Since the mobile site obviously doesn’t show certain things that the full site would, we can simply not send them in the response.  In RWD, we would hide them.  Our strategy makes the page response smaller and faster.  This is especially important on mobile devices which have lower bandwidth and processing power than computers.

Presentation Details

All Content Rendering Controls are Shared

This is the part that many people miss.  They write two separate versions of every control.  We decided to reuse all of our controls and write CSS to make them render correctly in our mobile layout.  So a banner in the full site is still a banner in the mobile site.  There are a few controls that are only used on the full site, but there are no content rendering controls that were written specifically for the mobile site.

Presentation Details

Conclusion

The goal was to get some of the RWD benefits while avoiding some of the disadvantages.  In the end we are happy with the result and have full and mobile sites that are consistent and easy to maintain.  This brings us back to the initial question around RWD.  Of course you can use it and sometimes it is the best option, but it is good to know that you have other options as well.

  • Plus there's a aesthetic and practical concern...if you' use RWD and you're in Page Editor, you'll need to narrow your browser to get the other views...which can wreak havoc with the Page Editor's ribbon.