Skip to main content or search

My Process from Comp to Page

Wednesday July 12, 2006 / 18 Comments

This isn’t rocket science, but I’ve started thinking more and more about the most efficient way to build out markup and CSS. I’ve always varied my process a little bit depending on my environment and the circumstances, but I’ve finally settled on what I believe to be a rock-solid process for me.

Step 0: Create a Reusable Framework

I’ve spent some time up front creating a consistent framework that I start with every time. It’s a group of files that include markup, CSS, and scripting that I can copy and paste and start with off the bat. The naming conventions are the same, the directory structure is the same, and I can hit the ground running with every new site.

Forms

Since much of my time is spent creating forms, the framework includes a CSS file for styling forms so that I have my own little microformat/pattern for styling forms without relying on tables. By simply changing class names I can quickly modify and adapt my forms to any style I need.

Markup

While it’s constantly evolving, I have a fairly consistent pattern I use for marking up my sites. It varies slightly from site to site, but for the most part, my meta, header, footer, body, skip navigation, and other things are consistent enough to reuse as a starting point every time.

CSS

The CSS files mainly consist of place holders using Doug’s CSS flags, but there’s also some basic styling of the header, footer, and body.

Scripting

Scripting is the biggest variable from project to project, but I have developed a small library for very basic things that I take with me from project to project. It encompasses the most basic building blocks and keeps things as simple as possible.

Step 1: Markup

Step 1a: Write the Markup

I always start with markup. I look at a comp and write the absolute minimum markup I can to represent all of the content. During this phase, I pay particular attention to semantics and accessibility and only think about CSS or scripting a little bit. (Of course, I’m commenting all of my closing divs as I do this.) The goal is to create a document that is structurally sound and ideally organized such that it would be a pleasure to read in any user-agent.

Step 1b: Validate the markup

Also, while it’s not the end game, validating the markup once I’m finished usually proves to be a helpful and rather easy step. It helps catch stupid mistakes, and it only takes a few moments.

Step 2: Open Browsers

My next step is to open about somewhere between 5 and 10 different browsers based on a variety of factors. This varies based on the target audience, the life expectancy of the site or application, and a few other miscellaneous factors.

However, I generally default to overkill and test on more browsers than I need to because they serve as a plethora of bug finders. The important part here is that I’m thinking about browsers long before I start my CSS. This is key to finding bugs earlier in the process rather than later.

Step 3: Write some CSS

Step 3a: Create the Color Glossary

The first thing I do is go through my comp and pull all of the colors into a CSS color glossary at the top of my CSS file. It seems little, but this saves lots of Photoshop opening and color guessing later.

Step 3b: Add the Grid

The next major step is using Khoi’s grid background image method to provide reference points before getting the layout in place. Greg’s ruler background image method works well too.

Step 3c: Lay It Out

After that’s done, I start by getting the main containers in place so that the high-level layout is nice and tight. For every 10 or so lines of CSS I write, I’m double-checking every browser I’m testing against to make sure things look good. I’ve found that nipping problems in the bud is much easier than coming back to do cleanup.

Step 3d: Write a little CSS. Test in All Browsers. Repeat.

I’ve read a lot of discussion where people discuss building a page in Firefox or another standards compliant browser and then going back to do cleanup in IE or the other browsers, but this has never been very successful for me. The problem is that you end up with a plethora of problems that are inter-related, and it’s hard to isolate, and thus fix the resulting problems.

I’ve found that it’s always easiest to fix a browser bug when the problem can be boiled down to a simple state. The easier it is to isolate the cause, the easier it is to correct. Similarly, the sooner you catch it, the less likely the fix is to have far-reaching and unintended consequences. So for me, it’s test, code, test, code.

Also, it’s an unfortunate truth that we have to go back and make changes to the markup to accommodate designs. It’s inextricably tied together, and I’d be remiss if I neglected to mention that there’s constant markup tweaks going on during this step. Just remember to keep them as small as possible.

Step 4: Validate Again

At this point, I’ve found it pays to throw that code through the ringer again. The markup tweaks or other changes could have introduced a few unwanted errors into the code, and I want to catch those before we start doing the scripting.

Step 5: Scripting

For me, DOM scripting is like adding that little bit of spice. I could always stop right here and things would be good, but with progressive enhancement, I can sprinkle in a few little tweaks that make things that much nicer or easier for those with JavaScript.

Like CSS, this piece sometimes requires some markup modifications for hooks, but they should be few and far between and generally be a matter of adding classes or ID’s rather than changing tags.

Summary

Over the last month as I’ve gotten back into the production side of things, I’ve spent a good amount of time refining my process so I can be a bit more efficient. This is essentially what I’ve come up with, and while it may be different tomorrow, it’s been pretty stable for at least a day or two now, so I thought I’d throw it out there for everyone else.

Featured Stuff - Resources: Wireframes & Page Description Diagrames

Omnigraffle and Visio versions of the wireframe templates and stencils I use on all of my projects. There’s even a few examples included for good measure. More about Wireframe & Page Description Diagram Stencils and Templates

Fantastic. This is great. Always nice to read other folks development process.

Josh Pigford

It is very informative and interesting to see how other people work. Often I find some little nugget that I wasn’t doing before that I now can’t live without.

I use very similar methods, especially the check-as-you-code method. Some don’t think it very effecient, but I have also caught many things before they grew much bigger.

