These kinds of questions are hard to solve well for any design project but when you throw in the context of this series of posts things get more difficult still. How do we make these considerations for those projects that don’t exist yet? Do we have methods in the bank for scaling content when we don’t even know what the content is? All of this is going to boil down to a couple of very important elements that make up the crucial foundation of a design project: typography and layout.

Typography

It wasn’t long ago that typography on the web was supposed to have a watershed moment. Services like TypeKit and Google Fonts and the growing support for the @font-face property were going to usher in the typographic renaissance for the web. To a degree they did; compared to just a few years ago, our options with type have expanded exponentially. But at the same time things have also gotten more complicated, as they are wont to do on the internet. Now we need to figure out what to do with our typography at different screen sizes and different resolutions to boot.

Fluid containers are great things, its part of what makes the web a wonderfully flexible medium. But fluid containers alone don’t render a great reading experience. As we adapt the web to make better use of the flexibility it thrives on we need to adapt our content too. This is the most important piece of any website and it’s important that no matter how our users access our content, they find it effortless to consume.

So that’s the goal. However, in order to understand how we can get there we need to first explore the close relationship that typography has with the layout it lives within.

Layout

Orbital content is awesome. If it’s a concept that you haven’t made yourself familiar with yet be sure to get on that ASAP (after you get done reading this, of course). Allowing our content to be lifted and transposed to other environments without any disruption to the message and readability is an ideal and achievable situation. However, when our content is not being transposed to other places the relationship it has with the layout it was born into is undeniable.

Your site structure and layout plays the role of a parent to your content and typography. As long as that content lives under this structure the layout must provide the best environment for it to represent itself well and be respectable while at the same time providing the ability to grow and let the personality of the content take center stage. Like any good parents, a site layout must work itself out of a job, fade into the background and go unnoticed but always be there for support. The harmony between these things is a crucial component to the foundation of an awesome user experience.

So how do we achieve this? What process can we take to ensure that we kick off a responsive design project the right way with a solid layout and crisp typography? And even beyond that, what measures can be taken in the context of building resources that will help us save time on these problems in the future?

The Ideal Solution

Let’s take a minute to talk about the ideal solution here. In this dance, someone needs to take the lead and in the hierarchy of design content lands on top, so it makes sense to allow our content to control our layout as much as possible. But how? This is the part where I point to smarter people who have done the hard bit for me. Trent Walton addressed this method previously on his blog. It’s there that Trent discusses his method for laying out type, which is to take measures to ensure that the average line length of a paragraph lands between 45 and 75 characters.

Achieving this requires a balance of adjusting font-size and controlling your containers to keep line lengths in check. That 20 character cushion should be gracious enough to ensure you have wiggle room between breakpoints and it’s a pretty easy thing to measure. Of course this can’t apply everywhere, an aside comment, narrow sidebar, supporting content, image captions and other situational elements will likely be exempt to the rule. The important thing to keep in mind is that the primary content on the visible page should represent an ideal reading experience at all resolutions and building your grid around that will force an answer to some layout coin tosses.

Furthermore this is a pretty simple goal to achieve (relatively). Generally speaking, as your available real estate expands and you work your way from small screen to really large screen (because we love mobile-first design) you’ll increase your font size on the html element to scale your primary content region up to maintain the character-to-line ratio. There will naturally be a point where sizing text alone to achieve this gets a little ridiculous. Here, we use our sharpened designer skills to restrict our layout containers and make sure we can see more than 2 lines of our paragraph without scrolling.

So that’s it… easy, right? No. Don’t be dumb.

The Part Where Things Break

There are two reasons why that isn’t the end of our problem. First, if it was I wouldn’t have written anything about it. I already explained to you that Trent did an awesome job explaining this stuff so I would just tweet his article and call it a day. Second, we haven’t solved anything I’m trying to get at here on this blog. Our goal is to build long-term solutions. We want patterns to execute responsive designs and we want new thought processes and exercises that will help us become more efficient designers.

