May 22, 2013

Is Responsive Worth It for Small Businesses & Bloggers?

There’s a lot of information floating around about making your website “responsive,” much of it targeted at designers & developers. I haven’t seen quite as much written for small businesses nor for bloggers, so I thought it might be helpful to outline some of the concepts behind responsive design and some of the things you should consider as you embark on a site update to help you decide whether responsive design is right for your website.

Click to enlarge, or visit the live site

A recent responsive client project, designed by Amanda Jane Jones. Click to enlarge the image, or visit the live site

Goals & Strategy, Generally Speaking

I am of the opinion that any decision you make about your business should be rooted in a solid understanding of both your goals and your overall business strategy, and decisions about your website are absolutely not an exception (see my thoughts on planning and tweaking your site).

Don’t default to responsive just because it’s the new big thing.

The only people who should be updating their website with the latest technology just to have the latest technology are companies that have their actual business based in that technology.

I made my updated website responsive because I code modern websites for a living, and it was important to me to show that I can work in that particular context. If you’re not a developer and/or you’re not interested in working on responsive design projects, you shouldn’t adopt it as a default just because it’s the new big thing in websites.

What does responsive actually mean?

Now that I’ve got my initial standpoint out there, let’s back up a little and make sure we’re on the same page as far as what “responsive” means – I get a lot of requests mentioning it in contexts where it’s clear people really aren’t sure.

Responsive design is designing and coding a site such that it responds to the parameters of the device being used to view it. At it’s most basic, this typically means the width of the content adjusts to always fit neatly within the frame of the browser across various screen and browser sizes. This often requires a combination of fluid/ flexible column and content widths, as well as “breakpoints” at which layouts change to better fit the new width.

Readability

One very good reason to go with a responsive site is if you’ve got a text-heavy site and you think people are likely to be trying to read it on a device other than a desktop or laptop computer. It can be challenging to read on tablets and phones when websites aren’t optimized for them, but a responsive design will both adjust the content column to fit the device and will usually adapt font sizes and spacing for maximum readability.

It’s probably obvious, but site owners for whom readability will be important are often bloggers or editors of writing-focused sites. However, while readability is certainly a compelling reason to consider a responsive site, it doesn’t necessarily follow that if you’ve got a lot of text you have to go responsive – your analytics and user base should also inform the final decision (more on that below). Especially for bloggers, you may find that most of your readers are actually getting your content via RSS or email, in which case they won’t even be seeing your responsive site.

Access on the Go

The other really great reason to go responsive is that your site content is highly likely to be accessed by visitors who are on the go, and therefor are likely using a smart phone or tablet.

One example of this is restaurant sites, or sites for other location-based businesses, where visitors may be coming to your site while actually out and about in the neighborhood. If you slow them down (or worse, block them entirely) by using technology that is unsuitable for a mobile device, you may actually lose business.

Or, if you’re in a field where you often need to display your content while away from a computer – for example, showing a portfolio or work samples during business meetings away from your office – you probably want to make sure your site is optimized for whatever device you’re using (iPads seem to be getting really popular for this sort of thing).

A Basis in Analytics

Beyond your goals for your site, and the above two examples of compelling reasons for responsive design, decision-making should also be based in data where possible (e.g. for an existing site undergoing a redesign).

To be perfectly honest, when I used Google Analytics for data I never looked at it. Now I use Gaug.es and it is worth every penny – if you follow me on Twitter you may have seen one of my occasional bursts of love for them where I post random data screenshots and gush an embarrassing amount. No, they don’t sponsor me. I just love their service, and here’s why:

browser-width-data

This graphic shows my actual browser width data from April 2013. A full 88% of my visitors are viewing my site in a browser at least 1440px wide. That is pretty wide, my friends, and probably not what I’d expect if I were just guessing based on all the hype about mobile internet users, etc., etc.

platform-data

There’s more! This second chart shows the stats on platforms used to access my site. Even if you’ve decided “yes” on responsive in general, there are decisions to be made about breakpoints and testing on devices and optimizing for devices, and this sort of data makes those decisions so much easier. (That tiny percentage of Android visitors? Kind of fascinating given recent generalized data in the news.)

What Does it Cost?

Goals + Site Purpose + Data + Budget = Responsive (or Not)

Sorry but there’s no good answer other than the perennial developer favorite “It depends.” I know, not that satisfying.

