DEV Community: Mac Daniel

How I Structure my SCSS Projects to Keep Myself from Going Insane

Mac Daniel — Fri, 04 Oct 2019 12:32:54 +0000

We can't install SCSS and expect a web project to just magically fix itself, unfortunately. With all the designs I’ve built from scratch in HTML and SCSS, I’ve come to realize that structure is the underlying concept that makes projects easy to maintain, provides clarity, and ultimately keeps me from losing it. Ha-ha!

Okay, since I'm a designer, this structure is based off of Atomic Design. If you aren’t familiar with it, it’s basically having smaller components be combined with other smaller components to build bigger ones until you’ve built the pages of the website.

However, note that I’ve changed some of the terminologies because I'm weirded out by saying molecules and organisms in my projects. I prefer to use more accessible terms for people who are not necessarily designers and coders but are possibly concerned about bits and pieces in the user interface.

High level folders and files

It’s important to note that the main folders need to sort out neatly in the hierarchy to make browsing files a breeze. The folders are arranged from the non-tangibles to tangible elements of the website.

/abstracts
/atoms
/blocks
/components
/frames
/pages
css.scss

At least in my case, this arrangement makes pointing to a particular location more obvious. And as a UX designer, I can't stress this enough. I once worked on a project where all partials were stored in a single directory so we ended up constantly navigating a long list of unsorted files. Fun!

Abstracts

Abstracts contain rules and functions that govern the styles but are not visually tangible all by themselves. Rules and properties like text alignment, layers, and positioning shared among the more tangible elements are considered abstracts.

/abstracts
    ∟ /mixins
    ∟ _alignment.scss
    ∟ _animation.scss 
    ∟ _appearance.scss
    ∟ _layers.scss    
    ∟ _layout.scss    
    ∟ _positions.scss 
    ∟ _sizes.scss

Atoms

Atoms represent the smallest tangible elements in the website like colors, fonts, and icons. They are visually rendered in the page but need other atoms to make them look right.

/atoms
    ∟ /colors
    ∟ /icons  
    ∟ /images
    ∟ /typography
        ∟ _fonts.scss
        ∟ _sizes.scss
        ∟ _styles.scss

Blocks

Blocks are a combination of one or more atoms that visually render elements in the page. Buttons, which could be a combination of text, color, and icon, are considered to be a part of this group— the building blocks of the website.

/blocks
    ∟ _buttons.scss
    ∟ _cards.scss
    ∟ _labels.scss

Components

Components are the more prominent features of the website which can stand on their own and be reused in different pages.

/components
    ∟ _article.scss
    ∟ _feed.scss
    ∟ _footer.scss

Frames

Frames contain the bigger layouts that hold components into place. These include the main-aside combos, grids, sections, and wrappers.

/frames
    ∟ _columns.scss
    ∟ _grids.scss
    ∟ _sections.scss
    ∟ _wrappers.scss

Pages

Page-specific styles are made in this directory. These could contain either supplementary styles or overriding styles.

/pages
    ∟ _about-us.scss
    ∟ _products.scss

If you feel like this is something you can use from now on, the next step is pretty much breaking down your design into this hierarchy. Conflicts are expected to arise especially if Atomic Design wasn't observed in the design phase.

By adhering to this, you might be knowingly and unknowingly encouraging rules and guidelines which could improve consistency and quality.

For example, you could set a margin rule for a component being used in different parts of the website. Because the space around that component could be unpredictable, and you might not want to target that component every time just to apply a bottom margin, you could implement utility classes as a rule.

So instead of overriding properties like:

.component { margin-bottom: 15px;}
.container > .component { margin-bottom: 25px; } 
.container2 > .component { margin-bottom: 45px; }

You could just do something like:

