Yesterday I talked about the work a design system for Marcus’ new site and how I organize things at a 10 thousand foot level.
Today I want to talk more about the details of the project. Specifically how I am organizing the project for the front-end build out + living styleguide. We are now descending to the 5,000 foot level.
Here I am using ZURB Foundation and the ZURB Template as a starting basis for my project, but the underlying technologies are interchangeable.
On projects I always create a private git repo on GitHub. This is critical because I have a revision history, can get other people involved with the project at will, and quickly share it with other team members and stake holders. Not to mention I have an offsite backup just in case thing go terribly wrong.
When I first approach a project, I always look at the design and try to think about how can I break it down into smaller patterns.
I ask myself questions like
- Is this a pattern that exists across the entire site? Examples: header and footer.
- Is this a pattern specific to a view or page? Examples: Special page flourishes or spacing. Custom hero’s with specific content, sizes and shapes.
- Is this a pattern that repeats on across several pages, but not across all of them? Examples: Promos, Related Content, etc.
Thinking about this holistically gives me a better idea of how to approach the project.
I do this before I write even a single line of code.
When starting with a brand new project, I might keep everything together in one file so that I can rethink the patterns and how I want to organize my components.
However, I don’t just have a mishmash of a disorganized mess. I make sure that things are more or less in some sort of logical order. When I work this way quickly, I will often leave a comment as a note to myself as to how to categorize the CSS below when I return to it.
At the end I want the same result. I nice logically arrange hierarchy of Scss files that gives a nice overview of the project.
Here is an example of the ~/src/scss folder in my git repo
In this case the app.scss is mission control for the CSS / Sass build. Here I have two directories pages and components. Pages are as you might imagine page specific. Components are not.
Here is how you might break down the questions from above:
- Is this a pattern that exists across the entire site? Examples: header and footer.
Components, helpers (or sometimes sitewide)
- Is this a pattern that is specific to a view or page? Examples: Special page flourishes or spacing. Custom hero’s with specific content, sizes and shapes.
Pages or Views
- Is this a pattern that repeats on across several pages, but not across all of them? Examples: Promos, Related Content, etc.
Components
Without even taking a look at the source code, you can already get an idea about the components that are used. The names should be descriptive and unique.
There is no need to over think the naming bit. #NAMINGISHARD is a popular slack channel for a reason.
Now this might seem to be overkill for a small project, but I assure you you will soon reach the point where things become the “overwhelm.”
This is when you are stuck with a tight deadline and a boat load of technical debt (aka not planning enough) and you push onward. Not great.
When you approach projects with some intentionality and forethought at the beginning, you make the process much more lightweight and maintainable. Even as you progress through day-to-day maintenance mode and make changes, this structure will provide a nice framework for future work.
Tomorrow, I will take more in depth by talking about the Sass file contents and how I have created them with clarity and efficiency in mind.