Design to Code: Colour 101

Design to Code is a collaborative blog column where awesome graphic designer Alicia Carvalho will teach you about a design concept and related tips, tricks or resources, and then I’ll tell you how it can be applied to the web. This week is all about colour!

dtc_colours

Alicia says…

Let’s talk about colour! I believe everyone is familiar with the basics of colour wheels so I will jump right in and explain how colour works in design from a printing perspective, how it translates onto the screen and then Dara will continue the online exploration.

Most colour printing is done in CMYK; Cyan, Magenta, Yellow and Black. These colours are called process colours. Each of these four inks is stored on a separate tray in the printer and combined directly on the paper. Process colours can be printed in tints, ranging from solid to 0%. These tints are achieved by varying the density of tiny dots used in the printing process. Since processed colours are nearly transparent and you can create a large number of tints, it is extremely easy to create a super broad variety of hues.

Spot colours, also known as Pantones, are also very commonly used in the printing world. Unlike CMYK, which mixes a colour on the paper via layering, spot colours are custom pre-mixed colours. Think of Pantones like the big buckets of paint you would buy at Home Depot to paint your bedroom. They are pigments which have been specifically measured to create one very specific colour. Much like process colours, spot colours can also be printed at various tints.

Spot colours are often used for brand logos. An uncalibrated printer may not always print a processed colour exactly the same, but a spot colour will always be spot on. Get it, spot on? If your logo is made up of one spot colour and black it may be more affordable to print it as a two colour job, as opposed to four colour job (CMYK).

You know how sometimes you have something on your screen and then when you print it the colours look much duller or even darker? This is because screens don’t use CMYK so you can’t accurately predict what something will look like on paper. Unlike printers, who use physical ink, your computer screen uses light to display colour. All digital colours are defined through Red, Green and Blue, RBG. Similar to CMYK, RBG can be a solid or a tint, measured through the values 0 to 255 (255 showing the hue at its purest). When you go to print something make sure you change all your colours to CMYK since RBG can’t be printed on paper.

Keep in mind that every monitor will display colour differently, unfortunately there is no magic screen-colour-standard setting. If you are making the links on your website a very light grey you may want to test it out on a few screens. Your safest bet is to not go too light on anything important, as it may disappear on super bright screens.

feJlNDY5_biggerDara says…

Like Alicia just mentioned, colour on the web works differently from colour in print. While most colours in print (aside from spot colours) are made by combining cyan, magenta, yellow and black inks, colours on computers are made by combining red, green and blue light together to create millions of different colours.

There are a few different ways to use colours on the web through CSS. First, let’s check out the old school ways:

Colour names

Did you know that CSS contains a bunch of preset colours that you can call on by name? Some of them are actually pretty nice!

Check these ones out:

PaleVioletRed
PaleTurquoise
MistyRose
Thistle
and OldLace

Using these colours is as simple as this:

.thing-youre-styling {
    color: MintCream; /* or background-color, or border-color */
}

You can check out the built-in CSS colours here.

Hex colours

These are probably the types of colours you’re most familiar with on the web. Hex colours are made up of six numbers — the first two are the red values, the second two are the green values, and the third two are the blue values, because, as Alicia explained, on-screen colours are made up of red, green and blue! RGB colours are measured from 0 (none of the colour) to 255 (the strongest intensity of the colour), and the Hex codes values, which are are written in hexadecimal, go from 00 (0) to FF (255). That’s why pure black is #000000 (none of any colour) and pure white is #FFFFFF (since red, green and blue light combined make white).

Here’s are the colours we looked at before as hex codes:

#D87093
#AFEEEE
#FFE4E1
#D8BFD8
and #FDF5E6

Unlike the predefined CSS colour words, the colours you can make with hex codes are nearly limitless. Well, to be precise, there are exactly 16,777,216 different colours (256 red values x 256 green values x 256 blue values).

A little side note about “web safe colours”

It’s the year 2014, and amazingly, I still sometimes hear people talking about “web safe colours”. Back in the ’90s, many monitors would support only 256 colours, so to make sure that your colours would show up properly on people’s screens, you had to stick to an extremely limited (and slightly unfortunate-looking) colour palette. Nowadays, almost all screens support millions of colours, so the idea of “web safe colours” is no longer a thing. Whew!

Transparency on the web and newer colour formats

Hex colour codes are kind of hard to remember. What if there was a colour format that just used the RGB values from 0 to 255 in a straightforward way?

Oh, hey, there is!

You can also declare your colours like this:

.thing-youre-styling {
    background-color: rgb(175, 238, 238);
}

This is pretty intuitive – the three values, like before, stand for red, green and blue, with each of them being a number from 0 to 255.

Modern browsers let you add a fourth value for transparency, which is pretty handy, and that’s called RGBa. The transparency value is between 0 and 1, with 0 being completely transparent, and 1 being completely opaque. That looks like this:

.thing-youre-styling {
    background-color: rgba(175, 238, 238, 0.3);
}

I’m a background with RGB colour

And I’m using RGBa with the exact same colour. Translucent goodness!

The new, cool kid on the block: HSLa

