Front-end Development Work Flow Model

1. Build a Little

2. Stop

3. Validate

4. Test

5. Repeat

The other day while working with an intern in our office, I mapped out a workflow that I use almost every day, but didn’t even realize it. The steps in this workflow are above. The purpose of this workflow is to lessen development time and ensure quality in the work you produce. One important thing to note is that this workflow assumes that your project is “shovel ready”, as in all the planning and strategy has already been completed. This model does not cover that part of a project.

Step 1: Build a Little

Some XHTML & PHP

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.

Step 2: Stop

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.

Step 3: Validate

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.

W3C Validator and JSLint

It is important that you validate all the code you’ve written, whether it’s (X)HTML, CSS or JavaScript. All of them need to be validated. The W3C has both an (X)HTML and CSS validator that are quite easy to use. The W3C does not–at the time of this writing–have a JavaScript validator. For JavaScript validation, I use JSLint.

This is not to say that validating will solve all your problems before testing. If that were the case then there wouldn’t be a need the fourth step at all. How far you go with fixing validation errors is your decision. I can certainly understand a need for invalid code in some cases (e.g. YouTube embed code), however, for the most part I prefer 100$ valid (X)HTML, CSS and JavaScript.

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.

Step 4: Test

Testing is the hardest and most time consuming. The good thing is, the more you do it, the less frustrating and time consuming it will be in the future. Testing is all about ensuring that the (X)HTML, CSS and JavaScript that you built in step one displays acceptably in all your supported browsers. As mentioned above, it’s possible and very likely, that 100% valid code will not display/work the way you intended it to in all browsers. This is why testing is so important. There is little use of doing anything in step one if users are not able to actually use what you built.

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.

Common Browsers to Test With

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.

Step 5: Repeat

What do you think? Is there anything different in your workflow that you want to add? Anything you disagree with? Let us know in the comments.