Responsive vs Adaptive Web Design: Better Together

Responsive web design (RWD), the ability for your web application to “respond” to the size of the view port (traditional screen size vs mobile screen size) is common place and practice today.  Responsive design leverages client sidefront end UI frameworks to hide, show, stack, shrink and grow elements on the screen in a way that is appropriate for the size of the device’s screen.  In essence, it is many user interfaces in a single code base.

Adaptive web design (AWD), a (seemingly) alternative approach to RWD is a server side capability to respond to the client with completely unique templates / markup for a given device type (amongst other facets.)  Adaptive design, while extremely powerful is somewhat less common in part because it relies on a server and is thus a less general technology. It’s also less prevalent in part because, for a large class of problems, RWD is “enough” to get the job done.  However, as complexity and sophistication of requirements mount, adaptive design starts to show clear advantages over a purely responsive approach.

Responsive design and adaptive design are often thought of as an either/or architectural choice.  There is clear overlap in the problems they address and each approach has clear strengths and weaknesses over one-another.  Let’s take a quick look at a side by side comparison:


Technical Approach

Responsive Design: Leverages server agnostic front end frameworks (eg. Twitter Bootstrap) to render a appropriate content flow for the given screen size.

Adaptive Design: Leverages back-end server templates (e.g. Crafter CMS) to render distinct markup for the device and context requesting the application.


Responsive Design:

  • Mainstream approach with many frameworks that can be applied to any backend technology.
  • Single code base

Adaptive Design:

  • Truly unique markup can be delivered based on any kind of context (not just screen size.)  This means it’s much easier to deliver contextual functionality to your users.  Example:  A retail store .com site that has a traditional marketing website at but once it’s detected that a user is inside a physical store location, it gives them a personalized in-store assistance to enhance their shopping experience.
  • Performance.  With AWD you send only the data you need for the experience you are delivering.  On slower, mobile networks that can make a big difference.


Responsive Design:

  • Single code base.  The more variations you want to support, the more code and complexity there is in that single code base.  This can get out of control.
  • Performance can be an issue:  RWD sends all of the code for all variations to every consumer whether or not they will see it in their flow or not.  If the amount of code is significant, this can lead to a performance hit on slower/mobile networks.
  • It’s difficult (although not impossible) to address different contexts beyond screen size with Responsive design.  RWD was really intended to different screen sizes (view ports.)  Stretching its role beyond that takes the technology out of its wheelhouse.

Adaptive Design:

  • You need a server backend to support AWD.
  • Instead of a single UI design and template code base, you potentially have many.  If you don’t manage and factor the code properly it will be more difficult to maintain.


Responsive Design:

  • Provides a usable experience on any screen size.

Adaptive Design:

  • Provides a usable experience on any screen size.
  • Provide faster experiences for your users.
  • Allows you to truly contextualize the experience.  Device type/class/screen size is really just the tip of the iceberg.  Once the server is involved any type of contextual data (location, previous use, time of day, etc) can be used to deliver unique and relevant experience/features to the user.  That can be huge.


Responsive Design:

  • If requirements go beyond screen size, RWD may not be the appropriate solution.
  • If the number of variations is too high performance and code complexity may be an issue.

Adaptive Design:

  • Managing unique templates is a heavier approach that requires server technology and the skills to go along with it.

Better Together

While RWD and AWD are most commonly looked at as competitive approaches, the simple fact is that they are not.  These two approaches are in fact mutually exclusive with another and can be combined to acquire the benefits of both.

Responsive design is front end technology.   Adaptive design is backend technology.  Combine them.

Consider leveraging Adaptive design to drive truly unique and contextual markup to the user for what they are doing, on the device of their choice at that moment.   Allow the front end to leverage Responsive frameworks to make sure those experiences flow nicely on a given device.  For performance and code maintainability, as your RWD code grows in complexity and size, consider breaking it down in to smaller code bases that can be individually delivered to a device by RWD (the server.)

A simple example of this is to have AWD templates for Small, Medium and Large screens.  Each with their own unique features and markup.  When it comes to the specifics like an iPhone vs a Galaxy smart phone (both considered small), RWD steps in to make the minor adjustments required to provide a perfect fit for the given device type. This makes the code more maintainable and more importantly it makes the user’s experience much more zippy.


Patterns for Integrating 3rd Party Content in Your CMS

There are often times when you will want to integrate content in your site that does not ORIGINATE in your content management system.  In this article we’ll look at a few high level patterns for integration and discuss the pros and cons of each approach.

Approach 1: Sync to CMS, publish to site as full content

