Awesome Tools for Designing in the Browser

A bad workman always blames his tools. – Proverb

One of the biggest complaints I hear about designing in the browser is that designers do not have the tools they need to create good designs. Even though I think that mindset has many flaws in it, I want to focus on only one part … the tools.

While many may might not be aware, there are so many great tools out there to help create beautiful fluid designs within the browser window. These tools have been created by other designers and developers that faced the same issue. The tools that they have created turn an ordinary browser into a grid displaying, typography pumping, color blazing machine.



Gridlover gives you adjustable css for font sizes, line heights and margins. The default css output is for body, p and h1 – h4 headings, but you can of course apply your adjusted values to any element by editing the css later.



Looking for an easy way to overlay a baseline grid on any webpage? Baseliner is a JavaScript tool that can do just that.


Adobe Color CC

Adobe Color CC is a fun and simple way to capture inspiring color combinations wherever you see them.


Viewport Resizer

Viewport resizer is a browser-based tool to test any website’s responsiveness. Just save the bookmarklet, go to the page you want to test, click on your created bookmarklet and check all kinds of screen resolutions of the page.



Typekit is a subscription font service that brings thousands of fonts from foundry partners into one library for quick browsing, easy use on the web or in applications, and endless typographic inspiration.


Google Fonts

A web with web fonts is more beautiful, readable, accessible and open.

Google Fonts makes it quick and easy for everyone to use web fonts, including professional designers and developers. We believe that everyone should be able to bring quality typography to their web pages and applications.



When it comes to the web … this is a tool … so use it like one!

Available for both Windows and Mac, Adobe Photoshop is an extremely powerful application that’s used by many professional photographers and designers. You can use Photoshop for almost any kind of image editing, such as touching up photos, creating high-quality graphics, and much, much more.



When it comes to the web … this is also a tool … so use it like one!

Sketch gives you the power, flexibility and speed you always wanted in a lightweight and easy-to-use package. Finally you can focus on what you do best: Design.

Access Your MySQL Server Remotely Over SSH

When working on a client’s site, I usually have the privilege of having access to something like cPanel. From cPanel I then can access things like phpmyadmin and file manager. Using tools like this has always kept my life simple.

A problem arose, however, last week where I needed to get ahold of a database so that I could set up a local staging site. The issue was that the only credentials the client was able to give me was their SSH credentials. My gut instinct was to email them back saying that I needed more access, but then my inner adventuring self came out.

Over the last couple of years I have been pushing myself more and more to use the command line instead of GUI’s. The main reason for that is because I believe using command line gives you a better understanding of the things you are actually working on. This is what led me to my plan in this situation: to access the MySQL server remotely over SSH.

Luckily I work with incredibly smart people who I know if I don’t know how to do something, one of them will. Due to that I sought out one of the guys that I know is strongest in command line. In the matter of minutes he was able to help me get what I needed with only TWO COMMANDS!

In case anyone is wondering how to do this, please keep reading.

Before you Start

Before you start you will want to make sure you have the following information:

  • SSH host
  • SSH username
  • SSH password
  • SSH port number (if applicable)
  • MySQL database name
  • MySQL username
  • MySQL password

Running the Commands

Once you have that information you will want to launch your command line application of choice (I prefer iTerm 2 for Mac). After you have your application running, you need to run this command:

The syntax is ssh <username>@<servername> -L <localport>hostname<remoteport> -p <portnumber>. The reason we use 3307 for the localport here is due to the fact that you might be already using port 3306 depending on your setup.

Things that you need to replace:

  • username – this should be replaced with your SSH username
  • host – this should be replaced with your SSH host
  • (port_number) – this should be replaced with your SSH port number

Once you have done this you should be asked for your SSH password. When that comes up, insert your password and hit enter.

Now that you are in, in order to get a MySQL dump you can run:

Things that you need to replace:

  • mysql_username – this should be replaced with your MySQL username<
  • database_name – this should be replaced with your MySQL database name
  • filename.sql – this should be replaced with the name of the file you want the data to be dumped into

