Top Five Goals for Front End Developers
by Matt Garvin, published 2011
As Front End Developers, one of our most frequent tasks is to translate Photoshop mockups created by a designer into HTML/CSS. We pride ourselves on our ability to create Pixel Perfect translations that keep the designer smiling and make sense code-wise for when we hand our templates off to the rest of the team. Here are the top five goals that I strive for when translating a design into code, which I present in order of priority from most desirable to nice-to-have.
Goal Number 1: Your pages must look like the designs you were given in all targeted browsers.
I love being looked at by graphic designers as "the guy that made my designs look the way I designed them" in a browser. Those are the guys that really care, much more so than the Project Manager or another code jockey. So that is first and foremost my goal.
If the designer is happy with how I got his work to render in IE6, I know I have done a good job.
Of course, it is not possible to guarantee that the code renders 100% the same in all browsers; this is the web, not television. But it is usually possible to get very close, especially in modern browsers like IE8, Firefox 3+, Safari 4+, and all versions of Chrome (since it auto-updates and users always have a latest version). For other browsers and older versions of IE, it is still possible to get very close (though for IE6 usually through a considerable amount of work!), and that is always my goal. If the designer is happy with how I got his work to render in IE6, I know I have done a good job.
Goal Number 2: The HTML/CSS must validate with Zero errors.
The second thing that makes me happiest as a front end developer is when my pages are looking perfect, and at the same time I can see a little green checkmark in the bottom righthand corner of Firefox that tells me "this page is 100% Valid Markup with 0 errors and 0 warnings." Of course, this is something that 99% of users surfing your site will not notice or even care about. But the developers and other members of your team -- that will be looking under the hood as they integrate your code with their own -- they will care. Big time. Valid markup and CSS means code that is easier build on, code that is easier to debug, and code that is more likely to resemble what other front end developers who really know what they are doing produce. For the record, there are a number of Firefox plugins you can use to validate your code, but the one I like (that gives me that cute little green checkmark) is HTML Validator by Marc Geury (http://users.skynet.be/mgueury/mozilla/).
Goal Number 3: The HTML is "semantically correct"
"Semantically Correct" means that the markup used represents what it is. Lists of things are in list elements, the most important heading uses an H1 tag, paragraphs are in Paragraph tags. If there are tables, they are for tabular data. There are a number of advantages to coding semantically correct code, including SEO considerations, page load considerations, and accessibility considerations, among others. With a couple exceptions, I buy into the Semantics line of thinking. Especially if you are only worried about "modern browsers plus IE6". So, as part of my development process, I view my pages with all CSS disabled, and make sure that they are still workable. Doing this "markup only" test is the fastest way to identify how semantically correct your markup is.
Goal Number 4: All code is "Developer Friendly"
To me, "Developer Friendly" means that the code is ready to be handed off to others on my team. It is likely other team members – especially the .Net guys! -- have much less understanding of HTML/CSS than I do, so my code must be "developer friendly". That is, the code must be clean (see goals 2 and 3), the code muse have sensible commenting, and the code must have sensible indenting. When a developer looks at my code I want them to "clue in" to how it works without any extra thinking.
Goal Number 5: Pages must be optimized for Fast Loading
Slow pages make for a poor user experience. Period. Though he has said so many times, you don't need Jakob Nielsen to tell you that. We have all experienced the World Wide Wait.
"A snappy user experience beats a glamorous one, for the simple reason that people engage more with a site when they can move freely and focus on the content instead of on their endless wait."
There are many resources with tons of recommendations for optimizing page loads, but for the front end developer handing off HTML templates, I would say the most important recommendations are:
- Clean, unbloated HTML and CSS
- Using as few images as possible
Number one is a no-brainer and needs no elaboration. Number two ties heavily with earlier goals mentioned in this article. HTML should be as sparse as possible. Special mention needs to be mentioned of avoiding over-use of DIVs. Number three means using as few images as possible, and ideally using one or two larger CSS sprites instead of many individual images. The idea is to reduce the number of HTTP requests.
When I am developing templates, I do not meet the above five criteria "one-at-a-time". All of these items play off one another, and at the same time I am coding valid HTML/CSS, I am also making it semantically correct, and also making it developer-friendly. But the first goal I have to meet is it has to look right in the targetted browsers. So if I am doing a particularly tough design, and time is tight, the other goals will have less attention paid to them while I focus on "getting it right" in a browser. And Number 5 -- especially moving images into a sprite -- that may be left out all-together.
Ideally, however, there is time to get the look right, and meet all of the other goals as well.