Chelsea and I have been given the task of leading the rebrand and redesign of our old V9 Solutions website into VIX Digital.
Creating our new site is a good opportunity for us to make some improvements to our code writing techniques.
We are going to be using Zurb Foundation to style our site, some of the built in components make creating our layouts much easier and much quicker. For example, the grid, forms, buttons and the built in global variables.
However, we still need to create our own components as Foundation isn’t extensive. Our site designs include a lot of repeated components so it makes sense for us to create a pattern library which we can use alongside Foundation. It is important for us to make sure that our components are as clear and reusable as those in Foundation so that any member of the team can easily contribute.
We did some reading around pattern libraries and best practices. And we noted the following:
- If you give a pattern a presentational name its future will be limited as it will be confined by it style.
- A content pattern is very specific and can be restricting, a display pattern is more general and flexible.
- During the creation of a pattern library anyone can get involved at anytime, this helps to get everyone thinking about patterns at a granular level.
- Avoid writing code straight away.
The initial designs are ready and now need to be transferred to code…
Using our own take on Charlotte Jackson’s From Pages to Patterns Method, we broke down the designs into individual components.
We did this by printing out our designs and drawing on in colour each component.
We repeated this process until we had identified every element of the site.
Next, we quickly sketched each component and removed the placeholder content. By doing this we were moving away from a content pattern and more towards a display pattern.
Whilst we were sketching the components we came up with names for each element. We decided to use the BEM methodology to help us with our naming structure.
The names are likely to change over time as the site grows and evolves, but they will suffice for the time being.
The final step was to write the markup. This is what the HTML looks like for one of our grid squares.
Another benefit we have found by creating our components in this way is that it makes structuring our Sass files really easy. We have a Sass file for each component with the same name as that component. Which means a lovely, tidy codebase!
We need to repeat this process for all the identified components until we are able to create the layouts for all of our pages. Iterating and improving the process as we go.