The first step in my workflow is to build. Build a little that is. It’s important not to build your entire project in the first step. If you do this, it will only make validation and testing harder. If I’m building a full layout template for a website, then I will typically build a third of it before I move to step two (say the header, content area or footer). How much you build will largely depend on your experience and skill level. Those new to the field may want to build less while those with a decent amount of experience will be just fine building more. If you are just starting out you will eventually notice a natural inclination to build more before moving to validation. This progression will be the direct results of what you learn in steps three and four.
This step is self explanatory, but probably the most important. As I explained above, my experience has proven that not stopping only makes steps three and four more painful–most of the time. So no matter how tempting it is to keep building, remember to stop at some point to move onto the next step.
Validation isn’t exactly my push for standards driven front-end work–although I believe in it highly. This step is more about learning the language in which you write more clearly and not mention making your life arguably much easier with quirky browsers. It is likely that the project you are building has to support some of the older browsers in the market, however unfortunate that may be. In this instance, you’ll want to have the most valid code that you can possibly have before moving to testing. This is because what you may perceive as a browser quirk, may actually be a fault in your code (say an unclosed p tag), in which case you may spend many wasted hours trying to correct that during the testing phase. I have done this many times and it’s a huge waste of time, not to mention frustrating.
Note that at some point in this model, steps three and four will become intermingled and you will definitely need to cycle back and forth between the two before moving on. This is explained in the next step.
At some point in testing, you will likely alter the code that you built in step one. In this case, I usually continue until editing the code until my testing is complete. After this, you will have essentially circumvented the validation step. Because of this I recommend that you go back and validate your code. This can be a cyclical process, but in the end, you will hopefully have valid code that displays/works how you intend it to.
The tools I use in this step are many. I have two old computers at my desk, each with a Windows XP install. One has IE6 and the other with IE7. I test for IE8 on the windows machine I primarily use. I use profiles and separate installs for Firefox and Safari testing. I have noticed some variation in display across operating systems on the same browser, so I use a coworker’s Apple to test on MACs. You can duplicate this by searching Craigslist for old computers. The computers don’t need impressive specifications because after all, you’ll only be using them to run Internet Explorer, which requires very little resources. The two computers I use were just laying around our office not being used so I got lucky. You may want to search your office for old unused computers like I did. Another option I suggest is purchasing a license of VMWARE, which will let you run a virtual computer inside your computer. This essentially gives you another install of an operating system that you can run asynchronously with your development. I used this method to test before I setup some quality assurance machines, but I found it to be resource intensive and also took up half of my screen real estate. There are several options that replicate older versions of Internet Explorer and other browsers, but I haven’t had the best of luck with those, so for professional development I wouldn’t suggest them.
What do you think? Is there anything different in your workflow that you want to add? Anything you disagree with? Let me know in the comments.