A petition to stop the usage of lightboxes(rohanprabhu.com)
rohanprabhu.com
A petition to stop the usage of lightboxes
http://rohanprabhu.com/?p=161
10 comments
Personally I think they suck for showing zoomed images and image galleries, because they break my expectations about what should happen when I click a link. Even worse, their javascript is often written in a way which clobbers "⌘-click to open in new tab".
Is there any advantage of using a lightbox vs a proper pop-up to present zoomed image or gallery?
I, for one, much prefer the latter. You can continue with reading the article, you can use all the window management you already know and you don't have to suffer the horrible effects that author of the lightbox library though you can't live without. Not to mention that on netbooks, because lightboxes are always contained within the size of your browser viewport, the "zoomed" content is often smaller than miniature on the site.
I, for one, much prefer the latter. You can continue with reading the article, you can use all the window management you already know and you don't have to suffer the horrible effects that author of the lightbox library though you can't live without. Not to mention that on netbooks, because lightboxes are always contained within the size of your browser viewport, the "zoomed" content is often smaller than miniature on the site.
A lot of people don't like popup windows, due to the their abuse years back. That also led to browsers and security software blocking them a lot of the time.
They're blocked automatically when untrusted application tries to open them not in direct response to user interaction. If you open one from <a> tag, I don't think any browser will try to block that.
Schlonky security software and 'popup blocker' add-ons might, though.
But then you're worrying about users that deliberately decided to block all pop-us.
It's exactly the same as with nojs users—if they can block, they can unblock it. Especially if they expect a pop-up to appear, because they've just clicked on a miniature.
It's exactly the same as with nojs users—if they can block, they can unblock it. Especially if they expect a pop-up to appear, because they've just clicked on a miniature.
Well, not really... I get support requests/error reports from users all the time who are running stuff like this, and couldn't click their way out of a paper bag. They have no idea that they are running software which interferes with websites working the way the author intended.
Thankfully, it seems that makers of security and antivirus software are changing their products to not restrict JavaScript and browser functions.
Thankfully, it seems that makers of security and antivirus software are changing their products to not restrict JavaScript and browser functions.
Lightboxes are a very effective tool for FORCIBLY FOCUSING YOUR ATTENTION RIGHT HERE RIGHT NOW. What do most commercial websites want to forcibly focus your attention on right here right now? Yeah. Adverts.
It's an arms race. Advertisers will always use the most in-your-face tool available. First it was banner ads, before Javascript and pop-ups became common. Banner blockers appeared. Then it was pop-ups, until the broader community and browser vendors decided that the S/N ratio for pop-ups was so low that we were better off killing them entirely. Then it was Flash, with the added benefit of literal noise... and now Flash-blocking is an essential component of any browser. The current advertising tool of choice is lightboxes and other floating divs: harder to automatically distinguish from actual desired content within HTML, but we're starting to see browser addons and tools that can do that blocking job too.
Currently gaining in popularity is requiring that an advertisement appear and be experienced in its entirety before any access to content at all. Hulu led the way on this. Well, unless you count television and radio which discovered that format about sixty or ninety years ago. The market response was the VCR then DVR once the technology was feasible. Next move: a "web DVR" that will experience the ads for you and "record" the web site until it can be played back without the interruption?
It's an arms race. Advertisers will always use the most in-your-face tool available. First it was banner ads, before Javascript and pop-ups became common. Banner blockers appeared. Then it was pop-ups, until the broader community and browser vendors decided that the S/N ratio for pop-ups was so low that we were better off killing them entirely. Then it was Flash, with the added benefit of literal noise... and now Flash-blocking is an essential component of any browser. The current advertising tool of choice is lightboxes and other floating divs: harder to automatically distinguish from actual desired content within HTML, but we're starting to see browser addons and tools that can do that blocking job too.
Currently gaining in popularity is requiring that an advertisement appear and be experienced in its entirety before any access to content at all. Hulu led the way on this. Well, unless you count television and radio which discovered that format about sixty or ninety years ago. The market response was the VCR then DVR once the technology was feasible. Next move: a "web DVR" that will experience the ads for you and "record" the web site until it can be played back without the interruption?
My biggest gripe with web browsers today is middle-click hijack. If I left-click on a link/picture, fine, you can do whatever you want. Fancy javascript, lightboxes, the whole jazz. But if I middle-click that same link, by god it better be opening in a new tab in the background. No exceptions.
I prefer lightbox implementations that extend a standard hyperlink to the enlarged image. If you middle-click, ctrl-click, etc, your browser grabs the URL from href and opens it in a new tab/window. The script is initiated by an event attached using a framework like jQuery, which uses a DOM query to locate links with a specific class. This has the additional upside of working as expected for users with JavaScript disabled. The implementations that fail miserably either use 'javascript:methodCall()' inside href, or have a kludgy onclick implementation.
Built properly, a lightbox shouldn't get in the way of your desired behavior.
Built properly, a lightbox shouldn't get in the way of your desired behavior.
Chromium bug for "Middle Click with named Target opening in foreground"
http://code.google.com/p/chromium/issues/detail?id=62319
My main problem with lightbox is when viewed on mobile devices and pages that don't allow you to zoom.
I really don't get why mobile Safari can be set to not allow zooming on a web page.
Who benefits from that option existing?
Who benefits from that option existing?
Happens in Android browser, too. Whose bright idea was it that I didn't need to be able to read my phone without holding to my face, or stretch the screen so I can hit that tiny checkbox?
I have to admit, lightboxes have been very prevalent lately and I'm getting sick of them. Signed.
Sounds like a petition for the appropriate usage of lightboxes. That's something I definitely agree with.
It's similar to the old problems with modal dialogs in desktop applications. Basically: don't use a modal dialog unless your situation absolutely requires it.
It's similar to the old problems with modal dialogs in desktop applications. Basically: don't use a modal dialog unless your situation absolutely requires it.
What would be the appropriate usage of lightboxes? I really can't think of any besides the Facebook's "Before you submit."
On the web, they seem to work pretty well for image galleries. Although I think it's important that you can dismiss the lightbox by simply clicking anywhere outside the image.
In general, modal dialogs are suitable for operations where it helps to have contextual information in the background, but you don't need to interact with it. A 'Save' dialog is a common example.
This thread on UX exchange has some more thoughts and examples:
http://uxexchange.com/questions/1153/when-should-you-use-a-m...
In general, modal dialogs are suitable for operations where it helps to have contextual information in the background, but you don't need to interact with it. A 'Save' dialog is a common example.
This thread on UX exchange has some more thoughts and examples:
http://uxexchange.com/questions/1153/when-should-you-use-a-m...
here's a link:
http://viewtext.org/article?url=http://rohanprabhu.com/?p=16...
...looks like the site is struggling to serve requests right now
http://viewtext.org/article?url=http://rohanprabhu.com/?p=16...
...looks like the site is struggling to serve requests right now
Or use the Coral CDN by appending nyud.net to the host:
http://rohanprabhu.com.nyud.net/?p=161
It preserves images better than ViewText does.
http://rohanprabhu.com.nyud.net/?p=161
It preserves images better than ViewText does.
All I get are 408 Time-outs now. As I've mentioned before[1] CoralCDN isn't very good at preserving content that is already down.
If OP knew his hosting wasn't very well suited for handling load spikes HN users can generate, he should have posted the original link behind the cdn.
At this point the only thing OP could do is to create a rule to redirect to .nyud.net link if the referrer equals HN.
[1] http://news.ycombinator.com/item?id=2235559
If OP knew his hosting wasn't very well suited for handling load spikes HN users can generate, he should have posted the original link behind the cdn.
At this point the only thing OP could do is to create a rule to redirect to .nyud.net link if the referrer equals HN.
[1] http://news.ycombinator.com/item?id=2235559
At this point the only thing OP could do is to create a rule to redirect to .nyud.net link if the referrer equals HN.
At this point there might be nothing the OP can do except wait until the initial hump of traffic has died down: ifthe server really is completely bogged down he may not even be able to open SSH session to make any config changes.
For an article like this, that does not need any dynamic content, would be better served by an event based server as these tend to cope better on low-end boxes in the presence high demand for static content than thread or process based servers.
Or, like you say, stick with the current web server setup and post links to high volume sites via a cache like CoralCDN.
At this point there might be nothing the OP can do except wait until the initial hump of traffic has died down: ifthe server really is completely bogged down he may not even be able to open SSH session to make any config changes.
For an article like this, that does not need any dynamic content, would be better served by an event based server as these tend to cope better on low-end boxes in the presence high demand for static content than thread or process based servers.
Or, like you say, stick with the current web server setup and post links to high volume sites via a cache like CoralCDN.
> At this point there might be nothing the OP can do except wait until the initial hump of traffic has died down: ifthe server really is completely bogged down he may not even be able to open SSH session to make any config changes.
I actually did some testing at that moment, before I edited the part you have quoted (I added this later), and I'm confident OP could have probably rescued it if he wanted to.
But I agree, it's pretty much game over because you can't edit the link after you've submitted it. So if you're not prepared to handle dense traffic, it's a good idea to submit coralled link instead or put your website behind CloudFront temporarily.
I actually did some testing at that moment, before I edited the part you have quoted (I added this later), and I'm confident OP could have probably rescued it if he wanted to.
But I agree, it's pretty much game over because you can't edit the link after you've submitted it. So if you're not prepared to handle dense traffic, it's a good idea to submit coralled link instead or put your website behind CloudFront temporarily.
I only cache the HTML, not images. I just don't have enough money for hosting :-p
[deleted]
A big offender on this is actually Reddit. The lightbox that pops up prompting you to log in when you try to vote is broken for smaller screen sizes. Though personally I keep Reddit zoomed significantly, and that makes it even more broken.
The worst part about lightboxes is that when you click the back button like you've been doing for the past 15 years, you get really pissed off.
HTML history pushState should fix that.
Lightboxes are great for showing zoomed images or image galleries. They're not welcome for spammy widgets, signup offers or ads. But then, what format do you prefer for spammy widgets or ads? None obviously, so lightboxes are not the problem.