Distributed design, better than responsive design ?

Nowadays every web developers have to focus on each screen that gravitate around us. Desktop, mobile, tablet, TV, smart watch and so on, with specific aspects for each targetted device. Search engines such as Google are penalizing web sites that are not offering an adapted experience to mobile user. Therefore thinking to all connected screens is a necessity. 

Although responsive design is simple and a quick answer to adapt a website to different views, is this the best solution ? The “distributed design” could be a serious alternative. More than a language specification, distributed design is an architecture defining inheritance and resources used for a requesting device. Unlike its counterpart, this solution does not rely on media queries to adapt the display based on the screen resolution. But it relies on a device detection to load specific resources to it. The idea is simple : same service, same URL, optimized render. The benefits are multiple, finer weight management of pages, called resources, better display performance, adapted content, reduced maintenance…

Some figures

Connected devices count don’t stop growing, implying a huge diversity of environments to take into account. In year 2015, 1 on 2 internet users owned a tablet, 1 on 3 owned a smart TV, and 1 on 10 owned  a smart watch. Resolution, size, usage, if you want to make your brand visible you have to adaptto the users’ habits. It is crucial for a company to know how to be present on each media that represents a potential market.

design what do internet users own ? laptop tablet smartphone

Let’s take a real world example

The problem

You want to make a website with a high visibility, able to satisfy most of your visitors regardless of the device they are using with an adapted view. You may have already a lot of visitors or not.

First approach

An obvious answer would be to use CSS media queries in order to adapt elements style, hide or show blocks and so on. I have to admit that solution will work and provide a relatively sufficient result. However if you start thinking about optimizing your pages, you will start to encounter problems such as how to adapt image resolution according to the viewport, how to get rid of duplicated DOM nodes, how to load only needed scripts or how to limit the number of requests to your API.

Of course there are solutions for each of these problematics. You will problably tell me that we can use “srcset” with a polyfill for adaptive images resolution, use asynchronous load of scripts to get those adapted to the current device, etc. But if we take each problem individually, it can have impacts on the other sides, such as execution performance with too much Javascript to run or slow pages loading due to an oversized weight.


Here comes Distributed design goodness. What if your service could load automatically a list of defined dependencies according to the device? What if you could load automatically the code only needed by your device ? And if you could share templates between devices and include specifities only when needed ?

design what device ? tablet pc smartphone

The devices share common parts, styles and sources, and can also have individual features


The architecture relies on 3 main components. Each one can be implemented differently depending on the environment and code languages used, but the goal will always be the same.

architecture design and pc smartphone tablet devices

1. Device detection

First step, define what kind of device is interrogating your service. The common method is to rely on a browser user agent filtering. This filtering can be done on HTTP cache server side, HTTP server side, or in your application. For obvious performance reasons, the sooner this filtering is done in the request flow the better.

If you still prefer to do it directly in your application, possibly because of your environment constraints, numbers of open source bundles are available to avoid the frustating pain of writing rules that covers every conceivable device (MobileDetectBundle, Spring device detection,…)

However if you are the adventurous type and still want/need to create your own filtering rules, a lot of free sources are referencing the huge amount of existing browsers user agents. A good source : https://udger.com/resources/ua-list/devices .

Keep in mind that the device filtering should be done once by request and the result should be available through all your application.

2. Templates inheritance

Now that you have a way to detect the requesting device, you have to deliver it the good visual. You should to have a directory structure organizing templates by device and a common folder for shared templates.

The idea is to implement a service that will load automatically an adapted template to the context given its name. Service should follow this rules :

  • if the path of the required template is relative, check in the detected device folder if the templates exists and load it, else check in the common folder and load it
  • if the path of the required template is absolute, load it directly (used to force the loading of a specific version)
template css js devices

With this rules you will be able to mix common parts with device specific parts.

Another advantage is that you can override at any time a part of your visual simply by creating a template in the targetted device folder. For instance, if you have a common sidebar block for desktop and tablet and you decide to have a different view for tablet, simply create a new copy of your template in the tablet folder and it will be automatically loaded.

When organizing your templates this way, it will be easier to create, modify and maintain your layouts. Then the introduction of a new supported device will be way faster.

3. Resources bundling and delivery

Last crucial point is to organize resources for each device in a way that will allow to deliver only the ones needed by the requesting device. A lot of tools dedicated to concatenation and minification are already existing. With the advent of nodejs and its ecosystem of packages such as grunt or gulp, the process of minification is becoming a common task. But for distributed design, you will have to push a little more the logic and split resources such as JS and CSS into distinct folders.

As previously said for the templates, the resources should be divided in a device named folders and in a common folder. This way we can create lists of resources for each device and generate a final bundled resource to deliver.

design mobile css js tablet css js desktop css js

Following this process, we can have for example these bundles generated :

Target Resources Generated file
Desktop common/utils.js, common/conf.js,desktop/jquery.js desktop.js
Tablet common/utils.js, common/conf.js,tablet/jquery-mobile.js, tablet/tables.js tablet.js
Mobile common/utils.js, common/conf.js, mobile/jquery-mobile.js, mobile/touch.js mobile.js
Mobile common/layout.css, common/article.css, mobile/article.css, mobile/mobile-ad.css mobile.css
TV common/utils.js, tv/conf.js, tv/layout.js tv.js

The advantages of this process are a better pages weight managementbetter load performance. Also it assures reduction of conflicts risk between styles or libraries.

All in all, distributed design is not a replacement for responsive design. It is more of an architecturethat will take responsive design one step further. It could afford an easier maintenance, better overall page rendering and delivery, and a more flexible way to handle device specific content. Thanks to the fact that you may reuse your previously written templates, styles, scripts and tools, a migration to this kind of architecture could be really fast. This is a solution that every company should think about when it is sensitive about performance and adaptive content.