Hex colours, RGB, and RGBA all use the same model to declare a colour: R, G, and B values from 0 to 255. What if there was a new, cool way?

Oh, hey, there is!

HSLa is really different. It accepts four values:

H is for hue. This is a number from 0 to 360 (think of it like degrees of a circle)
S is for saturation. This is a percentage from 0% to 100%.
L is for lightness. This is a percentage from 0% to 100%, where 0 is black and 100 is white.
A is for transparency, just like in RGBa. This is a number between 0 and 1.

To wrap your head around HSLa, check out this HSL Color Picker. This lets you change all the colour values on the fly, and it also returns the hex and RGB colours. RGBa and HSLa are supported in every modern browser so feel free to start using them! If you’re still supporting IE8, you can use a fallback to a hex or RGB value.

Now go forth and make some awesome colours!

Reflections on a year of pricing projects

9062011476_fc223a2f90_b

Pricing your products or services can be pretty hard, right? I’m guessing that most self-employed people can relate to this, especially at the beginning of their careers. How much is too little? Too much? Do you charge an hourly rate? A fixed rate based on estimated time? A fixes rate based on value? Of course, as we all know deep down, there are no clear answers to these questions, and everyone does things a little bit differently anyway.

I’ve been running my business full time for almost a year now (!) so I’ve had a bit of time to try different things. After accumulating almost year of data on pricing my projects, I finally put it all together last week and analyzed it by taking each project and comparing how much time I estimated it would take, how long it actually took, how much I charged, and how much I really made per hour I worked on it.

What I found… was a little surprising.

First, a brief note on how I priced my projects this past year

About a year before I went full-time, I started to use fixed pricing based on time instead of billing by the hour, which is how I started off. That means that I would imagine how long the project would take, multiply it by an appropriate hourly rate, and that would be the price. If a project took less time than I’d anticipated, hurray! If it took more time, then oh well, my fault for estimating poorly.

This past year, I took a fairly similar approach, but with a couple of refinements. Instead of scoping each project from scratch, I created an internal price sheet to save myself some time when quoting similar projects, and I used a multiplier for complexity. When I got the sense that some projects would be more challenging than others (for whatever reason), I bumped up my quote, knowing that they were likely to take more of my time and energy. At this point I’m really interested in value based pricing, and am currently working on implementing that in my business.

And now, my main takeaways

Track your time like your life depends on it

When you’re charging fixed prices, tracking your time can feel like frivolous pain in the ass. But, if you don’t, you won’t have the proper data to refine your business practices, and every pricing change you make will be based on guesses. That’s no good! When I worked at Jet Cooper, I was sometimes a little lax about my time tracking, and I feel badly about it now that I understand how important it is. SORRY, GUYS!

I use a really simple app called TimeKeeper, which lets me tag every time entry both by project and by task type. It’s almost perfect for my purposes, aside from the fact that it doesn’t sync to Dropbox automatically. C’mon, TimeKeeper devs! Get on it! (Plz?)

Coding my own designs takes way less time than coding someone else’s

I take on two main types of projects: full websites (design and development) and development only. When I was putting my price list together, I came up with base prices for design and base prices for development, which seemed to make sense at the time. This means that I was scoping developing my own designs exactly the same way I scoped developing other people’s designs.

BIG MISTAKE!

After “crunching the numbers”, as they say, I found out that sites I designed and developed sometimes earned up to three times more per hour worked than developing sites by other designers. That, friends, was pretty shocking, though when I think about it, it really shouldn’t have been. I didn’t take the additional complexity of working with another person into consideration, and I didn’t think about the fact that I would never design something that I knew was impossible (or just irritating) to code, so I would never be putting myself in a difficult development situation. If that wasn’t enlightening enough, I then found out that…

The least fun projects were generally the most lucrative

Wait, what?!

This really surprised me when I saw this pattern, but then I thought about it for 5 seconds and realized that it actually makes a bunch of sense. I think we all have a tendency to overestimate the time and difficulty of something we’re not as enthusiastic about, and underestimate the things that sound like fun. Though this is a totally natural thing to do, it essentially means that we’re rewarding ourselves for taking on projects that we’re not too fond of. That’s a little backwards, isn’t it? Oops!

In conclusion…

When you’re running your own business, every day is an opportunity to learn something! Also… track your damn time.

Design to Code: Serif vs Sans Serif

preview_serifvssansserif

Hey, everyone! After getting lots of positive feedback on our Design to Code column concept last week (thanks! we really appreciate it!), we’re excited to be posting our first installment this week! We decided to start with the very basics and talk typography, beginning with serif versus sans serif fonts (plus some other basics about how to embed fonts and where to find them, so if you’re a beginner, this one will be perfect for you).

This one is posted over on Alicia’s blog, so check it out!

Introducing… Design to Code!

Happy Wednesday, everyone!

I’m excited to announce that I’ll be collaborating with awesome graphic + web designer Alicia Carvalho on a new blog column called Design to Code. Every few weeks, Alicia will teach you about a design term and some related tips, tricks or resources, and then I’ll tell you how this design concept can be applied on the web.

dtc-logo

