Why You Should Build a Front End Package

by on 12th February 2010 with 22 Comments

How do you begin building a website?

The majority of developers probably start from scratch or pull in a few resources from previous sites. The more organized among us have developed a custom toolbox from which to begin a site that proves to be an essential part of their workflow.

Today we’ll discuss why you should consider building your own front end package to serve as a starting point for every single site you create.

What Is a Front End Package?

What I mean by front end package is essentially a set of tools and conventions that standardize certain elements of the web development process. The inspiration for this article comes from the creative minds at Erskine Design. As a designer, you’re probably a visual thinker so we’ll cut straight to the diagram:

The Basic Outline or Erskine’s Ultimate Front End Package

screenshot

As you can see, Erskine has essentially built a basic framework from which to jump off for major web design projects. They sum it up as “a bumper compendium of cascading and connected CSS files, naming conventions, modules, plugins and library scripts that ensure any project led or worked on by any member(s) of the team will stay on convention, and be simpler for anyone else to step into and work with at any time.

Possessing such a framework can be invaluable for a number of reasons, which we’ll discuss below. The argument posed by some is that such a framework or toolkit is not only helpful, but absolutely necessary. Erskine Design’s Simon Collison goes so far as to say “Without question or compromise, every website needs to be built with a solid foundation layer and an Ultimate Package.”

Let’s take a look at some of the benefits from, and reasons for, building your own custom front end package. (Based on some of the suggestions from Erskine’s Presentation, found here)

Elimination of Repetition

This is the most basic and understandable reason for developing a front end package. Every time you start to build a site you go through several setup steps such as forming the bare HTML structure, creating the external CSS files, linking the HTML to the external CSS, importing jQuery and/or any other JavaScript libraries you often use, etc. Developing a front end package recovers all of this lost time by making it extremely easy to start a new site: just copy the folder containing the framework and you’re up and running.

You might argue that these tasks don’t take a significant amount of time or are even necessary to get your brain into a web development mindset. To answer these arguments I would first suggest that you time yourself to see just how long you lose on every project getting your file hierarchy in place, setting up and loading scripts and styles, figuring out naming conventions, and fixing sloppy mistakes. I’ll wager it’s a lot more than you think. Finally, to the latter argument I would challenge you to retrain your brain to accept a new part of the process as the beginning. Try jumping right into experimentation with your system in place and discover how much nicer it is to skip all of the tedious, repetitive tasks.

Standardization

Standardization is a major benefit from using a prefab toolkit. Every time you start a new project, you might do things slightly different. This can be something big, like changing the way you layout your HTML, or something small, like deciding on a new naming convention. This can make it extremely difficult for others to follow your work or even for you to go back later and remember how you were doing things at the time.

As you develop your front end package, keep standardization at the forefront of your mind. Decide on the best way you know to do every little thing and stick with those conventions through every project you start. Markup your comments the same way, organize your CSS the same way, use the same variable naming conventions, utilize the same folder hierarchy, use the same CSS resets, etc. Taking all the little decisions and guesswork out of your system has the benefit of streamlining the entire development process to ensure you’re creating a discernible, organized site as quickly as possible.

This is not to say you should decide on a system and stick with it permanently. Let it evolve as you learn and discover better methods, just don’t integrate new methods flippantly or frequently enough to void the usefulness of the entire package. When you decide on a better way to do something, make sure you are absolutely certain that it will improve your system and be sure to make a note outlining the change and when it was integrated so you know what to expect from older projects.

Better Collaboration

This is where a front end package crosses over from “nice to have” to “absolutely essential.” When you’re working with a team of developers on a large project, one of the biggest inefficiencies you can have is a failure to get everyone on the same page from the outset of the project.

If you’ve got Bill structuring his part of the project one way, Jill structuring her part another way, and Will trying to keep up with both Bill’s and Jill’s methods, things are going to get messy fast (and not just because all of your employees’ names happen to rhyme). This will inevitably lead to long meetings spent arguing over trifles. If you have team members that have already started a project using certain conventions, you can bet they’re going to defend that method to the death to avoid going back and fixing what they consider to be finished work. This is why it’s extremely important to develop a front end package in cases where significant collaboration is involved. You’ll probably still have to hold a meeting to decide on specific conventions to follow, but you’ll find that team members are much more flexible to new methods if it doesn’t require backtracking.

The key takeaway here is to develop a system before a project begins, not during. This will increase the chance of acceptance and prevent a lot of incompatibility issues down the road. Also, be sure to include your team in the decision making process. This is hugely important to the success of the package for a number of reasons. First, it’s always a bad idea for management to create a system to streamline a given task without consulting the people who are closest to that task. No matter how many more college degrees you have than the people under you, chances are they are the single best authority on what will and won’t work. Finally, apart from the issue of effectiveness is again the issue of acceptance. If you hand your team a set of guidelines that they’ve had no part in developing, they will drag their feet and complain the entire way because you are forcing them into something they don’t want to do. However, if you let team members from every level actively participate in the development of the conventions, they are much more likely to conform to the new system because they aided in its creation and direction.

Quality Control

Developing a front end package allows you to implement a certain degree of quality control across the members of your team from the outset of the project. It ensures common mistakes, such as grabbing the wrong doc type or forgetting to include a certain browser specific style sheet, aren’t made. Further, having a strict system in place can help prevent intentionally sloppy work. In a mad rush to get a project going, developers will often use non-standards compliant code, vague variable names, obscure tricks, and any number of other shortcuts with the argument that they will go back and fix these things later. The problem of course is that there usually isn’t time to go back and fix these things later in the project as you approach key deadlines. Many of these problems will disappear if your foster a culture that avoids such practices and discourages straying from agreed upon conventions.

