The Trouble with Lightbox (and its Variants)

Posted: October 12, 2009 Comments(31)

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.

Get my newsletter

Receive periodic updates right in the mail!

  • This field is for validation purposes and should be left unchanged.


  1. Hmmm… I’m about to use Lightbox on a site I’m putting together. I kind of feared this — you may have saved me the trouble of going through the user testing.

    Let’s be honest: we like Lightbox because it looks cool and will spice up any plainish site. Anyone who knows how to use it will like the effect straight away.

    Shame, because Nielsen sort of OK’d it (in a different context at least), so we all felt happy using it 😉

    Good solution as well.

  2. Very nice. Thanks for putting this together!

    I’d be concerned about linking directly to a lightbox. I feel like it might be a bit confusing for the user, but it is a nice side effect of using SWFAddress.

  3. We use a lightbox script for photo galleries (and several variants for other purposes) quite often at Cyberwoven. As a front-end dev, I typically don’t get to speak directly to our clients, but in all the time that we’ve been using these solutions, I’ve honestly never gotten any complaints about the back button being broken. I’m sure that’s something our users are hitting and not complaining about, so we should probably implement it anyway. Honestly, I’m more excited about the ability to bookmark specific images.

  4. While I understand the reason for this, I find the implementation annoying. If you look through each of the images, opening and closing them, then you hit back to leave the page, you find you have to hit back about a dozen times to leave that one page. As a user I would be very annoyed by this.

    I can see having the back button work to stop the Lightbox mode, but I wouldn’t want the history to be clogged with each image. This would likely add some hurdles to implement, but would be more usable from my perspective. I might look at the code some to see if I can find a way to do this if I find time.

  5. The worst thing about Lightbox is its users. Especially those who treat it as a replacement for target=”_blank” – and you’ll know what I mean when you visit a gallery using LB separately on EVERY. SINGLE. IMAGE.

    Uhh, sorry for venting off. 🙂 This was supposed to be a usability *improvement*, right?

  6. Agreed with Kendall–closing the image should drop it from the history, as though you’d clicked “back”. Very cool nonetheless.

  7. I’ve never had the problem of people hitting “Back” when viewing images, however, i do have a similar problem when using modal windows and lightbox variants: When showing inline content — specifically forms — if you’re not performing live ajax validation, you have a a huge problem. Submit the form with errors, go back, and it’s like you were never there.

    Would this technique work here?

  8. @Leon Paternoster: I was a bit surprised to read that piece by Nielsen when it was originally published to be honest! Although the example he used was much more modal-y and dialog-y with very blatant cancel buttons and the like. Many lightbox variations attempt to be minimal by showing the image as the focal point with some subtle interactive cues. Shadowbox for example, assumes the user is familiar with the lightbox technique and provides only a small ‘x’ in the corner to close the lightbox. Thanks so much for remembering that link!

    @Colin Devroe: Glad you like it!

    @Jason Beaird: I really like the premise of bookmarking an image that automatically loads in a lightbox as well!

    @Kendall: I can understand your frustration, and that’s one of the reasons the lightbox technique exists – to be able to view a series of photos with the least amount of effort. Many lightbox implementations (Shadowbox included) provide a ‘gallery’ feature allowing users to sift through the photos rapidly, however I didn’t implement it on the demo page simply for the sake of showing the involvement of SWFAddress. In a production environment you’d definitely find those controls available. With a bit of time and effort you could definitely avoid adding each image view to the history (via SWFAddress) and have the back button close out of the lightbox only, great idea!

    @Jack McDade: Technically, this could be implemented on any lightbox variant at any time, including inline content. I believe, however, that unless you’re actively saving entered form data, it would be up to the browser to fill it in upon the user hitting the Back button, and you might be faced with the same problem regardless. It would be interesting to do some tests though!

  9. This is exactly what I’ve been looking for for a couple of weeks now. I found Backbox (, which is generally pretty good, though I prefer the overall style of Shadowbox. Also, Backbox, being a mod for Lightbox, doesn’t support the variety of media that Shadowbox does. Actually, that’s one place where I’m hitting a snag – since the SWFAddress fix declares the Shadowbox player as “img” in handleChange’s call to, I can’t get other media to work. Is there a workaround for this?

    Thanks for the excellent work.

  10. without url…
    sorry for my english and look to my test…

    from a START page i find a link to your GALLERY:

    opening image 3 i find the image:

    click on BACK i back to GALLERY:

    ok that works…


    if i start from same START page, where start a link to your gallery:

    opening image 3 i find the image:

    if i click on CLOSE icon…
    i find the GALLERY page:

    but i can’t back to START page…
    i can’t click on BACK on my browser,
    because BACK on the browser open the image again:

    regards :p

  11. Inspired idea, I guess this would be another simple solution to a common problem where you wonder why it’s never been addressed before!



  12. @EsseZeta: If I follow you correctly, you’re finding a problem when clicking the close button on the Shadowbox? It is expected functionality that the Shadowbox therefore closes and you are ‘directed’ to the original gallery page. Perhaps I’m misunderstanding the difference between the “start” and “gallery” pages?

  13. think to this page…
    this is the article page (start page)

    i click on the link to you demo-page (gallery page)

    then click 3th image

    then if you close image whit X-icon i find gallery page…
    of course… if i would come back to this page (article page) i try use BACK on browser… but i come back to the 3th image…

  14. @EsseZeta: That’s actually an expected result. Viewing each image is to be thought of as a page view, so technically hitting back should bring you back to the 3rd image. This is of course not a hard requirement. In fact I took the time to hook the Shadowbox close event to add the page to the history for the sake of the example. That step can be omitted at any time. Sorry for my misunderstanding, and thank you for bringing up the issue!

  15. Great article and decent solution. I’d also like to throw this notion out there for discussion: it might be beneficial if the back button would evolve a little.

    This discussion parallels ones about ADA compliance and accessibility. Like the back button, screen readers still utilize basic web 1.0 methods to interpret content.

    The existence of this post and discussions such as these indicates that designer and developers would like a little extra control (native, not workaround) to provide a better experience for users.

  16. “lightbox” is the new modal dialogbox. read jef raskin book and see why this is a bad idea right from start. don’t try to fix it, just don’t use it.

  17. It looks as if SWFAddress is already catching any presses of the Back button and doing the appropriate fade in/out, so what about calling “history.back()” when the user clicks the close button? That would solve the problem of history accretion.

  18. I haven’t tried the plug yet but it looks very nice!

    I can think of a few sites I can use something like this on.


  19. Hi, I’d love to look at your example code, but its giving a 403 Forbidden. Is there anyway you could bring it back to life?

  20. Hi there! This is exactly what I’m looking for, this is the only article I’ve found that discusses swfaddress AND lightbox… but I can’t get into the sample either, is there any chance you could bring it back?

Leave a Reply

Your email address will not be published. Required fields are marked *