We’ll be taking turns posting the column on our blogs, so make sure to follow both Alicia’s blog and mine to get each instalment and learn how to improve your designs and apply your new skills to your own website!

Developer Tip Tuesday: Always develop locally (part 2)

Part 2: Software!

At last! The very long-awaited (oops) sequel to my previous post about why it’s so important to develop websites locally. In my first post I gave you the theory, and in this one I’ll give you some more practical information.

This post is going to focus on developing WordPress sites, because if you’re developing something more complicated than that, you probably already know enough about local development, do everything via command line, and don’t really need me! ;D

Running the local server

As you’ve probably already figured out, WordPress is written in PHP, which is a server-side language. This means that the website has to communicate with a server in order to display the pages, unlike a static HTML website. WordPress, like most content management systems, separates the site’s structure (which is PHP-based) from its content (which is stored in a MySQL database). The server is what brings the two together, and this is why you need a server with PHP and MySQL to run WordPress.

I personally run my local servers by using a program called MAMP. The WordPress Codex (aka your new best friend) has a good article about how to set up WordPress with MAMP. If you’re not using a Mac, you can use XAMPP for Windows, which works similarly. If the Codex is a little too dry and/or confusing, there’s a great screencast over at CSS Tricks on this very topic! Essentially, MAMP (or XAMPP or one of the other alternatives) sets up Apache, MySQL and PHP on your computer, which lets you run a local server that you can access, but that isn’t online for everyone else to see.

One drawback of the free version MAMP is that you can only have one local server running at once, and its address is always localhost:8888, which can be fairly limiting, especially if you’ve taken on multiple projects at once (story of my life). If you’re going to be developing locally a lot, I’d recommend shelling out for MAMP Pro, which lets you run an unlimited number of local servers and name them whatever you want. I use MAMP Pro, and all of my local sites are named [sitename].dev. These local URLs are really easy to remember, and way sexier than localhost:8888… am I right?

Edit! Thanks to @Wordius on Twitter for reminding me that even in regular (free) MAMP, you can have an unlimited number of sites — they’ll all just reside at http://localhost:8888/[insertsitenamehere]. I prefer having separate local domains for each installation for a variety of reasons, but it’s not entirely necessary, especially if you’re just starting out.

This is my MAMP screen, and to the left are the zillions of local installations I have set up right now (including a local version of my own website, where I test all of my changes first before they go live). And no, don't worry, I'm not working on them all at once!

This is my MAMP screen, and to the left are the zillions of local installations I have set up right now (including a local version of my own website, where I test all of my changes first before they go live). And no, I’m not working on them all at once! I might be crazy, but not thaaaat crazy.

I’ve recently heard of another (free) program called AMPPS that provides similar functionality to MAMP. I haven’t tried it myself, but it may be worth looking into. If you’ve used it, let me know what you think!

Developing the actual site

As I mentioned in my previous post, one of the biggest advantages of coding locally is being able to use a nice text editor with syntax highlighting to do your work (as opposed to the horrors of the WordPress built-in editor), which lets you easily undo any catastrophic changes that you may or may not make. The best part about developing locally is that you’re never breaking anything that anyone else will see. It’s pretty nice when you take that pressure off yourself!

My current editor of choice is Sublime Text, which I’ve been using for about a year now, and it’s a real pleasure now that I’m used to it. I appreciate that it gets out of the way and lets me code in peace, but also has a ton of useful functionality under the hood. Before using Sublime Text I was a huge fan of Espresso, which has a really beautiful, friendly interface and some nice extra CSS features, like a built-in gradient generator. I only switched away from Espresso because I was doing a bunch of work with Sass and Haml, which Espresso didn’t support very well. You snooze, you lose, Espresso!

Leveling up your dev environment

One of the other joys of local development is being able to live reload your changes without having to manually refresh the page in the browser. Right now I’m using CodeKit for this purpose (as well as for using Sass, which is so awesome and useful and time-saving that it deserves its own post). Once you get used to seeing your changes happen in the browser without having to refresh, you can never really go back. I have a nice, big display, so I often have my code editor open on one side of my screen and the browser on the other, like so:

This resized image doesn't convey the majestic nature of having a 27" display. What is this, a display for ants? It needs to be at least three times this size!

This scaled-down image doesn’t convey the majestic nature of having a 27″ display. What is this, a display for ants?

Adding your WordPress project to CodeKit is super easy. With your CodeKit window open, click on the plus sign in the bottom left hand corner, and click “Add Project…” and find your WordPress theme directory (the one inside /wp-content/themes/). Open the directory, and now CodeKit is monitoring your work and will live-reload all of your changes (as well as run CSS pre-processors if you choose, minify your JavaScript, optimize your images, and all sorts of other stuff). Easy!

Like so!

Like so!

Okay, that’s cool, but now how do I get my local site on a real server?

Glad you asked! Since this post is nearly 1000 words at this point (!), it’s probably best to save that for another time instead of putting you to sleep by continuing this epic saga. In the meantime, I’ll refer you to another very helpful screencast at CSS Tricks that will walk you through this process. What this video shows is basically what I do (though I think I do a couple of things more efficiently) so definitely take a look and see if that helps you.

Till next time!