Once you run that command you will be prompted for your password. This is now referring to the MySQL password.

WAHLA! You now should be able to find that file inside the current directory. In most cases that is /home/(mysqlusername)/(db_name)/. You can access this via SFTP.

In the End

In the end this was a great solution for me. I’m sure there are even more advanced command line wizards that know of even better ways to do it. With that said, this worked for me. I believe that due to the simplicity of it, it works pretty well. I hope you find it helpful!

Designing in the Open

A few friends of mine have recently asked me why I have not taken the time to design my blog. I am a web designer after all … right? Whenever I am asked that I point them back to my original post: Get Off Your Butt (PT 1).

For years now I have been wanting to blog so that I can do my best at giving back to the community just as so many countless others have done for me. The problem was I could never find the time to design it, so I always made that my excuse for never doing it. This crushed me and so a few weeks back I did something about it. I went to and in the matter of 10 minutes I had a blog (Thanks to the Automattic team for being so awesome)!

Even though I have gotten into the habit of blogging, it does feel weird to be writing on a website that is not truly my own. Also, one thing that I have been applying to my workflow is designing inside the browser which is what inspired me to write Own Your Canvas: Learning to Design for the Web. The only problem with that is that it is really only big picture thinking and does nothing to really talk about how that is practically worked out. Not only that, I actually don’t think this workflow has really been fully laid out in great detail (more then a single blog post) by anyone.

With those things in mind I have decided to do something about it. I am committing myself to redesigning my blog, but even more then that, I plan to design in the open.

This means:

  1. As soon as I start I will open up a public GIT repo.
  2. I will commit my work along the way so you have access to the code.
  3. I will give everyone access to the URL i will be working with so that they can see the progress.
  4. I will be creating webcasts along the way to show my progress and show how I am going about designing in the browser.
  5. I will blog about my journey along the way.

By doing this I hope to show how one can approach designing in the browser. I don’t expect it the be all way of doing it, but my hope is that you could capture the principles and then make the workflow your own.

This should be fun! Stay tuned!

Create. Stop. Be Creative.

Own Your Canvas: Learning to Design for the Web

Some of the best advice I was given when I first showed interest in the web design industry was “Learn to design. Learn to develop.” Some in our industry would say that when I was given that advice, I was being directed to be a generalist. I disagree.

Why you might ask?

The reason I disagree is because I believe that in order for one to be a good web designer, they must know how to develop. In other words the advice I was given was essentially: “Learn to design for the web.”

Don’t get me wrong, I’m not saying that one has to be the best front end developer out there to be a good web designer. In fact, I work with designers that are far more gifted at design then I am, that know less about development then I do.

With that said I do believe that one needs to have at least some rudimentary knowledge of development to be a good web designer. I would even go as far as to say one must have at least some rudimentary knowledge to even be considered a web designer. This is because the very thing that separates a print designer attempting to design for the web, versus a web designer, is a knowledge of development.

Understanding Your Canvas

The reason I classify such knowledge as the defining mark of a web designer is because it is only when one has a knowledge of development, that they also have an understanding of the canvas that they are working on. It is vital for one to understand the canvas that they are working on. Why you might ask?

Take a painter for example. If they were going to paint on a canvas they would need to know what that canvas is made of, what paints work well with it, what techniques to use in relation to it, and more. If they didn’t have that knowledge, then they would have a difficult time in creating something on top of it. Their paint might not dry correctly. There might be inconsistencies in their brush strokes. There could be an endless amount of issues.

Just as a painter must understand their canvas, so must a web designer understand theirs. A web designer must understand what type of designs work better on the web then others. They must understand how the different components on the web are built. They must understand the dynamics and what causes designs to break on the web. Most importantly, they must understand their canvas as it is the key factor in deciding what workflows they use and how they approach designs. This is a massive decision and one that often either causes a project to be a success or a failure. Unfortunately we as web designers can have a tendency to miss the mark on this.

One Step Removed

