front-end quality levels

how to define quality

If you ever had to judge the code of someone else you might already know how difficult it is to put some kind of grade on it. Not only because of differences in coding styles, but also because the quality of good front-end code doesn't really show itself at face value. The quickest way to judge is to take a look at the source code of the html, css and javascript, but that will only tell you so much.

I'm not too interested in defining a grading scale, as that is quite impossible anyway. I think it's more important to define what areas and scopes there are to define the quality of front-end code. In my experience, there are four important levels that need to be taken into account. I'll start off with the easiest and smallest one, working my way up from there.

1. making a page

This is where it always starts. You make or receive a design, sit yourself down in front of your computer, you pick your favorite browser and start work. Writing html, css and javascript to match a design and functional breakdown is quite the challenge in the beginning. As a non-designer it took me some time to understand the delicacies of good design and to translate those to a web page. On the other hand, this is probably the easiest part of the job.

Apart from design issues, you also have to worry about writing valid code and you have to make sure that your page is accessible to people not using regular web browsers. For most people this will open doors to a whole new and unfamiliar world, but it's essential for the overall quality of your code.

Checking the quality of this first level is quite easy. Code validators, a quick glance across the source and quickly scanning the page with css turned off will tell you a whole lot. But of course, this is only the beginning.

2. making a page work cross-browser and cross-platform

Time to zoom out. Making one single page to work in your favored browser is one thing, making sure it works okay in a range of browsers and operating systems is a whole different challenge. First of all, it is important to note that it's not necessary to have the page show up exactly the same in all browsers. For older browsers it suffices to make it look and work okay, just without the fancy stuff. It is important though to make sure all the functionality is still there. Sacrificing essential functionality is simply not done.

Usually worrying about browser-compatibility is something that happens afterwards, but it's actually important to have it in mind when you start on a project. Some techniques work better than others, some techniques are easier to fix than others. Choosing the right ones from the beginning will make browser-testing and fixing so much easier for you. Knowing the ins and outs of browsers and slightly changing your code course to steer away from the biggest issues is a long and tiring process, but it helps to improve the quality of your code by a great deal.

Measuring the actual quality of this level is a tad harder, though the length of the browser-testing phase is a good indication of this. The better you get, the easier it becomes to tackle browser problems, and the faster you'll be at making sure all browser show a page in an acceptable way. But even then, some extremely obscure bug might keep you up all night.

3. making a site

Time to zoom out once again. A site is more than a simple collection of pages. You'll notice that several components will be featured on different pages within the site, you'll also notice that css and javascript files will be used across multiple pages within the site. Keeping your code consistent across all those pages might be a lot harder than you first imagined.

The key is to think in components. html is a descriptive language, so independent of visualization or context, a certain "block of content" should always be constructed using the same html. An example I like to use is that of a news article. This can appear in a separate focus block, in a summary list, as a search result or as a whole on a detail page. Essentially it is always the same thing (a news article), so the semantic part of the html (also think class names) should be the same for all these instances. Variations in design should be based on context or by defining variants (adding an extra base class for differentiation). Once you got all of this covered, writing the correct css and javascript should be a a lot easier and code duplication will be reduced.

This level is actually quite easy to check. Simply take a few pages from a site, single out a few components with clear design variants and check how they are constructed and styled. If there is no common base, this will surely affect the quality of your site in the long run.

4. stability and flexibility

The three levels above are all important, but even matching all three criteria the quality of your code can still be quite subpar. Your code will only truly shine when it proves itself to be stable and flexible. The problem is, you can only measure this when it is effectively too late. You can look for several indicators though.

The first one is when you've reached the point of "the 5 last bugs". These are either last minute changes or bugs with a slightly lower priority you postponed because they are quite hard to fix. You know you did a good job when you can quickly dispose of them. On the other hand, if fixing these bugs introduces new ones or requires reworks of complete sections, there is still plenty of room for improvement.

Another good indicator is "phase 2". How well prepared are you to incorporate functional and design changes without ruining half your site. Can you drop an existing component somewhere else without having to rework the whole css? Can you make your left column wider by only adapting a minimum of css values and without recutting any images? Can you create a design variant of a component without having to deliver new hmtl code? How easy is it to switch places for components? What if a breadcrumb spans two lines? All these elements are indicators of the stability and flexibility of your code.

conclusion

If the quality level of scope 4 isn't met, it might cost you a lot of time, effort and money. Simple questions of your client will have to be answered by complicated technical answers your client doesn't really care about. It will lead to overtime, missed deadlines, stress and a decline in the relationship with your client.

It is a serious learning process though, as flexibility and stability are only attained by mastering the first 3 levels and evolve from there. If you want to improve your skills, take a look back at the project you just finished and grade yourself on these four categories. See where you've slipped and think of ways to make sure it won't happen again. If you do so with each project, the sky is the limit.