Improving Your Process: Faster Front End Development

Posted: June 15, 2009 Comments

In our business, time is of the essence. Regardless of your billing policies, as a professional designer it is imperative that you have the ability to accurately estimate a workload and then follow through, on schedule. The ability to estimate work comes only with experience. You can read countless articles on design, even specifically on Web design, but until you get at least a year of consistent, professional work under your belt, it just won’t be there. It’s absolutely no fault of your own, simply because you haven’t worked enough.

That said, depending on your billing structure, you’ll be able to optimize your workflow in such a way that not only reduces your stress level, but will make your clients happy to boot. I mention a dependence on your billing structure simply because sometimes getting a project done well under a time-based budget can result in trouble for you financially. The important thing to realize, however, is that with newfound extra time comes extra polish. If you come in a few hours under budget, you now have the time to try that element you were toying with in design. Does it work now? How about the leading in that area? Would it look better if it were bumped up, just a bit?

Reducing the time you spend on front end development can lead to more experimentation and a better end product should you have extra time to play with late in a project. Personally, I like to keep front end development estimates to a minimum, allowing the budget to focus on design. I work with a team of designers, so the better we plan from the start, the better a project will go.

Have a plan, start with a static file

By far the most effective way to cut down on front end development time is to be involved in the design process. You don’t even have to be the designer, but you should periodically review any design for a basic feasibility assessment. That’s not to say that you should be prototyping designs to make sure something is going to work, but you should be able to process a design to a level that will let you be comfortable with it.

As you examine a design, try to abstract your brain from admiring the aesthetics of the design. Try to visualize how you will approach the front end for this document. Take a look at a comp for another page, can you determine how much markup and style you’ll be able to reuse from the first page to this one? Are there any modifications that should be made to the design to establish some consistency on a more technical level? Take a second look at the design, take a third look. Has someone added a gradient or texture that physically can’t translate to the Web?

Once you’ve signed off on approval for a design and it comes time to begin work, I can’t emphasize enough how much it will help you to start with a static HTML document. Stay away from your server side technology, no matter what it is, and instead use a static file that takes advantage of any dynamic resources you’ve set up.

For example, at my company we’ve established a site framework that we use to begin each project. In this site framework is your usual array of template-supported, server-side powered files that tie in directly with our CMS, and the like. Alongside this set of files are two static files: home.html and secondary.html. These are the first two files I’ll open and work with on a project.

The files are prepped in such a way that the path to the CSS directory is hard coded, removing the need to copy and paste once our original documents have been written. I’ll work my way through a secondary page, then the home page, and once that’s done, I’ll integrate.

Write your markup first, all of it

Nearly two years ago, I wrote about my development and design process. Much of my strategy remains the same to this day, specifically the first steps I take. The initial markup process ties in heavily with the original review of a site design. From the first time I open a PSD or PNG my mind begins working, breaking down the design into markup and markup alone.

I’ll break apart the design into sections, until I’ve found myself at the lowest common denominator, whether it be an h3 or an li. Once I’ve got a general idea of the overall structure, I’ll write it. All of it, from #header to #footer. I’ll switch to and from Fireworks (or Photoshop) and my editor, making sure all of my elements are in place.

Writing the initial markup for a document doesn’t take very long, an hour if you take your time. There really isn’t that much to it, especially if you’ve had a look at the design as it was being put together. You already know what to expect, and you can hit the ground running.

The important thing to keep in mind at this step is optimization. Don’t move on to CSS until every bit of markup is in place to support the design. Sure, you’re probably going to have to add an element or two as you continue development, but getting the initial structure entirely in place will be super helpful when it comes to the style layer.

Use a reset stylesheet

I can’t stress enough how helpful a reset stylesheet is when it comes to optimizing your front end development. It doesn’t have to be Eric Meyer’s reset stylesheet, but working from a consistent base is extremely helpful when it comes to building out your CSS, even more-so when it comes to The Browser Gauntlet.

Write CSS in blocks