In Regard to Design & Innovation

Before I close and ask to hear your opinions, I want to preempt an argument that might arise. Many see common conventions and strict rules as something that will cripple the design process, virtually eliminating any room for creativity or innovation. This simply is not the case in this instance and is in fact the opposite result of what a well-designed front end package will provide.

A good front end package will actually allow you to focus more on the creative elements of the development process through standardization of areas that eat up time and whose variation would not making a significant difference in the end result. What I mean by this is that such elements as your folder hierarchy will go completely unnoticed by the end user and are therefore not the place to focus your creativity on every single project. The idea here is to get through the boring stuff in one fell swoop so that you can quickly dig into the things that do, and should, vary from site to site; the things that make each site unique. With this type of system in place, you can spend more time developing original user interfaces, choosing custom color schemes, trying different font-families and coding innovative functions.

If the system you come up with hinders the creative process, it simply isn’t doing its job and should therefore be scrapped in favor of a trip back to the drawing board.

Free Resources

Sold on the idea of developing your own front end package but don’t know where to begin? Here are some free resources to get you started.

Speak Your Mind

The above represents my long-winded argument for why I believe Erskine Design is right in asserting that every website should be built from a strong, standardized and preset foundation. Let us know if you think developing such a system is worth your time. Better yet, if you have a system in place, let us know how it works!

Comments & Discussion

22 Comments

  • http://www.mcgdesignstudio.com MCG Design Studio

    Fantastic! This will make building websites so much easier, there is no need to faff around and remember where you stored all your necessary files. Now if i could only use “standardisation” within my designs…

  • http://bass.MAKEMYWISH.INFO New York Web Designer

    Super concept! When i was a Fresher, i was looking for something like this. I have Bookmarked, future reference.

  • Pingback: This Article Discusses Why You Should Build a Front End Package « Web Page Authority Blog

  • Pingback: links for 2010-02-12 | AndySowards.com :: Professional Web Design, Development, Programming Freelancer, Hacks, Downloads, Math and being a Web 2.0 Hipster?

  • http://www.visualswirl.com/ Chris Thurman

    We’ve experimented with such a site template and even go as far as creating a folder that includes templates for client forms and deliverables (sitemaps, etc.) It works for most and if we decide not to use it for a certain project, that’s okay too. Great post!

  • http://www.musings.it Federica Sibella

    Very easy and really useful, everything at a glance, I do something like that (like “deliverables” and “useful stuff”), but not so standardised. I’ll give it a try, thanks!

  • http:///www.digital-results.com Russell Bishop

    You raise some excellent points in regards to the reasoning behind such a framework. We’ve been using a similar model for a few months now, and it’s made the whole development process radically smoother.

    We’re always adding and editing it, to further streamline the processes we’re carrying out during construction.

    My only issue is the name you have for it! “Front End Package” is not a term I want to be using in the office, we’ve opted for “The Box” instead.

  • http://www.merixstudio.com Kamil Kaniuk (Merix Studio)

    So true! We have built our own model too to make xhtml/css coding even more cost-effective.

  • http://www.brunoatwork.com Bruno Monteiro

    Already working with my own Frontend Package. It doesnt differ from this one. Actually i’ve updated/improved my own with some elements of this one ;) Got mine in “Portuguese”. Big thx, great post!

  • http://www.modeten.com ModeTen Designs

    The concept is solid and logical – as many above have said – been using it for a while. The main use here is for larger agencies and projects where people change frequently, or multiple team run the same job. Smaller agencies and projects will probably need a lighter set of rules!

  • http://www.ghosthorses.co.uk Stephen Fairbanks

    This is very useful article, it’s amazing how much stress and headaches can be resolved by putting in place a simple package that keeps everyone working on a project on the same page.

  • http://www.ponjoh.com Pontus Johansson

    To be honest, I thought everyone did this. At least to some extent.

  • http://www.rorschach-design.com rorschach design

    Enjoyed the article a lot. I’m a new designer and I’ve thought about doing something like this before, but after reading the reasons as to why designers use a pre built system, I realize I HAVE to do it, if I want to focus on the important things…the job at hand.

  • http://mumsstudio.com Bjarne // Mums Studio

    Thought of this like 100 times. Never done enything about it! Now it’s in Things on my “Today” list. Meaning I’ll make this “starter-kit” tomorrow…

    Thanks for pointing it out! :)

    Cheers

  • Pingback: All Teched Up!! « Caintech.co.uk

  • http://www.BuildingZone.com.au James Waugh

    I’m already working with something very similar to what you describe here – but picked up some very useful tips to add to my approach. Thanks, and Well done!

  • Pingback: Blendia » Blog Archive » Why You Should Build a Front End Package

  • Pingback: Mes favoris du 20-02-10 au 21-02-10 » Gilles Toubiana

  • http://www.103graphics.com elmalak

    the idea seems cool to me especially as I am used to the same concept in creating WordPress themes.
    I prefer to use blank starter themes instead of creating all files from scratch.

    I agree it does save time and effort and provide consistency in work.

  • Pingback: ブランクプロジェクトフォルダで効率アップ | CSS Radar

  • http://www.circulationstudio.com Brian

    For streamlining boilerplate workflow check out CodeKit if your on a Mac. Otherwise, get a Mac and then check out CodeKit. Especially, if you are using Less.

  • http://www.kingkroell.co.za Website Design Durban

    Great article, I always keep a file and folder template that is consistant through out all my projects. Helps a lot when a couple site’s need to be updated, you can easily find where everything is and save time!

Subscribe
Membership
About the Author