Opportunity Costs of Responsive Design with Sitecore

Unleash the Potential of Power Platform With a Center of Excellence

Business innovation often comes from within. Discover how to empower innovation from non-traditional developers with the Microsoft Power Platform.

Learn More

I recently got to see the first Responsive Designed-Sitecore powered site I have ever worked on go live.  If you’re not familiar with Responsive Design…well, where have you been?  Seriously though, Responsive Design is a pretty big buzzword in not just the tech industry but in any business that wants to be relevant in today’s ever changing world.  I’m certainly no designer, but I think I can boil the concept down to its basic pretty well if you’re still not sure what I’m talking about.  Responsive Design is the concept of using one set of HTML / CSS markup that looks optimal for any screen size.  It’s a big deal because the mobile and tablet computing markets are exploding and surpassing traditional PC’s and laptops for usage right now.  If your website is not utilizing Responsive Design, it probably means you need completely separate sets of code to ensure your visitors are seeing optimal content regardless of their device.
At this point, you may be asking “Jamie, if this is such a hot topic, how come you’re first site using it just launched now?”  That’s certainly a fair question, and I hope I have a fair answer.  The first and foremost answer is that Sitecore comes with a concept of devices out of the box.  These devices make developing your presentation on different devices really easy, which means that it’s completely possible to have optimal experiences on all devices without a lot of hassle when a site is built on Sitecore.  The second reason is that like most things in life, Responsive Design is a choice, and with that choice is an opportunity cost.  I’ll spend the rest of this post covering what I see as the pros of choosing to use Responsive Design as well as the opportunity costs of choosing to implement a Sitecore powered site using Responsive Design.
Let’s start with the pros as I see them.  First, Responsive Design is a current buzzword, and implementing a site on top of it can give you some bragging rights.  We all know bragging rights don’t equate to dollars in business, however bragging rights communicated properly can equate to increased web traffic – which can in turn equate to dollars.  Responsive Design can be pretty cool looking too – if you’re on a full-size browser, navigate to a Responsive Design site and start playing with the width of your browser screen.  It’s certainly cool to watch the screen rearrange itself to remain optimized.  As fun as that is initially though, I don’t know of any real life visitors who go through the web constantly changing their browser size, so there’s really no benefit to the “coolness” factor of Responsive.
When talking about Sitecore implementations, another pro regarding Responsive Design is that the back end code can arguably be made with less effort.  The reason is that with Responsive Design, I’ll only have one set of markup, and I can code my back end functionality directly into the code behind of that markup.  If I’m going to use the Sitecore device concept, then I’m better suited taking that back end code and putting it in common classes that are called from the code behinds of my full size markup and my tablet markup and my mobile markup, etc.  The amount of code varies little, but the complexity may be increased using the device concept.  The fact that responsive only requires 1 set of markup reduces the amount of sublayouts I need to create in Sitecore, which can reduce development time and maintenance.  It can also help with technical understandability and the ability to transfer site ownership to new developers.
Another thing about Responsive Design is that it takes a pretty experienced designer to do it well.  That means that you’re probably going to completely separate the responsibilities of design from your back end developers.  Depending on the environment, this may be a pro, or it may be a negative.   If you already have a solid design team and a solid development team who work great together, separating their responsibilities can mean better throughput for both.
Now that we’ve covered the benefits of developing your Sitecore site with Responsive Design, what are those opportunity costs?  The first is that typically, designing the site using Responsive is going to elongate the design period.  This elongated design period can put the rest of your projects timeline in jeopardy, and maybe even cause you to try to do some tasks, like Information Architecture in parallel to design.  Parallel IA can be done with design, though it certainly poses a risk that the outcomes of each activity don’t match each other and you’ll need a period to revise one or the other (or both) so that they can match.  Speaking of elongated times, in my experience, you should expect to see a lengthened period of time for your sites QA stage.  This is because a change to one device’s markup is tied to all the other devices.  For example, if you want to adjust something on your desktop view to be centered, that change could inadvertently break your table and / or mobile device views.  To combat this, any change made automatically has to be tested on every device size – and if a problem was introduced in the fix for your desktop, then you need an alternative fix that will not present as an issue on other devices.  (Trust me, there’s nothing worse than introducing a fix for one view only to find out you forgot to test another view and then being told that view is broken!)  In contrast, when developing using Sitecore devices, a change to the presentation of the desktop layout is completely insulated from the mobile view, so you don’t have to worry about inadvertently affecting a separate device.
Going back to the last pro of Responsive – if you don’t already have that solid design team and development team, now you’re looking for one or both – which means higher cost up front.  Even if you have both already, if they don’t play well together, that can lead to issues.  Luckily on my implementation, we worked very well with the design team, and had a very competent design team to work with, so we didn’t encounter this issue.  I could easily see a lot of issues arising if there’s not a very high level of communication and trust established from day one between these teams though.  If the developers have enough HTML / CSS knowledge to be dangerous, they can start changing presentation on their own – and not even maliciously.  We’ve all heard the “if you want something done right…” saying before, but as a developer it’s easy to not only think that way but to also think “if I make this change myself, I can do it in 5 minutes and not have to involve anyone else – yay for higher production!”.  If you’re using Responsive, that’s a very dangerous thought – you’re running the risk of breaking something you don’t even know you’re breaking.  This type of thing can set the project schedule back very quickly and easily.  Because of this, I think it’s safe to say that a negative of implementing Responsive Design is that all changes need to be exposed through your design team to confirm that they won’t break anything in the Responsive set.
Another cost of Responsive Design is the amount of client side code that is required to make it work.  That means you’re throwing a lot over the bandwidth of the network in order to make sure that the site renders on all sized devices.  As I’ve already mentioned though, outside of the fringe case of the person who just thinks it’s cool that your site changes when they resize their browser, why would you need the site to work for all browsers at once?  It’s much more efficient, thus faster to only send the design that is necessary for the particular device that is currently being used rather than to have to account for all them.  After all, a mobile device user can never change their browser to be larger than the size of their phone screen, so why send the user data that handles that case?  Conversely, with the Sitecore Device separation of presentation, you are only sending them what they need to see your site optimized on their device.  That will result in better performance for the visitor.  Personally, I think this outweighs the “coolness” factor of Responsive.
A final cost is the considerations of any non-Sitecore technologies you’re integrating with.  Sitecore has plenty of technology partners, and a lot of Sitecore sites integrate into custom-built Services and sites as well.  If those technologies aren’t ready or built for Responsive Design themselves, you may find that you’re now implementing a hybrid “some Responsive / some not” site.  This adds to the complexity of developing, maintaining and training on your site because now there’s some code that’s Responsive and some not and your technical team has to keep track of what is what.
From the list above, I hope it’s clear that there are certainly both strengths and weaknesses to utilizing Responsive Design for a Sitecore powered site.  Because of this, I don’t think there’s a clear cut recommendation of “Always use Responsive with Sitecore” or “Never use Responsive with Sitecore”.  Instead, clients must weigh the above pros and cons and decide the proper path for their website(s).  Shameless plug time – Perficient’s Sitecore Practice and XD teams would love to help anyone out with that decision so that the best outcome is achieved.  Finally, I would love to hear from any implementers or clients who’ve used Responsive Design for a Sitecore site.  What were your thoughts on it, and would you recommend it or against it?