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.
Source: Branded
|
|
The post Back to the … Vanilla UI Framework – Part II appeared first on Jass V.
No comments:
Post a Comment