If you read my previous post here, you’ll know that we have recently put a new way of working on the front end of projects into practice.
Our old method involved making use of the third party frameworks from Zurb and Twitter – those being Foundation and Bootstrap, which are both good responsive front end frameworks in their own rights. If they’re good and widely used, why stray from the herd? Hopefully by the end of this post, I’ll have convinced you that Vanilla is a better solution than those currently available.
Now we haven’t gone and reinvented the whole UI workflow (something we are in the process of!) and this is by no means ground-breaking.
I’m sure many people make use of the same technologies and possibly make better use of some! If you fall into that category, leave us a comment – we’re learning as much as you are in this fast-paced world of UI development.
The new tools which we utilize have been packaged up and baked into the platforms we develop on, so now have a set of repositories we can rapidly roll out for each new project.
The name Vanilla is well suited, as it’s a very basic structure in which a UI developer can work. It’s the bare bones of a project, which is a step away from the likes of Bootstrap and Zurb, which are bloated in comparison.
Most projects which are built using those third party frameworks only ever utilize a small portion of what’s available to use. Digging around to strip out what’s needed and not needed, on a project by project basis is both time consuming and quite frankly, very boring for a developer.
What is Vanilla and why is it a good idea?
The Vanilla framework we have created differs slightly depending on the platform, as you would imagine. In Sitecore, we have a shelf system for laying out content, and in this, we have a series of span classes we have applied to our layout shelf system. Our lead .net developer has this to say about our Vanilla solution for Sitecore:
“Sitecore Vanilla is a pre-installed version of Sitecore in its own repository, which is maintained like an active project. It is configured to a standard that we have set out in a way that we believe is the best for building sites on this platform.
It helps us to standardise everything and therefore offer standard features that don’t have to be built or imported each time. Whenever we start a new Sitecore build, we take the initial base from the Sitecore Vanilla repository, so within an hour, we can have a ready-made and checked-in solution ready to tailor to the client’s needs.”
Working from a solid groundwork in which we have put time and consideration into for each platform we develop on, initially took some time to design, develop and improve.
However, this ultimately saves us time on the initial setup and also means that we don’t have to write a lot of code that tends to repeat across projects. In this regard, we use our Vanilla framework like anyone would use Zurb or Bootstrap – as a time saving and consistency focused tool.
The benefit is that we don’t include anywhere near as much bloat as the common frameworks, and each platform has its own version of Vanilla – not as a one size fits all, but a customised springboard into whichever CMS platform a project needs to be built on.
Style guides
Similar to the logic behind having something like normalize.css in a project to give you a blank canvas across all browsers, we create a styleguide to save even more time. We have our designers work out a full UI element inventory – Anna Debenham has a great collection of resources on this subject here.
What we as UI developers want from a designed style guide is the ability to pre-populate our style guide in code with all the required UI elements of a project, including all their states. Again, this aids with rapid development, in knowing the classes you need upfront to style elements and knowing that all the elements you add to a page are styled in an organised way.
It also saves you from needlessly styling an element per section of the site you come to build. A designed style guide should be an inventory of every single type of UI element and its hover/active/focus states all in one document. From this, we spend a day filling out the blanks and customising each element which is required as part of the project.
By the end of a style guide sprint, you should be able to look at a page which has been populated in the platform with all of its UI elements, and get a real feel for the design. It also provides the designers with an opportunity during the initial stage of a build to critique styles.
At this point of a project timeline, where we have a fully populated page of HTML elements, we can have a designer take a look and sign things off.
This means that a large box has been ticked in terms of work that goes into building a project up, and you can continue to rapidly develop, knowing that each time you place a button, it will be correctly styled and won’t need amending later on in the project.
Here is an example of a style guide from one of our designers.
Pattern library
A pattern library is created in addition to the style guide document. It collates each of the various design patterns into one place.
What we mean by a design pattern is any repeating styles used across a site. This isn’t usually needed on small projects, but it’s the first step to coming up with a plan to tackle the front end architecture.
A pattern library should be collated during the initial project meetings by both the relevant UI developer and designer, as a way of breaking a project down into its smallest component parts and to enable a good understanding by the UI developer of the work involved. This step also benefits project managers, as more accurate timings can be produced.
This is beneficial for the designer to spot any potential issues with a design and refine inconsistencies, as well as allowing the UI developer to create an organised CSS plan from the designs before they jump into any actual code.
It’s also useful for other developers who might begin work on the project at a later date, as it lays out all existing patterns in a page with mark-up. A great example of one of these is the Mailchimp pattern library.
Once you have all these elements together alongside the styling that comes from the style guide, you should build up the pattern library in code. You should include the HTML that goes into producing these patterns as a reference for any other developers who may work on this.
Again, this comes down to limiting the amount of time a developer is writing repeating code.
Project architecture
When sitting down to a large web project, it’s always best to lock the designer and the developers in a room to go through the design meticulously, to ensure that everyone is on the same page in terms of UI/UX direction and expectations.
From this initial breakdown of the design, a UI developer should have a good roadmap for moving forwards in terms of how they are to tackle the code and structure they intend to write. They should have a good idea of all the classes and styles you are going to be writing and a way to break them down into the simplest of solutions, always keeping in mind the importance of low specificity css.
Making use of the pattern library can help to identify repeating styles that can be broken up into small functional classes for global use. It can also identify the number layouts used in the design, and come up with a good solution that caters for as many of them as possible, with as little css as possible. For this we use layout classes in combination with last classes, and for our rules we use Susy to generate our grids maths.
Taking a meticulous approach as part of the project’s planning phase before sitting down and writing any code, should enable you to start to see your projects as a collection of globally styled elements and parts rather than individual pages to be styled.
From all of this you can work out a good selector naming convention (we go with BEM) for the whole project, as well as getting a good idea of the amount of work which is required to achieve the perfect end product. This should also make your project manager happy.
The language – SCSS
Why do we use SASS over LESS, and why SCSS and not SASS? There are many articles on the subject, as any technology goes for front end development – there are numerous solutions out there. The trick is finding the one that best suits you, and we go with SCSS for the following reasons:
We found LESS to be counter intuitive when bringing a more programmatic approach to writing our styles. LESS aims to be as much like CSS in style, syntax and structure, and while this is a nice thought for new users who are writing it, there are some issues which make less fun to write.
Another great benefit to SASS is the compass library. This comes with all kinds of handy tools for an eager front end developer to make good use of.
Now for why we choose SCSS over SASS: in version 3 of SASS, the ‘sassy CSS’ syntax was introduced to replace the old syntax for SASS. It builds on the existing syntax of CSS, which every developer should be familiar with. This takes away the opinionated syntax of SASS, but leaves the developer with all the tools available when using it. So any valid CSS would also be valid as SCSS.
On top of this, we find SCSS easier to read because it follows the same rules as CSS, which we are all used to reading. There isn’t a learning gap for any developers who are new to the team.
There are arguments on all sides of this; I’d recommend having a go with the different syntaxes yourself and decide. At the end of the day, it’s a tool to help you achieve more for less work, so it’s entirely down to personal preference.
Responsive – Breakpoint
So there are a few methods by which we could make a site responsive in our CSS. Back in the day it’d be writing single media queries and putting all of your rules in them for whatever you wanted changing at certain sizes.
@media screen and (max-width: *some value*) {
*some rules*
}
Thankfully we no longer have massive media queries. By using SCSS, we can make use of variables and mixins, and have a more inline approach to writing our media queries.
Regarding the inline approach, there are a couple of ways you could go about it. You could write your own mixins or use some of the ones which are available from sites like css-tricks, or like us, you could make use of an existing mixin library.
We use breakpoint SCSS for our responsive queries and the results are amazing. Organised media queries in line with the elements they affect, make things much easier and much more rapid to develop responsively, especially when setting your dimensions in variables so you can refer to a list of custom breakpoints whenever you need to.
We don’t ever work to a standard list of dimensions, instead we cater for the major breakpoints like 768px for an iPad etc. Our method is more of an “add a breakpoint at a point that the site breaks” approach.
Obviously, you must keep in mind that these breakpoints can cause load on browsers (only if someone sits and resizes from desktop down and back up again) but still it’s worth considering.
So keep the number of breakpoints as limited as possible, while still achieving a robust responsive solution. A use case of breakpoint SCSS would look like the following:
$bp_ipad: max-width 768px;
.foo {
width:50%;
margin-bottom:50px;
@include breakpoint($bp_ipad) {
width:100%;
margin-bottom:20px;
}
}
Now you may be thinking that with this method, it might cause bloat in our CSS, but a little research reveals that this isn’t the case.
While having numerous different media queries firing across a resize from desktop to mobile, size does cause CPU and memory load; when running on an actual device, the impact of having many media queries is negligible when considering performance.
So we can be confident that adding in multiple breakpoints and using them whenever we need won’t make our site slow.
Here are some useful resources, on performance, management and tools for breakpoints.
Naming conventions
Another practice we have in place for our Vanilla framework is a strict doctrine of naming conventions.
We have come across problems before when working on legacy projects, due to bad selector names, names that are far too vague and could apply to any number of things.
We follow the BEM syntax when writing our selector names. If you’re not familiar with it then check out this article by Harry Roberts. I won’t go into much detail because frankly it’s very well documented in other blog posts and articles. The bottom line to BEM in selector names is that it gives greater transparency to other developers and to yourself!
We follow a similarly strict doctrine when naming our variables.
For colours we call, we have as ‘$accent’ and a number – accent1 through 10 for example. We also have a rule for naming our breakpoint variables. For these we use nonspecific names that are in no way related to the content of the variable.
The reason for this is due to the potential for a value in a breakpoint to change, so we would have: $bp_blue, $bp_pink, $bp_yellow etc. None of these names have a bearing for the value of the variable, to save confusion if things get changed.
By using a structure doctrine of naming conventions, we know that, across multiple projects, we will have no issue going back to work on anything, and can further our aim of creating beautiful sites with low specificity CSS.
Using SCSS we can write our classes like the following:
.block {
@at-root #[&]__element { }
@at-root #[&]--modifier { }
}
Which outputs
.block { }
.block__element { }
.block--modifier { }
The idea behind our use of these methods is to replace “can you build this?” with “can you maintain this without losing your minds?”
To sum things up
Creating a custom front end framework is a daunting task. If it’s not well researched and well considered, you’re wasting your own time and potentially impacting on projects by using a substandard framework for the job.
At the same time, you can have this problem with the bloated common frameworks. It all depends on the needs of the project, although all considerations on what to use should be on a project by project basis.
We invested time in creating a custom framework because we saw the worth in doing so. We are now ultimately familiar with its use and abilities, because we built it ourselves, and most importantly, you will never know a framework like you know your own.