SCSS boilerplate with Bootstrap baked in

bootstrap

I know starter projects using Bootstrap are common enough, but I’ve added to the plethora this week by adding my own to Github in a public repo.

What is it?

It’s a dead basic project using Bootstrap which compiles all of Bootstrap’s SCSS plus your own SCSS styles into a single CSS file. It’s component-based, so useful features like buttons, forms, etc are in separate scss files for ease of finding. Because it’s all compiled as one big project using SCSS, you can @extend Bootstrap’s classes so you don’t have to add all their zillions of classes all over the place, cluttering your markup.

All the files are in the hierarchy I wrote about in this article.

Why?

I’ve been working on a few projects recently that all needed a sensible starting place. It saves all that setup time I guess. It’s not like this is amazing or anything. It’s just how I’ve started every project lately so thought it was handy.

Limitations

Bootstrap are bringing out new versions all the time. Therefore it won’t be long before my repo is out of date. I’ll maintain it for as long as it’s useful to me, but if you’re going to use it, check for a new version of Bootstrap first and potentially copy the files across. I always leave the Bootstrap folder untouched in every project, extending or overwriting the classes if I need to change them, in case the originals need to change.

See the GitHub repo here.

My 1st & 2nd games built in Unity

I’ve been spending a lot of my spare time recently creating a Unity 3D game. I’m still very much a beginner at the platform, and each game I work on feels like the first. I’m still learning, but getting faster with each project.

The latest project has taken me months already, fitting it in around work and other commitments.

But I’m not going to write anything about that yet (okay that’s a lie, I’ve written plenty about that over on IndieDB already – click here), because I haven’t yet blogged about the games I created first.

The 1st game – ReTardis

Because I was a total beginner, I started on a ridiculous project that wasn’t to be taken seriously at all (hmm, that sounds familiar, this applies to my 2nd & 3rd attempts too!).

I did add it to Newgrounds though, you can play it in the browser – click here.

The 2nd game – Starbug Thruster

Starring the spaceship from Red Dwarf, one of my favourite comedies as a teenager, this game was based on the physics used in my previous game, but simplified for mobile touch interface. You only have to touch the left or right of the screen to thrust up and in a direction.

I loved making this game, and based the story around Blue Dwarf, the text-based game I created many years ago, and which people still play (because it’s awesome, and the most rewarding game you can play).

I spent some time creating it for mobile, although abandoned that idea when I realised using a spaceship which is someone else’s IP isn’t a good idea. I might bring back the idea in a future game though. You can play this in the browser on the Newgrounds website – click here.

starbug thrusting starbug thruster hitting overhead beams Starbug thruster screenshot, knocking over boxes

The 3rd game – Attack of the mega turd from space

Yes. You read that correctly. This is another ridiculous game. It’s so ridiculous I wrote about it how ridiculous it is here.

Intended to be another silly learning experience, I’ve actually been putting a lot of effort into this game. And I’ve been learning a LOT. I think my next Unity project will be a lot quicker, as I now actually know what I’m doing.

Here’s a sneak peak of the progress:

progress of attack of the turd from space

Okay that screenshot doesn’t actually feature a turd. But there’s more to this game than the title.

I’ll be posting more progress and screenshots on IndieDB – click here.

 

My favourite CSS comment style

I wish I could say this post was an intellectual discussion on the the importance of creating guidance through your code. But it isn’t.

I’m posting it because I want a handy place to keep my favourite CSS comment style. Which is this:

/* ====================================================
CSS comment
======================================================= */

I like to use this as a separator for each section because it’s nice and clear.

If you’re interested how I like to split up my CSS, I’ve written an article about that (click here).

Why I think smartwatches will destroy cinemas

With smart phones getting bigger and turning into phablets it was inevitable that someone would invent a smaller device to use instead of the bigger one, to save you having to pull the TV-sized phone screen from your pocket. So that’s what we have now, smartwatches to save you the effort of looking at your smartphone.

I have 2 friends with smartwatches now, both different manufacturers but both have the same feature that the screen activates when you move your wrist in a certain way.

