buckyschwarz.net

Should links open in new windows?

Smashing Magazine answered that question succinctly and correctly (back in July of 2008, I might add): No. They shouldn’t. It’s as simple as that*. You should let your uses decide how to handle their links. When you force users to open a link in a new window against their will, it destroys their web experience for a few reasons:

• It removes control from the user in favor of control of the developer, and users should always be in control of their experience
• It forces the user to use the site in a way you’re dictating, which is usually not the way the user wants to use the site
• It removes use of the back button, an integral part of the web experience, even today with all of our AJAXy goodness
• To novice users, it’s confusing: where did my back button go, what just happened?
• To experienced users, it’s downright enraging: thank you, I know how to open links in a new tab or window, I don’t need your help telling me how to browse the web. In fact, I’m going to close your stupid site right now, just to spite you and your stupid ideas.
  
• It doesn’t do what it’s supposed to (keep users on your site): If a user wants to leave, opening a link in a new window won’t get them to stay. Giving them what they want (good content, good user experience) will, however.
• It destroys the very thin veneer that we’re in control of at least something in our existence, often leading to very severe existential crises in which a person’s entire reality might be shattered, leading to unintended consequences including but not limited to: psychosis, rage, murderous rampages, and losing touch with reality

*Of course, there are caveats. I would say that you should force the link to open in a new window or tab only when opening the link in the current window will interrupt the flow of the user experience. What does that even mean? I don’t know. Nah, but seriously, for example: let’s say a user is using your site to buy a vintage harpsichord, and he’s on the last step of the buying process: checking out. He’s found the perfect harpsichord to put in his basement, he’s entered his shipping and payment information, but he has a question about shipping. So he clicks the link that looks like it can answer his questions, and he’s taken away from his shopping cart. Crap, he’s thinking, now what? Do I have to re enter all my information? Do I have to start the whole process over? This is a perfect opportunity to open the link in a new, small window positioned right next to the link.

Smashing and webcredible provide a good cross section of times when you should open links in a new window:

• The link provides assistance, as in the example above
• The link will interrupt an ongoing process, again, see example above
• The link leads to a non-html document, like a PDF, mp3, or movie file
• The link leads to content that will take a long time to load, like a large image, or javascript heavy web page
• The link leads to a printable version of the current web page, although this can be mitigated by using a print stylesheet

Keep in mind however, that even if you do have a situation where it is appropriate to open a link in a new window, you should always inform the user that the link opens in a new window, either via the title attribute of the anchor element, or by specifying in the link text that the link opens in a new window. Similarly, if you’re in a situation where you’re forced to open links in a new window, like say if you work under someone who is convinced he is a usability expert and also makes the decisions and one of those decisions is deciding that all outgoing links will open in a new window, you should try as hard as you can to inform the users that their usability experience is about to be disrupted.

Remember: it’s not 1999, web usability has grown by leaps and bounds over the past decade, and one of the things we’ve learned is that you should trust the user to be in control of their user experience.

At work, I’ve been working with a user who needs a few certain pages on the site I’m developing to be printer friendly. These pages are usually ones that display data in tables with a dark blue/light blue zebra stripes. All the pages of the application (these table pages included) have a two-column fluid layout with the site navigation occupying the left column. Obviously, for printing tabular data, the navigation need not be displayed, nor do any kind of form controls that might be used for searching for particular data in that table, so obviously, those should be disabled in the print stylesheet.

So, for the first time ever, I wrote up a stylesheet with the media type set to print. I’ve just never needed to print anything from a website before. So I wrote up a stylesheet with the media type set to print. I just set the display properties of elements I didn’t want to show to none and went about testing it. During testing, I kept running into a problem where the left column, which should have been hidden, would still be causing the center content column to float right. The navigation menu wouldn’t be there, but the container the navigation menu lived in was still there, even though its border and content were hidden. This stumped me for a good day and a half, and after hitting my head against my cubicle wall I finally decided to try setting the media type of the main stylesheet of the app to screen. This solved every problem I had and now the tables are printing beautifully.

The moral of the story: Always set the media types of your stylesheets. It’s a good idea and a good way to add semantic meaning to your header files, and also, all the cool kids are doing it these days.

I ran into an issue with Safari and jQuery 1.3 today that had me stumped. To keep things unobtrusive for the folks on the web who don’t have JavaScript enabled (and to keep current with good practices since no one except my girlfriend visits my site), I had a form which wasn’t needed if JavaScript was disabled hidden using the display: none property in the site’s main stylesheet. In the $(document).ready() handler for jQuery, I set the form to be visible using the show() method (which, to my understanding, set the display: property to block).

This worked fine every time in Firefox 3 and IE7, but in Safari, I noticed some strange behavior: Occasionally it would work like expected, but most of the time the form would stay hidden. It seemed the only times it did work were when the actual page load took longer to load than the stylesheets and scripts.

The following image shows the Safari Web Inspector when the strange behavior was occurring:

This image shows the Web Inspector when the normal behavior was occurring:

In all of the cases where the page behaved as expected, the page would finish loading after the stylesheets and scripts. I’m not really sure what this means, but it seemed like when the strange behavior was happening, the page would load, jQuery would show the form, and then the stylesheet would load and hide the form. I spent several hours searching for an answer to no avail.

The fix came when I changed the jQuery code. Instead of using the show() method, I used the css() method to change the css property, display: block. This fixed the problem in Safari, and did not introduce any strange behaviors in Firefox or IE7.