I can remember my first few weeks with CSS; I’ve never been so excited to refresh a browser, and I never will be again. With each refresh came a new and exciting change that I was struggling to understand. Learning about CSS was very exciting for me, but it forced me to implement designs slower than ever. As with everything, the more you do, the better you get. As your skill with CSS grows, force restraint on yourself when you think you need to refresh the browser.

Chances are, that property:value; you just set is going to work out just fine. Move on to the next, and the next. Finish setting all the properties you want for that selector and then switch over to refresh. Once you’ve become comfortable with that, style an entire div before refreshing. Once you’ve become comfortable with that, structure your entire document before refreshing, and the move on to styling each div you just positioned.

The more CSS you can write in a single thought, the better and faster you’ll be. The important thing to keep in mind, though, is not to write too much at once. As you’re forcing yourself not to refresh, you may make a significant mistake that wreaks havoc on a few dozen lines of later CSS. Push yourself, but don’t push yourself too far too fast.

Save JavaScript until last

Exciting as it may be to implement, make sure you’re postponing all JavaScript development until last. Integrating JavaScript too early is going to destroy the integrity of both your markup and style, and will cause more trouble than it’s worth.

Instead, take the time to develop the markup and style for any states you may be integrating with JavaScript, and make sure they’re ready to be toggled (or otherwise) via JavaScript. Abstracting markup and style from JavaScript can help you to focus and optimize as you put together a design.

Take advantage of helpful tools

My last tip is something I depend very heavily on; finding the right tools for the job. If there are any applications under consistent development and refinement, it’s Web development applications and tools. Even browser makers are now giving us gold platters with which to work through built in developer tools.

First, find yourself a great text editor. Who cares what everyone else is using, find something that you enjoy working with, and most important: something stable that saves you time. I can definitively say that TextMate (Windows users: e text editor) has had significant impact on my development time.

There are plenty of fancy tools out there, but I can’t stress enough the importance of your editor.

Along with your editor, another integral part of your workflow is your browser of choice. Your browser should support your efforts, providing the tools you need to get the job done. Toolsets for browsers have been talked to death, but a favorite tool of mine has never received much press, and I’d like to heavily suggest your adoption of it.

ReCSS is a bookmarklet that comes from dojo and it’s something I use on a very consistent basis with every project. The sole purpose of the bookmarklet is to force a reload of CSS used on the current document. This helps you to avoid reloading the entire page (including server processing and other latency) and instead request only the latest stylesheets. It’s such a simple idea, but I’ll use the bookmarklet at least a few dozen times per-project to ensure that I’m not dealing with any caching issues.

Let’s have it

Do everyone a favor and post your favorite time saving front end development tip or trick.

Get my newsletter

Receive periodic updates right in the mail!
  • This field is for validation purposes and should be left unchanged.

