Reading Common web app usability gotchas? I felt guilty when I read that using a target = "_blank" is a bad thing.

I have developed a small web application that format Stack Exchange questions in a printer-friendly view and I feel there's something broken in the interface about the target = "_blank" navigation experience.

Let me explain:


  1. people could insert a question Id and print it by clicking "print" button
  2. printer-friendly view is opened on the same page
  3. people could return to the homepage clicking a small Home icon on the upper left corner of the page.

I think there's nothing wrong with this (though any feedback is appreciated).

Top Voted

  1. People could browse a list of questions
  2. Clicking a small "printer" icon a printer-friendly view is opened in a new window (target = "_blank")
  3. Focus from the "questions list" page is lost
  4. People should click again on the "questions list" page
  5. People could print another questions from the "questions list" page

Why I did this?

First reason:
Gmail "print" feature works like this (opening a new page)

Second reason:
Because I wanted to give the opportunity to print a bunch of questions at the same time.
With a sequence like print - back to the "questions page" - print - back to the "questions page" - print etc. etc. user could print his\her questions in parallel (print process is not very fast on fat questions like this one).

I think there's something broken because:
1. First case experience is different from the second one
2. Once new "printer-friendly" windows is opened, people has the same "back to home" icon on the upper left corner and I think it could be confusing.[fixed]

Any suggestion?

8 Answers 8


I disagree with the notion that target="_blank" is always bad. In some cases, especially in web applications, it can be very useful, as in the situation you're describing above. (And I've also met a breed of web designers who hate it simply because the latest W3C spec says it's illegal...)

The reason UI designers don't like it is because it takes control away from the user, which is annoying - on websites. That's because you're in control of your browsing experience, and when you're browsing, eg. reading an article, you don't want websites popping up new tabs or windows every time you click on a link. You'll decide that for yourself.

But when you're using a web app, especially these days as web apps get more and more complicated (Gmail is a good example), the user is in a different state of mind and wants convenience centered around use of the web app. I'm not saying target="_blank" is a perfect solution, but it's certainly not as terrible as it's made to sound in the "gotchas" question.

As usual, it comes down to figuring out how your users feel about it. As the designer, you should make decisions based around what you feel is best for your user base, and try not to depend too much on universal "rules" that seem to apply to everything, always. Conventions and patterns are great, but it's important that you keep an open mind and use common sense where appropriate. :)

  • "met a breed of web designers who hate it simply because the latest W3C spec says it's illegal"...uh...they dislike it because JavaScript is the proper methodology rather than abusing an old frames attribute.
    – DA01
    Oct 14, 2010 at 19:12
  • 1
    No, I'm saying they literally hate it "because the spec says it's illegal." Trust me, I talked to these guys ;) Web designers with good reasons (like the one you cited) are fine!
    – Rahul
    Oct 14, 2010 at 20:09
  • I personally dislike links that force a popup, regardless of the technology used. But I'm a power user, and not everyone knows how to use tabs or open links in a new tab/window. Though if you're going to force users to have JavaScript anyway, it's better to just load your app dialogs in an AJAX popup than a popup window. The W3C specs are right; window behavior should be controlled by the browser--and they are. If you need the parent window to be visible behind your new dialog, then you need to do it via an AJAX dialog. Otherwise, some browsers will open a tab instead. Nov 10, 2010 at 1:34

This is not directly related to your question, but here goes... One thing that has always bugged me with "Print" buttons is that you never know if clicking on it will actually print or whether it's going to show you a printer friendly layout. I've seen only one or two web site that have labeled their button "Show Printer Friendly Page" (or something like that).

  • "printer friendly page" links are what I would do also.
    – Ape-inago
    Dec 2, 2010 at 8:46

I disagree with the need to have a printer friendly button open a different page at all. Using CSS you can hide all the things you don't want to print and make whatever changes are desired. Therefor almost every page can be printer friendly by default. The only real exception is paginated lists where you want to print the full list.


I think even when using css to make pages printer friendly you should still have a Print button on the page but all it should do is call the browser's print functionality directly. The point of this is that most users aren't accustomed to the browser's print functionality working really well and a Print button on the page providing cleaner output.

  • 2
    I suppose you've never tried to print a Stack Exchange question with 560 answers and hundreds of comments. Oct 14, 2010 at 18:56
  • 2
    @systempuntoout, And how would a print button there help? The browser's own ability to provide the user a UI to print the first page or first 2 or first 10 is best.
    – Sam
    Oct 18, 2010 at 13:01
  • I used this to great effect with my resume.
    – Ape-inago
    Dec 2, 2010 at 8:46

I can't agree more with Rahul, especially on the last paragraph. Dan Saffer in his book "Designing for Interaction" calls this Genius Design where designers use their best judgment as to what users want and then design based on that judgment.


I think that users should have a preview of what will actually come out of their printer. This might be less needed in case of a "print this article" button and the transformed page in this case might also be directly transferred to the printer if possible.

About opening a new window I think a modal window (a la safari reader) is always the best choice, because it focuses the attention of the user on the window itself and is very easy to see how to close it, and that by closing it the user will return to the previous state of the application (the dimmed page in the background), also if the data is updated in realtime it would be clear,given that it is shown somewhere in the ui, what update of the page is actually being printed.

Anyway it's not easy to find optimal solutions for this particular kind of problem.


Purely my opinion not backed up with any specific research:

"Print Friendly" is preferred over "Print" for a number of reasons:

  • as already stated, one doesn't know what a 'print' link will do…will it open a new window? Show me a print friendly page? Launch my browser's print dialogue?
  • a 'Print Friendly' option is often very useful for on-screen reading. It serves a purpose beyond the printer.
  • You ensure people will have an expectation of what will be printed before they hit print (do all people know that they can see a print-preview via their browser's print dialogue?)

As such, I prefer to have both a proper print CSS file as well as a 'print friendly' link.

As for whether it should open in a new window or not…that's a tough one. New windows still introduce usability and accessibility issues. I'd lean towards loading it in the same page with some sort of obvious 'return to web version' link.


Printer friendly never is. I don't know why it has to be that way.

What you can do is render the page on the server with wkhtmltopdf (using your own stylesheets, preferred fonts and SVG images as required for hi-res logos) and then serve that with the print dialog box - no preview nonsense, just PDF straight to the printer, no _blank or anything like that. In this way you can control your page layout and get it to 'catalogue' standards, and save your user the extra step of having to hit the print button.

Let your print button 'do what it says on the tin'.


Am I misunderstanding you, or are you making your users go back and forth each time they want to add a question to a single print command? If so, you should really think of a better way to accomplish that. Something like an "Add to Print List" button that stores a list of question ids, and formats everything up for the end user when they click "Print My List of Questions". Going back and forth between screens like that would be very frustrating to me.

Sorry if I misunderstood what you are saying there.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.