There are many established systems for these approaches but they often lead to more code, not less. A common case would be creating multiple sets of HTML markup but dictating which shows by CSS rules. This means many users are being served code that they never plan to use, which is wasteful. Many content management systems and platforms (at least the good ones) of mechanisms by which server-side code can be component responsible for producing optimized code for a specific situation. Ideally, any robust application would use a combination of server and client approaches to provide the best experience for the user while minimizing the total development effort.
Sitecore offers a great set of tools as part of it’s stock platform to facilitate the server-side part of the equation. The heart of those tools is the designation of a set of customizable “devices”. The default device is considered a standard browser and anything else is dictated by your own specifications. Most people use the 51 Degrees Mobile Device Detector module which creates SItecore rules that can be leveraged to define separates one device from another. I won’t go into detail about how all that works as MDD’s documentation and various other blog posts do a pretty good job of describing how to use the rules in a conventional manner.
What I wanted to get into was perhaps an alternative approach to implementing responsive behavior by using one of Sitecore’s other flexible features: personalization. Let’s take a look at an example page I configured using the standard approach with devices.
Are you picking up on the issue? Out of 15 renderings, only 3 are different between devices which makes that more of an exception than a rule. Moving forward, to implement changes to this page everything has to be done in triplicate. Actually, what we found was more often our content editors would establish the desktop version, copy the configuration to the other two devices and then would swap the header, footer and anything else that need a device-specific rendering. Definitely not efficient.
For a more recent client, we saw the flaws in the previous approach and wanted to come up with something more sustainable and appropriate for the situation. Again, we were looking at only changing a few renderings per page, like the header and footer and a handful of interactive components (ex. swapping tabs for an accordion). Here’s an example page:
Notice the “2” indicators on the header and footer? That’s telling me that the rendering is personalized and that there are two possible outcomes. Let’s look at the header specifically.
I’m telling Sitecore “if you see a user with a mobile device (as deemed by 51 Degrees), show them the Collapsed Page Header, otherwise show them the standard Page Header”. I have a similar rule for the footer. Everything else about the page stays the same. I actually defined this personalization configuration at the Standard Value for this Template. In other words, I made it the default behavior for all pages of this type which means we really only needed to do that step once. Hours of content editor labor saved.
So far, the only drawback that has been pointed out to me is potential performance loss since we’re technically using the personalization engine on every page. But my response to that is…well, shouldn’t that already be the case? In a perfect world, we would be tailoring the content of virtually every page for the specific user based on their behavior and preferences. It just so happens that one of their “preferences” is the type of browser they are currently using. Plus, I don’t see much difference in the amount of resources necessary to do the standard device selecting Sitecore does by default. If I tell Sitecore that I only ever have one “device”, I just have a couple of tweaks based on the situation, that seems more streamlined.
I’m happy to hear any opposition or additional hints to this approach in the comments. Is this something that would work for your next project? How could it be improved upon?