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 WordPress.com 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.

Vertically Align Anything

For this first week I want to give total props to Sebastian Ekström over at zerosixthree.se. 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 zerosixthree.se 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!

Demo:

Create. Stop. Be Creative.