In Ethan Marcotte’s book “Responsive Web Design” he talks about how we as web designers often approach our work by emulating a print workflow (3). The way we do this is we create a blank slate in our image editor of choice, define widths and heights, establish grids, and then begin to design. Once we have finished laying out all of our designs in our image editor, we send them to a front end developer. The front end developer then brings our designs into the browser.

After they are complete we begin to make lists of things that they did wrong and need to be corrected. Later when those are fixed, we open up our web browsers in our mobile devices and begin to see even more issues. We then send those back to the developer. Ultimately we end up in this endless ping pong battle of design versus development until we finally come to a satisfactory result.

As you can see this approach to web design is highly problematic and waists tons of time. We could easily try and blame the front end developers for not getting the designs pixel-perfect and for not cross browser testing, but in my opinion that is a cop out. The reason that it is a cop out is because the entire scenario could be different if we did not approach our work like a print job.

The reason we can’t approach our work like it is a print job is because while print design is rigid in nature, web design is fluid in nature. In fact web design is one of the few creative processes that allows a user to manipulate the canvas. As soon as one opens up a website in their browser window, they are able to change the size of the window, zoom in and zoom out, turn features on and off, and more. If that is the case, why are we creating our designs in an image editor and then calling our job done? I mean think about it. When we design inside our image editors, we are actually one step removed from our actual canvas: the browser window (Marcotte 3).

Own Your Canvas

When dealing with such a complex canvas, we must engage with it instead of insisting others do that for us. This brings me back to my point that when I was told “Learn to design. Learn to develop.” I was really just being told “Learn to design for the web.” This is because in order for us to not be one step removed from our actual canvas, we must engage with our actual canvas. In order to engage with our actual canvas, we must know how to develop.

I’m not saying that an image editor must be fully removed from our workflow. In fact I believe an image editor is an essential tool to a web designer. The problem occurs when we begin to treat that tool as our actual canvas. The browser window is our canvas.

Own it.

How We Adapted Atomic Design

A couple of years ago I was perusing the web when I came across a thought-provoking article written by the one and only Brad Frost. It is a concept that has spread like wildfire in the development industry and rightfully so.

In a day where the majority of websites are built using a CMS (Content Management System), our websites are becoming more and more modular. Since the web is changing, the way we write code should adapt so that we deliver the best code that we can. We must understand that “we are not designing pages. We’re designing systems of components” (Stephen Hay).

Enter Atomic Design

The ideas and philosophies behind Atomic Design have been created with these ideas in mind. At the backbone, “Atomic Design is (a) methodology for creating design systems” (Brad Frost). This methodology is comprised of 5 parts:

  1. Atoms
  2. Molecules
  3. Organisms
  4. Templates
  5. Pages

As we look at these 5 parts, especially the first 3, we see that Atomic Design’s methodology relates highly to chemistry. What it is doing here is it is relating the building blocks of the web to the building blocks of all living things. That’s a short intro into what Atomic Design is, and I don’t want to go any further in the explanation of it then that.

The reason that I don’t want to get into more details is because my goal here is not to explain to you every detail of what Atomic Design is, but instead to let you know of a time it fell short. To fully explain where it fell short, let me tell you my own story with Atomic Design.

The Problem

After I had read Frost’s amazing article my juices were pumping and I couldn’t have been more exited to take it back to my team of developers. The team of developers that I worked with at that time comprised of a very diverse set of people from all different countries. Therefore I was interested to see how they would react when I presented it to them.

The next day came and I logged on to work all excited thinking “these guys are going to love this as much as I do!” The only problem was that when I presented it to them for their feedback, they weren’t 100% sold, and for a viable reason. The terminology was to hard for some to grasp.

See they totally bought into the core concepts of Atomic Design but when it came down to what each of those components were called, it didn’t make sense to them. The reason it didn’t make sense to them was because they had not learned with chemistry. Thus for them, it was too hard to relate these different terms to the overall big picture.

The Solution

