My Development and Design Process

When first teaching myself CSS, I often became frustrated making sense of the whole thing. I was used to wrapping my content in presentational markup and everything obviously happening for a reason. I read as much as I could about CSS and the separation of structure and style. As I read more, I could see that my markup began to make more sense, I was applying semantics to document markup and it felt like I was starting to make the most of what XHTML and CSS had to offer.

To this day, I try to read as much as I possibly can about design and development, and I’m always seeing new and improved ways of doing things. Not because it’s using the latest trend on the Web, but because it makes more semantic sense, or is more accessible. In the long run, that is what’s important.

Developing the standard, semantic, and accessible Web is an ever changing process. As time moves on, there are better and more effective methods of presenting information (and design). I’m constantly looking at past projects, realizing there are aspects that need to be updated as there are better ways to do certain things. It could be a single document element, or an entire range of things that spread site-wide. The point I’m trying to make is that when it comes to Web development, it’s impossible to know everything, and it’s important to want to keep learning.

My Development Begins with the Markup

I quickly learned that it’s much more time effective to separate the development of a website into parts; markup and style. When starting work on a new project, I’ll usually receive an approved mock from a designer. My first step is an attempt to envision the overall structure of the document. I’ll first pick out the overall structural elements that need to be put in place. From there I’ll pick out such things as divisions, lists, paragraphs, headings, and definition lists, as those are the most common elements I end up working with. This process of envisioning the document structure doesn’t take long, but proves to be extremely valuable.

Take, for example, a page of Google search results:

A Google SERP isn’t the most involved design, but I think it gives good insight as to what I’m talking about when I say that I try to visualize the structural elements of a design mock before I begin writing markup. Usually now when I’m faced with a mock, it’s hard not to think about what elements would be best to structure the end design.

Ideally, when a new project is started, I like setting up the site during the time the designers are working on mock approval. Although it doesn’t happen with every project, it helps when it does. The site design should not distract your markup from being semantic. Having a working version of the website put together with no style is comparable to viewing the end product in a text-based browser, as the style doesn’t visually structure the content and you’re browsing naked documents. More often than not, if I’m able to mark up the site before a mock is approved, I’ll have to go back and add some structural divisions or make some other adjustments, but they’re usually minimal.

I will always suggest writing your markup first, as it will allow you to give more focus to the semantic value of each element. It will help you to keep your code organized and clean, which in turn helps keep control of validation errors. You’re able to limit your markup to an acceptable minimum and put everything in a logical order, as opposed to moving elements around in order to compensate for your CSS.

Producing the images needed for the design

Once I have the markup complete, I will begin to think about the design. The first step for me is gathering all of the images that when put together, will form the design in its entirety. This step has become easier as I put together more websites in that I’m able to think about images as a background-image, visualizing their repetition where applicable. Experience will also provide you with knowledge about specific cases where one technique will work out significantly better than another. I realize that’s a very big generalization, but it’s hard to get much more specific as every design is completely different than the last. The process becomes increasingly easy with each project as you pick up your own tricks along the way.

I try to have a naming convention as far as images are concerned. That way, when it comes to referencing them in my CSS, I can easily tell which image belongs where. I usually give background images a ‘bg_’ prefix followed by a meaningful identifier. Navigation images can also be prefixed with ‘nav_’. There are also other project-specific cases where a prefix can come in handy. Another technique I’m a big fan of is working with are CSS sprites, which are easily identified if you use a descriptive filename. They help keep image file counts down, and limit the number of requests that need to be made on a page load. I choose to use file prefixes as it keeps them more organized not only for active use, but also when viewing them in a file browser or FTP client.

Now it’s time to apply the CSS

After all of that is done, now is when I apply the style to my markup. I have been writing CSS in the same style for quite some time now, but I’m always open for new tips on writing better CSS. It is at this time markup elements are given their class and id names, and the markup is styled according to the design mock.

As I style the document, I’m constantly looking for repetitious properties and values in order to keep my style sheet streamlined and as light as possible. I’ll also keep a close eye on known pitfalls I’ve run into in the past, such as trying to avoid the cross browser box model issues. I write as much style as possible before checking things out in a browser, as it slows down the overall process. It’s more difficult to do as you’re defining the visual structure, but there are many times you can style an element with no need to double check yourself in a browser.

Cross browser testing

After I’m satisfied with the markup and CSS, I begin a barrage of browser testing. My browser of choice for development is Firefox, so the mere fact the document was under constant using that browser, it goes without further testing. I’ll then move on to IE6, and using conditional comments, I’ll put together a separate style sheet containing all the fixes IE6 needs. This process is repeated for IE7, which still definitely has it’s share of quirks that need to be handled.

Beyond Internet Explorer, I will also test in the latest version of Opera, and then move on to Konqueror, as it uses the KHTML rendering engine, which is as close as I can get to Safari within my Linux install. I’ll always take a final step to test in a legitimate install of Safari in OS X as well, but testing in Konqueror does help expose some pitfalls before having to move to a different machine for testing.

Putting together a print version of the document

After all the above has been done, one of the last steps I perform is preparing the document for print using CSS. There is a lot you can do to make sure that the printed version of a document is presented in a way that proves useful as hard copy. Again, many times conditional comments are used to ensure the print version renders correctly in Internet Explorer.

Last, but absolutely not least, the website is put through the validation paces. I have a constant eye on my markup and style validation, but always run them through the official tests provided by the W3C. Automated accessibility tests including Section 508 and WCAG are also performed to ensure I didn’t overlook anything. There are often other steps involved with the development of an entire website, but perhaps me explaining my methods can offer some insight into my Web design/development process. Writing this article was inspired by Jonathan Snook’s chronicle of his design process. I love reading articles like that, and thought I’d offer a version of my own as well.