There is a reason I started with typography and grids. They’re incredibly hard to nail down and build patterns for. And it’s not for a lack of trying. There are plenty of solutions out there when it comes to fluid grids and even responsive grids. By now you should be familiar with things like the fluid 960 grid system and there have been some clever solutions put together for a responsive version of this. The bootstrap project has a take on it and other projects dedicated entirely to a responsive grid system. I think these projects rock and I would encourage anyone to get their hands dirty and use them. With that said, I always arrive at the same conclusion.

These efforts don’t lead us to a reliable solution. Yes, it’s a column-based layout system that shifts to fit on different devices and for the most part they do a great job at that. But this still leads us short of creating an ideal solution for our content. No matter what sort of pre-made responsive grid system you may implement there’s going to be a lot of tweaking required. In a lot of cases that tweaking and overriding can lead to more work than it would have been to build the container reflow pattern on your own.

The truth is that there are too many variables involved in a responsive grid system to build a perfect one. The more I foiled with other solutions and even tried to develop my own the more I came to my overall answer for this problem.

I Don’t Even Want This

What comes off initially as a childish reaction (“I can’t figure this out? Fine! I don’t even want to figure it out; I never cared about this at all. It’s stupid.”) is the right answer. I don’t want a pre-made responsive grid framework I can plug into my site because it simply can’t work. That pre-made solution doesn’t know anything about my content and until I know something about my content I don’t really know how I want it structured. We already decided that content takes the lead in the foundation of a design which, by nature, makes the layout a reactionary element.

Containers must be crafted around their precious possessions and adapted to all of the unique problems a responsive design presents. This is a hands-on task and really our job as designers. It’s also one of the beautiful things about being a designer. This part of the job can’t be outsourced and it can’t be automated. There is no pattern for the process a professional designer takes in understanding content and shaping it to allow its purpose to shine through. We should be happy about that, its job security.

So where the hell does that leave us? 1,600 words of pointlessness where we go around this big circle and decide to screw it all we still need to do this by hand? Thankfully no, I actually thought about this post before I wrote it so I won’t leave you at that.

Something Real to Take Away

There are some real lessons here. First, when it comes to typography we have a precedent to follow. Maintain readability across devices, build your typography to allow your primary content to flow at 45-75 characters per line and build out from there. Second, this should drive your layout as well and decisions about design elements that live around your primary content should fall in queue with that order of importance, making it easier to figure out how they flow through various resolutions.

Finally, when it comes to grids not all hope is lost. When it comes to individual designs and solutions on a small or medium scale a custom grid is almost always the best option. However, if you’re designing for a framework or a solution that will be applied to multiple sites or a very large project w can still use pre-made grid solutions. There is nothing wrong with using one of the dozens of fluid grid systems and frameworks out there. Any system that builds layouts based on class structures can save a lot of time in the design process. However, when it comes to reflowing this layout and getting responsive it’s best to stay hand crafted.

As I continue to experiment with this one method that has become increasingly reliable is the media query ladder as I’ve come to call it. I may expand on this in another post, but when it comes to working with grid systems they tend to be constructed for larger resolutions. This doesn’t play nice with our mobile-first responsive design approach so what’s a designer to do? In the media query ladder I start with max-width statements and work my way down from widest screen to smallest, making adjustments to my grid as I go. Then, once done with max-width queries I start on my min-width queries for all of my CSS properties not related to the grid and work my way back up. The max-width and min-width values need to match for a smooth sizing experience.

So layout and typography don’t hold a silver bullet solution when it comes to responsive design but that’s hardly surprising. These are some of the most important pieces of any design and require a lot of planning, execution and tweaking to get right. It’s part of what separates great designers and will likely continue to be. The good news is that there are ways to speed up this part of the process and work we can complete towards the future.

The Big Picture

This post is a part of a series I am piecing together to explore methods, patterns and techniques designers can utilize to improve efficiency in the responsive design process. Other parts:

• Introduction
• Typography & Layout
• Navigation
• Tabbed Page Structures
• Images / Video/ Multimedia
• Tables
• Popups / Modals
• Smaller Components (buttons, form fields, asides, etc.)

So if responsive design is going to be our new default approach, it’s important that we start to explore ways to improve our project efficiency. This is nothing new for designers. We have been mastering the art of recycling for quite some time now. Pattern libraries have long been standard for companies or agencies, grid systems help us speed up layouts, barebones themes get us kicked off with CMS projects and projects like HTML5 Boilerplate save a surprising amount of time with simple assistance in building a good reset and starting point for any project.