The thing is, it really does depend on a variety of factors from the design, layout, structure, and content strategy of the site to the technical specifics of breakpoints to the data on which sizes it makes sense to spend the most time on.

Very very roughly, I’d say it’s safe to expect responsive design and development to add anywhere from 30% to 70% to the cost of your project. Also, please assume quotes you get from designers and developers do NOT include responsive design and coding unless otherwise specified. It’s still the sort of thing that should and will be specified (and thoroughly discussed) if it’s on the table.

Of course, that cost should be another factor that goes into your overall decision-making process. While I do (obviously) think it’s worth spending money on a great website, it’s one part of your overall marketing/ communications strategy and responsive is only one part of an overall website strategy. Budget accordingly.

End Game: Is it Worth It?

Sorry, I don’t have a final answer for you (are you feeling let down?) but I can say that in many cases a responsive site is probably NOT your top priority for building your blog and business. All the data points I’ve discussed will hopefully help you decide if it’s a good choice given your particular set of circumstances.

Additional Reading:

An interesting article from Elliot Jay Stocks about how to think about what RWD (responsive web design) really is/ means. I don’t agree with all his points (especially about cost), but it’s a great read.
MediaQueri.es is one of my favorite resources to share with people just wrapping their head around RWD – lots of great examples in a nice clear gallery format.
There are tons of grid systems out there to act as starting points for RWD – the Golden Grid System is just one. I like the typography ideas in this one, in particular.
Getting into the details of RWD uncovers all kinds of complex issues and problems, such as how to handle images. This article from CSS Tricks is a great overview of the image-related issues and possible solutions.
Type is another issue with responsive, and this is a great article to start to understand why.
Of course, I always recommend everything from A List Apart, including their book on RWD.
Also, I just found the mother of all lists of RWD resources & tools which probably includes most of the above and then has about a million times more.

May 20, 2013

Add a Rolling Date in WordPress

I used to have this problem on my contact page where I wanted to clearly show my next availability. It was a problem because if I just put a lead time (e.g. 6-8 weeks), people didn’t seem to take the time to do the math to figure out when that actually put my next openings. On the flip side, if I typed in the next opening manually, I invariably forgot to update it in a timely manner.

I’ve posted before about how I feel about small nuisances on websites and in workflows – the gist is that they drive me nuts and I feel compelled to fix them.

Eventually I decided on a two-pronged attack to this particular problem. One prong involved changing my quote request form to show multiple notices about timeline/ availability. The second prong involved coding my contact page to display my next availability on a rolling basis, where I just enter the lead time as a single digit and the displayed date is calculated automatically based on the current date.

Click to enlarge

Step 1: Create a Custom Entry Field

I definitely wanted to be able to update the lead time value on an ongoing basis from right within WordPress, since it tends to shift a bit based on scheduled time off, holidays, and of course client scheduling, so I used the Advanced Custom Fields plugin to add a simple input field to my contact page.

The ACF setup:

advanced-custom-fields-lead-time-field

On the page:

lead-time-field

If you’re working on this yourself, make sure you enter a lead time and save the page – otherwise you’ll find yourself very confused when you add your template code and nothing appears. Yes, I’ve done that. More than once.

Step 2: Add a Bit of Code to Your Page Template

This assumes you’ve already got a page template going on for your special page, or you know how to make one.

As an alternative to a new template in the theme, you could try using a plugin that lets you create your own PHP-based shortcodes, such as this one (haven’t used it, but it purports to do what you’d need).

The Code:

Yep, it’s short. Hopefully the comments make it clear what the two lines do, but let’s break down that second one a bit so you can customize things if you’d like.

About STRTOTIME();

The whole backbone of this method is the PHP function strtotime();, dedicated to which there is apparently an entire mini-site. I’m actually not that surprised, it’s a pretty sweet little function. What it does is convert the date/time however you tell it to relative to now. So in my example, I’ve told it to take the current date/time and add whatever value I’ve put in my custom field to it (using that variable I set in the first line).

The really cool part is the syntax – it accepts relative date formats such as “next Monday” or “tomorrow.” You can read up on all the accepted relative formats, as well as all the formats in general if you’re into that sort of thing.

About DATE();

Once the date has been calculated, this snippet uses the PHP function date(); to format and display it. There are a ton of display and formatting options, but basically you’re using characters to stand in for various formats of month, day, time, etc., display. I wanted to only show month and year, so I used F Y where F displays the full month name and Y displays all four digits of the year.