.component { // no margins specified }
.mb-sml { margin-bottom: 15px; }
.mb-med { margin-bottom: 25px; }

Then in HTML:

<div class=“component mb-sml”></div>
<div class=“component mb-med”></div>

Still, I would say that it will take you a couple of tries and a deep understanding of what you’re working on before you could finalize these rules. After all, there's usually more than one way of doing things. Don’t forget to document your code thru comments so that it’s easier to make tweaks and minimize the learning curve for the newcomers.

The project base is available on GitHub with a little styling for you to explore and use. Feel free to build on it and let me know your thoughts in the comments so we can all make the CSS process better for everyone.

xavierpdaniel / scss-project

A standard SCSS project structure

Moving into Vue.js

The main difference I have right now as I’m learning Vue.js is that I move the SCSS component partials to each their own Vue components.

I also have to generate a base.scss in the SCSS folder which I then import into those components to serve as abstracts.

/src
    ∟ /assets
    ∟ /components
    ∟ /scss
        ∟ /abstracts
        ∟ /atoms
        ∟ /blocks
        ∟ base.scss

So in the Vue component:

<template></template>
<script></script>
<style lang=“scss”>
    @import “../scss/base”;

    .component{
        //some properties
    }

</style>

Aaand that's it. I hope you find this useful. I'll catch you guys on the next one!

3 easy-to-apply CSS improvements that you can use in your project right now

Mac Daniel — Mon, 30 Sep 2019 23:36:06 +0000

CSS can be messy, and it usually is whether for the lack of conventions or well thought-out systems of doing things. This is why easy fixes with little to no effort is a breath of fresh air in a project that could be suffocating on a bloated code.

Font Loading

If your project was created before May of 2019, you probably don’t have a font-display property set for your Google fonts. Font display defines the way they are loaded (Here's a demo with simulation). For me, swap works best to assure that text content are loaded immediately while the actual font is still downloading. Other values are none, block, optional, and fallback.

The easiest way to do this is add the &display=swap at the end of the import link.Like so:

@import url('https://fonts.googleapis.com/css?family=Roboto&display=swap');

or if you’re hosting the fonts yourself:

@font-face{ font-family: ‘Roboto’; font-display: swap; }

Buttery-Smooth Scrolling

Divs with scrollable content are a staple of websites to manage larger content without using significant amount of screen real estates. However, you might notice that in iOS, scrolling through these divs could feel glitchy and a bit unresponsive.

You may dd the -webkit-overflow-scrolling property to improve it.

.scrollable-div{ overflow-y: scroll; -webkit-overflow-scrolling: touch; }

Empty Elements

With components whose content are generated thru tinyMCE, say article body content, I always run into the problem of editors unmindfully adding unnecessary line-breaks.

.article p:empty { display: none; }

In this case I target the empty paragraphs inside the article. With this I can effortlessly get rid of them and at the same time maintain the visual rules of the website.

Do you have other easy CSS hacks for existing projects? Share them in the comments below. I'm all ears!

I'll also be sharing Easy-to-apply CSS before starting a project. Stay tuned if you're interested.

An Incredibly Easy Way to Manage Layers in SCSS

Mac Daniel — Sat, 28 Sep 2019 02:53:43 +0000

If you’ve come across websites that uses 0, 1, 999, 99999, 9999999 as z-index values, then you’ve probably already guessed that the layers have been arbitrarily arranged and therefore poses the imminent headache of maintaining those websites in the future.

The way I manage layers is thru SCSS placeholders. Assuming I have a couple of layered components to deal with, I extend a placeholder with the same class name but prefixed with %layer-.

.nav{
// some properties
    @extend %layer-nav;
}
.dimmer{
    // some properties
    @extend %layer-dimmer;
}
.modal{
    // some properties
    @extend %layer-modal;
}

Then, in a separate SCSS partial called _layers.scss, I lay these placeholders down, each in a one-liner manner so I can easily glance over the layers and their corresponding values.

%layer-nav  { z-index: 10; }
%layer-dimmer   { z-index: 11; }
%layer-modal    { z-index: 12; }

I also don’t mind extending the placeholder in different components first before declaring them because the compiler shall indicate some errors which I use to easily encode them in the layers partial file later on.

And that’s pretty much it. Because z-index values are implemented as placeholders, we don’t need to constantly revisit components just to adjust the values. We also don’t have to put a lot of comments to note how one thing affects another. And most importantly, we don’t have to jump tens and hundreds (or even thousands) of units just to make sure a box appears on top!

It’s also worth noting that in this implementation of @extend, sharing the same placeholder across multiple components may not be the best idea because of the naming convention.[EDIT] You're better off using variables in this case, as pointed out in the comments below.

I hope you guys find this useful as I have. Let me know what you think or if there’s an even easier way, feel free to share. I’ll be sure to check it out.

What do developers wish designers knew?

Mac Daniel — Thu, 08 Aug 2019 15:01:44 +0000

With an increasing number of designers and developers being more and more collaborative, I still read and hear a good amount about the gap these teams have in the process.

In hopes of bridging the gap and finding the missing pieces of the puzzle, I ask: what are the things developers wish designers knew?

What are the pain points being disregarded (knowingly and unknowingly) by design teams to give way for their visual pursuits?

And how can we improve our dynamics as teams working on the same product?

Your insights will be greatly appreciated and shared.

5 Realizations About Speaking (after attending a painful developer meetup)

Mac Daniel — Mon, 05 Aug 2019 03:59:14 +0000

Yesterday I attended the worst tech talk I've been in. It's a developer meetup-turned-workshop in Makati. As a designer learning Vue.js, I came in more of an observer so I already saw it not going so well for me. I really just wanted some perspective and to be able to say at least I tried. The thing is, even the developers in the audience couldn't quite understand what was going on.

It wasn't the venue nor the general topics that made the talk horrible but the way the speaker handled it. And instead of listing down what went wrong here are my five realizations about presenting/speaking, validated by the lack of them in yesterday's event.

1. Structure is everything

It's important to setup and communicate how everything will fit into the equation. A speaker shouldn't just randomly pursue ideas. He/she must specify the journey from point A to point B and the topics needed therein.

A talk/course outline needs to be presented to the audience. It's not just 'old-fashioned' but it's effective in marking milestones for the audience. It gives a sense of how far along the discussion is and how much more is to be discussed.

There should also be a sort of learning model to make things more predictable for the curious audience. For example, a talk could be broken down in a Principle-Example-Hands-on pattern which allows for a consistent flow. The speaker could first introduce a core principle before giving real-life examples related to the audience's work situations before allowing them to try it themselves.

It could also start with the endpoint (point B) making the audience understand WHAT they can achieve, and then break it down so they know HOW to arrive at such an output.

2. Know your audience

It's pretty much a no-brainer but I'm always surprised how many speakers disregard this. Knowing the audience either ahead of time or on-the-spot gives speakers an idea of pace and tone required for the talk.

Are they formal or casual? Are they timid or outspoken? Are they beginners or experts?

If the audience are adults, the talk needs to be practical and should directly convey its importance for adults that could be busy about their family, business, and other responsibilities. The value proposition should be obvious and upfront.

If the audience is a mix of experts and newbies, the speaker has to find the middle ground and make sure they're not heavily favoring one over the other.

3. Rehearse the presentation

I can't imagine the cringe people feel whenever a presentation is obviously rushed and unorganized. Good presentation just makes sense while bad presentation sticks out like a sore thumb. It's the responsibility of the speaker to make sure that the flow of ideas and the sequence of topics effortlessly moves the talk forward.

The speaker could impart relatable stories and sometimes jokes to break the monotony. Avoid using Google as a visual aid.

The speaker shouldn't set himself/herself up to fail and be caught in a situation he/she can't resolve.

4. Be mindful of time

Respect people's need to go to the comfort room, take breaks, and leave on time. A speaker should communicate that these are allowed and that some breaks occur at specific times.

Being mindful of time also help the speaker in identifying the scope of his/her topic.

5. Gather Feedback

As with anything interactive, speakers need assessment. They need to have feedback forms ready before dismissing the audience at the end of the talk. You never know how you did, or there could be unanswered questions that the speaker could have attended to if not for the lack of time. Giving people the option to rate and give speakers feedback imparts a sense of openness which is a quality of a good speaker.

In the end, it's important to assess ourselves as speakers. Good speakers can turn complex ideas into simple blocks that the audience can easily understand and play around with. Good speakers can turn things around to aid the dynamics of the audience while at the same time adhering to structure. And lastly, they should seek to inspire - making the audience feel that the effort was worth it.

What other pointers would you add to these?