Some of these tools can be carried with us to the responsive promised land but others are doomed to be left in the graveyard of static site design. Over the next few weeks I would like to explore some areas where we can prepare ourselves ahead of time for responsive projects that have yet to begin or even be conceived.

How can we prepare?

There are quite a few areas in a RWD project that allow for time saving methods. While some components, like how to create media queries, how to handle media and where to define breakpoints have been heavily discussed there are other areas, like how we do wireframes, concepts and style guides in an efficient manner that have room for exploration.

A lot of these things are flexible in their nature, not too unlike responsive design itself. There is no inherit right or wrong when it comes to decisions like how to build out wireframes for a responsive project. Some designers may be comfortable developing static representations in Photoshop, Illustrator or Fireworks. Others take it straight to the browser and some keep it LoFi with pencil and paper. Your best bet at this stage in a responsive project is to find out what you’re comfortable with and get the practice and experience you need to be efficient.

Project workflow is another area of concern with a responsive project. Responsive designs are less likely to consist of a designer passing a finished concept off to a developer and walking away. More parties are involved at more stages and communication becomes a crucial skill set. If you are freelancing or your project doesn’t have a dedicated manager or owner, you’ll need to start honing your communication and management skills. Adopting personal policies of writing clean code, making clear notes and comments, and submitting frequent updates to the other stakeholders will save a lot of headache.

These are areas worth covering more in depth but not my biggest interest for this series of posts. Instead, I will be focusing on the execution side of things. This is because I think there is a lot of work a designer can do to be prepared for a project before any project even exists. My goal is to share and discuss ways we can be prepared for a responsive project that has myriad unknown factors… the responsive unknown.

What is the Responsive Unknown?

Working on projects that don’t exist may come across as an incredibly stupid waste of time. But really it’s nothing new. Anyone who has ever used a boilerplate or framework, like one I mentioned earlier, has benefitted from this sort of practice. It’s basically recycling common project components where it makes sense to do so; it’s simply a smart practice that saves time and money without sacrificing originality or quality.

But can we go beyond the starting line with our preparation? There is a bit of a debate to be had here. We all love to share clever solutions to common page elements like navigation, popups, data tables, forms, etc. and often times it doesn’t hurt to start with a pre-made solution to avoid writing all of the HTML or CSS from scratch. We even have some rather exhaustive resources for these kinds of patterns in a responsive environment. If you haven’t already, checkout (or contribute to) Brad Frost’s “This is Responsive” project. The other side of this coin is that we wind up with a bunch of sites that look the same. I don’t consider this to be a big issue at this point, so it’s an argument for another day.

So we have these resources available to us, but not all of them meet the right criteria. If we are going to use a pattern for “the responsive unknown” it not only needs to be responsive but also flexible in the content it can hold or the content that’s around it. And this will be the purpose of the next few posts here. To explore our options with popular site components and seeing if we can find or develop some good resources for building responsive solutions that have unknown variables, not just in viewport size but content and purpose as well.

What’s the Benefit?

Is there a measurable advantage to this? I say there is. Especially when it comes to the world of responsive design, there is a lot of tweaking and nudging of HTML and CSS before I’m happy with a result. If I can produce a starting point where a lot of that work is already done, I know I am saving myself time.

There will be occasions where I can slap a pre-built solution into a wireframe and it works perfectly for the application. We like to hope these scenarios are going to come along often but the reality is that design involves a lot of “it depends” scenarios. This means making adjustments to our starting point. But I think that starting point can come from a much smarter place, in which case there is still a lot of time to be saved.

Time Saving Areas

Finally, let’s look at what areas I think we could stand to save some time with really smart defaults. I will be covering these things here on my blog in the coming weeks. If you think something should be added to the list suggest it!

• Typographic Scale
• Grid Layout
• Navigation
• Tabbed Page Structures
• Images / Video/ Multimedia
• Tables
• Popups / Modals
• Smaller Components (buttons, form fields, asides, etc.)