Thanks for the window into how you work.

Joshua Brewer

This might seem like a silly question, but are you starting with a .pds or fireworks comp for this, or doing IA and design as you go. I guess the latter but it’s not clear…

I think this sounds like a good process, it’s similar to what we’ve been doing at Blue Flavor (although it changes every time for various reasons, kinda like you imply here) but we’re still trying to figure out how to join IA, Design and production in an efficient manner while maintaining multiple roles and areas of focus (our projects are big enough that one person can’t do it all and it’s hard to split time between design and coding, for example) while at the same time having deliverables in order for client buy-off.

If we’re just talking about production here, then I can see how this works, but when you try to save time by blurring the lines, like trying to have a framework of usable code in the IA phase, it breaks down a bit.

Keith

Keith – This is simply production from a Photoshop comp. It assumes that there were clear requirements going into the design phase and that those questions were sorted out in the design.

It’s an entirely different process if I’m going to design a large application. Of course, that mix depends entirely on the circumstances with the client and the amount of unknowns in the application.

Merging production, design, and IA is definitely a tough tightrope. So far, it’s worked for me to create working wireframes with minimal style and go with that. The challenge here is that it works best when you have the same individual doing all three aspects, but that’s just not realistic in most cases.

Garrett

Garrett—As I thought. For production I think this is a nice methodology, thanks for writing it up. I’d never seen Khoi’s grid (not sure how I missed it) and that’s a great idea.

Our biggest problem when it comes to this stuff is with IA and client sign-off. No matter how hard we try they seem to want to go back and change things after they’ve signed-off.

We’ve tried making things more abstract (Page Description Diagrams) and that helps some people. We’ve tried working wireframes to help save some tme inproduction, and that helps others.

For some reason though that process of finding the right deliverables and process has eluded us. To be honest, I don’t think it exists. I’ve been working on Web process improvement in one form or another for 11 years now…it’s all tricky with IA being the one thing that stands out as a constant pain. I’m starting to doubt the value of IA as a seperate phase as far a client is concerned. I find value in it as a designer, but then again, to me it’s part of design.

Anyway…

Thinks are so much easier when you don’t have cleints to deal with…lol.

Comes with the territory I guess.

Keith

CSS on Rails? Or even, webdev on Rails?
Good tips, I found it also helps to put together a basic folder structure (inside root | img/css/js/etc). Under the folder css I usually have files like master.css which links to all the other and print.css, ie.css and forms.css.

I have found it speeds up the process of creating and naming everything.

Bruno

I love these types of articles. It can be very helpful to see the processes that other people follow. The reusable framework is a great idea. Thanks.

Matt

Really good advice. On seeing the title in my feed reader, I almost didn’t click: thought it would vague, not helpful. Your proces sounds quite similar to mine, but you did in fact give me some ideas to make my process more efficient.

I’ve found that the discipline and efficiency created by a clear process are a very important part of the business of web design. These things become more and more important as my business grows. I’m focusing very much on making my work more reusable. I am also trying to codify my process, patterns and conventions so that future employees of mine have structure and projects are portable (meaning that anyone familiar with those conventions can pick one up and quickly get to work).

Thanks for the ideas.

David Benton

As a developer working by myself, I often don’t think of various methods to make my work easier, so it’s nice to know what methods other people have.

I’m more of a coder than designer, so I’m trying to work out some useful design techniques. I would be interested in knowing about your process for developing the comps, and how you go from them to the markup, some time in the future.

Steve

I wish more Designers/Developers would write more about their own methods so we can compare and contrast what works best and implement it into our own methodology.

There are a few tidbits in this article that I already do or decided that I was going to start to do (XHTML, CSS starting templates), and there were a few things that makes sense (such as validating through out the process, rather at the end) that I’m going to work into my workflow.

Nice article.

Chris Griffin

Great read. I use some of the same methods. What I love and am going to start doing is html and css templates. Great ideas!

Chris

I have a quite similar process. On the CSS part I use another trick, a two levels declaration.
In the HTML I call a file named switch.css. Inside it I call other stylesheets with the @import syntax.
This way I can filter old browsers and serve them a minimal styling in the switch.css file itself. For visitors with old browsers it’s a lot friendlier than plain naked html.
For modern browsers these minimal styles can be overriden in the imported files.

elv

Thanks, Garrett. Great article. You should post your framework files for us to download ;) I’ve been hoping that Max Design would post a “Layoutamatic” like Listamatic and Listamatic2 with tons of layout options but I haven’t seen one yet. Maybe if I get some time I will start compiling the major layout options into one consolidated resource like that.

Dustin Boston

Dustin, there are tons of layouts at Layout Gala

elv

Just curious how many different monitors most people test on? I try to test on a few different laptops, and a few CRT’s/LCD’s however I really don’t have any ancient monitors to test on for those still using the lower end of technology.

Ross Johnson

Great to have an insight on a well developed process. Reading what you’ve done here let me look on my own personal process and make a few refinements that should save me some time in the long run.

Jon

Wow, great resource elv. Thanks for the link.

Dustin Boston

I wish I could be like this and not rush into things when I create a new website. I always wake up after everything it’s done and I find myself with a lot of work to do, re-style, add some, cut some, eliminate tables and so on. It’s a very good idea to have some pre-made css’s to get you up and running with every new project.

Mihalcea Romeo

Comments are closed for this entry.