Responsive Design: beyond Grid and Columns

ByFernando Monteiro in

Last year iMasters held, in Brazil, and edition on Responsive Design of their ​​7Masters talks. I was invited to be one of the speakers, but a last-minute problem prevented me from going. So I made this article to show a little of what I would speak there.

A slide presentation can be found at the following link.

Talking about what everyone already knows

It is very common nowadays the term Responsive Design still is seen in a completely backward way, many people talk only about grids and columns, optimization for video, responsive images and media queries (breakpoints). We have a plethora of plugins and frameworks that facilitate our work, but do we really need all this?

The answer is Yes, we still need all of this and a little more, not forgetting that many of the sayings responsive sites do not meet all devices and so little concern for TEXT that’s right, I have visited many sites that do not render text properly at all screen sizes.

Besides all this, we should think more about how to optimize responsibly the way the user interacts with our applications. Using grids and columns to form a layout is great, but the question is:

If your layout is prepared for mobile devices, how is the speed of your application with those many features used at the same time?

Responsive Design in Single Page Web Applications

Many can answer the previous question in a few words, some would say:

– concatenating and compressing JS and CSS

– Using a CDN for images and static files

– gzip

And so on, the list is extensive. And all this helps, but when we talk about SPA things are a little different, since single page apps (not to be confused with one page websites) use templates to inject content into a kind of master page with a single header and footer, that is, if we take literaly the concept of single pages app.

Yes, we can include a header and a different footer in a template, but in besides being clumsy, if you use nested views within nested views this will be a failure.

Imagine an application using AngularJS where we have something close to the following image.

Things are starting to be not so simple; even using all the techniques mentioned above we still need to cover and support a lot of size and resolution of screens.

Imagine using breakpoints, thinking mobile first, go from smaller to larger, adding all necessary sizes, to facilitate we can still use a  CSS pre-processor to let it all as dynamic as possible.

SASS has an excellent MAP feature that is extremely useful in these cases.

Now think about implementing this in all the following breakpoints:

With the features mentioned above, it is still a relatively simple task, even for a team of front enders, with a well-defined style guide of course. Since when we work alone it is a lot simpler to maintain consistency and standard code.

Then the problems starts…

After all this is implemented in the application above, a quick reference to the Web Inspector shows a somewhat frightening result, as we can see in the image below:

Exactly 89% of the rules in our style sheet are not being used by the current page. This means that:

– In SPA applications, this will happen 100% of the time on every page (Views/Templates), since every change that happens, happens in the core/application template.
– Even with mobile first the result is almost always the same.

Remember, we are talking about SPA applications with AngularJS.

Although the application is extremely optimized, we have three style sheets on its header, not including the JS that are in the footer and taking into account that this is not such a big application.

A clever way to deal with this problem

The solution we found and that was by far the best and most robust of all, was the use of ocLazyLoad, a module in AngularJS to load not only JS files but also CSS.

As we can see in the following image on a registration module:

In this way, as we use OOCSS and SMACCS on style sheets, we can only inject the related sheet with the specific module and their respective widgets.

That is, in a registration screen, it is injected only int the forms and validation libs, without the need of all contents as tables, cards, tabs and others.

So each view/template uses 89% of CSS rather than the opposite.

A simple solution that takes Responsive Design in SPA to a path of success and appropriate speed for your application.

Visit the official link for this module.

Leave a comment! 0

0 comentário

Comentários

Your email address will not be published. Required fields are marked *

Commenting asAnônimo

read more