And that’s what I think is the problem. I was in the cinema at the weekend and my smartwatch weraring friend moved his arm slightly. He was probably only scratching his nose or something, but the watch activated the screen.

I noticed this because it caught my eye. I wasn’t annoyed or anything, but it did catch my eye and temporarily distract me from the film.

Right now smartwatches are rare, but imagine in only a short amount of time everyone has one, each watch face activating when someone scratches their nose. The amount of distractions could be unbearable! Especially irritating when you’ve already paid an extortionate amount to watch the film at the cinema, believing it to be a better experience than sitting at home, where ironically there isn’t a problem with a hundred smartwatches flashing around you.

This is why I think smartwatches will destroy the cinema.

…Unless we start to see signs saying “Turn off your phone AND your smartwatch”. Yeah, to be fair, that might save it.

Some awful #darkpatterns

I’m always on the lookout for examples of horrible examples of interfaces, especially websites with terrible user interface. I hate terrible user interface, in fact it’s more perverse than that, I LOVE to hate terrible user interfaces.

Really bad user interface that’s actually intentional is called a dark pattern. This is something that’s deliberately intended to mislead the user.

A colleague of mine found this example of a dark pattern recently and screenshotted it:

Constantly switching the context and switching positive and negative actions makes it confusing. 

 

Here’s another with confusing negatives intended to catch you out:

I think the worse example of a dark pattern is on the RyanAir website, where there’s a section asking if you want travel insurance. You don’t HAVE to buy travel insurance from them, but the way to opt-out isn’t all that obvious. You have to find the “Don’t insure me” option hidden amongst the countries of residence:

ryanair-website-ux3

I wonder how many people have unnecessarily bought travel insurance because they didn’t know how to opt-out?

You’ll find more stuff like this tweeted as #darkpattern and I’m going to try and opost any I find here under the category dark pattern.

I use BEM – A good clear naming convention

It’s not the most exciting skill in the world, but I like to think I’m pretty good at naming things. That’s because it’s so damned important to be clear and concise, or you risk confusion.

That’s why I use BEM.

Bem is great, although can get a bit wordy with massive long class names. But I try not to let it. It’s great because you can declare a reusable component, for example:

search {}

search__input {}

search__btn {}

search__label {}

And then use a standard BEM modifier (“–“) to make alternate versions, just by adding a new class:

search–vertical {}

…inheriting most of the styles but adding some overrides.

The best thing about BEM though is the specificness, and you’re absolutely certain the class hasn’t been used elsewhere. For example if I found a class like “full-width” I wouldn’t dare touch the css for it, in case it was inherited by something else tucked away on the website. But I know that “search–full-width” It’s pretty clear what that class is for and where it’ll be used. It’s just clear naming really.

My CSS layout – group by component, not by screen-size

I read an interview with Eric A Meyer today, who is supposedly the “Godfather of CSS wisdom”, and one thing that stuck out for me is how he structures his CSS files. He says:

I usually organize my CSS by section of the layout, so the header styles are all together at the top of the CSS, the page-content styles are in the middle, and the footer styles come at the end. Then I do my media-query blocks, with the same internal organization.

No, no, no Eric! The first bits seem fine, but don’t group your CSS by screen sizes into different media queries! I have to say I’m a little bit confused why anyone would do it that way, splitting your entire stylesheet into sections wrapped in different media queries. It’s like building the website multiple times over.

I tried to explain this in an older article (see it here), but wasn’t too clear so I’ll have a go at explaining the reasons why I think you should avoid grouping by screen size, and what I do instead, which I actually think is much easier (although obviously do whatever suits you and your project!).

1) Working on the file – and tracking down the distant sections you need

Okay so I’m assuming you’ve got a mobile-first website (and if you’re not using mobile first, you should be!). And if you’re doing it Eric’s way you’ve got at least 2 separate chunks of CSS, styles for mobile (including default styles), and the styles for desktop separately. Between them you might also have media queries for in-between, tablets or small browser windows on desktop. So if you’re using Eric’s method, to change any component on the page, say… the footer, you’d have to skip between distant sections of the same document to add styles.

2) What if you want to target a different screen size?

