• filed under
• Web Design

One of the questions I face a lot when presented with a problem in web design is this: should I build it myself? Or should I take something off the shelf?

The Web today is full of "time-saving" alternatives to us coding things ourselves. These sorts of tools range in complexity from really simple things, like a little piece of Javascript to make .png files appear properly transparent in IE6, to extremely powerful tools that perform a huge host of functions, like content management systems. Some of them are more popular than others.

What can go wrong?

Well, a number of things. The biggest is that you're taking a risk by using someone else's code. You don't know how it works. You won't be able to modify it without breaching what may prove a steep learning curve. Such things often break in unpredictable ways. People don't set things up the way you expect. You can cause bugs in places you never expected them.

There's a risk associated with using these shortcuts, which you're balancing against the risk that you might not finish the project in time without them.

So how do I choose?

There are a few questions I usually ask myself before I choose solutions like these:

Does it work?

This ought to be a no-brainer, but it's often skipped: before you commit to using something, make sure it does what it's supposed to. (If it's not easy to test yourself, wide adoption is often—but not always—a good indicator of this.)

How long would it take me?

If you're going to use a shortcut, it should at least be saving you time. This is why I don't use CSS frameworks (like the increasingly ubiquitous 960.gs). Sure, it's nice. But I can throw together a custom CSS layout for a site that works as well or better in about the same time it'd take me to put the framework in place and tweak it the way I like it. I'm picky, and it's just not that complicated.

What does it prevent you from doing?

Shortcuts are often limiting. For example, there's a really elegant script called s3 slider, built in jQuery, to make a rotating image/link gallery. It's gorgeous—one of the most elegant examples of its kind, honestly. But it's restrictive. To set up buttons to skip to particular items in the s3 slider, say, you'd have to alter its core functions (which means first going through someone else's code to figure out how that might work).

By contrast, jCarousel Lite isn't as pretty out of the box, but it's massively configurable. It doesn't limit you. It's not that s3 slider is bad: if s3 slider fits your needs exactly, by all means you should use it—but if it doesn't, or if you think your needs might grow in future, you're better off using jCarousel Lite.

Is it extensible?

This isn't always important. In the case of a small element, like the slider managers I discussed above, it'd probably take you longer to learn a plugin architecture for them than it would to just reprogram them from scratch. But when you hit the really big projects, extensibility is key.

Realistically, you'll never hit a content management system or a JavaScript framework (or anything of comparable complexity) that does everything you want it to, out of the box. But it's easy to build a plugin for jQuery or WordPress or ExpressionEngine—and there are tons of plugins already built for them. If you've picked a good system, it'll be saving you so much time that learning the plugin system will still be worth the effort.

In summary...

There are some really great systems out there that have saved me huge amounts of time, like jQuery, jQuery UI, and ExpressionEngine; there are plenty of others, like Google Maps, Google Checkout, or sIFR, which let me do things completely beyond my abilities and/or resources. Plenty of others have proved exercises in frustration.

In general, I'm skeptical of timesavers and tend to want to build my own solutions where and when I can. But carefully selecting smart pre-built solutions can save a whole lot of time.

There's no point reinventing the wheel. Just mind the square ones.