random posts about nerdy stuff

Pros and Cons of Using a Website Template

For some, the idea of being able to download a pre-built website template sounds like the quickest way to get a site up and running. Though this is the case for some, it may make things even more time consuming in the long run. As with any web project, it is important to have a good plan, including a site hierarchy, user flow, goals and an idea of what sort of content each page might include.

Benefits of using a pre-built theme:

  • Template is a complete, working website out of the box
  • It may include some fancy features that being part of the template, you don't have to build from scratch
  • Theme developers may have spent time making sure the design is mobile friendly and works well across a wide variety of web browsers

These are all things that can help speed up the development process and let you focus on content rather than building a site from scratch. Things like browser compatibility, responsive grids, charts and other animated features might be there ready to go.

Question to ask yourself is "Will my content fit into this theme?"

If you're lucky enough to find a theme that is in line with the site you're building, going with a theme is a fine idea. Here are some great places to find Wordpress and other website themes:

When not to use a theme:

  • A theme doesn't match your content
  • Many updates are required to change the look of the theme to your needs
  • Theme isn't frequently up to date or well supported by the author
  • Comes with a long list of bells and whistles that you don't plan to use

It makes sense that a theme developer will try to fit every possible element and feature into their product, especially when it's one that's for sale. However, if you plan to use a theme as a starting point for your project but don't plan to use many of those extra features, those will just get in the way causing your site to run slowly.

Many systems are so full of these little features or elements you don't want, you might find yourself spending more time just getting things to work than you would simply building on your own.

Design is a big issue for most themes. By using a theme that isn't designed around your content, you aren't able to gain a benefit you would otherwise get from a designer's design which considers your user's experience, calls to action and other elements that may better get your site's point across.

You're the developer, build it yourself

If you're a web designer/developer, your best course of action is build your own stuff. Build from the ground up using tools you can depend on and learn some new tricks. If all you do is rely on a plugin for some site feature, you won't get the benefit of learning how things work. The fewer things you learn how to do, the quicker all this web stuff will start to go over your head. Sure, it might take some time in the beginning, but the benefit is an increase in knowledge and a lean, mean, end product that works great.

A starting point isn't a bad idea though. Things like Bootstrap or other CSS frameworks can save you time when putting together a custom UI.

The Comping Process

When designing a website, the first step is and should always be scoping. This scope is what defines every other aspect of a web project, from cost to content to design. When the design process begins, there are three ways to approach it.

  • Design a static comp in Photoshop or other design software
  • Build wireframes that position things how they might look in the final product
  • Start in the code and build using HTML and CSS for a functional comp

Static Comp in Photoshop

This has been the standard for years, which lets the designers with the experience review the scope and build the look and feel of the site with tools the designer knows well. The end result is a file or series of files that are static images that act as screenshots of what the end product might look like, filled with placeholder or actual site content.

Pros: The design is put together using design tools by an expert in design. Designer defines colors, block treatments, fonts, etc, and the developer takes these resources when stepping into the code.

Cons: Not all designers might be as familiar with how things work in a web environment and may design elements that look great but might not work as well. This creates an uncomfortable position for the developer where an approved look may be time consuming or difficult to translate into a website.

Build Wireframes

For a more data centric, or agile design process, it might be more efficient to simply wireframe the layout and begin development with the goal of defining images, colors and other design related elements later.

Pros: Get started in the code quickly

Cons: Not as much time or focus spent on user experience or the user interface (UX/UI) which may result in a design that's a bit bland.


For many sites, a comp isn't much more than blocks of content or media that are displayed in the browser using HTML and CSS. By starting here, you're addressing two steps of the process at once. This is best handled by a designer who is also a developer, one who knows HTML, CSS, mobile as well as core design principles. By building in the browser, the developer won't get hung up on margins and padding or other inconsistencies that might be included in a Photoshopped comp.

Pros: A design will have to be turned into HTML/CSS at some point anyhow, might as well start there. Some things are quicker and easier to do in HTML and CSS than they are in Photoshop, such as globally changing colors. In addition, you can easily create both mobile and desktop versions of the design at once using CSS media queries so that the client can preview how it'll look in all environments.

Cons: Revisions, especially ones where the client doesn't like the design at all, become potentially more time consuming possibly requiring a larger amount of work to be scrapped. This is also potentially a longer process to complete initially, but minor edits might be simpler and quicker to make.

Best Option

Depending on how a project is managed and scoped, the ideal solution is to come up with a static comp along with a style guide or Style Tiles. This guide defines colors, fonts, sizes, buttons, and other design elements to be used everywhere else. Buy starting with a guide, a developer or designer knows how something should look and ensures that each page follows the same design rules.

Using a BaseURL in Your Code

Each developer's system is different. When setting up a codebase for deployment in different environments, it's important to define your globals in such a way that they're easily changed to work in each environment. My local development environment uses MAMP Pro with all of my sites in a ~/Sites folder on my Mac, organized by a series of parent folders.

My site's configuration file lets me define a unique set of details based on my environment, whether it's a subfolder on my localhost, a dev site subfolder on the remote host or the live site itself. These unique values might be database connection credentials, paths to server files, or settings on whether or not to show debug output or send emails.

Here's an example of a conditional that sets some constants for when I'm working locally on my primary computer. The DOCUMENT_ROOT is the path to a secondary volume on my mac called "Data", which I know is unique for my own environment.

if($_SERVER['DOCUMENT_ROOT'] == '/Volumes/Data/Sites'){
    define('ROOTPATH', '/folder/');
    define('ROOTURL', 'http://localhost/folder/');

The code can use this snippet to determine what ROOTPATH and ROOTURL to use when it's running on my local machine. Some other developers use ABSPATH or ABSURL (ie: absolute path, etc). That ROOTPATH and ROOTURL can then be used in my code to ensure things like links, images, and other urls are all pointing to the right stuff. When building out my code, all I have to is make sure I include those values when referencing site assets, like in this example image tag:

<img src="<?=ROOTPATH?>images/logo.png" alt="My Logo" />

If I pass my codebase off to another developer, all they need to do is update the configuration file with their own environment details, paths and other settings that might be applicable. Good code setup means you can easily change something once, in just one place, and that update is reflected throughout the site.

Never assume a site path is in the root of the domain.

In the code blocks above, note that I use a ROOTPATH and a ROOTURL variable, which have different values. For any site elements like images that are pulled from the same domain as the website, I use an absolute path minus the parent domain. This way, the assets don't require looking at the full domain path to download the file, a minimal, but handy page load benefit.

CMS systems like Wordpress have something similar, though their Site URL values are hard coded in database content. This means that if you assign an image to a post, that reference to the image is a full URL, http:// and all, to the image asset. There are scripts out there that will search and replace one URL string to another, however this adds an extra step when moving a site between environments.

If you plan your code right, other developers should have an easy time setting your codebase up on any supported environment. Server paths differ per environment, so it's best to plan for the inevitable and make it easily updatable.