Despite how much people don’t want it to be true, using target="_blank" when coding pages is becoming less and less of an accepted practice.  But don’t take my word for it.  There’s a reason that strict (X)HTML has dropped the target attribute from valid specs, and really, it’s a good one:  designers/coders should not be making decisions for the user as to how a page opens.  We might not like it, we might not agree with it, but in the end we should cede behavioral attributes to the user, who should be able to control their own experience.  There’s no good reason not to let them, too.  The marketing side of the argument is that you want to keep people on your site rather than send them away, and many times this is a harmless inference, but in the end if a user no longer wants to be on your site, they will leave whether or not you’re directing their links into a new window.  Additionally, it is suggested that lay users find new windows opening to be confusing, frustrating, and an annoyance when it breaks accepted navigation, such as a browser’s back button (discussed in both Jakob Nielsen and Johan Petersson’s articles linked above).

I’m a code-nazi, and I admit that.  Generally, if I can’t code it to strict standards, then I don’t code it.  But until recently, the target attribute has been a fuzzy area for me, where I had a habit of fudging for the sake of what I thought was appropriate behavior.  After some soul searching though, I have decided to not only drop it from personal usage, but also adapt a new way of using it on our college’s web site.  With the technology and code we have at our disposal as designers and developers, there’s little excuse as to why we shouldn’t give users the control over how the site works for them.  Let them do what they want, and help make their experience the best you can.  That is how you make a positive impact, and leave them wanting to come back again.  If you feel like you need to force a user to stay on your site for some reason, maybe you need to look at what’s wrong with your site that makes it a destination that isn’t compelling enough to attract and retain visitors on its own.

Problem: Remove a web site’s reliance on the target attribute while giving the visitor a way to persistently customize their ability to interact with links leading off of your web site.
Solution: Create non-targeted links that are progressively enhanced to allow the user to set options for opening external links in new windows through an options modal.

So, what can we do about this?  Better yet, what should we do about this?  There is one argument in particular, that trying to give users control at the web page level is redundant and duplicates existing functionality.  I respectfully disagree.  First, in my experience, lay users rarely know the shortcut to opening links in new tabs/windows.  Secondly, there is value to letting a user control their experience on your web site.  It allows them to impart a consistent, pleasant user experience across the board, and lets them do things like override content contributors who might not subscribe to my or your critical sensibilities on the matter of the target attribute.  When you have a hundred different people doing God knows what with content and code as they build your college’s web site, any opportunity to normalize the experience is something you should take.  And lastly, sure, I’ll admit that it might be a tadredundant, but it’s cool, it’s useful, and it barely takes any time to implement.  The key is that web sites no longer exist in a static shell, and by giving users control, you are acknowledging them as an audience, and showing value to their opinion as to how things should work.  You’re saying “Hey, this is how we think stuff should work, but really, you might not like it.  So here’s a way to make it do different stuff.”

There are a lot of folks out there discussing JavaScript alternatives to target="_blank" like using onclick="window.open(this.href);".  I must chastise these people for being so careless that they want to maintain strict code, but also want to ignore the reasoning for not using it.  The fact of the matter is, that kind of solution ignores usercentric design principles in order to keep the target attribute around, without actually using it.  It’s a loophole, not a solution.  And really the only way a user has to control that activity is to disable JavaScript all together.  Not a happy medium.  The first viable option I found was over at Dynamic Drive.  They had a nice script that used cookies to allow a user to select how they want external links handled.   This script works well, and really, there’s nothing wrong with it if you want to play with it.

But, me being me, I wanted to see what I could do on my own.  We are already using jQuery for some progressive enhancement, so I decided to go that route.  And while JavaScript has cookie handling built in, I thought this would be a nice opportunity to try out the cookie plugin, which streamlines the process.  The basic function I was going for was that it would operate such that by default, links going somewhere besides the basic domain open in a new window.  The user can then change this on any page on the site though, by unchecking the option in the footer.  That selection is saved to a cookie for 90 days.  This allows them to decide where they go when clicking external links, and by using jQuery, I can even override the behavior of links precoded with a target attribute.  On top of the cookie plugin, I decided to jump on the SimpleModal plugin too, which you see a screenshot of above, which can allow me to make a nice options interface as we add more user control of the site (think font size, colors, navigation enable/disabling, etc…).  The end goal is a usercentric, flexible design, that puts them in charge over some of the finer behavior of the site.

First, this works great.  Secondly, it’s a nice progressive enhancement, as users without JavaScript enabled just don’t get the option and their overall experience on the site isn’t damaged.  While I’m not going to go over a full howto on setting it up, you can see a demo of this in action, or take a look at it in action at the Pittsburg State University site – scroll to the bottom of the page and click where it says “site options.”  And this doesn’t mean that there aren’t exceptions to this rule, but I find under scrutiny, they are few and far between, there are right ways to handle them, and if you absolutely MUST use them then maybe you need to look at what the data is and how you are handling it to see if maybe there isn’t a more base problem in the user interface or information architecture.