Simple Conditional Loading in WordPress

Over a year ago, Jeremy Keith wrote an excellent post on enhancing the performance of responsive sites by checking for a minimum screen width before loading secondary content such as related news and latest tweets. Mobile devices would just show a link to the content, thus keeping it accessible. In this post I’ll show how to do a similar thing in WordPress.

Method 1: Custom page templates

I thought there should be an easy way to delay the loading of any secondary content, and my first thought was to use the very simple .load() method in jQuery along with a custom page. For instance you could create a special template to show related blog posts, and display a link to that page. On wide screens this link can be replaced with the content of your custom page using ajax. This is a perfectly valid way of doing it, especially if you have only one or two pieces of secondary content.

Method 2: Custom Endpoints

What if I want to conditionally load the WordPress sidebar on every page, and the contents of the sidebar is not necessarily the same everywhere? Creating page templates and pages for all that secondary content can become messy and error-prone. My esteemed colleague (and boss) Aki suggested a better way of doing this would be to check for a specific parameter in PHP and generate either the main content or the sidebar. All we need is the sidebar version of the page to have its own URL. Enter Sandman WordPress Endpoints!

URL endpoints are part of the Rewrite API, and are used for many things, among others to generate feeds (via /feed/) and paging (eg. /page/2/ to see older posts or the second part of split post). The following code will register a new endpoint /part/.

The above code should go in the theme functions.php file, or better yet, a separate plugin. To make the endpoint actually work you might have to clear your rewrite rules — simply opening the WordPress Permalinks settings and saving should do the trick.

Now the endpoint is registered, you can access it in PHP using the built-in WordPress function get_query_var(). For example, you could construct your sidebar.php template like this:

In the above example, when we access a URL ending /part/sidebar/, the condition will evaluate to true. So now we have an accessible, functional solution with cacheable URL’s. We’ll just add some jQuery magic to load the sidebar content in place on wider screens:

If you also want to support ajax loading on smartphones, add this to trigger it with a tap/click:

That’s all! A functioning demo can be seen on this blog: try loading it on a small screen vs. a wide screen.

The Mobile Book by Smashing Magazine

I’ve just finished reading through The Mobile Book by Smashing Magazine. The book is a fully packed 334 pages of analysis on the current state of mobile and best responsive design practices. Writers include gurus such as Peter-Paul Koch, Stephanie Rieger and Brad Frost.

Bottom line: most people working in web design today should probably read this book, whether they’re designers or developers. The book has useful data on today’s mobile landscape, discussion on how to bake responsive design into our processes, the peculiarities of designing for touch and instructions on how to optimize for mobile.

From the foreword (by Jeremy Keith):

There will come a time when this book will no longer be necessary, when designing and developing for mobile will simply be part and parcel of every Web worker’s lot. But that time isn’t here just yet.
Jeremy Keith

Here are my six key points I gathered from the book:

  1. The Internet of Things is a thing, and is likely to explode in the near future with more Internet-connected devices entering the market that are neither traditional mobile devices nor desktops or laptops. Some don’t even have screens.
  2. Responsive design that focuses only on screen size can result in huge downloads on mobile. We need to pay more attention to conditional loading of secondary content.
  3. Creating detailed Photoshop comps of web sites can set false expectations to clients and other stakeholders. Responsiveness should be part of the design process very early on.
  4. The capabilities of mobile browsers vary wildly (especially on Android), and browser/device detection is increasingly a necessary evil. RESS (Responsive design + server-side components) and server-side libraries like Detector (by Dave Olsen) are a possible solution.
  5. With new hybrid touch-enabled devices, we are less likely to be able to predict whether the user can use touch as an input method. Due to this we need to optimize for touch by default.
  6. Touch interfaces take web design into the realm of industrial design. It’s no longer just about how things look and behave, we also need to consider how people hold their devices. This has significance when deciding where to put key controls.

The Mobile Book is available here.

Page spread from The Mobile Book
The print edition is probably the most high quality book Smashing Magazine has produced so far. A real pleasure to read!

Regarding point 2 in my list: I’ll be presenting a simple example on how to use conditional loading for any content in WordPress in an upcoming post. The same method is used on this site to load the sidebar. Edit: it’s now online, see Simple Conditional Loading in WordPress.

You may follow me on Twitter.

My Dev Setup, part 3: Browser Testing

Some years ago browser testing meant just testing in Firefox, Safari and possibly Opera, and cursing and testing in IE6. Good standards support in current browsers has made development easier on one hand, but more complex than ever on the other hand with the demands of responsive design, the rise of mobile and websites themselves becoming more advanced.