Okay so you have the very specific styles for mobile, tablet, small and large desktop screens. But what about this, a new device comes out which your client/boss tells you is a big deal. The website HAS to look awesome at this particular size and aspect ratio. Not just acceptable – awesome.

So Eric’s method, he has to create an entire new media query section, slipping it in between the others. What does this do to your mobile first approach? Well you’ll have to leech some of the styles from the larger media query perhaps, and maybe add a few more very specific ones for that size range. Seems like your nice flow of mobile first to larger has just got a bit more bumpy.

My flow – 1) Generic to specific

The method I use was taught my CSS Wizardry’s Harry Roberts in a workshop in London a few years ago. I’ve changed it slightly to suit me, but I think the flow is pretty solid.

He starts with a triangle, because that’s a good way to imagine the best way to write CSS, from the most generic to the most specific, ending with some “trumps” which is essentially allowing for some hacks right at the end.

harry roberts css flow

His triangle needs a bit of explaining – Settings & tools are where you’d define variables and include CSS mixins, maybe your frameworks. Objects and components are things which are reusable throughout the website. Harry explains the rest here, go read that because it’s excellent, and it allowed me to come up with what works for me…

My flow – 2) Files I include

  • Framework
    • For me this is Bootstrap
  • Variables
  • Mixins
  • Animations
  • Global styles (fonts etc)
  • Components
    • Header
    • Footer
    • Menus
    • etc
  • Specific layouts
    • Home
    • About
    • etc

This order allows you to build reusable components, then if you need a specific alternative for a certain page, you can make a slightly more specific version without having to create a brand new version.

An example of this is all buttons (I like to use the class .btn) might be the same size colour and padding, except on the login page where you can make them all a bit bigger easily using a bit more specificity.

.login-layout .btn {}

Including separate SCSS files

Each of the above is a separate SCSS file, included into the styles.scss, which is where I’ll have global styles for typeface, font sizes, all the basic stuff for the entire site. This works for every project I’ve done recently.

I compile all of these into a single css file, including the entirity of Bootstrap which I do so I can extend some of its classes and use its mixins. It’s all included in the order above, with the most generic items able to be extended further down the line.

One cool thing about SCSS is that if you prefix the filename with an underscore, it doesn’t try and compile the file separately, it know it’s an include file only.

But what about the media queries?

One thing I didn’t mention in the list above is the media queries. That’s because I don’t have a specific place for those. They’re intermingled around the entire thing. If you’re not used to that, you might think it madness. But honestly it feels a lot more organised than the alternative. If you want to work on the _header.scss, all the header styles are right there in one place, and you don’t have to go chasing them down.

I use BEM too, but I’ll explain that in another article!

Mystery meat & hidden salad

Mystery meat – A term given for an option that you don’t know what it’ll do until you choose/select/click it. The metaphor as I underswtand it: You’re choosing tinned meat, but don’t know what’s inside until you buy it and open it.

I especially hate this used in navigation, where in recent years it’s become common practice to replace words with icons, to easily translate the interface into different languages, and fit more onto the screen for mobile.

Hidden salad – I went to a resetaurant recently and asked for a side salad with my burger instead of fries. The burger wasn’t supposed to come with a salad, so I expected to pay extra. As it turns out, the salad WAS a legitimate option, but a hidden one.

“Hidden salad” is what I call options that are valid but completely hidden from the user. Similar to mystery meat but instead of being presented with a cryptic option, you’re not given any option at all until you discover it. This is used especially in interfaces where you have to type, like command-line tools (which I especially hate). Or a more fun use might be Google’s hidden easter eggs.

WordPress have ditched the title tag in links

WordPress have previously always asked for title text when adding a link, but from version 4.2 they’ve abandoned this.

LinkmodalChange…Which is quite a good thing imo.

I wrote an article about how bad the title tag is for accessibility, because some web developers assume this is read aloud by screenreaders, bit it isn’t. I wrote an article about this here: I thought title tag improved accessibility, I was wrong.

I learned this after pretending to be blind for a week, and learning how to use a screenreader. I learned loads, and recommend every web developer to do the same!

Image above is from this article which is where I was first alerted about WordPress’ change.