Pardon the mess

Ah yes, the semi-annual redesign.

The new site will look different, but looking different is not the reason I’m redesigning. The primary reason I’m revamping this site is because I want to make it clear that I care about a lot more than just being a freelance web developer. There’s so much more I want to write about that the old design – a basic portfolio site – was just no longer suitable. I don’t even know how I want to address creative work on the new site.

The new site is also going to be hosted on githubpages, and powered by jekyll. Mostly, I just want to focus on writing there, not on overhead and I’m pretty well done paying hosting for myself.

Ah, Web design.



Web Typesetting Basics

Web Typesetting Basics

A list of some good, basic, easy to implement practices.

Web Typesetting


  • Set body copy first, and make sure you set it relative to REM (so we can make other measures on our site relative too).
  • Acceptable sizes for body copy range from 12-21px. When in doubt, use 16px.
  • Pick a scale, and let that set the sizes for your headings.
  • Enforce line lengths of 75 characters, max. 45 is a good character count
  • Line heights for body copy will range between 1.2 and 1.55, if using acceptable line lengths.
  • on larger screens and for larger type (19-22px), line heights between 1.6-2 become useful.
  • The longer the line length, the taller the line height
  • Use the regular variation and regular weight of a font for body copy, unless there’s a compelling reason not to.


  • Establish distinct, clear, and consistent anchor styles
  • Unless there’s a compelling reason not to, design for your body copy to be dark gray as the base color.  If you want to use completely black text, try using an off-white background.
  • Avoid using light text on a dark background for body copy (though this is just fine for buttons, calls to action, and navigation elements where there’s less to compete with)
  • Always check to see that your color choices are WCAG compliant (AA is a 4.5:1 ratio).


  • Make sure there’s enough variation between your heading styles that a user can tell what is an H1, an h2, etc. at a glance
  • Reserve H1’s for page titles
  • Header sizes can get quite large but most H1s range from 30px to 72px.
  • Line heights for headers generally range from 1 to 1.4 – the bigger the Heading size, the smaller the line-height.
  • As screens get smaller, both the size of the headings and the line heights ought to shrink.


  • use the equation of (element size * line-height) + margin = multiple to establish a baseline grid height
  • When every element that you’d use in an article has a multiple that is divisible by the baseline grid height, you should have vertical rhythm for the majority of your content.


  • Keep your font kits to 5 total variations or less, or 100kb or less.
  • Use web fonts to ensure a consistent, attractive and meaningful design effect.
  • Even if you use a “system font” instead of web fonts, set type with care and be aware your design may vary from device, browser, and operating system.
  • Consider using a font loading strategy, and when I say to consider, I mean, implement a font loading strategy.
  • Use a fallback font. You don’t need to go overboard here, 2-3 fonts, max.

Complex WordPress IA part 3: WordPress Parent – Child Pages

This is part 3 of a 3 part series looking at how to achieve less straight forward relationships between data on WordPress.  Read Part 1 and Part 2 here.

For our last part we’re going to extend something that WordPress does have, namely, hierarchical pages.

In this example, we’ve got a Parent Page and each Parent has multiple Child Pages.  We want to do two things; first, use WP Query to display the children on the parent page, and when we’re on a child page,  to show a menu of the Child’s sibling pages (that is, other pages with the same parent).

List Child Pages

Before we actually write our query, we need to tell WordPress to use this page’s unique ID in order to only show this Parent’s children. We could just get the integer, but we’re going to create a variable so we can use this for other parent pages with out manually updating our code for each id.  This is also really important when you’re thinking about developing locally and pushing your changes up to a development environment (and from there, a production site).  Fortunately, this is really simple. The WordPress function get_the_id gets the ID, and we’ll store it in a variable $postid.

The next step should look familiar to you by now. In to our $args variable, we’re going to pass these options: 'post_type' => 'page', and 'post_parent' => $postid.  We pass args in to a new query like so: $query = new WP_Query( $args ); and then we’ll pass our $query in to the WordPress Loop, like so: if ( $query->have_posts() ) : while( $query->have_posts() ) : $query->the_post(); .

