Code should fail nicely

Web designers tend to be pretty particular about their designs. However, often times, if you watch how end users use a website, it can be surprising when they don’t do things how the designer and developer would expect.

Perhaps the client or buyer didn’t have images for a section of the website where you expected them to have images. Or maybe you included a recent events widget, only to find they aren’t posting events frequently. Or maybe you built a custom metabox that you anticipate the user will fill out every post, before they don’t.

There are various potential scenarios for a website administrator to not use the site as it was designed and intended to be used, but it’s the designer and developer’s jobs to build appropriate fallbacks for custom display functionality to help prevent the website from looking awful.

Let’s discuss a few instances where you will want to consider how well your code fails.

Post loops

Be sure in a WordPress posts loop to include an if statement to make sure you have posts, before you actually show markup for a particular section. That way, you can create a custom output to show users if no posts are available.

If you start with the while loop, then you will not only not have a fallback for if no posts exists, but you could also have weird, empty markup where you expected posts to exist.

A really common example for this problem is event feeds. I’ve seen many designs intended to show upcoming events, only to sit most of the year as an ugly, empty section with no events to show. Wouldn’t it be nicer to show some default copy and markup to show information about events in general, if there are no upcoming events to show?

Featured images

Featured images can be used in many ways with WordPress. In most theme demos, all posts have featured images assigned. However, in real life, the featured image may not be set, or it may not be as large as the theme expects. There are a few ways to account for such scenarios.

Theme developers could use a script like the Get The Image plugin (which is also bundled in Hybrid Core) to grab fallback images from posts even if the featured thumbnail isn’t set. However, this may not always be ideal, because you might sometimes want the user to purposefully set a featured image.

For themes that require large, nice images, it’s important to educate the site owner to help them choose appropriate images. You can do this by providing some sample images and documenting appropriate aspect ratios for various parts of the theme (like featured posts or sliders).

Finally, the theme can choose what behavior to exhibit if the site owner doesn’t utilize a featured image where expected. There could be a theme option with a default image saved and used anywhere a featured image doesn’t exist, or the html output can be adjusted for when a featured image doesn’t exist.

For news feeds or archives where you don’t expect the site owner to use images all the time, you could also do something as simple as float the featured image right instead of left. I do this on my base installs, so that if there isn’t an image, everything still looks aligned and fairly uniform. If you had images floated left, posts without images would have headlines misaligned with posts that do have images, and make the website feel just a bit less organized.

The key is to stress test your theme or client website to see how it looks when it’s not used as expected. Try and break it before the client does.

Meta data

I use meta data and custom meta boxes pretty often in my client work. Using custom meta boxes so publishers can fill out uniform data that a theme or plugin can easily structure is very valuable and makes for more fun design opportunities.

However, it’s important for the templates where this meta data is shown to not assume the meta data exists. A simple if statement to check first if the meta data exists, before outputting markup, is a necessity to prevent meta data from looking silly.

404 pages

404 pages can be tricky. As a theme developer, you don’t necessarily want to assume too much, but you also want to make the 404 page fairly useful out of the box. At a minimum, you should have a 404.php template. In that template, at a minimum, you’ll probably want to include a snippet of text to describe that to the site visitor that they didn’t find the page they expected, and also provide a search box for them to search for what they were looking for.

Beyond that, you could get quite creative. Some people like to list a sitemap of sorts on 404 pages, but you’ll want to be careful with that. With publicly distributed themes, you don’t know how many posts, pages, categories, etcetera, that a user will have. So if you show all posts from various content types via custom loops, your 404 could be an extremely bloated page. It would likely be best to limit how many posts or pages you show of each content type.

One thing I like on 404 pages is a way for site visitors to report what they were looking for in the first place. That way, if they tell you via a form, the site administrator can investigate why they didn’t get to where they intended to go. That can be valuable for reducing the number of 404s in the first place.

Here are some examples of creative 404 pages, as well as Bing’s recommendations for 404 page best practices. Personally, I would recommend that you balance creativity and useful information. The key is to predict what most users probably want in a 404 for a particular kind of website, and try to create something effective for that. I should note that the 404 for this site has been, um, neglected. Oops. I’ll work on that.

In summary

I know I didn’t get into code here, and I apologize for that. But these are relatively simple practices that vary considerably based on the situation. Hopefully my notes still help.

I think the the _s theme by Automattic handles some of these issues really well by default. Check out their 404 template and no-results template for effective generic fallback content.

Sometimes, we create websites with the best case scenario in mind. And then, when the user doesn’t use it the way we expect, we cringe and wish they would use the website “the way they were supposed to.” But perhaps we sometimes point the finger in the wrong direction. We can do more ourselves to handle what happens when site administrators inevitably use the site in a different way than we expect.