The great thing about design rules though is that they can and should be broken, granted that you know what you’re doing. Read on to see some examples of effectively breaking design principles in order to improve a project.

Read the Rest

Each client has the ability to design their website as they see fit, but we have an unbalanced ratio of designers to clients. I do not have the luxury in my day-to-day work of spending months working through a design process as part of a client’s implementation. However, this scenario of limited time hardly strikes me as rare among my design peers.

Because of these constraints, I hear a phrase quite often that many designers would compare to nails on a chalkboard. The people I work with who do not handle the design side of our platform will often tell clients, “The designer will make it look pretty.” Now, “it” could refer to a lot of things: a log-in form, maybe a simple button, or the entire website. When content is raw, unformatted or confusing to the user, it gets sent to the design department so that it can come out the other end “pretty.”

Read the Rest

This sort of opportunity (to learn directly under these people) has always had a particular interest to me. Not just because I’ve had a certain interest or passion for design since I was quite young but also because it was an opportunity largely unobtainable to me. While the state of Indiana does have some very talented and incredibly smart designers, it doesn’t provide the honeypot of design and technology related opportunities boasted by either coast of the US and plenty of other areas worldwide. This was especially true in the town of Evansville, where I grew up.

I knew then as I still know now that having a mentor in my field would provide a ridiculous amount of value in what I could learn from another designer who had years of experience and a wealth of talent that I did (and do) not possess. But what’s a young Hoosier to do? When I was 17 I stumbled into an internship opportunity with a local agency that provided design, hosting, and commercial production services for some businesses in the area. I was very excited for this, the people I got to work with were great and it was my first professional experience playing the role of a designer for a company. I got to work with clients and solve problems, it was great. However, I was disappointed to a degree when it quickly became apparent that the existing design skills of the company did not exceed those I had already generated on my own (which wasn’t much).

Through high school and college I worked my way into freelance gigs that paid the weak ass bills I had at the time and allowed me to put a little cash in the bank. During college I had a few part-time jobs that placed me in designer positions. Both were great in that they were fantastic work places and I had a surprising level of creative and personal freedom for a part-time employee. But alas, the same problem remained. No opportunity to work directly with people who clearly knew a whole lot more about what I was doing than I did.

While I am no old man I do know that I could be a lot better at what I do today if I had an opportunity for that experience. I also know it’s something I could still grow a heck of a lot from today. It wouldn’t take more than a few minutes for me to come up with a list of 50 or maybe 100 designers that I know produce good work, have smart thoughts on our industry, and blow my mind with their creativity. I want to work with these people, but here I am, still in Indiana and not complaining about the fact that I have a yard (with grass and trees and stuff) and that the mortgage on my house is probably half of what my rent in an NYC apartment would be.

But is my dream dead? I think not. When I look at what I would value out of an apprenticeship it’s not the sound of someone else’s mouse and keyboard clicking away. It’s their feedback on the decisions I make, it’s the eye-opening experience of someone explaining to you that you are totally wrong and here’s why. I know this kind of interaction when I see it. I’ve had the opportunity to look like a total fool and grow from it in a lot of areas in life, some more related to my profession than others. I think this type of Jedi-to-Padawan relationship can be established digitally. Because all it really takes is some time to provide feedback, answer some emails and have an occasional chat about a project or idea. I have no doubt there are plenty of experience designers out there that could even pass off some minor parts of a project they are working on or give an intern/apprentice the opportunity to execute a job that you would otherwise not have the time to take on.

Asking someone for their time is easier said than done. Everyone’s time is valuable and I can imagine that most of the designers that I could expect to learn the most from are busy as-is without the inclusion of one or two young designers in their inner-circle. There has to be an interest there; one of investing into the future of design and passing along what you learn to those eager to accept it. I know this interest exists. I see it from simple blog posts idea all the way to things like Summer Camp that involves a direct financial contribution into the design community.

So I ask those who certainly know more about all of this than I. Do you, or have you, taken time to mentor the generation behind you? If not what prevents you from making that leap or taking that time? I am certain that I do not stand alone in what the individual young designer stands to learn and what the community as a whole stands to gain. We certainly don’t want to be left in the dust.