Don’t forget to close your loop with endwhile and endif,  and if you have other loops you need to account for, wp_reset_postdata never hurts. Inside your loop, write any markup that pleases you. Generally for this purpose, I prefer to use an unordered list and list items.  That’ll do for your parent template.

Sibling menu

But once we’re on a child page, it’s not a bad idea to show a user what else is on this heterarchical level. On the child template (or wrapped in a conditional on what ever template you plan on using for children), let’s define our $children variable.

We’ll use the WordPress function wp_list_pages and set the child_of option to post->post_parent.  When you’re done setting the rest of the options the way you’d like, we’ll pass that variable to echo in a separate unordered list.  Simple, right?  Here’s the full code:

if ($post->post_parent) { $children = wp_list_pages( array( 'title_li' => '', 'child_of' => $post >post_parent, 'echo' => 0, ));} else { $children = wp_list_pages( array( 'title_li' => '', 'child_of' => $post >ID, 'echo' => 0, ) ); }if($children) : ?><ul class="nav-list"><?php echo $children;?></ul><?php endif;?>

Styling the Sibling Menu

We’re going to base our styling around this responsive pattern. Although it has a small javascript dependency, it allows to keep our menu present in the flow of the content and allows a user to use the native tools on their smartphone.  For screens over your typical mobile device, we’ll just situate it inside of our container as a list like other navigation. Easy and robust!


Information Architecture is just making sense of your mess.  It’s a subtle craft and on good sites and applications, a user will never see the IA at work.  Unfortunately for you and me as Front End Designers, we have to understand the intent of the IA, be aware of the limitations of the platforms we use, and discern the best methods of building out the site based on both. Now, at least, you’re armed with a tool kit to tackle more complex information structures in WordPress.

Responsive Images

Update 2: this technique – the padding box aspect ratio – is featured in Ethan Marcotte’s excellent book Responsive Design: Patterns & Principles.

Update: My good friend Russ made a JS Fiddle of this. Check it out!

More than any other single problem,  Responsive images illustrate *why* front end design is so difficult.

Responsive Images have too many solutions

There are a ton of solutions to responsive images, and this is one of the giant problems with figuring out how to solve them.

Here are some of the common approaches:

  1. width: 100%; height: auto;
  2. Interchange – swapping out images based on media queries (either via show/hide css,  javascript or using the picture element and a polyfill)
  3. Cropping
  4. background images (which have long had better support for some features)

These all have use cases and none are “better” than the other.  When making front end design decisions, it always comes back to what’s right for this project, which always starts with understanding the content of the project.

It is also important to understand that each has trade-offs too. For instance, if you’re going to use interchange, you’re going to need multiple files that have to be sized, optimized, maintained, and figure out how you want them to load, and really wonky markup, and or a javascript dependency. On the plus side, you also have much more control over the art direction on various devices.

However, an approach that enjoys a lot of support and solves a lot of problems is one we use a bunch at Spry.

We call this an aspect-ratio first approach.

Aspect Ratio

Just to refresh you: aspect-ratio is the width of an image over the height of an image.  All screens have an aspect ratio, and the math of a ratio is easy to communicate across disciplines. The Creative Director, Art Director, or Designer and I will talk through picking the aspect ratios we want to maintain in the design. Some of the common ratios out there are:

 Square – 1:1 (or 100%)
Panoramic – 21:9 (42.857%)
Widescreen – 16:9 (or 4:3, 56.25%)
Thirds – 3:2 (66.667%)
Landscape – 8:5 (62.5%)

The code

The coding here is pretty simple (another benefit). For markup, we’re going to start with the figure element This tells any screen readers that there’s a visual element here, and also gives us the option to pass in whatever we want. Inside of the figure element, we’ll have a wrapper div and for this example we’ll have a div with a background-image. Like I said, background images have wide support and really good features like background size, background position, background blend mode, repeat, and more. It also lets us do things like add text over the image without extra markup.

Next, we’ll create a few classes in our .css to achieve the effect.