Comments

  1. I’ve developed a site “Framework” it contains my preferred site directory organization, a basic set of templates, an CSS file with reset and my common conventions built in (I tend to structure my markup and HTML the same every time – why keep doing it over and over?)

    When it comes time to start prototyping the designed site, I duplicate the entire directory, rename it, and go from there.

  2. I’ve been meaning to write about this for a while, but I actually draw out on graph paper a sketch of the design with all the dimensions noted (sorta like a technical drawing/blueprint).

    This not only serves as a quick reference for when I’m doing the actual coding, but also by the time I have everything drawn out I pretty much have the entire thing already coded in my head.

    I’ve already run into and worked out potential problems and know pretty much exactly how I will slice up the PSD, which element will be a background to what, where/how I’ll need to add in son JQuery, etc.

    I’ve found taking the 15-20 minutes or so up front to visualize and plan out how I’m going to code up a template saves me a ton of time during the actual build out.

  3. @afruit: We’ve set up a very similar structure within my company. I hope everyone has at least a few files and a bit of structure to work with prior to starting any project. It’s an absolute time-saver!

    @Brendan: You’re not the first person I’ve known to diagram a quick reference sheet that contains various dimensions with which to work. I haven’t taken the opportunity to integrate such a technique into my workflow, but I can definitely see its worth. Your second point of knowing about problems before you encounter them is the most valuable asset you can have as a front end developer, and it can only come from experience. Taking a short time to plan before getting to work can be totally helpful when starting a project. Thanks for your tip!

  4. Some good tips. Re: writing CSS in blocks before refreshing, another option is to get a good css editor such as CSSEdit (my personal fav) or just using the web developer toolbar in FireFox to do live CSS editing. Cuts down your refreshes to just about 0 while still getting live feedback.

  5. Hey Jonathan,

    Great write up. I am already implementing several of your ideas here on my latest project, and they are helping a lot! Thanks!

    I tried to use ReCSS, thinking it would be awesome to simply click a bookmark to reload just the CSS. Unfortunately, as I use @import to “modularize” my CSS, the ReCSS doesn’t reload any .css files that are imported.

    Otherwise, thanks once again for the write up! I’m really digging your site.

    Pat

  6. ’ve been meaning to write about this for a while, but I actually draw out on graph paper a sketch of the design with all the dimensions noted

  7. I completely agree with the browser refresh tip. When I started writing CSS I was quite excited to refresh. I was wasting hours changing a single value then refreshing.

    If you can’t pull yourself away from the refresh looking to something like CSSEdit with the live preview. It will satisfy the needed instant gratification, while not slowing you down too much. I use it for the final tweaking.

    Overall if you can trust yourself to write CSS in block it will save you time, develop your skills, and confidence in writing good code.

  8. Add a color pallette and font size guide at the top of your stylesheet in a comment. Then you have easy access to your colors and font guide when you need it.

    you can get your font guide from http://www.pxtoem.com.

    example:

    /* COLOR PALLETTE
    main blue: #58a450;
    highlight blue: #b95aff;

    */

    /* FONT SIZE CHART FOR A 16PX BASE SIZE – PLEASE USE PERCENTS!

    6px 0.375em 37.5% 5pt
    7px 0.438em 43.8% 5pt
    8px 0.5em 50% 6pt
    9px 0.563em 56.3% 7pt
    10px 0.625em 62.5% 8pt
    11px 0.688em 68.8% 8pt
    12px 0.75em 75% 9pt
    13px 0.813em 81.3% 10pt
    14px 0.875em 87.5% 11pt
    15px 0.938em 93.8% 11pt
    16px 1em 100% 12pt
    17px 1.063em 106.3% 13pt
    18px 1.125em 112.5% 14pt
    19px 1.188em 118.8% 14pt
    20px 1.25em 125% 15pt
    21px 1.313em 131.3% 16pt
    22px 1.375em 137.5% 17pt
    23px 1.438em 143.8% 17pt
    24px 1.5em 150% 18pt
    */

  9. Hi all, what about real deployment ? i mean deploy the site on the hosting ?

    Which are the smartest and most solid tecniques to upload all and only files that have been modified (or created), in automatic way ?

    Alberto

  10. I would have to say that the single biggest time saver for me is Firebug. I can just write some rough styles then refine in Firebug, while getting immediate visual feedback. I also use a ruler extension for getting things lined up.

    I think it’s a good idea to use a modular approach, that is to have a copy of certain styles and markup that is used often, such as layout structures, typographic styles, forms, and then make changes to suit the project.

  11. For me the best of time saving tools are Clips (in Coda), templates (NetBeans), snippets (Textmate) or whatever you call them.
    I’ve set up clips for almost everything in HTML, CSS and JavaScript. Sometimes it’s much better and faster than editor’s auto-completion or auto-closing tags.
    E.g. I just type “nav”, press TAB and I’ve got UL and 5 list elements with links – a base for site navigation in about 1 second. Love it.

  12. Hi
    Thanks for this great post. I have just indulged myself into the field of front end designing. I wanna know what are the basic things one should keep in mind while preparing a prototype or site framework. I work for a software firm so my designs need to be basic but attractive. Images and other gaudy stuffs are no-no for me. So if anyone can provide me with a list of techniques for improving my designs with cross browser compatibility I would greatly appreciate them.

Leave a Reply

Your email address will not be published. Required fields are marked *