Improving Your Process: Faster Front End Development

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.