Over the years of developing and creating different websites I have come up with my own tried and tested method for doing web development. I would like to describe here my method for developing front end code in particular. All of these techniques will probably be familiar to seasoned web developers as they have proven their worth over the years. In this entry I will only give a general outline of my methodology, leaving the task to go into the finer detail of each technique for other articles.
The first principle I apply to web development is progressive enhancement which, in simple words, implies developing in layers, beginning with the HTML layer, which represents the content, and progressively moving to CSS to add presentation and then to JavaScript to add behaviour to the content.
The best way to go about this is to construct semantic HTML based on the content for your website. This clearly implies that you first need to have either the actual content for your website or a very accurate idea of what this will be before you start writing a line of code. This is mainly for two reasons: the first is that, once you know the actual content of your website, it is then easier to think which HTML element provides the better semantic representation of your content. The second reason is that, by starting with the HTML first, you set a solid foundation for the subsequent layers and avoid putting design and behaviour considerations before content. Remember: in the web, content is king. Semantic HTML and progressive enhancement are the next two principles I apply to web development.
After having a solid base of HTML I can then move on to thinking about a few, two or three maybe, different layouts and then, based on the chosen one, adding styles to the site or web page. A technique that helps me tremendously in this and the next phase (adding behaviour) is that of coding a little and testing often; what I mean by this is quite simple actually. What I do when I am adding CSS is to add a few styles and then test the changes in all the browsers that I have previously defined as required to be supported. This lets me iron out any discrepancies and browser bugs early during development instead of having to deal with a finished design that totally breaks in one or more browsers. I find this particularly useful for debugging problems with Internet Explorer; as a result of coding a little and testing often I can identify IE bugs very early and address them as they arise. I make use of conditional comments for IE in order to fix its bugs and I have found that, by using the technique mentioned above, I usually end up with very few lines of IE specific code that address specific bugs in a very specific way. This in turn keeps my main CSS files clean and hack free and it keeps the IE specific code isolated so that it can easily be modified or removed in the future if the particular IE version doesn’t need to be supported any longer. When using CSS3 properties I go with the commonly accepted technique of using vendor prefixes.
Finally, I add the behaviour layer; the JavaScript. This adds enhancements to the page or site so that its usability is improved but in no way is the JavaScript used to provide functionality that is both fundamental to using the site and unavailable in circumstances when JavaScript is either partially or no supported at all. This is where having a solid HTML foundation also shows its worth since all enhanced JavaScript functionality, when vital to accomplish the core tasks of the site, will have its equivalent in the plain HTML version. This is often easier said than done and each particular case offers its own challenges and compromises that sometimes have to be made in order to maintain usability and accessibility, but the results are worth the effort since an accessible website is usually more usable for all visitors and can also rank better in search engines.
I have a set of preferred tools when accomplishing all the tasks mentioned above. One of the most useful is Firebug, a very well known add-on to Firefox that makes many development tasks a breeze and which has set the standards for similar tools that most modern browsers now include as default in their configuration. So, along Firebug, I also use the IE developer toolbar, Chrome’s and Safari’s developer tools, and Opera’s Dargonfly since these are the browsers that I support in most of my projects. On top of that, I use Virtual PC with images for the other IE versions different to the one I have in my development PC and, of course, any useful text editor. These days I use Komodo Edit, but I have also used Crimson Editor, Notepad++, Eclipse and plain Notepad. It also helps to have a local web server (Apache is a common choice) to run my pages from there.
The above steps summarise my methodology for developing front end. I have found that, by following the simple principles of progressive enhancement, semantic HTML, content before presentation and behaviour, and code little and test often for cross-browser compatibility; my task of creating cross-browser, accessible and usable websites becomes a lot simpler. I keep learning new techniques all the time and I try to incorporate them to this process in order to further enhance my skills. I hope that this short writing is found useful by readers trying to understand the process of creating front end code for the web; my aim is to expand each of the mentioned techniques and tools in future entries.