Alex Arriaga

The context: why should I need to know this stuff?

In the last years front-end web development has became one of the most exciting areas of IT and software development, as front-end developers we have a tone of new tools, APIs, editors, packages, etc. that make our life easier.

There is an area that is particularly interesting: Responsive web design, but now, we try to go a little bit further, and not only create amazing responsive web sites, but also we try to provide the best web experience for our visitors, there is one aspect that is in particular really important when we create web portals: loading the resources depending on the device, it doesn’t matter if it is an smartphone, a tablet or a high resolution desktop; we must provide different views per device, and here is when something come out!

Most of websites are responsive but many times the views or layouts only hide or show graphic elements (like menus, carousels, blocks, etc.) that means all the resources are loaded even if they will not be used on phones or tablets.

The IBM proposal

Instead of just hiding or displaying elements depending on fixed media queries, we can provide a better mechanism which is called Adaptive Web Design. When we talk about adaptive, we mean we must load only the resources that are really necessary for displaying our views depending on the user’s device, for example if I have a list of news but in desktops I show titles, summaries, and images, but in smartphones I am only interested in displaying the titles, why in the phones should I load the summaries and images.

Let’s see how this kind of blocks look in the simplest way:

Now, if we want to show some specific content or components for desktop and tablets we can use the “negative” syntax of this plugin

Let’s see the example

Going back a bit… in our component to display a set of news we can follow next steps to have an adaptive content per device:

• For desktop and tablets where we have more space to distribute our news (titles, thumbnails, summaries, etc.), so, it makes sense to include more HTML elements.
• For smartphone since we have less space available we don’t render all the information but instead just the titles.

Desktop and tablet

Let’s imagine this is a fragment of the results of a menu or personalization component:

The rendered HTML content would be something like this:

Smartphone

And in the smartphone we can have a simpler version of the same component including only the title like this:

In this case we would have this kind of output:

Pretty simple, doesn’t it?

I hope you find this short article useful for your future implementations and remember be happy with your code!

See you next time!