First, we’ll set a width of 100% on the wrapper, and we’ll set the position of this wrapper to relative.

For the div inside of the wrapper, we’re going to set it position: absolute, and top:0; left:0; bottom:0;, and right:0;. To make our lives easy, we’ll set background size to cover too – this will pull the image to “cover” the div, which is now absolutely sized to the 4 sides of the wrapper. If we need to add text styles, like, making it white text so it will show up on a dark background, we can do that here too, but if it’s just the image, it’s not necessary.

Here’s the trick: padding is always calculated based on the width of the element. Which means we can set a % value of padding-top or padding-bottom, and this will always set the height relative to the width. Which is *exactly* the concept of the aspect ratio. Because we might be using different aspect ratios, I like to set classes for each of the aspects I noted above.  Which means adding an aspect ratio is as simple as adding a class to this display pattern.  This is more code up front but better scalability later because I don’t have to reinvent the wheel or come up with a new clever name.  It’s treating the job like a prep chef instead of a diva.

 .aspect-wrapper {
.aspect-image {
background-size: cover;
.square-aspect {
.pan-aspect {
padding-bottom: 42.857%;
.wide-aspect {
.thirds-aspect {
padding-bottom: 66.667%;
.landscape-aspect {
padding-bottom: 62.5%;
<div class=”aspect-wrapper landscape-aspect” >
<div class=”aspect-image” style=”background-image:url(insert the url of the image here);”></div>

I like to write this with the background image styled inline, because then I can pass it’s url in as a variable using php or whatever the templating language is, or just because I’m probably not using the same image for each instance of this pattern.

This allows our image to always maintain the same aspect ratio (e.g. no weird cropping, no losing focus, etc) no matter what.  As solutions go it is robust, reusable from project to project, and allows lots of control over art direction.

Hope it helps!

Free WordPress Plugin: AlphaIndex

Have you ever wanted to list all of your posts by the first relevant letter of the post’s title? What about a custom post type, like maybe your staff profiles? How about a free WordPress Plugin that does it for you automagically?

I had to make a simple plugin for a client project and it solved this exact problem. It’s one .php file, it works, and only requires basic developer skills to configure.

  1. download
  2. change show_ui from false to true if you want to see it work in the WordPress Dashboard
  3. change $slug from ‘post’ to whatever the name of the post type you want to use, like ‘projects’ or ‘people’.

That’s it! It’ll create the taxonomy for your use automagically, and then when you need it you’ll use it the same as you would for any taxonomy, in queries (via tax_query(array( ‘taxonomy’ => ‘alpha’)) ), or in wp_dropdown_categories( array(‘taxonomy’ => ‘alpha’)).

Free WordPress Plugin

get it here: Alpha Index

Complex WordPress IA 2: Custom Taxonomy Navigation

Complex WordPress Information Architecture

Part 1.

Before we dive in,  I forgot to include the code that actually shows the pages.  I won’t go in to it, because it’s covered here: in detail, but after we end our custom query loop, we want to insert another if statement to see if it’s paged or not.  If it’s paged, it will display our pagination.

What is a Custom Taxonomy?

A Custom Taxonomy is simply a grouping (taxonomy) that we, the developer, create, based on the needs of the project.  WP only comes with two default taxonomies, Categories and Tags.  While useful for illustrating the concept of what a taxonomy is, they can be very limiting and increase confusion on a site because a category or tag archive will pull every post and page that is tagged with that category or tag. Most of the time if you want an archive, you want to make it easier to find a specific type of post, and it gives us a lot more flexibility in organizing content.

In this lesson we’re going to:

  1. Create taxonomy-genre.php
  2. Create an in-page navigation element that lists all the genres and
  3. insert that element in to both templates.

First, creating templates is easy in WordPress.  We do the exact same thing we did last time. In our text-editor, open a new file, save as taxonomy-genre.php and we’re on our way.  We can do this because of the WordPress Template Hierarchy, which I’ve mentioned before.

The template hierarchy describes how the software finds the appropriate files to serve. If it can’t find the most specific file, it finds the next most specific, then the next, until it gets back to index.php.  Sidenote – when making your own WP theme or reviewing someone else’s work, templates should always be named according to the WP theme standards and coded to their spec. It’s not simply good practice, it’s manners, and those conventions exist for a reason.

Off of my soapbox.

Step 1: Custom Taxonomy Archive

In the case of custom post types the hierarchy is this:

  1. archive-customposttype-slug.php (where slug is the name of a specific item in that post)
  2. archive-customposttype.php
  3. archive.php

and the same logic applies to taxonomies. When in doubt, get more specific!  It helps for debugging.

We’ll make sure we include the header ( get_header() ) and the footer ( get_footer() ) and then copy in our code from archive-songs.php, because the same basic format will be used, just with slightly different logic.

Step 2: The Loop

For the loop, we’re going to add the $tax_query parameter.  Tax Query takes an array of arrays, and is in an array itself!  So our new custom query looks like:
// Define custom query parameters
$custom_query_args = array(
'post_type' => 'songs',
'tax_query' => array(
'taxonomy' => 'genre',
'field' => 'slug',
'terms' => $term->slug,


The query is getting posts of the post type songs, with a genre assigned to them, matching the slug of the term.

The logical question is, what is $term?

$term is a variable we need to set.  this should look a little familiar, but basically we’re setting $term to equal the slug of the page we’re on. Here’s that code, and we need to include this inside a php tag before our query.

$term = get_term_by( 'slug', get_query_var( 'term' ), get_query_var( 'taxonomy' ) );

This modifies our query to output only the Songs matching the Genre in the slug of the page that we’re looking at. Pretty cool huh?

Step 3: The tiny nav

Let’s take this one step further.  We can now add a navigation element to both templates using the same code to get all of the Genres so we can navigate between genres easily!  This is a win because primary site navigation has to reflect priorities and even important content like this may not be the most important 2-6 links.

Pro tip: the easiest way to make sense of navigation is to avoid overstuffing it in the first place.

I’m using a design pattern which you can find here. There is a tiny javascript dependency,  but the logic on it is pretty simple – basically, replace the full list with a select menu when the browser window is small enough.

But how to dynamically (that is, tell WordPress to automatically insert) our Genres in to the list?

We’re going to start by creating variables.  Inside of a php tag, paste in:

$taxonomy = 'genre';
$orderby = 'name';
$show_count = false;
$title = '';
$args = array(
'taxonomy' => $taxonomy,
'orderby' => $orderby,
'show_count' => $show_count,
'title_li' => $title,
'use_desc_for_title' => 0,
'current_category' => 0,

Then, we’re going to pass those arguments to a WordPress function called get_categories, and store that result in one final variable, $categories, like so:

$categories = get_categories($args)

Last, inside of of the nav element we’ve just made, we’ll make a foreach loop. For PHP newbs, the syntax can be a little challenging, but basically we’re telling WordPress that, for each Genre, output this specific chunk of html.  And, we’re also taking advantage of WordPress get_categories, because if it’s the current category, it will now append the class “current-cat” to the list item. This allows us to style the list to show a user what genre they are on.

foreach ( $categories as $category ) {

$term_id = $category->term_id;
$term_slug = $category->slug;
$term_name = $category->name;
$term_URL = get_category_link( $category->term_id );
$class = 'current-cat';
if ($term_slug == $term->slug) {
echo '<li class="cat-item cat-item-'. $term_id .' '. $class .'">'.'<a href="'.$term_URL .'">'. $term_name .'</a>'.'</li>';
} else {
echo '<li class="cat-item cat-item-'. $term_id .'">'.'<a href="'.$term_URL .'">'. $term_name .'</a>'.'</li>';

We’re wrapping each term name in the link to the term’s unique page.

This won’t include a link back to the songs archive, but that’s easy enough to include manually, like so:
<li><a href="/songs">ALL</a></li>

There you go!  To recap,  we now have the templates we need to show all of the songs, and all of the songs by a specific genre. Our custom taxonomy of genre is all set up to work automagically.

Next time, we’ll cover how to set up parent and child pages, and how to show sibling pages when you’re on a child for our discogrpahy and album pages.

How to make Complex WordPress IA Part 1

I’ve been heads down on a project at work that has had a number of reasonably interesting challenges, so I’m writing a series of posts to capture not just what I did but how I actually did it.

One of the major knocks on WordPress is that, because it was originally designed as blogging software, making comparatively complex information structures is more difficult than it could be with a different system. Still, there may be reasons a project needs to be both WordPress and have a complex architecture. As a developer, our overarching goal is to bend the software to the human needs, not try to bend people to the limits of software.

Without getting too in the weeds about how WP treats content, let’s show a hypothetical case instead.

Say we’re building a site for one of our favorite musicians.  Obviously, they want people to discover and understand their music better.  So we decide that the key content item on this site will be each Song they choose to put on the site.  We will need to have a custom post type called Songs. Each Song is part of an album, and each album has a genre.

Song -> Album

Song -> Genre.

Believe it or not, this is can be pretty complex to display.

Let’s say we wanted to show all of the Songs in a Catalog.  Then we want to sort the Catalog by Genre. Additionally, we’ll want to have a page that lists all our Albums (call it “Discography”) and each Album gets it’s own page. On each album page,  there’s a menu of all the albums.

Still following?

Here’s the basic IA structure we’re going to make.

Catalog -> Lists all Songs, Sorts by Genre (each Genre is it’s own url).

Genre -> Lists just the Songs in this Genre

Discography (parent) -> Lists all Albums (child)

Album (child) -> has menu listing all Albums (siblings).

Default WordPress IA has a really difficult time making this happen. The default WordPress IA can be summed up as: We make Menus out of Pages, and we display Posts on a Blog Page. It is not a coincidence that the templates WP looks for are home.php and index.php.  In our example we have posts, pages, parents, children, and if you’re not careful the logic could end up looking like spaghetti.

WP Ideal Site Map
This is the Ideal WP Information Architecture. You have 3 basic types of content, all related by built in functionality. 

Let’s start with giving our custom post type, Songs, a custom taxonomy.  I use the plugin Custom Post Type UI plugin, but the code to do it yourself is pretty straightforward.

Here’s the custom post type code:

add_action( 'init', 'create_posttype' );
function create_posttype() {
register_post_type( 'songs',
'labels' => array(
'name' => __( 'Songs' ),
'singular_name' => __( 'Song' )
'public' => true,
'has_archive' => true,
'rewrite' => array('slug' => 'songs'),

and here’s the custom taxonomy code:

function genre_init() {
// create a new taxonomy
'label' => __( 'Genre' ),
'rewrite' => array( 'slug' => 'genre' ),
add_action( 'init', 'genre_init' );

Now we’re cooking. Note this line especially:

 "has_archive => 'true'.

This allows us to create an archive template for songs, and tells WordPress to look for an archive template.

For this illustration we’re not going to create custom fields for each Song, but certainly we’d want to do things like:

  • list any awards this song won or was nominated for
  • list who produced, mixed, wrote, or performed on the song
  • show the lyrics
  • insert a soundcloud module so a user can listen to the song right there
  • insert a download link

and we can create all of those fields either on our own, or, even better, with the Advanced Custom Fields Pro plugin. There’s a free version that is excellent but A) I encourage you to support them, B) the pro version is even more useful and C) it’s a steal at the price.

Now we can make an archive template for all of the Songs, that is, our Catalog. We’ll make a new archive template,  which we’ll name


Like all WP templates we’ll start with get_header() and we’ll close the document with get_footer();. If you’re completely new to WP,  these tags help you repeat the head and closing parts of the page, which saves your typing and ensures that the right stylesheets and scripts load on every page.

Problem 1: how do we get all of the Songs?  In this example we’re going to create an unordered list (<ul></ul>) and each list item (<li></li>) will show a Song title, wrapped in a link (<a></a>) back to that song’s unique page.  This is the simple part.

WordPress queries the database using a function called, you guessed it, WP_query.

And this function accepts arguments – that is, we can tell WP_query what to, well, query the database for.

The way we do it is like so (inside a php tag):

// Define custom query parameters
$custom_query_args = array(
'post_type' => 'songs',

The key is we’re telling WordPress to only query the post type we’re after. There’s about a dozen different parameters we can configure with these arguments, and you should bookmark this link in the WordPress Codex. (For WP, the answer is almost always in the Codex).  Note that we are *not* going to use the ‘posts_per_page’ argument here. This is so we can use virtually the exact same code later, for our genre pages.

One thing you might not find is how to paginate these. This took me a little digging, but is actually quite simple.  We can write 1 line of php that will insert this parameter into our arguments, which will then be passed on to the query.

// Get current page and append to custom query parameters array
$custom_query_args['paged'] = get_query_var( 'paged' ) ? get_query_var( 'paged' ) : 1;

However, this only gets us halfway there.  We then must add additional code that sets the query object back to null.  The reason is simple – without this code,  WP will use the default query object.  Instead, we’re telling it to use our object, then null, and then finally reset everything so we don’t break the site.

Here’s that code:

// Pagination fix
$temp_query = $wp_query;
$wp_query = NULL;
$wp_query = $custom_query;
//then later, after we end the loop wp_reset_postdata(); // Reset main query object $wp_query = NULL; $wp_query = $temp_query;

and here is all of the code, together, so far for our




Voila!  You now have all of the Songs on an archive template.  This basic code will also help us make the Genre pages,  which will display all of the Songs in that Genre.

We’re right at about 900 words, a few php concepts, and lots to grok about WordPress IA.  In the next part of this series, we’ll tackle problem 2: How to let a user sort these songs by Genre from this template.



The Number One Question I Get

The Wrong Question

is “What will this website cost me?”

“How much will my website cost?” is a bad question.  A much, much better question is “How much value do you want to create with your website?”  Freelance web design varies a lot on cost (even in a local market like STL), and even more on the value they will deliver.  I’ve decided that whatever the project is, I’m going to focus on value for the business.

In fact, that’s where I’ll start a conversation with you about website cost. Because while there is a point of diminishing returns, there’s a pretty consistent relationship between investment and return. And, as we know, the returns do not have to be all that big to make a big difference in your company’s or organization’s bottom line.

So the first question is, How much value do you want to create? The next set of questions will be about the constraints. See, I could just tell you a fixed price here. I’d look at my family monthly budget, use the total, add a healthy bit of margin to it, and quote you a price. But the problem there is that price is only about me. It’s not about you and it’s a bit of a lie. Oh, sure I could justify it post hoc but I think that’s not what I want to be about.

I want to create value for you, which means, well, I need to get to know you. I’ll do my homework and come up with a few options for you, each of which will be suited to what your project goals are.  I try to provide three options no matter what. I want to blow your mind!

The Tiny Problem

That said, I do have some informal benchmarks I use to help me figure out what is possible. You simply can’t get a Michelin meal on a McDonald’s budget. And if your cousin will do it for only X amount, let them!  I won’t. There are options, and I’m happy to tell you what they are.

What if you have a small budget? First, let me say thank you for making a budget. That means you have your head on straight. Second, a small budget isn’t a bad thing, it just means different options and compromises.

Big Eyes

I’ve worked on big, complex projects and have absolutely added value there, but the truth of the matter is that Web Design is a team sport at that stage. There’s just too much to do. Ideally you’d want a team of 2-8 to work on projects over a certain dollar amount. This is exactly why I work at an agency –  I’ve got a team of people who are experts at what they do and together, we can deliver a lot more. It’s just not smart to try to take on something too big for me. I will let you know if something is too big for me to handle. And, honestly, if you’re reading this, you probably don’t have this particular problem.

Know Thyself

Getting the right answer to the question “What does a website cost” is an exercise in self examination.  You need to know how much you can afford, what your goals are and what you prioritize before you’ll get the best price for you.  The more self aware you come in to the project – or at least willing to let me get to know you – the better it will go.

Website Audits

Conducting Audits is part of a Web Designer's job.

Taking Stock means Audits

If you want to create value from your website, then you need to treat it like any other business asset. A company which does not take regular inventory will quickly go out of business. Good businesses know to avoid stocking up on too much at one time, and keep reliable, comparable records to check their positions.

A Website is a Warehouse

It’s critical to be able to say at periodic intervals how it’s doing, and to know what kind of reports you should be reading. Yes, web design is creative, but as I’ve argued time and again, without a critical component, it is more than likely a waste of money. We need to apply the kinds of rigor we use for other business disciplines to design or risk irrelevance.

In accounting, the basic reports are a balance sheet and income statement. For a website, the basic reports would be an Interface Inventory, a Content Inventory, and an Analytics Statement.

How To:


An interface inventory is about recording the elements of a design.

Start by taking screenshots of every design element you can identify. Then, organize them in a Keynote or power point. The goal is to be able to systematize your interface styles so that every decision has a clear rationale.


A content inventory is your balance sheet. For Content inventories you’ll want to make a spreadsheet. You want to clearly note for each piece of content as much of the following data as it applies to your site:

  • URL
  • Content Type (e.g. Archive, Post, Profile, Product, Navigation, etc)
  • Meta Snippet
  • Meta Keyword
  • Who handles that piece of content
  • Last Updated
  • Status (in the content lifecycle)
  • Promotion
  • Comparative Ranking on the site – do visitors use this content?

An analytics statement is your income statement. If you do them right, you can clearly see which actions caused which effect for your website. I suggest only tracking 2-5 metrics, and that you are absolutely sure you understand how those metrics are tabulated. A good metric is not only easily measured but easily controlled. Be wary of the quality of the metrics you choose to measure and even more wary of tying compensation to these metrics.

Auditing for Heuristics

A heuristic evaluation is applying a checklist of established best practices to a site.  An auto inspection is an heuristic evaluation.  These are analogous to internal controls in accounting. We want to detect or prevent errors in our work and heuristics help. The four dimensions on which I’m evaluating sites are:

  • Semantics – this is both a code and a copy evaluation. Is content structured to be reasonably understood? Is the grammar, syntax, diction, voice and tone of copy and code correct?
  • Style –  Code wise I’m looking for styles that are
    • separated from structure and interaction
    • organized within stylesheets
    • made as simply and readably as possible.
    • Visually I’m looking for
      • clear hierarchy
      • emphasis
      • use of negative space
      • proper treatment of images and
      • a logical type system.
  • Accessibility –  there are semantic, style, and interaction concerns that feed into this.  I’m looking for:
    • correct HTML tags
    • Correct usage of ARIA roles
    • easily distinguished links
    • browser compatibility,
    • progressive enhancement,
    • Treatments of color, text, and images meet established standards,
    • and website performance all factor in accessibility.
  • Interaction –  I’m looking for interactions that are
    • clearly marked,
    • do what they say they are going to do,
    • do them securely and reliably,
    • and have reasonable enhancement.

If a site meets the least acceptable standards along these four dimensions, it’s a good site. Notice that this does not prescribe how a site looks or feels.

An Audit is not a Critique

Audits are objective, repeatable, verifiable tools to evaluate a website or app; they are not design critiques. Design critiques after the fact are not useful in making better sites!

A mile in their shoes

A design critique is often an invitation to rip a fellow designer.  That’s completely classless and something I refuse to do. I know that there are simply too many factors that go in to a web design that I can’t judge objectively what a designer was thinking. Without being in the room with those designers, you just don’t know and it’s presumptuous to guess.

Art is not design

You can measure many things about a site, but aesthetics are completely subjective. We must remember that design is not art and art is not design. So long as the aesthetics support the message that the site intends to communicate, the site’s visual design is good!

Website Audits Early, Website Audits Often

Keeping accurate books and controlling inventory are part and parcel of a well run business, and your website is no different. I offer website audits because they are key to designing and developing websites that not only work, but create new value for you.