What I so respect about that particular team is that even though they couldn’t pick up on all the terminology, they didn’t throw the concept out the door. Instead we rallied together to transform it to work for us.  The way we made it work for us is by changing the 5 parts that make it up while still maintaining the overall concept. Our goal was to come up with terms that made sense to us and anyone we would on board in the future.

So we began spit balling ideas when we all of a sudden we landed on a set of terms that I in particular think are genius:

  1. Foundations
  2. Materials
  3. Rooms
  4. Templates
  5. Pages

As you can see what we decided was to draw analogies from the process of building a structure. What we found was that just by tweaking these terms slightly, everyone was able to understand the full concepts behind what we were trying to implement.

Let’s Get Real

At the end of the day I’m not going to say that these same terms will work for everyone or that Atomic Design is flawed. This is just what worked for us.

I think what I learned the most, and what I hope you learn from this, is that we shouldn’t throw away great ideas just because some people on our team don’t understand them. Instead if our team is struggling, we should morph the ideas until they catch the big picture, thus allowing us to make better websites.

Create. Stop. Be Creative.


When I initially launched this post the title was “Where Atomic Design Fell Short”. I will be the first to let anyone know that I am not perfect and that I make mistakes. I am continually learning from advice from those around me. On Designer News Justin Barber commented that he thought my title was misleading and, after reading his reasons, I totally agree with him. Therefore I changed my title to be more accurate.

Again I want to thank Brad Frost for spurring on these ideas!

Vertically Align Anything

For this first week I want to give total props to Sebastian Ekström over at He wrote an amazing blog post that has spurred me on to share this snippet even more.  Shall we begin?

…… Dramatic Pause ……

I think so!

Have you ever been in a situation where you just wanted to vertically align an element in the center of something and didn’t want to write out a bunch of code to do so? A year ago I found one of the most helpful code snippets I have ever found. Sebastian Ekström wrote an amazing post that shows by using the power of transform: translateY, you can vertically center align the way you have always dreamed of … with three lines of code (plus vendor prefixes)!

To do this we write:

.awesome-element {
position: relative;
top: 50%;
-webkit-transform: translateY(-50%);
-ms-transform: translateY(-50%);
transform: translateY(-50%);

To take this a step further we can use the power of SASS and write it as a mixin.

@mixin vertical-align {
position: relative;
top: 50%;
-webkit-transform: translateY(-50%);
-ms-transform: translateY(-50%);
transform: translateY(-50%);

Then the only step you need to make after that is to add this to it’s parent container (this keeps things crisp):

.parent-element {
-webkit-transform-style: preserve-3d;
-moz-transform-style: preserve-3d;
transform-style: preserve-3d;

Again an even better way to do this would be to make it a mixin:

@mixin parent-vertical-align {
-webkit-transform-style: preserve-3d;
-moz-transform-style: preserve-3d;
transform-style: preserve-3d;

Taking it a step further:

If you are wanting to help reduce bloat within your code (which I highly advise), you could use the SASS placeholder selector like so:

%parent-vertical-align {
-webkit-transform-style: preserve-3d;
-moz-transform-style: preserve-3d;
transform-style: preserve-3d;

%vertical-align {
position: relative;
top: 50%;
-webkit-transform: translateY(-50%);
-ms-transform: translateY(-50%);
transform: translateY(-50%);

.incredible-parent-element {
@extend %parent-vertical-align;

.awesome-child-element {
@extend %vertical-align;

And that’s it folks!


Create. Stop. Be Creative.

Learning to Follow

Some of the most valuable advice that I have ever been given is that if I want to lead, I must first learn to follow. I think that applies to all aspects of life, but today I want to highlight a few agencies / individuals (both recent and past) that I have been following due to my enormous respect for their work:

  1. Focus Lab / Design
  2. Elegant Seagulls / Design
  3. Pixel Peach / Design
  4. The X-Team / Development
  5. Chris Coyier / Development
  6. Allan Peters / Design
  7. Green Chameleon / Design
  8. Haraldur Thorleifsson / Development

Are you following anyone? I would love to know! Post it in the comments so everyone can check it out.

Create. Stop. Be Creative.