Now on the desktop we have to worry about Chrome, Firefox, Safari, Internet Explorer 7,8,9 & 10, and on ‘mobile’ there’s at least Safari for iOS (phone and tablet), Windows Phone, multiple versions of the Android Browser, Chrome for Android, the BlackBerry Browser, Firefox, Opera Mobile and Opera Mini.

This post describes a snapshot of my current browser test setup and it’s the third part in my “web dev on Mac OS X” series. The first two were about utilities and web development apps. I’ll try to keep this series of posts up to date as the tools of the trade change.

Latest versions of Chrome, Firefox, Opera and Safari

Google Chrome with Web Inspector

You should of course have all the latest versions of the most popular desktop browsers. Ideally it would be a good idea to have older versions too, but since both Firefox and Chrome update themselves automatically, this is not much of an issue (see Arstechnica’s browser share analysis from last October)

Since Firefox 3.6 was the last version not to be updated automatically, I like to keep it around, since it has quite a few issues with some HTML5 elements and CSS3. An easy way to install an old version of FF alongside the current version is via portableapps.com.

Internet Explorer 7, 8, 9 & 10 in VMWare

IE 8 running in XP, IE 10 running in Windows 8

Internet Explorer testing is annoying, because installing multiple stand-alone versions of IE is difficult, and in some cases impossible. I currently have a VMWare virtual machine running XP with IE versions 6,7 and 8, installed using Multiple IE. Unfortunately this setup is somewhat buggy, but it works. I have a separate Windows 7 and 8 VM’s running IE 9 and 10 respectively. This can get messy and requires a lot of HD space. Also, testing local websites requires editing the hosts file of each VM.

Microsoft offers free VM images for IE7-10.

Mobile testing

The Real Thing

Testing on iPad, iPhone, Nexus 4 and Nokia E51

Testing on real devices is essential, and at least before going live I try to test on as many devices as possible. Since my own collection is limited (Android, iOS and S60) and there’s no open device lab near me, I occasionally visit the local department store and try out all the phones on display. Necessary, but not very practical for quick debugging.

Adobe Edge Inspect

Adobe Edge Inspect

For devices that support it (ie. Android and iOS), Adobe Edge Inspect is a great time saver. Basically it allows you to browse the same site synchronously on your desktop and your mobile via a mobile app and a browser extension. Even Edge Inspect doesn’t allow browsing local sites though, and that’s where the next solutions come in.

Opera Mobile Emulator

Opera Mobile Emulator simulating a Nokia N9
Opera Mobile Emulator simulating a Nokia N9

The Opera Mobile Emulator is an excellent and easy way to test a responsive web site in a huge number of different sized displays. It’s a useful tool whether your users use Opera or not.

iOS Simulator

Apple iOS Simulator

The free Mac OS X Developer Tools include an iOS simulator, which is at least 99% identical to the actual devices (iPhones and iPads). The emulator allows rotating the device, simulated shakes etc. This is probably the mobile testing tool I use the most.

Going forward: Remote virtual machines with Browserstack

Maintaining all these emulators is messy, to say the least. So I’ve been eyeing Browserstack, which allows testing in IE 6-10, recent versions of Chrome, Firefox, Opera, and best of all, emulators of most Android & iOS devices of significance. From my point of view the only thing missing is Windows Phone. Oh and Symbian would be nice too.

Browserstack running IE7 in Windows XP

The interface is really easy to use and straightforward. You input the address you want to test, choose an operating system and browser, and that’s it. Using a remote desktop via a browser is of course fairly slow, but the really killer feature of Browserstack is the ability to test local sites (like testsite.dev). This often makes Browserstack more convenient than the alternatives.

Browserstack is a subscription service (starting at $19 per month for an individual user). If you feel like trying it out, there’s a Microsoft-sponsored three-month free trial available. CrossBrowserTesting is another similar-looking service, although I haven’t tried it out.

Final Words

Browser testing is a complicated business, and your needs will depend on the type of site you’re developing and user demographic. Testing in more than one browser is a start, but mobile testing has also become a must. In a year or two it might even be more important than desktop browser testing, if it isn’t already.

Testing on a real device gives a good feel to the restraints of that device, but remember your iPhone/Samsung/Nokia model isn’t the only one out there. As more and more varied devices enter the market and testing needs get more complex, tools like Browserstack are likely to be the only realistic testing option for the vast majority of designers and developers in the future.

On Pragmatic Responsive Design

Responsive design shouldn’t be just about checking screen width and removing stuff on mobile devices, even though this is what it often amounts to. I also admit to doing this myself. Designing with a mobile first approach is sensible, but we run into problems with the typical wireframes/photoshop/html pixel-perfect workflow.

Stephanie Rieger made this excellent presentation on pragmatic responsive design with lots of good points.

You should check out her other presentations too.

Continue reading “On Pragmatic Responsive Design”