random posts about nerdy stuff

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.

Virtual Machine Wallpapers

As a web designer, I have to open up multiple verisons of Windows running various web browsers and versions of each. To do this, I've found that VMWare Fusion works great. I can run most any operating system right on my Mac without needing multiple computers on my desk. To keep things tidy, I put together some consistent desktop wallpapers for each operating system that matches the OS branding colors. Most Windows primary color is blue, but they each have their own unique hue that sets them apart from the others.

VMWare Fusion Screenshot - multiple versions of Windows

If you have a similar setup, or just want some super-simple desktop wallpaper to remind you which version of Windows you're looking at, feel free to download them from the links below.

VMWare Desktop Wallpaper

All images are 1920x1080 in high quality PNG format, perfect for any VM you might want to run. Hope you find these useful.