Approach 1 focuses the integration at the CMS level only.  Content is either pulled or pushed from the 3rd party system in to the CMS.  From there it can be further processed and is ultimately published to the website where it can be used like any other type of content including native involvement in search and targeting scenarios.


  • 3rd party content is converted to 1st class content which allows it to be used natively by the system with not rendering engine level integration.
  • Authors may augment the content coming from the 3rd party system to include additional content and metadata
  • This integration is typically very simple
  • There is no impact on the performance or complexity profile of your delivery environment


  • Syncs can be tricky.  Remember content originates in the 3rd party system but it’s possible that it may need to be further modified by the CMS.  
  • A mechanism and a process must be defined that allows content updates to flow from the 3rd party system in to the CMS.  Typically this involves a strong ID that identifies each object, a mapping of fields that can always be overridden in the CMS  and mechanism for communicating creates, updates and deletes.

Other Considerations

  • By passing through the CMS 3rd party content is not “immediately” available on the website.  Content must wait for the sync mechanism to operate. Further, there may be workflow required before content can be made live.

When to use this pattern

  • This pattern is often preferred
    • It is relatively simple
    • Allows augmentation of the content in the CMS
    • Requires no run-time integration
    • Has no impact on the performance and SLA of the run-time

When not to use this pattern

  • When any create, update or delete to the content in the 3rd party system must be IMMEDIATELY available on the live site.

Approach 2: Partial sync to CMS, full details retrieved at run-time

Approach 2 syncs a simple jacket for the content to the CMS but relies on runtime integration with the 3rd party system for the full details of the 3rd party content.  The jacket in the CMS carries only the metadata required for the 3rd party content to participate in search, targeting and other dynamic behavior on the site.   The “sync” that creates the jacket in the CMS may be done through a simple integration or can even be a manual process.


  • Less content is relied on from the CMS which means that for items that have been previously published, detailed data is always 100% in sync with the 3rd party system.
  • Search, targeting and other dynamic capabilities native to the delivery system may still be relied on for functionality within the site.


  • There is a runtime dependency on the third party system for the actual content.  If that site is down, the content is unavailable.
  • As discussed in approach 1, syncs can be tricky.  In the case of approach 2 we still have some sort of manual or automated sync to create a jacket in the CMS.
  • In this approach there are 2 points of integration 1 at the CMS and one at delivery.  When you add additional moving parts, you are adding operation complexity that must be maintained and supported.
  • Content can be out of sync between what the site has in it’s jacket (and this in the indexes) and what is in the 3rd party system.  You must consider all cases: create, update, and delete

Other Considerations

  • By creating a run-time dependency between the delivery system and the 3rd party system you dictate that the 3rd party system must (generally) have the same reliability and performance capabilities of the delivery system.

When to use this pattern

  • When detailed aspects of the 3rd party content must be IMMEDIATELY up to date.
  • When it is impractical to import all of the 3rd party content in to the CMS.  A typical use case for this approach is 3rd party hosted video.  The CMS may contain only basic metadata and thumbnails while the 3rd party system retains all of the various video encodings.

When not to use this pattern

  • If the website and the 3rd party system must be 100% in sync on ALL aspects of the content at all times
  • When approach 1 is viable.

Approach 3: Run-time integration only

Approach 3 focuses integration at the content delivery tier only.  Display and behavior related to the 3rd party content is all handled through integration.


  • Approach is the most simple from a “moving parts” perspective. There is no syncing involved
  • 3rd party content is immediately up to date when changes are made in the 3rd party system


  • There is a runtime dependency on the third party system for the actual content.  If that site is down, the content is unavailable.
  • All content display, and behavior such as query driven listings, content targeting, and search must be integrated.
  • It can be difficult to integrate functionality like search where CMS content and 3rd party content are placed together on the page in a seamless way.  This is because the implementation is very likely to require issuing at least two queries (one to the CMS and one to the 3rd party system.)

Other Considerations

  • By creating a run-time dependency between the delivery system and the 3rd party system you dictate that the 3rd party system must (generally) have the same reliability and performance capabilities of the delivery system.

When to use this pattern

  • When 3rd party content must be IMMEDIATELY available and up to date on the site the instant it is updated in the 3rd party system.
  • When there is no need to rely on native capabilities of your delivery platform for delivery of the content and dynamic behavior (like search.)

When not to use this pattern

  • When option 1 or 2 are viable and use of native capabilities of the content delivery platform useful / required.


Never Use a Traditional CMS to Back Your Applications!

Almost every application today, regardless of the delivery technology and channel (web, mobile, kiosk, etc) has content in it. Smart developers quickly realize that managing the strings and the other content should be done outside the application rather than embedding it in the code base. Rather than build custom databases and authoring tools most developers look for a Content Management Systems (CMS) to fill this need. But there’s a problem with that…

