The Trouble with Lightbox (and its Variants)

Lokesh Dhakar changed things with the original Lightbox JS. He designed and produced an interactive functionality that made nearly every Web designer slap his own forehead in amazement that it hadn’t been thought of before. Those are the best ideas, aren’t they? More often than not, it’s because those ideas solve a problem so simple and common place, we hardly see it as a “problem” any more.

In the case of lightboxing, it came down to displaying images either by using target="_BLANK" or simply dealing with a full page refresh. For what? Clearly both the latency and resources involved were too taxing both for the user and her experience, even if she didn’t know it.

Lokesh recognized the problem and developed a very elegant solution that took the Web by storm. As with all great things on the Web, his implementation was first widely accepted, and then widely copied forked. The technique was applied to every JavaScript library and/or framework under the sun, in multiple cases, and the technique of lightboxing really took hold.

So what’s the problem with lightboxes, gramps?

Don’t get me wrong, I’m a huge fan of lightbox! To me, the trouble isn’t with lightbox as an entity or technique, the trouble surfaces when it’s put into production. I can’t remember a client project in which a lightbox variant was used where we didn’t need to take time to explain what it is and how it works.

That’s not to say that the lightbox used odd controls or was modified beyond recognition, no. It was simply because the average Web user doesn’t understand what’s going on. At all. Here’s where the problem comes up, and it’s a deal breaker. (Most) lightboxes break the Back button.

In every case of showing a client a development site using a lightbox, he would examine an image and disregard the controls put in place to return to the page, and always go for the Back button in his browser. Even after explaining the reasons we implemented lightbox for image viewing (user experience improvement, etc.) it was very apparent that the client was turned off by the technology.

A proposed fix

To our benefit, such technology exists to assist us with such problems. SWFAddress was written to tackle this problem specifically. Originally written for the benefit of full Flash websites, SWFAddress works wonders with JavaScript implementations as well.

Combining SWFAddress with your favorite lightbox variant would solve this very common problem with its use. A potential issue arises on a couple fronts. First, you’ll need to teach yourself how to use and implement SWFAddress. Beyond that, you’ll need to learn how to integrate SWFAddress with your lightbox.

As an example, I’ve taken those very steps and combined my choice lightbox implementation Shadowbox.js with SWFAddress and used jQuery to bridge the two.

Lightbox (Shadowbox) and SWFAddress integration demo

Please view the source for documentation.

You’ll notice that the Back/Forward browser buttons should retain expected functionality. Additionally, if you were to bookmark a SWFAddressed URL, hitting that URL should automatically invoke the Shadowbox and display the image. Users without JavaScript wouldn’t see the SWFAddress URLs at all, so it’s important to remember your alternative version for those users. But that was already in place, right?

Mind your audience, that’s the deciding factor

As per usual, the important thing here to consider when determining what technologies to use on your current project is to remember the target audience. Are they going to accept lightbox as an acceptable image display technique? Are you better off just doing things the old school way and firing a page refresh? Just be sure you’ve got reasoning (and fallbacks in place) when opting to go with such technologies.