Responsive design doesn’t work for every use case

I want you to go over and read the whole post – I agree with a lot of what he says and I think it’s well-written and interesting, and also his responses to the comments are smart – but I have to say I very much disagree with that particular “misconception” and his explanation for it, and not just because I wrote a post last week on deciding when responsive is the right choice for a small business website or blog. I commented on the post itself with my first thoughts but wanted to expand on them a bit here.

Mr. Kling writes:

The bottom line is that our web sites should be accessible to everyone no matter what device or screen resolution they are using, without restrictions.

It’s funny because taken out of context I totally agree with that statement. I also agree with what Mr. Kling says in the post about fixed widths being limiting.

I think my biggest quibble with the argument I get from the text in context, however, is that responsive = accessible and non-responsive = inaccessible. I’ve used plenty of “regular” websites on my iPhone with no trouble at all and there are plenty of responsive sites that are hard to use. That doesn’t necessarily tell me that responsive/ not responsive is unimportant – rather it tells me that it’s only one of many important things about a site that lead to usability.

I guess what I’m trying to articulate is that many sites are sufficiently (even pleasantly) accessible without being responsive. A site does not have to scale or shift or use any of those other RWD techniques to be accessible and functional and usable. Also, scrolling or pinch-scaling are not exactly what I’d consider “restrictions.”

What’s more, I think it’s a bit of a scare tactic to imply otherwise, given that I know that many small businesses and individuals just don’t have the option of getting every last thing they want out of their new or redesigned website. (Side note: I don’t think Mr. Kling is out to scare small business owners in his post, it’s more that this “misconception” just one in a line of similar sentiments that have bubbled up without a lot of specifics and context and data behind them, and I think that while “dangerous” might be too strong a word, “unfortunate” is a fitting descriptor for that trend.)

While I am 100% for spending money where it counts, there are limits to what is reasonable to spend on a website and those limits should be determined by a combination of content strategy, purpose & goals, and budget.

One counter-argument out there is that responsive doesn’t/ shouldn’t cost more than a regular project, but I think that’s only true in very specific cases and probably more so on the large-scale/ corporate/ we’d-otherwise-be-making-a-mobile-site/ simple layout with focus on text content type sites. For many of my clients, especially those in design-focused or otherwise creative businesses, the design of the site is a high priority, and the design decisions are often in conflict with making the site responsive, at least in budgetary terms.

As I said in my comment on the post, blogs are a great example of a use case where responsive is often a good choice. But I’d argue (and have argued, also see two paragraphs ago) that there are a lot of other factors that go into the decision, including analytics on how people are actually using the site.

So I guess what I’m trying to say is that it’s ok to not go with a responsive site and that you shouldn’t feel that by opting against it your site will be inaccessible to visitors and you will have somehow failed the internet.

When a reader recently asked about this functionality, I thought I’d go ahead and tackle it in a tutorial post.

Quick Note: If you just need the drop down to appear on hover, and you don’t need it to stay open if the mouse is moved off the list, you can use CSS (think: navigation bar drop downs). If you want it to stay open after a click, you’ll need jQuery (or vanilla Javascript, if that’s your thing).

Here is an unstyled but working example of the general functionality we’ll be creating in this tutorial:

And in case it’s a little more motivating, here’s a screenshot of a real-life styled version (you can try it action over on the EverlySo blog):

Sidebar Drop Downs

Content strategy-wise, this is a great technique for cleaning up those monster sidebar widgets that people probably really only need on demand, such as those for archives by date and for lists of categories. It’s a nice bridge between a cluttered and distracting sidebar and the other extreme. So let’s get to it!

1. Create Your Widgets & Give Them a Common Class

Unless you’re creating totally custom widgets, you probably don’t have a ton of control over the exact structure of your sidebar widgets. That’s ok!

You can either manually select individual widgets by class or ID OR you can use a plugin that lets you add CSS classes to widgets. I usually do the latter because it allows the site owner to add more drop down widgets in the future with minimal support and training just by adding whichever class I define for the drop down/ expanding widgets.