Problem Solved!

Now all I have to do is occasionally note if my lead time is drastically different than it’s been recently and update that one little digit accordingly. It’s easy to do, since it’s right in WordPress (where I spend lots of time anyway), and I can safely ignore it the rest of the time knowing that the page will always display the month and year the appropriate interval from the current day.

May 17, 2013

Using the Referring Page in WordPress

While a number of different projects over the last few months have included features where I’ve needed to use information from a URL to do something special with a page, two in particular stand out. These two required that I use PHP to find out the referring page so that I could then define the actual content and structure of the page before it was created client-side.

Client-Side, Referring Page URLs, WHAT?

Let me back up just a little, since I know some of you may not be that familiar with this sort of thing but may still be curious about the techniques. When thinking about WordPress and PHP sites in general, it’s helpful to know that PHP is a server-side language. This means that everything going on in your PHP code is read by the server and performed before the page is ever created in the browser (on the client-side, or the side of the end user). This is why you don’t see any PHP in your browser web developer tools when you inspect the code – only the HTML and other stuff the PHP outputs.

Much of the time, the changes I’m making based on the referrer or URL are fairly minor, and a lot of the time I need them to be flexible based on the user’s interaction with the page. In these cases, I use special content in the URL such as fragments preceded by the hash symbol (#) or query strings, which use question marks and other symbols to set up a whole set of information right in the URL. Then, I use jQuery to read the URL and perform whatever page tweaks are necessary.

jQuery Example: Fairmount Fibers

I recently coded a wonderfully complex site for local Philadelphia business Fairmount Fibers, the US distributor of Manos del Uruguay yarns, through Aeolidia (the site was designed by Meg Lewis). There is a directory of available patterns, which can be filtered and sorted by yarn, pattern type, and whether the pattern is free or for purchase.

While the client wanted to highlight the free patterns in the navigation menu as well, it didn’t really make sense to create a whole second page that does the same thing as the main patterns page. Instead, I coded just the one page, and set up some visual changes based on whether the URL has #free at the end. When you click the “Free Patterns” link in the menu, you’re really just reloading the same page with that fragment on the URL. Then, the code reads that fragment and triggers changes to the page title and filtering.

Here’s the code, including the filtering bits and thoroughly commented:

You can also check out all three code snippets from this tutorial over on the full Gist page.

Referring URLs in PHP

As mentioned, that jQuery method works on the client-side, meaning it happens in the browser and can respond to user interaction. The two projects I mentioned that lead to this post required code changes to be made on the server side, meaning the actual page itself or a piece of content on the page needed to exist or not based on where the visitor came from.

PHP Example 1: Love Taza

The first instance was for Love Taza’s “Once Upon a Time” archive page, which features their favorite posts. Naomi and Josh wanted the page to show a grid of posts and then to display the full post content underneath the grid when an item is clicked.

In order to do this, I needed to be able to pull just the middle part of the individual post template onto the page using ajax, but only when the post was called up from this specific page. In all other instances when the individual post is called up, the header, sidebar, and footer also appear (e.g. the whole template is used).

WordPress actually has a useful function for finding the referring page – wp_get_referer(); – so that’s what I used here:

PHP Example 2: Em the Gem

The Love Taza example is great when you have a specific URL you’re working with, but when I was creating the blog section of Em the Gem, I needed to include a “Back to the blog” link on single post pages and I quickly discovered I needed to be checking for any referring page that included /blog/ in the URL.

Think about it, the link needs to go back to the last blog archive page you were on before getting to the post. That may not be just the main http://emthegem.com/blog/ page – in fact it’ll ONLY be that page if the post is one of the most recent 5 posts and you got to it via the main blog page. In many cases, I bet you’d get to the post via a category archive or a page farther back in the blog. In other cases, you may get there from a non-blog page, in which case a link “Back to the blog” doesn’t actually make a whole lot of sense since it isn’t equivalent to your back action.

What I wanted was to find out if I came from a blog page and, if so, link back to it. If not, no link would display at all, minimizing potential confusion and awkwardness (nobody likes that). Solution:

In this one, I didn’t use the built-in WordPress function. But I could have – that wasn’t a specific for-a-reason decision, it just happened that way.

All of the above examples and decisions came out of necessity (there’s nothing that gets me going more than a good functionality challenge in a client project), but they’ve definitely made me ponder the potential use cases for finding the referring URL and/or providing information between pages using URLs and fragments.