At last year’s Magento Imagine Conference Enterprise Edition v1.14 was released. The biggest announcement from the conference was that the default theme is now fully responsive. This theme is based on the latest technologies (CSS3, HTML5 and jQuery), which makes it the first major update to Magento Enterprise’s default theme in years, and very exciting for everyone in the industry. This also makes Magento’s default theme an even better option for merchants to launch a modern and cutting-edge store on!
So the question is, should everyone adopt this new theme? It’s already responsive (one of the many qualities we look for when building new sites), but it was also developed by the same guy that brought us Skinny Ties. Sounds like an easy solution based on this was a great looking site that caught a lot of attention the last couple of years on the Front End Development community.
Related: Tips for a Beginner Magento Front End Developer
The Adventure
While we wait for the release of Magento 2.0, we decided as to start working with Magento’s v1.14 theme. To take on this endeavour someone had to be the first one to test it, to learn it, and share their knowledge with the rest of team…essentially someone had to be the team’s “Guinea Pig”.
As someone who loves sharing knowledge and was raised reading adventure books, I saw this as a great opportunity to learn and create my own “adventure story” while fighting my own “front end demons”. So I became the Demac Media’s Don Quixote, Sherlock Holmes, Buzz Light – you get my point.
The endeavor to understand is the first and only basis of virtue.
- Baruch Spinoza
The Guinea Pig
Call me naive! The opportunity sounded great, but new adventures require some preparation and lots of patience as I would be spending time reading other’s code, understanding their thoughts, and adapt to their ways of working.
When it comes to programming it is hard to read someone else’s code without criticizing it. Usually I think to myself, “I would have done it this way”, “Why did they do this?” or even admire it “This is a neat trick”, “I like this, and want to incorporate this to my work”.
We invested some a few months developing our very own Responsive theme, before v1.14 was announced. Luckily we chose Foundation and SASS, which turned out to be really close to the work done on v1.14.
The Differences
Creating a summary comparing both methods of work would produce a novel rivalling the size of Tolstoy’s War and Peace, however I would like to point out the most important findings I’ve seen so far. This is not a definite list, nor is it my intention to compare, “my code vs. your code”. I personally believe Magento did a great work with the v1.14 but some things could be improved.
Related: 8 Easy Ways to Improve Magento Site Speed
Elements on the DOM are moved via jQuery. Depending on the Stop
The responsive breakpoint definitions are done both on via SASS files and jQuery files. Both need to match in order for the theme to work. Also notice that 5 stops have been declared: xsmall (mobile), small (small tablets), medium (tablets), large (desktop), xlarge (large desktop).
/skin/frontend/rwd/default/scss/_var.scss
// ============================================= // Primary Break Points // ============================================= // These should be used with the bp (max-width, xx) mixin // where a min-width is used, remember to +1 to break correctly. // If these are changed, they must also be updated in app.js // $bp-xsmall: 479px; $bp-small: 569px; $bp-medium: 770px; $bp-large: 1023px; $bp-xlarge: 1199px;
/skin/frontend/rwd/default/js/app.js
// =============================================
// Primary Break Points
// =============================================
// These should be used with the bp (max-width, xx) mixin
// where a min-width is used, remember to +1 to break correctly
// If these are changed, they must also be updated in _var.scss
var bp = {
xsmall: 479,
small: 599,
medium: 770,
large: 979,
xlarge: 1199
}
Heads up: on two columns pages like a category listing page, the following DOM elements will be moved via jQuery (after page load)
Be aware that this change might not be aligned with your design. It’s done to hide the sidebar and change the behaviour and look & feel from an open list to an accordion list.
Size Variables are used at will
To work the responsiveness of this theme a new function was introduced incbp(). It’s well documented on the Magento CE 1.9 and EE 1.14 Responsive Web Design Developer’s Guide.
A custom bp() mixin includes media query breakpoints. For example, this Sass:
@include bp(max-width, $bp-medium) {
/* These styles will only display on viewports smaller than or equal to 770px */
}
@include bp(min-width, $bp-medium+1) {
/* These styles will only display on viewports larger than or equal to 771px (770px + 1px) */
}
generates this CSS
@media only screen and (max-width: 770px) {
/* These styles will only display on viewports smaller than or equal to 770px */
}
@media only screen and (min-width: 771px) {
/* These styles will only display on viewports larger than or equal to 771px (770px + 1px) */
}
However, even though the variables for the breakpoints have been defined on SCSS & jQuery files, there are also hard coded stop values defined on some SCSS files. For instance: /skin/frontend/rwd/default/scss/content/_home.scss were 880px is used or /skin/frontend/rwd/default/scss/core/_common.scss where 480px is used.
Class .no-display added via jQuery (to some elements)
Same as some elements are moved on the DOM via jQuery, a .no-display class to hide elements. If you find elements disappearing on your theme make sure to search for it using the Inspect Element and look for this class.
The element might have been magically disappeared.
If you would like the element to show, either change the jQuery to remove the call or add an overwriting display: block !important to the class on case. None of which seems to be the best solution (so far) but they both work.
No Grid System
If you have worked with any Grid System, you know how important Grids are for the design & development of any website. Having them removed could have to my understanding more of a negative than a positive impact on the workflow between your Design & Development teams.
In our case, we got used to work with Grids. They are simply great for alignment and making our lives easier.
As I write this post, seems to me that Magento v1.14 doesn’t seem to use a Grid System requiring a different approach process when it comes to aligning elements on the site.
A good example is the listing page, where you might need to align 4, 3, 2 or 1 product on the page depending on the device that’s currently displaying the site. On Magento v1.14 a mixin is introduced for this purpose, however this mixin requires the width of the container to be defined:
/skin/frontend/rwd/default/scss/module/_product-list.scss
@include bp(min-width, 960px) {
@include product-grid(4, 960);
@include product-grid(5, 960);
@include product-grid(6, 960);
}
Accordion Behaviour is enforced on Tablet Sidebar
Since we worked on our Responsive theme, we established that Tablet view will give a look & feel similar to desktop, with minor variations of course. For instance the Menu works on Hover on Desktop but it works on Touch for tablets. That’s a simple and much needed change.
When it comes to the Product Filtering (Category Pages) we like to show the options and let the user choose accordingly. On Magento v1.14 this behaviour is enforced to be an Accordion, requiring extra Taps to filter the content.
SASS code Styling
To make SASS files readable between our team members we chose to work on an “inlined” kind of way.
.block {
color: $c-black;
background: white;
@include bp(min-width, $bp-medium +1){
color: $c-black-light;
}
@include bp(min-width, $bp-large +1){
color: $c-black-dark;
}
}
This truly differs with Magento v1.14 way of coding
.block{
color: $c-black;
background: white;
}
...
...
...
300 lines later
...
...
include bp(min-width, $bp-medium +1){
.block{
color: $c-black-light;
}
}
...
...
...
300 lines later
...
...
include bp(min-width, $bp-large +1){
.block{
color: $c-black-dark;
}
}
Which one is better? That’s up to you to determine. Our reasoning behind making the break points to be “inlined” is to make it easier and faster to find the code that changes the style of the current element; especially while working with large SCSS files this seems to be easier to read and maintain.
Final Thoughts
My take on Magento v1.14 theme is that’s a big change from the original theme that comes with previous versions. This one already includes HTML5 and CSS3 support (finally!!!). And also comes with SCSS, a resource that front end developers appreciate.
We currently give support to clients that have different versions of Magento, some use Magento v1.14 and others use earlier versions of it, some use our Demac Media responsive theme, others use older not-responsive version of it. As you can imagine we have a variety of themes that we have to work on daily basis. To be able to do so, it’s really important to define standards. We have come up with our own, and as we move forward and adopt Magento v1.14, we’ll be incorporating more changes to it.
Even though Magento 2.0 hasn’t been released it has been announced that the new themes will be using LESS. This will include new changes on the way of work and might create conflicts to support old clients. But we’ll deal with that adventure when it comes. In the time being we’re focused on the current path while making our clients happy! Comment below if you have questions about v1.14.
Related: The Magento Upgrade Guide
The post Magento v1.14 – A Responsive Adventure appeared first on Demac Media.