I’ve used Widget Classes for that specific use case. It hasn’t been updated in a long time but I’ve had good experiences – if that makes you nervous, this is another option.

For reference, here’s the code I use to register my sidebars (nothing very original – it’s basically the same as Twenty Eleven, I think):

That results in widget HTML that looks more or less like this:

(If you’re so inclined, you can grab all the gists for this tutorial together. Grab the sidebar code snippets here and the in-page snippets here.)

2. Hide the Widget Content & Style

There’s actually very little CSS required for this – just a bit to hide the actual widget content on page load:

I’ve accounted for three common widget situations in this snippet – widgets with content wrapped in divs, lists, and forms – but I suppose it’s possible there are other configurations that you might want to account for as well (maybe .widget.expand > p would be a good addition).

It’s also nice to show some interactivity on hover over the titles, and you can get really fancy with icons/ graphics and pseudo-classes if you’re so inclined, so I’ve shown how you might handle those things in the above snippet as well.

3. Add the Animation

Just a little bit of jQuery gets the animation rolling:

All my comments make it look much more complex than it actually is, I promise you. Throw that snippet into your footer.php file between some script tags and just before wp_footer(); and you should be good to go!

In-Page FAQ-Style Dropdowns

The in-page drop downs are very similar – the main difference is that you’ve got to figure out how you’ll handle the content entry such that it’s easy to maintain (I wrote about why ease of maintenance is so important the other day).

Another content strategy decision is whether you’ll start the page with all answers collapsed. It might be a good idea to have the first answer open as a visual cue as to how the page works for the user. You’ll also want to consider whether the questions act independently – e.g. should clicking on a second question close the first and open the second, or can more than one be open at once and you have to click the same title again to close each block?

Example where only one can be open at a time:

1. Create Your Content-Entry Mechanism

Since this feature is often used for things like FAQ pages where the site owner is likely to want to add or remove content blocks and edit the content over time, it’s important to create a flexible system where they can easily pair their questions (the click area) and answers (the area that’s toggled).

I’m starting to sound like a broken record on this, I think, but I use Advanced Custom Fields to handle the content entry. I’m telling you – best plugin ever. For this one, I use the repeater field add-on, which is $25 AUD for a multi-site license (that is an amazing deal, in my opinion).

All you do is create a repeater field, something like this:

Click to enlarge

I like to use a limited WYSIWYG field with no media uploads and only the simple button set so people can add links easily, but you could use a text area field if you want to limit things even further. The above set-up lands you with an entry area that looks something like this:

Click to enlarge.

2. Lay Out Your Content

Once you’ve got your content entry worked out, you’ve got to add said content to the page template. PSA: Child Themes are the way to go, also here’s some info about page templates.

For this particular layout, I want to have a containing div with the title and content inside – I’m creating the same overall structure as I showed for the sidebar widget, actually. This first snippet shows the PHP with the Advanced Custom Fields template tags in place:

And that results in the following HTML output (one of these for each Q&A block the author has created):

Side Note: There have been all kinds of discussions about semantic markup for FAQs (definition lists have come up a time or two), but that is so not the point of this tutorial. My general opinion is that FAQs are not definitions, so DL is not quite right. If I could do it while maintaining the flexibility I want for the site owner, I’d probably use pretty much what I’ve got here but with a paragraph element for the answer instead of the div I’m using in the example.

3. Hide the Answers

Again, this is quite simple CSS (aside from any design-focused styling you might be doing). All you really need to do is hide the answers, although again I’ve included the hover effect on the question and also a bit of extra CSS to show the very first answer to start out:

4. Create the Animation

Just like with the sidebars, it’s a simple jQuery snippet to toggle the answers on click:

As you can see, I’ve included a commented out line that serves to hide all the answers on click just before the called-for answer is displayed, in case you do want to have that feature in your use case.

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).

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:

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.

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?

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.

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:

On the page:

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.

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.