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.
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.
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.
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:
Sounds like he wishes to stop the abuse of lightboxes.
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.
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.
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.
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.
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.
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?
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?
img tag, optionally wrapped by an anchor tag pointing at a larger version. simple and working just fine since the early 90's i think. "if ain't broke, don't fix it!"
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.
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.
32 comments
[ 3.8 ms ] story [ 78.2 ms ] threadhttp://viewtext.org/article?url=http://rohanprabhu.com/?p=16...
...looks like the site is struggling to serve requests right now
http://rohanprabhu.com.nyud.net/?p=161
It preserves images better than ViewText does.
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 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.
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.
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.
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...
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.
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.
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.
Thankfully, it seems that makers of security and antivirus software are changing their products to not restrict JavaScript and browser functions.
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?
Who benefits from that option existing?
Built properly, a lightbox shouldn't get in the way of your desired behavior.