Traditional CMS technologies (WordPress, Drupal and many others) have an architecture and approach that was designed and built over 20+ years ago. Let that sink in.

How can something built over 20 years ago or even something that was built “today” but that maintains the same basic pattern that was introduced over 20 years ago possibly be the right answer for today?  It can’t.  Here is just a few of the issues:

  • They are built with older technologies like legacy PHP, Struts, Sling and JSPs etc.
  • They don’t scale easily/cost effectively because of shared content stores based on SQL and Java Content Repositories (JCR.)
  • They are monolithic.  Most systems couple authoring and delivery which makes the system complex to maintain, hard to secure and even more difficult to scale.
  • They mandate rigid development and theme frameworks that slow down and limit innovation.
  • They make it difficult to roll out new functionality through your dev-ops process.
  • Thy are full of bolt-on solutions to keep up today’s needs like content as a service. Remember when they were designed, the world was just web pages.  You can’t teach an old dog new tricks.
  • Because of their heritage as page centric platforms they lack flexibility

Who in their right mind would put a technology with all that baggage in their application architecture?! Don’t do it. Just don’t.

So what’s the answer?  Back to building custom databases and editorial tools?  No.

To solve this problem a class of CMS solutions have show up in the called Headless CMS.  These solutions provide very basic content management and deliver the content as a API.  This capability is called Content as a Service (CaaS.)  Many of these are available only as Software as a Service (SaaS) solutions in the cloud.  These solutions solve some of the problems that traditional CMS solutions have by moving all presentation and development responsibility to the consumer (outside the CMS) and making scalability a vendor issue.

If all you need is “headless content”/CaaS and public cloud/SaaS vendors are a viable answer for you then you may have a solution.

However, many situations call for a solution that includes but go far beyond headless content — templates, personalization engines, queries and other key CMS capabilities are still needed by most solutions. Further, some companies still require on-premise installations.  For these organizations the field of viable solutions is much smaller.  They need a fully featured CMS platform without all the baggage — one that that has been completely re-architected and re-oriented for today’s high rate of innovation/iteration and digital experience challenges. That’s where Crafter CMS, an open source, Java based, enterprise-grade CMS really shines.

Crafter CMS is not a traditional CMS. Crafter CMS is a new platform built on modern technologies and a completely different architecture that is designed for situations that require rapid innovation, flexibility, enterprise integration and extreme performance and scalability.

How is Crafter CMS different from traditional CMS technologies? Here are 10 reasons why:

  1. Not page centric: Crafter was built to manage any kind of digital experience and related content.  Unlike legacy CMS software, it’s not page centric.
  2. Modern technology: Crafter is built with today’s most modern enterprise friendly technology like Java, Groovy and Spring, Git and Apache Solr.
  3. Tech you know, skills you have: While Crafter CMS has a lot of built in services and capabilities it doesn’t add or enforce a lot of framework. Developers leverage existing skills for familiar technologies rather being forced to learn and use platform/vendor specific technologies, and frameworks.
  4. Rapid development: Coding support for Groovy and Freemarker scripting removes the need to for heavy coding and deployment cycles.
  5. Amazing for devs and ops: Crafter fits seamlessly into your development and DevOps process. Finally there’s a CMS available that is not only powerful from a development perspective but that also plugs into your development process!
  6. Micro servicesCrafter is a decoupled CMS with separate authoring/management and delivery capabilities that are built on a micro services architecture.
  7. FAST! Crafter is blazingly fast. Rather than use databases and JCR repositories that are fundamentally slow and difficult to scale, Crafter uses an in memory database, disk and Apache Solr for content storage and retrieval.
  8. Extreme scalability: Crafter is horizontally scalable. Experiencing a huge surge in “traffic”? Just add more nodes. There’s no database to scale behind Crafter’s delivery tier. Further, because Crafter uses simple but powerful technology to drive dynamic content a single server can do a tremendous amount of work.  That means fewer servers are required to get the job done.  Fewer servers translates to less infrastructure, less labor, less cost.  Huge win.
  9. Geo-deployable: Crafter is geographically scalable and can even serve content in remote or disconnected environments. No databases. No clusters. No problem.
  10. Proven: Crafter CMS is battle tested and powering content and experiences at many of the world’s top brands and most innovation-forward companies.

Separating content from code is smart move. Betting on a traditional CMS to try an make it happen when you need development agility and scalability is a dumb move. Check out Crafter CMS!  It’s a totally new take on what a CMS platform should be!!