This project doesn’t stand simply as an expression of my favorite movie quotes. I have always been a fan of typographic posters and typography-based design projects so I wanted a good excuse to get some practice in and improve my own skill set. Additionally this is a bit of a marketing experiment on Pinterest and Facebook as well, mostly Pinterest. So check it out and let me know what you think. Also, if you have some favorite movie quotes that you think would make a good addition to this set drop them in the comments!

Typefaces used for this project were the Ostrich Sans family and Lavanderia.

Power and Pitfalls

Buttons seem like one of those things that CSS3 was made for. We have a wide array of new(ish) tools to throw at our interfaces now, rounded corners, text shadows, gradients, transitions, and box shadows to name some of the more popular options. It’s tempting to use all of these at once, after all it’s pretty easy these days to put together quite a bit of fancy code in no time thanks to gradient generators and prefixing tools. Of course at the same time this can turn into some pretty sloppy code with questionable maintainability:

background-color: #f0f0f0; 
background-image: -moz-linear-gradient(top, #fff, #E6E6E6); 
background-image: -ms-linear-gradient(top, #fff, #E6E6E6); 
background-image: -webkit-gradient(linear, 0 0, 0 100%, from(#fff), to(#E6E6E6)); 
background-image: -webkit-linear-gradient(top, #fff, #E6E6E6); 
background-image: -o-linear-gradient(top, #fff, #E6E6E6); 
background-image: linear-gradient(top, #fff, #E6E6E6); 
background-repeat: repeat-x; 
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffffff', endColorstr='#e6e6e6', GradientType=0); 

I pick on the background gradient because my love affair with it has been short and is becoming tepid. While I still prefer using CSS3 for my gradients over images in most cases, it’s hard to argue that the above code is easy on the eyes. Of course background gradients have another downfall too, one that is especially frustrating with buttons. That is, at the time of this writing the background-image property is not supported by CSS3 transitions. So if we use gradients to build buttons we tend to be stuck with that gradient for different button states. So what’s a designer to do?

Animating Gradient Backgrounds

My fallback (or fall-forward) for this has been using box-shadow to create a gradient. The box-shadow property has several advantages here. First, the code is consistent between browsers. While we still need to do some prefixing to support all browser types, we have clearly reached a standard format between Mozilla and Webkit browsers that will likely reach the final recommendation stages before gradients. In addition, box-shadow gets along well with transitions, meaning we gain the ability to animate. Our trade-off here is that we are still faking a gradient, box-shadow will take a lot more trial and error to generate a smooth gradient from one area of an element to another. Lets start by taking a look at the finished product:

Classy Button

There is a lot going on here in terms of CSS but lets just take a look at the interesting part, the box-shadow:

    
 
box-shadow: 0 8px 3px -4px rgba(0, 0, 0, 0.2), 
            inset 0 25px 20px -10px rgba(255, 255, 255, 0.3), 
            inset 0 -15px 20px -10px rgba(0, 0, 0, 0.15); 

We have 3 different shadows in here. The first is the most boring, it’s simply the drop shadow that falls below the button however it does bring up a somewhat interesting point. I see a lot of designers neglect the fourth value set of box-shadow which is, in this case, -4px. This sets the size of the shadow relative to the object it is attached to, so in our example the drop shadow will be 4 pixels smaller than the button it falls off of. I think this gives a good effect of perspective and will come in handy when we animate things.

I’ve found that the fourth box-shadow property also serves to soften things up a little bit,which plays a much larger role in our two additional shadows. Both of the other shadows are inset, the first on the top of the button and the second on the bottom. I have always been a fan of using rgba white and black, not just for shadows but also gradients and backgrounds, I think it gives the designer a lot of flexibility and makes for some preset CSS styles that can be applied to myriad objects. If you want to go in depth into that sort of thing check out my article on Smashing Magazine. Here we have applied a light “shadow” to the top and a dark one to the bottom.

Again, I am using the fourth box-shadow value to soften up the shadow on either side of the button which helps it to run from top to bottom more like we would expect a gradient to. When we work with rounded corners and inset box shadows the shadow will curve with the button. In most cases that is the desirable behavior but in this case I wanted to reduce that rounded look from my shadows. Now lets take a look at the CSS for the hover state:

 
box-shadow: 0 2px 1px rgba(0, 0, 0, 0.35), 
            inset 0 20px 20px -10px rgba(0, 0, 0, 0.15), 
            inset 0 -15px 20px -10px rgba(255, 255, 255, 0.3); 

transition: box-shadow 0.15s linear; 

Keep in mind that I have stripped out the prefixed versions of everything for the sake of brevity. All I’ve really done here is reversed each of the box-shadows and put the lighter one on the bottom and the darker one on top. At the same time I’ve taken the first shadow brought it closer to the button, sharpened it up, and changed the size relation. The transition property is pretty straight forward.

So there we have it. A quick and dirty look at faking animated background gradients. These properties can easily be applied to any background color too which makes this practice pretty flexible. If you want to get more in depth check out the demo page. Also, for giggles here is the entirety of my sloppy CSS:

   
 
button { 
    display: inline-block; 
    padding: 0 35px; 
    text-align: center; 
    text-shadow: 0 -1px 0 rgba(0, 0, 0, 0.3); 
    vertical-align: middle; 
    cursor: pointer; 
    line-height: 40px; 
    border: 1px solid #0a72aa; 
    border-top: 1px solid #169abb; 
    background: #1eafd3; 
    color: #f0f0f0; 
    font-size: 16px; 

    -webkit-border-radius: 20px; 
    -moz-border-radius: 20px; 
    border-radius: 20px; 

    -webkit-box-shadow: 0 8px 3px -4px rgba(0, 0, 0, 0.2), 
                        inset 0 25px 20px -10px rgba(255, 255, 255, 0.3), 
                        inset 0 -15px 20px -10px rgba(0, 0, 0, 0.15); 

    -moz-box-shadow: 0 8px 3px -4px rgba(0, 0, 0, 0.2), 
                     inset 0 25px 20px -10px rgba(255, 255, 255, 0.3), 
                     inset 0 -15px 20px -10px rgba(0, 0, 0, 0.15); 

    box-shadow: 0 8px 3px -4px rgba(0, 0, 0, 0.2), 
                inset 0 25px 20px -10px rgba(255, 255, 255, 0.3), 
                inset 0 -15px 20px -10px rgba(0, 0, 0, 0.15); 
} 

button:hover { 
    text-decoration: none; 

    -webkit-box-shadow: 0 2px 2px rgba(0, 0, 0, 0.35), 
                        inset 0 20px 20px -10px rgba(0, 0, 0, 0.15), 
                        inset 0 -15px 20px -10px rgba(255, 255, 255, 0.3); 

    -moz-box-shadow: 0 2px 2px rgba(0, 0, 0, 0.35), 
                     inset 0 20px 20px -10px rgba(0, 0, 0, 0.15), 
                     inset 0 -15px 20px -10px rgba(255, 255, 255, 0.3); 

    box-shadow: 0 2px 2px rgba(0, 0, 0, 0.35), 
                inset 0 20px 20px -10px rgba(0, 0, 0, 0.15), 
                inset 0 -15px 20px -10px rgba(255, 255, 255, 0.3); 

    -webkit-transition: box-shadow 0.15s linear; 
    -moz-transition: box-shadow 0.15s linear; 
    -ms-transition: box-shadow 0.15s linear; 
    -o-transition: box-shadow 0.15s linear; 
    transition: box-shadow 0.15s linear; 
} 

The truth is that yes, RWD can indeed be that solution but the way we are being told to approach it is all wrong. Let’s take a look at the problem. The original problem we had was that phones were becoming a more realistic interface for browsing the web. The devices were ready for a browsing experience but the sites we design were not. We were fundamentally rooted in the idea of designing for a screen size. From the old days of asking which monitor size is the most popular, to the evolution of the 960/980 pixel grid.

Our initial solution was to serve up mobile-specific sites to mobile-specific devices. These sites would render well on a mobile device where we could assume not just different screen sizes but also different methods of interaction. It didn’t take long to find holes in this solution. The development and more importantly, maintenance, of a mobile site added up to time and resources companies didn’t have. At the same time that this problem was really coming to a head another was starting to emerge.

Just as the mobile browsing experience was starting to get rich we were introduced to the iPad. From there the scene has exploded into hundreds of devices of all shape (not really, they are all rectangles) and size. Clearly maintaining different sites for different devices is downright impossible now and will only continue to get worse. The lesson we have learned from all of this is that it is a bad idea to try and maintain our websites based on existing technology.

The Solution, Yay!

Enter stage left, responsive web design. RWD is the answer to everything, right? Well, no. It’s not. But it is an answer. RWD does give us the power to deliver a website to a range of devices and resolutions while maintaining a single code base, a huge weight lifted off of site maintenance. However, it would seem that we still haven’t tossed that old habit of picking our favorite resolutions to design for. And this is what really drives me crazy about all of these articles that discuss RWD and how to execute it. They pretty much always have the process correct, get your grid going, figure your images out and slap some media queries in there and boom, done (it’s not really this easy).

However, we can’t help but come back to setting up media queries for those old familiar resolutions. 320, 480, 768 pixels, where do these measurements come from? Stop pre-picking your breakpoints based on popular devices. Please, I beg you. If you design your site to work great on the iPad today then you’ll have to go back and fix it tomorrow. It is entirely possible to design a web experience that looks wonderful not just on the devices we have today but on the devices that we will have tomorrow and in the years to come.

How to Really Define Breakpoints

So if we don’t want to use device widths for breakpoints how do we figure out what our breakpoints should be? Well I’m going to tell you.

Look at your damn design you moron.

The mobile-first approach works wonders as an approach for developing a responsive site so start there. The first iteration of your design should work on a resolution of 0 pixels and up, including but not limited to, infinity. Once this is looking great all you’ve got to do is break it. Stretch your design out and at some point you will certainly stop, look at it and say, “hey, this kind of looks like total shit”. First off, you should watch your mouth. Second, you now have your first breakpoint. There is a good chance that this breakpoint doesn’t fall exactly at 320 or 480 pixels. There is an even better chance that you could apply this breakpoint at a range of probably 100 pixels and be just fine, it’s just that easy. This is your process, rinse and repeat.

At the end of the day you’ll have a series of breakpoints built around the process of fixing your site when it starts to look bad. This is why my site has breakpoints of 500, 800, 1000 and 1400 pixels. Because somewhere around those ranges things started to get out of hand and some design changes were called for.

Now my site looks just fine on my phone and it looks just fine on my 24 inch widescreen monitor and everywhere between. I don’t care what resolution the next wave of devices is going to have because my site will probably look just fine on them. When you attach your breakpoints to the specific requirements of the design at hand and ensure that adjustments are made based on the restrictions of your content you can design a site that finally breaks away from a screen.

There are a few reasons why I decided to go ahead with a refresh. First, as a designer I simply can’t stay happy with my own site for more than a few months. I think this is the 9th revision of my site and my personal website has always been a venue for me to expand on my skill set and build projects without any third party restrictions.

One of those skill sets that I really wanted to focus on with the new site was responsive web design. As you may have noticed at this point, the site is responsive. There is still work to be done in this area because I believe the process of responsive design can produce some really powerful results for a web design when used correctly.

Another step I wanted to take with the design was to focus more on the content of the site. Over the past 2 years I’ve had an excellent opportunity to write articles for design blogs the likes of Six Revisions and Smashing Magazine. I’ve enjoyed the process of writing about web design and including writing as a part of my design process has allowed me to continue to develop and learn more about this field.

The writing won’t just be a big part of the new site layout and design. The goal (and I’ve said this before) is to write and post here more often. While I will continue to reserve the large, research-based articles for publication on other blogs I would like to start posting more quick thoughts up on this site on a more regular basis. If I can, I would like to start writing for a few minutes every night or a few nights a week.

I can’t imagine that I have even come close to completing this redesign project in a perfect manner. My website is always in a state of flux to some degree because I have always treated it as a personal playground. There is a lot of browser testing yet to be done so if you are here on an older browser don’t be surprised if things are a little out of whack. With that said I will say that my audience on this site, according to Google Analytics, consists of less than 8% IE users.

So take a look around! I love getting feedback of all kinds, so let me know what you think or if you find anything broken.